Speed-up XP logon - move GPO processing to Local Security Policy

[#1]

Hi all
There are 1500+ people at our firm across several sites globally, all use roaming profiles and most have reported slow logons.  Only My Documents is a redirected folder, everything else (including APPDATA) is part of the roaming profile.  We intend to redirect APPDATA and possibly the Desktop and Start Menu but may not see much benefit in the latter two.  This is likely to pose a number of issues (e.g. Adobe Reader 9.0 does not working with roaming profiles that use UNC paths, but is resolved in 9.2).  We're also looking into DFS to replicate the roaming profiles around all sites but lack of budget may scupper further research.
In an attempt to further increase the speed of roaming profiles, we were wondering whether moving Group Policy processing to the Local Security Policy in our master build would offer any additional performance benefits?  In other words, for all the settings we've tweaked in the Group Policies, we could reset them all to default (i.e. Not Configured) then apply manually update the required settings in the Local Security Policy on our master image, that would apply to all machines.  Will this allow our users to logon faster or will this be a wasted exercise please?
Thanks
Scott

[#2]

99% of time, slow logons and roaming profiles are due to enormous profiles.  I assume you've checked profile sizes?
Folder redirection is the way to go.  However, you'll need to be careful using DFS to replicate them, if anyone is likely to be logged on simultanously on multiple machines utilising multiple folder targets (i.e. simultaneous logins on multiple sites). 
Also, if you're using the spawn of satan that are .PST files, DFS will just not work, period.
Try to utilise GPO to clear temp files from IE on shutdown etc.  Anything to minimise the processing load for DFS as it can get choked.
Finally, Computer GPO updates are handled incrementally - i.e. a GPO will only be processed if it is not already in place.  User based GPO's are always processed.  Thus, moving the GPO policy to the local computer policy will likely give you a very small net gain in login performance.
HTH
B.

[#3]

Quote from: Barry

Folder redirection is the way to go.  However, you'll need to be careful using DFS to replicate them, if anyone is likely to be logged on simultanously on multiple machines utilising multiple folder targets (i.e. simultaneous logins on multiple sites).

I've only got a three site 60 User system linked via ADSL Max, but use DFS to copy the User data to each server - so that the User only interacts with the local server copy.  As Barry says It can be a problem if a User logs on to Multiple sites!!!!!  DFS does make a good attempt to keep things in line - but you will need to keep checking the Deleted / conflicts folders.

Quote

Also, if you're using the spawn of satan that are .PST files, DFS will just not work, period.

I'd like to hear more on this Barry as I just may be heading down this path

[#4]

Thanks for your replies.
1. I assume APPDATA changes/updates are made on the local machine then uploaded to the server copy on logoff? 
2. Adobe Reader 9.0 is just 1 app we found not to work with redirected APPDATA folders, so we are concerned other apps maybe affected in a similar or indirect way.  What are your good and bad experiences of redirected APPDATA folders? 
4. Do you think the performance gain in moving GPO processing to the local machine policy would be so small that it would be a waste of time?  Or does every little help?
Cheers
Scott

[#5]

@Maurice:
From http://technet.microsoft.com/en-us/library/cc773238(WS.10).aspx#BKMK_050

Quote

Can DFS Replication replicate Outlook .PST files? Although DFS Replication does not explicitly omit Outlook Personal Folders Files (.PST) from replication, .PST files that are accessed across a network can cause DFS Replication to become unstable or fail. DFS Replication can safely replicate .PST files only if they are stored for archival purposes and are not accessed across the network using a client such as Microsoft Outlook (copy the files to a local storage device before opening them). For more information about why .PST files cannot be safely accessed from across a network, see Microsoft Knowledge Base article 297019 http://support.microsoft.com/kb/297019

@henderson1977:
If you use folder redirection, any changes to AppData are committed live to the server immediately.  With roaming profiles WITHOUT redirection, the changes will be committed when the user logs off.
I used folder redirection for the majority of a user profile in both an XP and an Vista environment, and the only problem I came across that had issues was a single plugin for Visual Studio. Programs should be written to handle UNC and drive-mapped AppData folders and if they're not, it's a sign of shoddy programming (which really wouldn't surprise me with Acrobat Reader bloatware)
Moving your GPO objects to a Local policy will gain very little benefit - I would suggest that it would not be worth the maintenance overhead tbh.  The policy (whether group or local) still needs to be 'applied' during login, so all you are saving is the requirement to transfer the GPO across the network during login.
To help debug the login process, edit:
Local Computer Policy -> Computer Configuration -> Administrative Templates -> System -> "Verbose vs Normal Startup Messages" and set it to 'Enabled'
When logging in, this will give you much more informative messages to allow you to trace exactly what is causing the slowdown.  Unless you have a complex GPO hierarchy, I do think you will find that GPO updates take much less time than you think.
If you do find that your GPO updates are what is causing the slowdown, then follow the following:
Firstly,  create a new “TEST” organization unit (OU) in the Active Directory Users and Computers snap-in and block policy inheritance to the OU. Once this is done, you can move the problem computer to that OU. Verify that there are no policies being “enforced” or set to “no override”. If there are polices with those settings, they will still be applied to an OU where policy inheritance is blocked.
Before you move the computer you should run the following command to find out exactly what group policy objects are linked to it:

gpresult /v > gp.txt

This will create a file called gp.txt which will contain a list of all policies applied to the current computer/logged in user.
Once you have the policies identified you can move forward with creating the test OU. Here is a step by step on creating the OU and blocking the inheritance:
1. Create a “Test” OU and move the computer account to it:

2.  Open the GPO Management and block inheritance to the TEST OU:

3.  Once you have inheritance blocked and the computer moved to the OU, reboot the computer at least two times to clear the previously set policies.
There are times where you cannot remove all policies if they are enforced. At least you will have a short subset of policies at this time. Time to test again…
If the computer boots fast now then you have a group policy (or combination of policies) that ARE causing the delay. To find which policy is causing the issue you will need to link them one at a time rebooting in between and monitor when the delay occurs again. This is done by selecting the “Link an Existing GPO” as seen in above picture. Once you have the policy identified a thorough audit should be done to determine which setting in the policy is causing the delay.
I still think your most likely explanation is oversize roaming profiles tho.
HTH
B.

[#6]

Just to add -  Having a ton of group policies that perform extensive tasks or configurations (like software restrictions) will increase your logon time. A few policies that accomplish everything are better than many policies that do a handful of things each. If possible consolidate your group policies.
B.

[#7]

Thanks for that link Barry - I think I'm safe in what I plan to achieve.  But who knows with the vagaries of Microsoft
A few bits of useful info on testing GPO's too.  I use GPMC.exe and the modelling and results wizards to do a lot of quick checking on new or revised GPO's
On consolidation of GPO' s  - I've discovered the hard way that it pays to heed the Microsoft advice to keep the WSUS policy separate     WSUS is great when it works, but a pain when it doesn't!!!!!
Having said that, the new version 3 SP2 seems to do the business
Maurice

[#8]

Barry, thanks for the detailed steps, much appreciated.  We'll certainly be giving it a go. 
1. I understand what you're saying about there being little gain in moving GPO processing to the local machine policy.  This maybe true when the roaming profile is on the same subnet but we have many users working remotely in any of our global offices.  Do you think we would see a performance gain if all GPO processing was done via the local machine policy instead in the case of a London based user working remotely in Hong Kong for instance?
2. Our roaming profiles are currently 50MB but this includes the APPDATA folder.  In theory, if we stripped down the roaming profile to re-direct APPDATA and MyDocs folders, what profile size limit would you recommend we set please?  20MB perhaps?  There must be a minimum recommended for NETHOOD, PRINTHOOD, etc surely?
Thanks
Scott

[#9]

I aim to keep profiles below 10MB on my network.
But mine is over 8GB - it logged on in around the time it took me to boil a kettle this morning. (Although I did have to fell a tree, and log it before lighting a fire to boil the kettle)
Other people I've discussed it with in the past tend to aim for various multiples of 10 between 10 and 50.