Logon

This article is based on my Citrix Synergy 2015 session and is the first in a mini-series on Group Policy performance. All measurements by uberAgent on Windows Server 2012 R2 with Citrix XenApp 7.6 in a steady state.

PowerShell is a popular and extremely versatile tool, but is it a good idea to use PowerShell in logon scripts? Let’s try to find out! Setting the Stage I am going to compare the resource utilization of the following languages frequently used with logon scripts:

Update 2015-04-28: Citrix provides the limited release hotfix ICATS760WX64009 that fixes this issue. More information below. During the research for my session about the XenApp 7.6 logon process, to be presented at Citrix Synergy and BriForum London, I noticed that the logon to my XenApp 7.6 lab server was taking a bit long. Longer, in fact, than the combined durations of the main logon phases user profile loading, group policy processing, logon script execution and shell startup. Much longer. Also much longer than on an otherwise similar XenApp 6.5 machine.

Whether user profiles are loading slowly or group policy processing is taking too long - uberAgent for Splunk tells you exactly what is causing slow logons. uberAgent always supported a broad range of platforms, from physical PCs through virtual desktops to Citrix XenApp. Today we add RES Workspace Manager to that list!

This article is part of Helge’s Profile Toolkit, a set of posts explaining the knowledge and tools required to tame Windows user profiles. Many errors related to user profiles result in the user getting a temporary profile instead of the regular local or roaming profile. I have written about possible causes for that here. In addition to that, there is an entirely different category of errors that occur when even a temporary profile cannot be created. This article describes likely causes.

Considering the importance of fast logons for a good user experience there is surprisingly little information on the subject. Windows does not even record the total logon time, let alone where it is spent. Administrators wishing to analyze their users’ logons are left in the dark. But that can be changed.

Know this problem? You try to start a XenDesktop session, Desktop Viewer opens … and closes. Then nothing. When you look at the machine in Desktop Studio you find that everything looks good: it is registered with the DDC and it is not in maintenance mode. However, you find an event with the following properties in the application event log:

Are you still using Active Setup to distribute per-user files or registry values? If so, stop! There are better ways to manage initial user settings. This article assumes basic knowledge of Active Setup. You might want to refresh your memory by reading my article Active Setup Explained.

Among the many security options that are configurable via Group Policy, there is a setting Interactive logon: Require Domain Controller authentication to unlock workstation. For security reasons, this is often enabled. Let’s have a closer look at the implications. Those are different from what one might think because the name is a little misleading.

This article is part of Helge’s Profile Toolkit, a set of posts explaining the knowledge and tools required to tame Windows user profiles. One of the problems inherent to roaming user profiles is that they are copied to the local computer during logon. That takes time. Hence the motivation to limit the size of user profiles. One way of doing that is to put a quota on them, another one is folder redirection. Although widely used, redirection has its problems; problems so grave that Shawn Bass started to campaign against using folder redirection altogether. In this article I describe why Shawn despises redirection, which alternatives are available now what we can hope for in the future.

This is a summary of my experience with Active Setup combined with what I could find on the internet. The information applies to older and current versions of Windows, up to and including Windows 7, Windows 10, Server 2016, Server 2019.

Have you ever tried to log on to a terminal server and, after entering your credentials, been forced to stare at a grey screen for a lengthy period of time wondering what the machine might actually be doing? Of course you have, along with a few million other terminal server users. Being a technical guy (you would not be reading this otherwise) you have checked CPU / memory / hard disk utilization and the current session count when users complain that logons are slow. You will probably have noticed that all relevant metrics are in the green and logons are the slower, the more users try to log on to a server concurrently. It turns out that parallel logons are the root cause of the problem. Why?