Roaming Profile / Folder Redirection Conflict

Has anyone experienced an issue where roaming profiles spontaneously start
using folder redirection? See details below.

Issue:
Roaming profile fails to update on profile server. Upon investigation, App
Data, MyDocs, and Desktop point directly to profile server when the folders
should be on local workstation.

Environment:
- Windows 2003 Active Directory environment configured with roaming
profiles.
- Citrix environment used for remote access.
- Citrix profile loads via Group Policy configuring folder redirection for
App Data, MyDocs, and Desktop where source is the roaming profile server.

Somehow, the configuration for roaming profiles and folder redirection is
conflicting, but I can't figure out why. Any help is appreciated.

thanks.

"aubienat" <aubienat@discussions.microsoft.com> wrote in message
news:193A3386-489A-4D41-BB00-EC254ABA1822@microsoft.com...
> Has anyone experienced an issue where roaming profiles spontaneously start
> using folder redirection? See details below.
>
> Issue:
> Roaming profile fails to update on profile server. Upon investigation,
> App
> Data, MyDocs, and Desktop point directly to profile server when the
> folders
> should be on local workstation.
>
> Environment:
> - Windows 2003 Active Directory environment configured with roaming
> profiles.
> - Citrix environment used for remote access.
> - Citrix profile loads via Group Policy configuring folder redirection for
> App Data, MyDocs, and Desktop where source is the roaming profile server.
>
> Somehow, the configuration for roaming profiles and folder redirection is
> conflicting, but I can't figure out why. Any help is appreciated.

Roaming profiles USUALLY come from the GPOs. Have you done a
GPResult (/v == verbose) or an RSoP (logging mode) so see what is
happening and if the GPOs are supplying any Folder Redirection?

aubienat <aubienat@discussions.microsoft.com> wrote:
> Has anyone experienced an issue where roaming profiles spontaneously
> start using folder redirection?

Nope. They're apples-->oranges - they aren't controlled or managed in the
same place. Roaming profiles are set in each user's ADUC properties. Folder
redirection is managed by GPO.

> See details below.
>
> Issue:
> Roaming profile fails to update on profile server. Upon
> investigation, App Data, MyDocs, and Desktop point directly to
> profile server when the folders should be on local workstation.

Well - IMO, if you're smart you'll redirect all three of them. It's helpful
when you don't use roaming profiles, but I'd say it's mandatory if you
*do* - large profiles cause tons of problems.

That said, running rsop.msc and/or gpresult should help you identify which
policy is doing it. However, read on.....
>
> Environment:
> - Windows 2003 Active Directory environment configured with roaming
> profiles.
> - Citrix environment used for remote access.

OK - this seems to be related. Do you *also* have a TSProfile path set up
per user? It mustn't match your roaming profile path - e.g., if you use
\\server\profiles$ for one, you would use \\server\tsprofiles$ for the
other. The latter can be configured automatically via GPO if you've got your
OUs & policies set up properly with loopback processing. The folder
redirection should also be configured in your TS GPO (can match the same
paths you use in your non-TS GPO which your regular desktop users access.

> - Citrix profile loads via Group Policy configuring folder
> redirection for App Data, MyDocs, and Desktop where source is the
> roaming profile server.

What path? Folder redirection must go elsewhere - not to the same place as a
profile. That would somewhat defeat the purpose!
>
> Somehow, the configuration for roaming profiles and folder
> redirection is conflicting, but I can't figure out why. Any help is
> appreciated.
>
> thanks.

My boilerplate on profiles follows.....

********************
General tips:

1. Set up a share on the server. For example - d:\profiles, shared as
profiles$ to make it hidden from browsing. Make sure this share is *not* set
to allow offline files/caching! (that's on by default - disable it)

2. Make sure the share permissions on profiles$ indicate everyone=full
control. Set the NTFS security to administrators, system, and users=full
control.

3. In the users' ADUC properties, specify \\server\profiles$\%username% in
the profiles field

4. Have each user log into the domain once - if this is an existing user
with a profile you wish to keep, have them log in at their usual
workstationand log out. The profile is now roaming.

5. If you want the administrators group to automatically have permissions to
the profiles folders, you'll need to make the appropriate change in group
policy. Look in computer configuration/administrative templates/system/user
profiles - there's an option to add administrators group to the roaming
profiles permissions. Do this *before* the users' roaming profile folders
are created - it isn't retroactive.

********************
Notes:

Make sure users understand that they should not log into multiple computers
at the same time when they have roaming profiles (unless you make the
profiles mandatory by renaming ntuser.dat to ntuser.man so they can't change
them, which has major disadvantages),. Explain that the 'last one out wins'
when it comes to uploading the final, changed copy of the profile. If you
want to restrict multiple simultaneous network logins, look at LimitLogon
(too much overhead for me), or this:
http://www.jsifaq.com/SF/Tips/Tip.aspx?id=8768

********************
Keep your profiles TINY. Via group policy, you should be redirecting My
Documents (at the very least) - to a subfolder of the user's home directory
or user folder. Also consider redirecting Desktop & Application Data
similarly..... so the user will end up with:

\\server\users\%username%\My Documents,
\\server\users\%username%\Desktop,
\\server\users\%username%\Application Data.

[Alternatively, just manually re-target My Documents to
\\server\users\%username% (this is not optimal, however!)]

You should use folder redirection even without roaming profiles, but it's
especially critical if you *are* using them.

If you aren't going to also redirect the desktop using policies, tell users
that they are not to store any files on the desktop or you will beat them
with a
stick. Big profile=slow login/logout, and possible profile corruption.

********************
Note that user profiles are not compatible between different OS versions,
even between W2k/XP. Keep all your computers. Keep your workstations as
identical as possible - meaning, OS version is the same, SP level is the
same, app load is (as much as possible) the same.

*********************
If you also have Terminal Services users, make sure you set up a different
TS profile path for them in their ADUC properties - e.g.,
\\server\tsprofiles$\%username%

********************
Do not let people store any data locally - all data belongs on the server.

********************
The User Profile Hive Cleanup Utility should be running on all your
computers. You can download it here:
http://www.microsoft.com/downloads/d...displaylang=en

********************
Roaming profile & folder redirection article -
http://www.windowsnetworking.com/art...rver-2003.html

Thanks for the replies.

Your explanation of Roaming Profiles and Folder Redirection is exactly how
the environment is configured. Sorry if my explanation earlier was not clear.

Roaming profile server = \\fileserver\profiles$\%username%
TS server = \\tsserver\tsroaming$\%username%
ADUC properties used for this config

Folder Redirection config for TS server (via GPO only applicable to TS server)
- source is \\fileserver\profiles$
- AppData, MyDocs, Desktop redirected from source to \\tsserver\tsroaming$

This issue only happens for a small percentage, less than 5%, of the
environment. Majority of profiles work successfully with regards to roaming
and folder redirection to the TS server.

I did discover today that recreating both local and server copies of the
profile resolved the problem. I was able to narrow down the failure to the
ntuser.dat file. I still don't know why this is happening, though. Is there
a way to open up the ntuser.dat file?

Additionally, I did a gpresult, but did not return anything useful.

thanks again for the help.

aubienat <aubienat@discussions.microsoft.com> wrote:
> Thanks for the replies.
>
> Your explanation of Roaming Profiles and Folder Redirection is
> exactly how the environment is configured. Sorry if my explanation
> earlier was not clear.
>
> Roaming profile server = \\fileserver\profiles$\%username%

Cool.....

> TS server = \\tsserver\tsroaming$\%username%
> ADUC properties used for this config

Note that it's really easy to configure that via GPO and ensures that you
don't have to worry about new TS users....and personally, I don't recommend
that you store any data on TS. Setup your TS profile path on your file
servers in the domain. TS should be a simple domain member server - no data
storage, no domain roles, etc.
>
> Folder Redirection config for TS server (via GPO only applicable to
> TS server)

Meaning you enabled loopback processing on that GPO? Folder redirection is a
user thing, not a computer thing. However, I'd use the same redirection
settings for *all* users.

> - source is \\fileserver\profiles$
> - AppData, MyDocs, Desktop redirected from source to
> \\tsserver\tsroaming$

Ah. No. Don't redirect to the *profile* directory. That's a problem! You're
confusing matters. Redirect elsewhere- such as \\fileserver\users\%username%
(and subfolders beneath that.) To the same place, for both your TS users and
your non-TS users,so they get the same data.
>
> This issue only happens for a small percentage, less than 5%, of the
> environment. Majority of profiles work successfully with regards to
> roaming and folder redirection to the TS server.
>
> I did discover today that recreating both local and server copies of
> the profile resolved the problem. I was able to narrow down the
> failure to the ntuser.dat file. I still don't know why this is
> happening, though. Is there a way to open up the ntuser.dat file?

I'm sure there is, but I wouldn't know how, and it isn't relevant....


>
> Additionally, I did a gpresult, but did not return anything useful.

It should tell you what GPOs are being applied, too. However, you can also
check rsop.msc / gpresult & the event logs. However, I think the answer to
your problem lies above....

>
> thanks again for the help.

Thanks for all your suggestions! I'll start testing some changes and will
follow up with questions as needed. And I'm sure questions will arise since
this stuff can get confusing.

aubienat <aubienat@discussions.microsoft.com> wrote:
> Thanks for all your suggestions! I'll start testing some changes and
> will follow up with questions as needed. And I'm sure questions will
> arise since this stuff can get confusing.

Yes indeed :)