DFS Folder Redirection - "Preparing your Desktop" delay

[gshaw]

Related to another recent thread I've set up a DFS namespace and associated shares etc. for auto-created user home folders. That works OK but there's an odd delay on the Windows 7 login process that's stumping me at the moment as it doesn't happen consistently...

 

• new user logs into a machine, no Documents folder present on DFS share
  
• login process starts quickly, gets through Folder Redirection GPO within a second
  
• gets to "Preparing your desktop"
  
• 10-20 second delay
  
• shows the desktop with a blank wallpaper
  
• another 10 second or so delay
  
• Explorer loads with icons etc.
  

Subsequent logins go in like lightning. The weird thing is sometimes I can delete the profile and home area i.e. reset the scenario and the behaviour repeats. Other times the login goes through normally, which is the odd part. At first I thought that was due to disabling some GPOs but a further test disproved that theory.

 

I already have Verbose GPO logging enabled which used to be one of the recommendations a few years back but that tended to be for the Folder Redirection part of the login rather than "Preparing your desktop". In comparison our legacy setup that redirects to pre-existing folders logs in with the same GPOs without the delay.

 

I'm poring over GPSvc logs at the moment but not seeing much apart from "User Session 1" logged in, followed by a delay then the session ends with a "User session 2" following shortly after, which I would presume is the actual Windows desktop loading.

 

Any ideas from your experiences?

[Steve21]

Did you setup DFS to use inherited permissions from the share or did you set specific ones? Just sounds like the old issues with desktop redirection and not having "change" permissions on the share.

 

Steve

[gshaw]

Did you setup DFS to use inherited permissions from the share or did you set specific ones? Just sounds like the old issues with desktop redirection and not having "change" permissions on the share.

 

Steve

 

@Steve21 which share are we talking about? The DFS root or the linked target where the data resides?

 

Used Server 2012's default setting of "All users have read-only permissions" on the DFS Root i.e.

 

• Share permissions Everyone > Read
  
• Security permissions seems to be inheriting from the root of the drive the DFSRoots folder resides on
  

[Steve21]

So like on the "in my example" StudentDocuments DFS mapping (Use DFS Mangement) in the properties what's set under advanced? "User Inherited" or "Set explicit" ?

 

And on the actual share on the file server? (Not the NTFS but share)

 

 

Steve

[gshaw]

So like on the "in my example" StudentDocuments DFS mapping (Use DFS Mangement) in the properties what's set under advanced? "User Inherited" or "Set explicit" ?

 

And on the actual share on the file server? (Not the NTFS but share)

 

 

Steve

@Steve21

 

Settings are...

 

• "Use inherited permissions from the local file system" is what it's set as within DFS Management
  
• On the server file share itself Everyone has Full Control, NTFS permissions are as per MS recommendations using CREATOR OWNER etc. as per https://support.microsoft.com/en-gb/kb/274443
   
  

Edit: tried a few more things and may have a solution related to your theory in the previous post:

• Made a copy of the GPO pointing directly at the file server path, logins were fast without the lag
  
• Reverted back to the DFS path GPO, lag returned
  
• Changed the DFS Root share from Everyone > Read to Everyone > Full Control
  
• Next set of logins were fast, no lag
  
• Users still can't create files in the DFS Root share as NTFS permissions only grant Users > Read and Execute
  

Hoping that may be the solution, was this the lines you were thinking of when checking the DFS permissions?

 

Edit again: spoke too soon, second round of tests has gone back to the lag

Edited August 17, 2016 by gshaw

[gshaw]

Well bizarrely it seems one GPO is causing the lag, see http://www.edugeek.net/forums/windows-7/174940-theme-gpo-slow-login.html#post1498942