locked
Roaming Profiles are loading as Temporary Profiles for some usesr RRS feed

  • Question

  • I have a Windows 2008 Terminal Server that randomly loads temporary profiles for some users, but not all. I have gone through and cleaned out any user profiles on the server that were in question using the User Profile tool under System Properties. I've also deleted all of the corresponding *.bak files in the registry found under: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList] Each time I do that, other users profiles that did not have this issue before start to have Temporary Profiles loaded in place of their Roaming ones.

  • Server OS + SP Version: Windows 2008 Ent. SP1
  • Client OS + SP version: Windows XP SP3
  • Remote Desktop Client version: RDC 6.1

    The following Events are shown in the Event Log:

    Log Name:      Application
    Source:        Microsoft-Windows-User Profiles Service
    Date:          09/29/2010 3:07:55 PM
    Event ID:      1511
    Task Category: None
    Level:         Warning
    Keywords:      Classic
    User:          MAXHEALTH\wischere
    Computer:      termsvr02.maxhealth.com
    Description:
    Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off.

    Log Name:      Application
    Source:        Microsoft-Windows-User Profiles Service
    Date:          09/29/2010 3:07:55 PM
    Event ID:      1515
    Task Category: None
    Level:         Warning
    Keywords:      Classic
    User:          MAXHEALTH\wischere
    Computer:      termsvr02.maxhealth.com
    Description:
    Windows has backed up this user profile. Windows will automatically try to use the backup profile the next time this user logs on.

    Any help is greatly appreciated!

Wednesday, September 29, 2010 8:22 PM

Answers

  • Hi,

     

    To narrow down this issue, Could you help to confirm some questions as below,

     

    1.       How did you set the roaming profile settings for the problematic users?

    2.       Temporarily disable roaming profile for the problematic user and retry to logon RDS via this account, does it work?

    3.       Can the problematic user access the roaming profile folder with full-control permission?

    4.       What’s the OS for the problematic users and what’s the events log on client machine?

    (Refer to http://support.microsoft.com/default.aspx?scid=kb;EN-US;947215 steps to diagnose the profile issues on client)

     

    By the way, I found following conditions may cause roaming profile issue:

     

       • You have a terminal server that is running Windows Server 2008 or Windows Server 2008 R2. 

       • You enable the Delete cache copies of roaming profiles Group Policy setting on the terminal server. 

       • You configure a user account to load a terminal server roaming profile on the terminal server. 

       • The Change password at the next logon option is enabled in the properties of the user account. 

       • You create a terminal server session to the terminal server by using the user account.

     

    This issue occurs because the User Profile service does not load the terminal server roaming profile correctly after the user account password is reset.

     

    When the Delete cache copies of roaming profiles Group Policy setting is enabled, and when a user is prompted to change the user account password, the User Profile service loads a local temporary user profile. The User Profile service loads this user profile to perform the password reset operation. However, the profile changes to a combination of the local temporary profile and of the roaming profile after the user password is reset. Therefore, the terminal server roaming profile is not loaded correctly.

     

    For more information: Please refer to the article as followed:

    http://support.microsoft.com/kb/971338

     

     

    • Proposed as answer by aside Wednesday, October 6, 2010 8:39 PM
    • Marked as answer by Alan Zhu Thursday, October 7, 2010 5:36 AM
    Monday, October 4, 2010 3:01 AM

All replies

  • Do your users log on to a domain sometimes or do you/your team log these users on the domain when troubleshooting issues? Because if you do then that will corrupt the profile. We found that TS will try and log a roaming profile on as a local profile and when the user then logs back on at site they experience temp profile issues. What we do now is either remote to the machine or log on the web access server via its public url over http. Regards Bryan
    TS GURU
    Thursday, September 30, 2010 1:17 PM
  • Hello I have seen similar issues during the past couple of years, what the exact cause is, I haven't quite figured out yet. What I have found out though, is the the users profile path is written to the registry of the terminal server, you can find it here: HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList Just browse through the various SIDs in the list, until you find the user who is logged on with a temp profile, delete the corresponding SID. Try to log the user on again and see if the problem is still present.
    • Proposed as answer by Perforator Tuesday, January 18, 2011 12:55 PM
    Sunday, October 3, 2010 5:10 PM
  • Hi,

     

    To narrow down this issue, Could you help to confirm some questions as below,

     

    1.       How did you set the roaming profile settings for the problematic users?

    2.       Temporarily disable roaming profile for the problematic user and retry to logon RDS via this account, does it work?

    3.       Can the problematic user access the roaming profile folder with full-control permission?

    4.       What’s the OS for the problematic users and what’s the events log on client machine?

    (Refer to http://support.microsoft.com/default.aspx?scid=kb;EN-US;947215 steps to diagnose the profile issues on client)

     

    By the way, I found following conditions may cause roaming profile issue:

     

       • You have a terminal server that is running Windows Server 2008 or Windows Server 2008 R2. 

       • You enable the Delete cache copies of roaming profiles Group Policy setting on the terminal server. 

       • You configure a user account to load a terminal server roaming profile on the terminal server. 

       • The Change password at the next logon option is enabled in the properties of the user account. 

       • You create a terminal server session to the terminal server by using the user account.

     

    This issue occurs because the User Profile service does not load the terminal server roaming profile correctly after the user account password is reset.

     

    When the Delete cache copies of roaming profiles Group Policy setting is enabled, and when a user is prompted to change the user account password, the User Profile service loads a local temporary user profile. The User Profile service loads this user profile to perform the password reset operation. However, the profile changes to a combination of the local temporary profile and of the roaming profile after the user password is reset. Therefore, the terminal server roaming profile is not loaded correctly.

     

    For more information: Please refer to the article as followed:

    http://support.microsoft.com/kb/971338

     

     

    • Proposed as answer by aside Wednesday, October 6, 2010 8:39 PM
    • Marked as answer by Alan Zhu Thursday, October 7, 2010 5:36 AM
    Monday, October 4, 2010 3:01 AM
  • Thank You Kasper!

    This was the solution to our environment!!!  :-)

     

    Tuesday, January 18, 2011 12:56 PM
  • Hello I have seen similar issues during the past couple of years, what the exact cause is, I haven't quite figured out yet. What I have found out though, is the the users profile path is written to the registry of the terminal server, you can find it here: HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList Just browse through the various SIDs in the list, until you find the user who is logged on with a temp profile, delete the corresponding SID. Try to log the user on again and see if the problem is still present.
    Geat solution!
    Wednesday, August 26, 2015 2:54 PM