Terminal Services roaming profiles & password change at logon
NOTE: The issue described below has been subsequently fixed in KB971388 for Windows Server 2008 SP2 (x86 and x64) and Windows Server 2008 R2. The blog entry has been left for reference.
“If I am forced to change my password at logon, then log onto a Terminal Server, I lose all my settings.”
This is something that has cropped up for a number of customers, depending on their configuration, so here I will try to outline the settings that impact this and the reason behind what is going on…
On every user object in Active Directory there is a path that specifies where a central copy of a user profile is held that is to be used when logging onto a Terminal Server.
Terminal Services Profile tab > “Profile Path”
In a normal scenario, where a user logs onto a Terminal Server with the above property set, the following occurs:
1. Windows checks the path specified for a folder named %USERNAME% or %USERNAME%.V2
(%USERNAME% is a variable holding the logon name of the user, e.g. testuser1, not their display name, e.g. “Test User 1”)
2a. If the above path is not found (i.e. first logon), the default user profile is copied to %USERPROFILE%
(%USERPROFILE% is a variable holding the path to local copy of the user’s profile, e.g. C:\Users\testuser1)
2b. If the path is found and the user has permission to access it, then it is reconciled with %USERPROFILE% instead
When the user later logs off, the profile is reconciled back to the central location – so that on the next logon, wherever it is, the user will have all the changes they made to their profile.
“Reconcile” in this context means to copy up the changed contents only, not the entire profile, so that the operation is quicker.
Also on each user object in AD there is a flag that indicates the user must change their password at the next logon, this is most commonly used at user creation or if a helpdesk does a password reset because the user forgot it.
Account tab > “User must change password at next logon”
When a user authenticates to Windows, the above flag is checked to see if they must change their password before their profile is reconciled – but the process needs to have a profile as it is running in the context of the user, so if there is no local copy of the profile for the user, the local default user profile is copied to create it.
Here is the problem – if the user does have a Terminal Services profile specified on their AD user object, following the password change it will be checked to see if it is older or newer than the copy we have locally.
As we just created the profile, it is newer than the timestamp on the central copy and so it is not reconciled – so the user sees that they have none of their personalized settings and may go through the “first run” wizards when launching Internet Explorer or Outlook.
Given the normal sequence of events, if there is no local copy of the user profile and they have not got a roaming profile yet, this causes no problem – this is the user’s first logon, so it is perfectly fine to have everything “out of the box”.
There is a policy setting which can remove a locally cached copy of roaming profiles when the user logs off, to avoid wasting disk space:
Computer Configuration > Policies > Administrative Templates > System > User Profiles > “Delete cached copies of roaming profiles”
If the above policy is enabled on the Terminal Server, every logon for the users with roaming profile has to go through a full reconciliation – so the user is basically guaranteed to hit the problem when forced to change their password during logon.
And worse, when the user logs off their profile is reconciled back to the roaming location is it is considered updated.
So how to avoid this problem?
Instead of specifying the unique Terminal Server profile paths on a per-user basis, there is a policy which can be applied to the Terminal Servers which specifies a UNC path where all of the users’ roaming profiles are held:
Computer Configuration > Policies > Administrative Templates > System > User Profiles > “Set roaming profile path for all users logging onto this computer”
So as an example, if the Terminal Services Profile Path for AD user object testuser1 was set to “ \\server1\roaming\testuser1”, the equivalent policy path would be “ \\server1\roaming\%username% ”.
As the same path can be specified in multiple locations, and Windows will use the first one it finds, it is important that the ones before this (1 and 2 below) setting are not defined.
Here is the order in which the path for a valid user profile is checked by Terminal Services:
1. GPO : Computer Configuration > Policies > Administrative Templates > Windows Components > Terminal Services > Terminal Server > Profiles > “Set path for TS Roaming User Profile”
2. AD user object : Terminal Services Profile tab > “Profile Path”
3. GPO : Computer Configuration > Policies > Administrative Templates > System > User Profiles > “Set roaming profile path for all users logging onto this computer”
4. AD user object : Profile tab > “Profile path”
A partial alternative solution to the problem is to not use the “Delete cached copies of roaming profiles” policy setting – then the problem only has a chance to occur if the user is logging onto a server for the first time.
If the disk space used by accumulating profiles is of a concern, there is another policy which is fairly self-explanatory:
Computer Configuration > Policies > Administrative Templates > System > User Profiles > “Delete user profiles older than a specified number of days on system restart”