rakhesh.com

I am a bit all over the place as I am trying to do multiple things and discovering so many new things. It’s exciting, but also a bit overwhelming. I know I should note it all down for future reference (as I may not be implementing most of these now) and rather than wait for things to settle down and then write a more organized blog post – which may not happen coz I could have forgotten by then – I think I’ll just “dump” things as they are now. :)

First off: I noticed that my freshly installed Citrix Director wasn’t showing any logon performance data. Empty. Said there’s no logons, nothing to report. Googled a bit, found some forum posts, but this blog post is what I will link to. Now if you look at that it suggests viewing the Monitoring database to see if some columns are NULL. How to do that? I had no idea, but again Googled a bit and found that if I go to the database table via SQL Management Studio I can view the table as below –

Once you have UPM installed, it takes care of the performance data. This runs via entries in the HKLM\Software\Microsoft\Windows\CurrentVersion\Run key and could be blocked via some GPO. That wasn’t my case, but I went ahead and disabled the setting anyways. (Didn’t check whether logon performance data is working since then).

Next: speeding up logon times.

Since Windows 8/ Server 2012 there’s a 5-10 second delay for applications when they are launched during startup (i.e. logon). This messes up with the figures from Citrix Director (as the process for monitoring too is delayed) plus gives you a slower logon experience. To remove that delay a registry key needs to be added: StatupDelayInMSec (REG_DWORD) to 0 in HKCU\Software\Microsoft\Windows \CurrentVersion\Explorer\Serialize. Came across this nugget of info from another blog post too which has some more useful suggestions (especially the one about removing the CD-ROM drive – I’ve done that). In a similar vein this post from XenAppBlog (great blog!!) is also useful. It mentions what I had written above about Citrix Director stats being skewed coz of the startup delay.

There’s a sequel to the post from XenAppBlog. From that I came across Citrix’s own optimization guide (it’s for Windows 8 & 8.1 but I figure I can harvest it for 2012 R2 info too). And this post from JGSpiers.com is awesome (I learnt about modifying the default user profile itself where possible than using GPPs to get that extra bit of performance). The author has a Server 2016 optimization script too which I hope to pull in bits and pieces from.

I am fascinated by the idea of modifying the default profile. That makes so much more sense than applying all these GPPs. I love GPOs but I am not a huge fan of them either. For me they serve a purpose but must be used in moderation. I’d much rather set the correct defaults via MST files when installing a package or just modifying the default settings some other way. I guess it’s coz I have seen the delays that happen during login when a large number of GPOs apply (at work for instance, my laptop has some 31 GPOs applying to it!).

The only catch with modifying the default user profile is that you can’t push out subsequent changes to all profiles. What I mean is once a user logs in and has a profile, and then I go ahead and make some changes to the default profile, I can’t push these out to the profiles that were already created. All I can do is delete the already created profiles so that next time they login the changes are pulled over.

Reading about this I came across this nice blog post. And what a blog too! Some amazing posts there. 

Group Policy Preferences must be processed to determine whether they have been applied. Whilst GPPs can implement a preference rather than a policy, Windows must determine whether the preference has been applied by reading a flag. Whilst checking those flags isn’t a big problem, implementing GPPs should be considered in the context of whatever else is running at logon, how many preferences are implemented plus what happens to the environment over time (how many additional policies, applications, scripts etc. will be added to the environment over the life of that desktop).

The author has a few scripts on editing the default policy directly during Windows deployment.

From that blog I came across a nice (and funny) post on folder redirection. When I was fiddling with folder redirection, initially I too had redirected the Documents folder to the user’s home directory and was struck by what the author mentions in his blog. All my user folders started showing the name “Documents”. So irritating! I had to manually go and delete the desktop.ini file (from previous experience I knew the desktop.ini file plays a part in the folder names and icons etc). Since then I changed the Documents folder to point to %HOMESHARE%%HOMEPATH%\My Documents. This blog post also made me realize one can redirect more folders via some registry keys present at HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders.

Speaking of variables that be used in folder redirection the officially supported ones seem to be %USERNAME%, %USERPROFILE%, %HOMESHARE%, and %HOMEPATH%.

(For anyone interested in more quirks of Windows Explorer this blog post is a good read).

Btw, as a matter of terminology, there is a different between folder and directory. A folder is more of a virtual construct while a directory actually exists. In most cases folders are same as directories, but when we look at redirected folders for instance then folders are not the same as directory. There’s a folder called “My Documents” for instance (under C:\Users\Username) but there’s no corresponding directory. The folder is virtual and points to a directory at say (\\myfileserver\RedirectedFolders\Documents\Username).

Part 2 of the above post on folder redirection. Has a bunch of videos on various situations and the impact. Key takeaways:

• Windows logon process is not solely dependent on the user PC. It depends on the load of the file servers too hosting the profiles (for roaming profiles).
• Heavily loaded profile server means slow login time for roaming profile user.
• If using folder redirection, then heavily loaded profile server means not so slow login time (as less data is transferred initially) but experience may not be great post login as the desktop etc. icons need to be pulled from the profile server and that is under load. This is made worse if AppData too is redirected as it impacts app launches too.
  • On a side note: I think redirecting AppData is a bad idea. I have had made experience with it at work. Best to keep AppData as part of the roaming profile and not redirected. AppData has a lot of read-writes too – is not suited for redirection.
• If using Citrix streaming profiles and the profile server is loaded, login time is better as it is streamed as required.
• The author doesn’t talk about Citrix streaming profiles + folder redirection and heavily loaded servers. That’s the scenario I was interested in.

Nice! Part 3 of the post on folder redirection shows the impact of not redirecting AppData. :) BTW, note to self: when you redirect AppData you redirect the Start Menu too. Obvious in hindsight, as I know the Start Menu is in the AppData folder, but I had forgotten.

Part 4 is on the impact on logon duration. Part 5 is on the impact of the SMB version (basically, use the latest version where possible, for better performance). Windows 8/ Server 2012 and above use SMB3 (well 3.0 and 3.02 for 8.1/ 2012 R2). And speaking of SMB, SMB is not CIFS. :) CIFS is ancient stuff, superseded by SMB1.

Another bunch of posts by these same others on folder redirection (yay!). Three parts again. Nice quote from part 1:

Folder redirection remains a popular method of user data and profile management because it can improve the user experience by achieving two things:

1. Faster logons – redirecting AppData out of the profile reduces the amount of data required to be copied locally at user logon

2. Abstracting user data – moving user data out of the profile to a home folder ensures data is available on any desktop and allows IT to protect that data

Abstracting user data. I like that. That’s exactly what I had in mind when I discovered the joys of separating a profile from the user data (as in limit a profile to just the settings or “profile” sort of stuff; keep all data redirected elsewhere so it can be shared among multiple profiles or even multiple versions of the profile). I won’t go into much detail other than link to the first part and also this post on how they did the tests (some good tools there).

Lastly, some alternatives to folder redirection. I am not a decision maker in my firm for desktop stuff, so I will skip this for now. Some day … :)

While on the topic of folder redirection, I wanted to point to this post too on automatic conflict resolution.

I guess that’s all for now. More later …

Update:

An excellent post by Helge Klein on the impact of GPOs on logon performance. I am awed by people like Helge Klein and Aaron Parker (whose posts I link to above). It takes a certain level of effort and persistence to test the impact of various settings across multiple scenarios. It’s something I would like to know of, but am lazy or disorganized to actually get off my butt and do. Very impressed. Check out the CSE Overhead section in the post I link to. Registry settings applied via policies have way different impact to registry settings applied via preferences. The latter has nearly twice the impact (i.e. registry keys via policies is less than 20ms, registry keys via preferences is about 50ms). Damn!

Beware of using preferences to set shortcuts, ini files, and environment variables.

Also interesting to note, it is better to put all settings in a single/ less number of GPOs than to spread them across multiple GPOs. Not a huge impact, but it matters. (That said – the version of a GPO is associated to the GPO, and not to the individual settings in it. So if you have a less number of GPOs with a lot of settings in them, a change to a single setting will result in the GPO having a new version and hence be reapplied (see below)).

Note to self for the future: registry settings via policies (we can’t control these directly, they are what the policies set) is stored in a registry.pol binary file. Registry settings via preferences are XML files.

The post has more nuggets such as the processing order of GPOs (admin templates first, followed by others – check the post for the order). Also, worth remembering that gpupdate is smart enough to only apply any changes Group Policies and what the /force switch does is tell it to re-apply everything – you don’t really need that in most cases. Group Policy be default keeps track of what settings have been applied.

The Client Side Extensions (CSEs) in a GPO are controlled per machine under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions. The CSEs are modules basically which do the actual applying of a GPO setting (e.g. drive mappings, registry settings, admin templates stuff). Worth noting that each CSE has a value called NoGPOListChanges. If this is 0 (the default) it means the CSE will process a group policy even if there’s no changes between the cached list and the currently downloaded list (note this contradicts what I said with gpudate above). If this setting is 1 then the CSE will process a group policy only if there are changes.

From this Microsoft blog post:

A Client-Side Extension is nothing more than a file (in most cases it’s a .dll file, but not always) that has been installed on the client machine which has the ability to interpret and process certain of the settings in a GPO. Because there are many different types of settings, there are different Client-Side Extensions. In order for your client to process a portion of a GPO, the CSE associated with that portion of the GPO will need to be present on the client machine. An example of this is the security settings that are found under Policies/Windows Settings/Security Settings on both the Machine and User nodes of a GPO. To process any settings that have been configured within these containers, your client will need the scecli.dll file.

Part 2 of the same post: When a computer starts up (machine policies) or a user logs in (user policies) the group policies are processed. This can be thought of as foreground processing – you see it happening. Apart from this, every 90 mins (which can be changed) with an offset, the group policies are also processed in the background.

• During background processing only GPOs with NoGPOListChanges set to 1 are processed (i.e. only if there are changes).
  • Fun fact: background processing runs multi-threaded. All other GPO processing is single-threaded!
• During foreground processing there’s two modes that processing can operate in. :) Asynchronous – which is the default – means policies apply without delaying the user login. That is to say when a user logs in, the full set of policies may not have applied – they can apply in the background. This is good in the sense that logins appear fast, but not good if you want all policies to apply before a user logs in. The alternative is Synchronous wherein all policies apply and then only the user logs in. When we go and change this GPO setting – Computer Configuration > Policies > Administrative Templates > System > Logon > Always wait for the network at computer startup and logon – a common practice in an enterprise environment, you are basically switching foreground processing to be synchronous.
  • Note: you need synchronous processing to ensure folder redirection applies in a single login. 
  • During synchronous foreground processing all CSEs are processed, irrespective of there being any changes or not. :) So NoGPOListChanges is ignored.

More fun stuff: disabling the computer or user configuration in a GPO has not much effect. And if you want to enable debugging and logging it is possible too.

Part 3: Lots of cool info on the effect of WMI filters and Item Level Targeting (ILT). Skipping WMI here for now as I am not using it currently (for Citrix purposes), but good to know about ILT: avoid using it via evaluations against AD such as OU, LDAP queries, Domain, and Site. Querying against an AD group is fine.

Here’s an official Microsoft blog post on pretty much the same info as above (not the performance tests etc). The official recommendation seems to be to use asynchronous foreground processing (the default) with the caveat that it won’t work for redirected folders. Bugger. :) Also, a good Microsoft Technet article on Group Policy performance. It touches on a lot of the same topics as the blog posts above but gives a different perspective.

—

I need to find a way of applying per user registry keys, environment variables, and drive mappings. These are the three things for which I currently using GPPs and I want to try and avoid that. I guess I can use Active Setup, or perhaps Scheduled Tasks? I could also look at modifying the default user profile but I am not too keen on that now (coz what would I do if there are changes? I don’t want to keep deleting user profiles so they pick up a new default profile).

Speaking of Active Setup, an excellent post by Helge Klein. I wasn’t aware the Version value could be used to run the same component in case of changes. Sounds useful in my scenario.