locked
Roaming profiles on workstations without connectivity to oririnal profile server RRS feed

  • Question

  • Hi.

    I’m about to try to move a few hundred users onto a VDI system. The users all have roaming profiles at the moment which will be used by the newly provisioned VDI machines but will be in a datacentre with only RDP connectivity from the existing workstations – the existing workstations will become RDP clients only.

    I’d expected apply a group policy to the existing workstations to prevent them synchronising their server based profiles:

    Administrative Templates/System/User Profiles/Only Allow local profiles: Enabled

    Administrative Templates/System/User Profiles/Prevent Roaming Profile changes from propagating to the server: Enabled

    I’ve set the above in a GPO applied to workstations in a test environment and roaming profiles changes no longer get written back to the shared folder holding profiles. So far so good.

    Not so good – using NetMon I can see a burst of SMB connectivity from workstations to the profile file server when a user logs off. This server won’t be available over SMB when the users move over to VDI so this is a problem.

    If I power the user profile file server off a user logoff stops taking 1-2 seconds and starts to take several minutes.

    With logging turned up I can see a whole bunch of references to the UNC of the server based profile. I can also see a couple of 30 second gaps when nothing’s happening presumably while a timeout is reached as the computer fails to find the server (not sure of that but it seems likely).

    USERENV(410.760) 20:20:12:659 UnloadUserProfile: Entering, hProfile = <0x127c>
    USERENV(410.760) 20:20:12:659 GetInterface: Returning rpc binding handle
    USERENV(28c.2b4) 20:20:12:659 IProfileSecurityCallBack: client authenticated.
    USERENV(28c.2b4) 20:20:12:659 DropClientContext: Got client token 0000014C, sid = S-1-5-18
    USERENV(28c.2b4) 20:20:12:659 MIDL_user_allocate enter
    USERENV(28c.2b4) 20:20:12:659 DropClientContext: load profile object successfully made
    USERENV(28c.2b4) 20:20:12:659 DropClientContext: Returning 0
    USERENV(410.760) 20:20:12:659 UnLoadUserProfile: Calling DropClientToken (as self) succeeded
    USERENV(28c.6ec) 20:20:12:659 IProfileSecurityCallBack: client authenticated.
    USERENV(28c.6ec) 20:20:12:659 UnloadUserProfileP: Entering, hProfile = <0x8fc>
    USERENV(28c.6ec) 20:20:12:659 UnloadUserProfileP: ImpersonateUser <0000014c>, old token is <00000000>
    USERENV(28c.6ec) 20:20:12:659 GetExclusionListFromRegistry: Policy list is empty, returning user list = <Local Settings;Temporary Internet Files;History;Temp>
    USERENV(28c.6ec) 20:20:12:659 CSyncManager::EnterLock <S-1-5-21-1553149241-711329150-2658147087-500>
    USERENV(28c.6ec) 20:20:12:659 CSyncManager::EnterLock: No existing entry found
    USERENV(28c.6ec) 20:20:12:659 CSyncManager::EnterLock: New entry created
    USERENV(28c.6ec) 20:20:12:659 CHashTable::HashAdd:
    S-1-5-21-1553149241-711329150-2658147087-500 added in bucket 21
    USERENV(28c.6ec) 20:20:12:659 UnloadUserProfileP: Wait succeeded.  In critical section.
    USERENV(28c.6ec) 20:20:12:659 MyRegUnLoadKey: Returning 1.
    USERENV(28c.6ec) 20:20:12:659 UnloadUserProfileP:  Succesfully unloaded profile
    USERENV(28c.6ec) 20:20:12:659 MyRegUnLoadKey: Returning 1.
    USERENV(28c.6ec) 20:20:12:659 UnLoadClassHive: Successfully unmounted S-1-5-21-1553149241-711329150-2658147087-500_Classes
    USERENV(28c.6ec) 20:20:12:659 UnloadUserProfileP:  Successfully unloaded user classes
    USERENV(28c.6ec) 20:20:12:659 UnloadUserProfileP: Impersonated user
    USERENV(28c.6ec) 20:20:12:659 UnloadUserProfileP: Writing local ini file
    USERENV(28c.6ec) 20:20:12:659 UnloadUserProfileP: Reverting to Self
    USERENV(28c.6ec) 20:20:12:659 UnloadUserProfileP: exitting and cleaning up
    USERENV(28c.6ec) 20:20:12:659 UnloadUserProfileP: Reverted back to user <00000000>
    USERENV(28c.6ec) 20:20:12:659 CSyncManager::LeaveLock <S-1-5-21-1553149241-711329150-2658147087-500>
    USERENV(28c.6ec) 20:20:12:659 CSyncManager::LeaveLock: Lock released
    USERENV(28c.6ec) 20:20:12:659 CHashTable::HashDelete:
    S-1-5-21-1553149241-711329150-2658147087-500 deleted
    USERENV(28c.6ec) 20:20:12:659 CSyncManager::LeaveLock: Lock deleted
    USERENV(28c.6ec) 20:20:12:659 UnloadUserProfileP: Leave critical section.
    USERENV(28c.6ec) 20:20:12:659 UnloadUserProfileP: Leaving with a return value of 1
    USERENV(28c.6ec) 20:20:12:659 UnloadUserProfileI: returning 0
    USERENV(410.760) 20:20:12:659 UnloadUserProfile: Calling UnloadUserProfileI succeeded
    USERENV(28c.1dc) 20:20:12:659 IProfileSecurityCallBack: client authenticated.
    USERENV(28c.1dc) 20:20:12:675 ReleaseClientContext: Releasing context
    USERENV(28c.1dc) 20:20:12:675 ReleaseClientContext_s: Releasing context
    USERENV(28c.1dc) 20:20:12:675 MIDL_user_free enter
    USERENV(410.760) 20:20:12:675 ReleaseInterface: Releasing rpc binding handle
    USERENV(410.760) 20:20:12:675 UnloadUserProfile: returning 1
    USERENV(28c.290) 20:20:12:691 UnloadUserProfile: Entering, hProfile = <0x940>
    USERENV(28c.290) 20:20:12:706 UnloadUserProfile: In console winlogon process
    USERENV(28c.290) 20:20:12:706 UnloadUserProfileP: Entering, hProfile = <0x940>
    USERENV(28c.290) 20:20:12:706 AbleToBypassCSC: Try to bypass CSC
    USERENV(28c.290) 20:20:38:566 AbleToBypassCSC: tried NPAddConnection3ForCSCAgent. Error 53
    USERENV(28c.290) 20:21:46:178 UnLoadUserProfileP: CSC bypassed failed.
    Ignoring Roaming profile path
    USERENV(28c.290) 20:21:46:178 GetExclusionListFromRegistry: Policy list is empty, returning user list = <Local Settings;Temporary Internet Files;History;Temp>
    USERENV(28c.290) 20:21:46:178 CSyncManager::EnterLock <S-1-5-21-1553149241-711329150-2658147087-1261>
    USERENV(28c.290) 20:21:46:178 CSyncManager::EnterLock: No existing entry found
    USERENV(28c.290) 20:21:46:178 CSyncManager::EnterLock: New entry created
    USERENV(28c.290) 20:21:46:178 CHashTable::HashAdd:
    S-1-5-21-1553149241-711329150-2658147087-1261 added in bucket 5
    USERENV(28c.290) 20:21:46:178 UnloadUserProfileP: Wait succeeded.  In critical section.
    USERENV(28c.290) 20:21:46:178 MyRegUnLoadKey: Returning 1.
    USERENV(28c.290) 20:21:46:178 UnloadUserProfileP:  Succesfully unloaded profile
    USERENV(28c.290) 20:21:46:178 MyRegUnLoadKey: Returning 1.
    USERENV(28c.290) 20:21:46:178 UnLoadClassHive: Successfully unmounted S-1-5-21-1553149241-711329150-2658147087-1261_Classes
    USERENV(28c.290) 20:21:46:178 UnloadUserProfileP:  Successfully unloaded user classes
    USERENV(28c.290) 20:21:46:178 UnloadUserProfileP: Impersonated user
    USERENV(28c.290) 20:21:46:178 UnloadUserProfileP: Writing local ini file
    USERENV(28c.290) 20:21:46:178 UnloadUserProfileP: Reverting to Self
    USERENV(28c.290) 20:21:46:178 UnloadUserProfileP: exitting and cleaning up
    USERENV(28c.290) 20:21:46:178 CSyncManager::LeaveLock <S-1-5-21-1553149241-711329150-2658147087-1261>
    USERENV(28c.290) 20:21:46:178 CSyncManager::LeaveLock: Lock released
    USERENV(28c.290) 20:21:46:178 CHashTable::HashDelete:
    S-1-5-21-1553149241-711329150-2658147087-1261 deleted
    USERENV(28c.290) 20:21:46:178 CSyncManager::LeaveLock: Lock deleted
    USERENV(28c.290) 20:21:46:178 UnloadUserProfileP: Leave critical section.
    USERENV(28c.290) 20:21:46:178 UnloadUserProfileP: Leaving with a return value of 1
    USERENV(28c.290) 20:21:46:178 UnloadUserProfile: UnloadUserProfileP succeeded
    USERENV(28c.290) 20:21:46:178 UnloadUserProfile: returning 1
    USERENV(28c.290) 20:22:18:882 LoadUserProfile: Yes, we can impersonate the user. Running as self
    USERENV(28c.290) 20:22:18:882
    =========================================================
    USERENV(28c.290) 20:22:18:882 LoadUserProfile: Entering, hToken = <0x76c>, lpProfileInfo = 0x6e3e0
    USERENV(28c.290) 20:22:18:882 LoadUserProfile: lpProfileInfo->dwFlags = <0x0>
    USERENV(28c.290) 20:22:18:882 LoadUserProfile: lpProfileInfo->lpUserName = <t11>
    USERENV(28c.290) 20:22:18:882 LoadUserProfile:
    lpProfileInfo->lpProfilePath = <\\svr01\users\t11>
    USERENV(28c.290) 20:22:18:882 LoadUserProfile:
    lpProfileInfo->lpDefaultPath = <\\DC01\netlogon\Default User>
    USERENV(28c.290) 20:22:18:882 LoadUserProfile: NULL server name
    USERENV(28c.290) 20:22:18:882 LoadUserProfile: In console winlogon process
    

    Does anyone know how I can convince these computers to stop trying to connect back to the inaccessible file server and just keep the cached copies they had of their profiles before the GPOs were applied?

    Any help appreciated

    Thanks

    Rob


    RobinG

    Thursday, April 18, 2013 7:29 PM

All replies

  • Hi, are any of the MS engineers who monitor this able to comment? This is 100% reproducible in a lab environment.

    In summary, after setting a GPO to prevent XP machines using roaming profiles, the machine will keep their own local copies of their profiles and not write them back to the server but if the roaming profile server isn’t accessible via SMB logoff takes far longer than when it was accessible. This surely isn’t expected behaviour (but if it is I can go away and make plans knowing there’s nothing else to be done)?


    RobinG

    Monday, April 22, 2013 8:10 AM
  • Hey, Microsoft dudes - are you able to give me any suggestions? Anything at all, even if you tell me this is the way it supposed to work?

    RobinG

    Tuesday, April 30, 2013 3:35 PM
  • Hi,

    Have you tried the following in GPO

    Computer Config >Administrative Templates > System > User Profiles

    Set "Only Allow Local User profiles"

    Regards,

    M


    If you find my information useful, please rate it. :-)

    Monday, May 13, 2013 6:19 PM
    Moderator
  • Hi Martin,

    Yes I have, as per my original post, I've tried two GPOs and that's one of them. My problem is that they appear to only work at logon. The computer still tries to contact the profile file share at logoff.

    Regards

    Robin


    RobinG

    Monday, May 13, 2013 6:26 PM
  • Hi Robin,

    Does it change anything when it connects?

    M


    If you find my information useful, please rate it. :-)

    Monday, May 13, 2013 6:28 PM
    Moderator
  • Hi Martin,

    No, nothing gets written back to the profile area. I can't tell using NetMon exactly what it does but I can tell for sure that it makes an SMB connection and I see the use profile folder path in some of the SMB packets. If the share is there then logoff is virtually instant. If the share can't be contacted then logoff takes longer than a minute (which the log file in an earlier post shows is mainly waiting to timeout).

    Regards

    Robin


    RobinG

    Monday, May 13, 2013 6:33 PM
  • Hi Robin,

    I believe this is normal behavior. I have just tested it on my WinXP Pro VM connected to a Server 2003 DC

    Even though there is no write back on the profile, the server logs other information such as user audit policy etc and would require a connection back for that.

    M


    If you find my information useful, please rate it. :-)

    Monday, May 13, 2013 6:35 PM
    Moderator
  • Hi Martin,

    I agree its normal behaviour as I’ve tested enough to know it’s repeatable. Many bugs are.

    I don’t believe the policy does what is intended (it’s a bug). It severely limits its usefulness of the GPO if connectivity to the file server is still required from workstations you specifically want to prevent using the content of the file server e.g. you have workstations in a distant country with limited bandwidth/dialup/satellite links but they STILL want to chat to servers in another country even though the GPO implemented makes it unnecessary. As XP was written when dialup links were still common place it seems infeasible that this was the intention. I’ve also found no documentation to explain why this would be the case.

    Not sure why you think user audit policy would be related to this if the server based profile isn’t supposed to be accessed from some workstations. Auditing on success/failure would be invalid if a read connection were requested where auditing systems searched security logs for success/failure on write attempts (which would be the norm for user profiles).

    Unfortunately, due to the age of XP I don’t expect to get any response from MS to the suggestion that this is a bug. That ship has sailed…

    Thanks for your replies.

    Robin


    RobinG

    Monday, May 13, 2013 6:49 PM
  • Hi Robin,

    I believe the parameter is to stop writeback to the profile which it does. The traffic however remains an enigma. I have tried disabling roaming profile altogether which also does not stop the traffic.

    In my case there are scripts in netlogon and my datastore is on the dame drive as the DC so im figuring that explains what im seeing. Without having an in-depth knowledge of your setup I will be most unlilkely of any help.

    Martin


    If you find my information useful, please rate it. :-)

    Monday, May 13, 2013 6:54 PM
    Moderator
  • Robin,

    Just something to test

    Set up a user account (test) with a roaming profile

    Ensure the user is not part of a GP that (Only Allow Local User profiles) so the user can have a roaming profile.

    Log in to the client using the test account

    Log out of the client

    Add the test user to the GPO

    Restart the client and log in again

    See if the same issue occurs

    M


    If you find my information useful, please rate it. :-)

    Monday, May 13, 2013 7:00 PM
    Moderator
  • Hi Martin,

    If you think an in depth knowledge of my environment may be the key, my setup is the minimum environment I need to test and this problem. 3 virtual machines: a domain controller, a file server to hold user profiles and a workstation running XP. All patches are installed and no additional software or configuration is performed other than workstation joined to domain, file server joined to domain, creation of a shared folder on the file server, NTFS permissions modified to allow automatic creation of user profile folder, dcpromo, creation of a test user account with a server based profile and the GPO settings I listed.

    Regards

    Robin


    RobinG

    Monday, May 13, 2013 7:04 PM
  • Hi Robin,

    Also Try:

    Computer Configuration\Administrative Templates\System\Group Policy, and enable “User Group Policy loopback processing mode” set parameter to “Merge”

    Martin


    If you find my information useful, please rate it. :-)

    Monday, May 13, 2013 7:11 PM
    Moderator
  • Martin, I don't have any user GPOs at all and certainly none linked to the OU the workstation is in. Is there a reason for that suggestion? It seems random and unrelated? Regards Robin

    RobinG

    Monday, May 13, 2013 7:23 PM
  • Hi Robin,

    My understanding was that you had GPO's enabled from previous posts.

    The merge parameter will enforce local policy as priority over remote policy should the server and the local host conflict.

    I could see how it is a possibility if users are enlisted in a GPO for their in office roaming profile while the same policy is expressed while logging into VDI

    http://pubs.vmware.com/view-50/index.jsp?topic=/com.vmware.view.administration.doc/GUID-E6DE1AAB-75A7-4C05-A97F-DFEA499DB4FE.html

    I cannot replicate your full setup here as i dont have an ext fileserver nor do i have VDI set up.

    I believe the merge option is the possible missing link.

    M


    If you find my information useful, please rate it. :-)

    Monday, May 13, 2013 7:29 PM
    Moderator
  • Martin, My test environment is 3 machines. No VDI is used or required to test. Loop back processing of GPOs has noting to do with local policies. It's the application of user profiles to computers in the OU or child OUs that the user policies are linked to. Your belief that the merge setting is the missing link is based on a misunderstanding of what loop back processing is. II know GPOs are applying because no data is being written back to the profile folder so fiddling with setting to ensure they apply is unnecessary. Thanks for your posts but I don't think you're on the right track. Regards Rob

    RobinG

    Monday, May 13, 2013 8:16 PM