Migrated users missing desktop wallpaper and pinned taskbar items.
-
26 aprilie 2012 16:30
I'm in the middle of testing an upcoming domain consolidation using ADMT 3.2. Source DC is running 2008, Target DC running 2008 R2. We are using both roaming profiles and folder redirection.
I've set the GPO on the target to point at the source DC for folder redirection still. Once the migration's done, I'll use the GPOs again to move them to their new home. I'm also leaving the roaming profiles where they are.
After running the user migration wizard and security translation wizard, the test user is able to log into their account on the target domain & their redirected folders are still populated. I didn't receive any errors about the roaming profiles being unavailable, but the desktop is black and every icon that was pinned to the taskbar is blank & don't function. Copying the roaming profile to the target DC and pointing the user's AD account at it have the same result. I've set the permissions according to what I've found on Technet: http://technet.microsoft.com/en-us/library/cc757013(v=ws.10).aspx
Anyone have any idea what that's happening?
Toate mesajele
-
27 aprilie 2012 10:08Moderator
Hi,
Please preparing for migration of roaming profiles with computers that run Windows Vista and Windows 7
A roaming profile location is configured for a domain user account, and specified in the following way:
\\host.name.fqdn\ProfileShare\<profilename>
Typically <profilename> is replaced with %username%. Thus the actual location of a roaming profile for user RoamUserX is:
\\host.name.fqdn\ProfileShare\RoamUserX
The roaming profile folder (in this example, RoamUserX) is created at the time of first logon for RoamUserX, and the actual profile data is stored within that folder.
In Windows Vista, a change was made to profiles that made them incompatible with previous versions of Windows. To differentiate the new profiles, a .V2 extension was added to all roaming profiles for users on computers running Windows Vista and later.
The location of a roaming profile for the same user RoamUserX for a computer that runs Windows Vista or Windows 7 is:
\\host.name.fqdn\ProfileShare\RoamUserX.V2
This version can co-exist with a roaming profile for an earlier version of Windows.
Only ADMT v3.2 distinguishes the two different profile folder names. Earlier versions of ADMT only look for the folder called <profilename> and do not try to locate a V2 profile if it exists. Therefore, earlier versions of ADMT do not migrate roaming profiles for computers running Windows Vista and Windows 7.
In order to migrate a roaming profile folder using ADMT v3.2, the default access control list of the folder needs to be modified. By default, when a user logs on and the roaming profile folder and contents are created, the <profilename> or <profilename>.V2 folders are given the following ACLs:
• SYSTEM – Full Control
• user_name - Full Control
• Owner = user_name
Therefore, only the owner of the profile, and the local system on which the share resides, are able to access the <profilename> or <profilename>.V2 folder. When the folder is assigned those default permissions, ADMT cannot access the folder for security translation.
To configure the folder permissions in order to allow ADMT v3.2 to migrate the roaming profile, you can enable a Group Policy setting for the domain. In Windows Server 2008 R2, the setting is:
Computer Configuration\Policies\Administrative Templates\System\User Profiles\Add the Administrators security group to the roaming user profiles
If this setting enabled and propagated before the first logon of the user (before the roaming profile is created), then the roaming profile directory will have an added permission that grants Full Control to members of the Administrators group of the share host (host.name.fqdn in this example).
After this setting is enabled, migrations can be performed as long as the user who runs ADMT v3.2 is included in the Administrators group of the share.
The user who runs ADMT user needs Full Control access on the roaming profile folders. To achieve that, you can try one of the following options:
1.
2. Create a script (for example, using Windows PowerShell) that performs that following:
a. Executes as SYSTEM on the share machine (host.name.fqdn in the example)
b. Adds the Administrators security group to the ACL set of the profile folders – propagating to all subfolders and files
c. Adds the Administrators security group with Full Control to the ACL set of the profile folders and have the permission inherited to all subfolders and files.
3. Create a script (for example, using Windows PowerShell) that performs that following:
a. Runs in the context of each roaming user (for example, as a logon task).
b. Adds the Administrators security group with Full Control to the ACL set of the profile folders and have the permission inherited to all subfolders and files.
In addition, there is a link for your reference:
Troubleshooting Security Translation Issues
http://technet.microsoft.com/en-us/library/cc974399(v=WS.10).aspx
The "Desktop Wallpaper" Group Policy setting is not applied in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/977944
Hope this helps!
Best Regards
Elytis Cheng
Elytis Cheng
TechNet Community Support
- Editat de Elytis ChengModerator 27 aprilie 2012 10:16
- Marcat ca răspuns de Carl Marshall 29 august 2012 17:51
-
27 aprilie 2012 12:16
Thanks for the reply.
I've checked the security settings on both the roaming profile and folder redirects to ensure the user account I'm using for ADMT does have full access to both. Maybe I'm not 100% on how the roaming profile is supposed to be migrated.
Right now, the account that's being migrated still has their profile pointed at the previous location. ADMT changes the user rights on the profile itself to reflect the new owner being the migrated account. I run the security translation wizard and the permissions on the folder redirects are updated properly as well.
In short, the profile for the user is pointing at the correct location, the permissions are correct, but the profile isn't being applied correctly in the new domain.
.png)
