Welcome to Part 2 of the WEM Blog series.

In Part 1, we discussed WEM System Optimization. In Part 2, we will be discussing WEM Logon Optimization.

So, as Cpt. Kirk once famously said, “Engage computers. Prepare for warp speed!”

Thanks once again to Pierre Marmignon, Principal Architect and Miguel Contreras, Senior Solutions Architect, for their valuable input.

WEM Logon Optimization

One of the most common complaints I hear from customers is about…….. unacceptably long logon times.

Customers experiencing logon times of 300+ seconds are not uncommon. I have even come across some customers that have logon times nearing 20 minutes (yes, twenty minutes!) While logon times of extreme duration are (thankfully) quite rare, the “unofficial” acceptable industry logon time average is somewhere in the neighborhood of 60 seconds. This, to me, is still excessive, and logon times of 30 seconds or less should be considered optimal.

The negative effect of excessive logon times

The question is, what kind of negative effect do excessive logon times have on End User experience?

Believe it or not, unacceptable logon times are not only frustrating for the End User, they also have a much deeper organisational impact. They effect both employee productivity and employee morale, they increase administration effort and increase pressure on support desks, all of which negatively affect overall organizational performance.

Let’s take a look.

From an end-user perspective:

It is certainly frustrating. There is nothing more annoying than waiting endlessly while your screen is stuck on “Please wait for ABC…”, or “Applying XYZ…” (we have all been there, right?). This often results in an end user “fearing the logon”, so they either stop logging off all together or, even worse, they end up sharing the same logon account with other end users in the organization (think shared computer environments, where logon and logoff needs to be as rapid as possible). All of which are not ideal, and could pose serious security risks. Rightly or wrongly, this isn’t the end user’s fault, it is simply them “finding a way” to be productive. After all, we all know that in the end, end users always “find a way,” whether it involves best practices or not.

From an administration perspective:

Unacceptable end user logon times make up a large proportion of support desk calls, right up there with frozen sessions and password resets. Even though the Windows logon process is well documented, and most of the individual phases can be accurately measured, it still often results in an extremely time consuming phase of diagnosis, which often includes many hours of data collection and analysis before any resolution can be put into place. This is due to the complexity of the Windows logon process and the sheer amount of elements that are involved in it.

From an organizational perspective:

The time it takes an end user to log onto their desktop, is time that the end user is potentially in an unproductive state. Therefore, from an organizational perspective, it is imperative that the end user is able to reach their desktop as soon as possible, and start being productive. This is true for first logons, and also for subsequent logons that may occur during an end user’s typical working day. The increase in administration effort to deal with excessive logon times, locks IT Support teams in a break fix cycle, which negatively effects the organizations overall ability to innovate.

Time is money!

A good example of where excessive logon times can have a serious negative effect is in healthcare, where patients’ well-being could, quite literally, depend on the ability of medical staff to quickly access their desktop and electronic patient records.

The solution to excessive logon times

What if I told you that Citrix Workspace Environment Manager (WEM) can dramatically reduce these logon times?

Well, it can. 🙂

But before we discuss how WEM solves the excessive logon time issue, let’s take a deeper look at the Windows logon process.

The Windows logon process:

The Windows logon process has not changed much since Windows 7. The logon process is unique to and completely owned by the Microsoft Windows OS. The logon process consists of the same sequence of 6 mandatory phases for all Microsoft Windows OSs dating back from Windows 7, through Windows Server 2016.

These six mandatory phases are processed synchronously, which means that each phase needs to fully complete before processing of the next phase can commence. In other words, if we have an issue in one phase which causes that phase to stall or, have a delayed completion, the next phase cannot and will not begin to process. Ultimately, this delay within the offending phase negatively effects the entire logon sequence, and unfortunately results in excessive logon times.

The sequence of six mandatory phases are as follows:

Phase 1: Session Initialization

In a Citrix world, this is the phase where the end user initiates a connection to either an SBC or VDI Session (or even a published app). This phase processes a number of tasks, but ends when LogonUI.exe is executed, and the end user is presented with the Windows logon screen.

Phase 2: Authentication

This phase starts when the end user presses CTRL+ALT+DEL, they are then presented with the SAS process (secure authentication sequence) if using Windows 10 or the GINA process, (graphical identification and authentication) prior to Windows Vista. Here, the user enters their logon credentials and presses the logon button to start the interactive logon process which will authenticate the user. Users can also insert a smart card, or interact with a biometric device.

From an end user experience, this is when the logon process starts and where we officially start to measure logon time.

In the Citrix world, single sign-on with pass-through domain authentication is often employed, this allows end users to log on to Citrix Receiver and launch an SBC or VDI session (or a published app) without having to re-type their credentials multiple times. (i.e. no need to CTRL+ALT+DEL)!

Phase 3: User Profile

Once the end user is successfully authenticated, the process moves to the user profile loading phase. Depending on how the user profiles are set up and what option are used (i.e. Local, Roaming, folder redirection, etc.) this phase can take a considerable amount of time, and is one of most time consuming phases.

Phase 4: GPO/GPP

Once the user profile loading phase completes, the group policy engine is initialized and we enter into one of the most complex phases of the sequence, GPO/GPP. This phase is where group policy objects and group policy preferences are processed. Group policy processing only occurs once per user on any single machine, this includes SBC environments.

This phase also contains the following secondary/sub phases:

• Logon Scripts
• Drive Mapping
• Printer Mapping.

Depending on how complex the GPO/GPPs are, this phase can take an extremely long time to complete, and often is the most time consuming phase in the sequence (but not always).

Phase 5: User Initialization

The main function of the user initialization phase is to load the SHELL. In an SBC or VDI environment, when explorer.exe starts, the User Initialization phase completes.

In a Citrix published app environment this process is slightly different, User Initialization calls CMSTART.exe, which starts the WFSHell.exe process, which then launches iCast.exe. WFShell.exe is the Citrix SHELL for published apps. The iCast.exe is the ICA application starter process, which launches the published application instance. In a published app environment, this is when the user initialization phase completes.

Phase 6: SHELL Initialization

This is the final phase in the Windows logon process, and now the user can finally interact with the SHELL.

Unfortunately, there is no easy way to tell when the SHELL is fully initialized.

Below is a diagram, showing the 6 mandatory phases of the Windows logon process.

As discussed above, the most time-consuming phases of the Windows logon process are the user profile and GPO/GPP phases. As also mentioned previously, one other critical factor to keep in mind about the Windows logon process is that the six mandatory phases are processed in a synchronous manner, meaning that each phase has to fully complete before the next phase can begin processing.

How does WEM solve the excessive logon time problem?

WEM solves this problem by taking specific elements from these time-consuming phases, and handing them over to the WEM Agent for processing. WEM uses parallelism (and other SMART Techniques) to filter out elements from these time consuming phases that are not required during the Windows logon process, the WEM agent then processes the filtered out elements in the background, after the user has initialized the SHELL. When we do this, the processing duration of these time consuming phases is dramatically reduced during the Windows logon process, and SHELL initialization is reached far quicker.

Even more importantly, the WEM agent is also multi-threaded, simultaneously processing up to 99 policies at once. The WEM agent also applies changes to the user environments only when required, ensuring that End Users always have access to their desktop as soon as possible!

Below is a diagram showing the Windows logon process post WEM optimization.

By simply reducing the number of elements within the most time intensive phases of the Windows logon process and handing those removed elements over to the WEM Agent for processing (think mapping drives, logon scripts etc.), the time that it takes between Session initialization and SHELL initialization is significantly reduced. Up to 75% in some cases, with most customers reporting consistent logon times of between 10 and 20 Seconds!

WEM Logon optimization in a Published App world.

In a published app world, we may sometimes need to ensure that any required environment variables, such as mapped drives, mapped printers etc. are processed prior to the published app launching, in order for the published app to work. Therefore, we need to make sure that the WEM Agent has fully completed any required environmental processing before a Published App is launched.

The good news is, we can do exactly that. We do this by taking advantage of a really handy WEM tool called VUEMAppCMD.exe. (Located at C:\Program Files (x86)\Norskale\Norskale Agent Host\).

To achieve this, we simply change the Published App’s location settings to use VUEMAppCMD.exe as the path to the executable file, then use the Published App’s executable as the command line argument.

It is important to mention that using this method, may add some additional launch time to any published app that requires additional environment variables, as those variables are being processed. The additional launch time will vary, and is dependent on the number, and complexity of additional environment variables required, but this additional launch time is normally no more than a second or two.

Additional WEM Published App settings

We also recommend that the following WEM settings are applied in an environment where published apps exist. This will prevent the WEM Splash screen from showing when the Published App is launched. Which is much more aesthetically pleasing for the End User.

Step 1: Agent Service Actions

Advanced Settings → Configuration → Main Configuration → Agent Service actions

Make sure that the Agent Type is set to UI and not CMD. Also leave Execute Only CMD Agent In Published Apps unselected. If you select this option, it will display the CMD Splash screen, but you will not be able to hide it for Published Apps, which is what we will do in the next step.

Step2: Published Applications Behavior

Advanced Settings → UI Agent Personalization → Published Applications Behavior

Select Hide Agent Splash screen in Published Applications.

Choosing these settings will now completely hide the splash screen when launching a published app, but still shows the splash screen in other scenarios, such as logging onto a desktop or session.

I personally like to see the splash screen when logging on to the desktop, it gives me peace of mind that WEM is operational.

CPM Profile Streaming

One of the other arrows in the Citrix quiver is Citrix Profile Management (CPM). As we already know, CPM can be configured either via GPO, Citrix policy or through the WEM console.

While this blog post is not delving into CPM, one of the amazing CPM features that we can use to reduce logon times is Profile Streaming and I wanted to touch on it here.

As we discussed above in the Windows logon process, the user profile phase is one of the most time consuming phases. (hopefully you are using CPM for profile management already).

Once we enable profile steaming on a CPM managed profile, only a very small portion of the users profile is loaded during the Windows logon process, with the rest of the user profile being “fetched on demand” after the user has reached SHELL initialization.

Files within the %userprofile% are actually replaced with pointers/markers. To the user, OS and Application, these pointers/markers appear as normal locally installed files. When a file is requested by the user, the CPM filter driver acknowledges that the requested file is in fact a pointer/marker, and the CPM service is then instructed to fetch the real file from the profile share.

Voilá!

You can also use a range of CPM settings to tweak profile streaming. For example, if a user has large files, these can be cached using the Always Cache setting. This will ensure that there are no delays when fetching larger files. We can also specify which users and groups can use Profile streaming etc. etc.

Combining WEM with Citrix Profile Management and the profile streaming feature will take logon times into warp speed!

This blog post by Mick Glover on Citrix Profile Management’s Profile Streaming feature goes into much more detail, and is well worth a read.

Logon Reporting

WEM also makes it easy for you to monitor the Logon Times within the environment.

Daily Reports:

Monitoring → Daily Reports → Daily Login Report

These reports show a summary of daily login times for all users within a WEM Configuration Set or Site, for the last 24 hours.

You can drill down for a deeper view which shows individual login times for each user on each device by hovering over, or double-clicking a particular category.

Monitoring → Daily Reports → Daily Login Report

These reports show a summary of daily boot times for all users within a WEM Configuration Set or Site, for the last 24 Hours.

You can drill down for a deeper view which shows individual boot times for each device by hovering over, or double-clicking a particular category.

User Trends:

Monitoring → User Trends → Login Trends Report

These reports show Login trends for all users combined within a WEM Configuration Set or Site. You can choose the time period to be displayed, and also drill down for a deeper view by hovering over, or double clicking a particular column.

Monitoring → User Trends → Boot Trends Report

These reports show Boot trends for all users combined within a WEM Configuration Set or Site. You can choose the time period to be displayed, and also drill down for a deeper view by hovering over, or double clicking a particular column.

Monitoring → User Trends → Device Types

This report displays a daily count of the number of devices of each listed operating system connecting to this WEM Configuration Set or Site, and also drill down for a deeper view by hovering over, or double clicking a particular column.

User & Device Reports:

Monitoring → User & Device Reports → User Report

Used to show login trends for individual users. You can choose the time period to be displayed, and also drill down for a deeper view by hovering over, or double clicking a particular column.

Monitoring → User & Device Reports → Device Report

Used to show login trends for individual device. You can choose the time period to be displayed, and also drill down for a deeper view by hovering over, or double clicking a particular column.

Configuration:

Monitoring → Configuration

Her,e you can specify configuration options for reporting. You could set reporting to only take place on certain days, within certain hours and also set minimum threshold boot and login times, which if not met, will not be reported

Summary

As you can see, implementing WEM alone could easily reduce logon times within your environment. Combining WEM with CPM and the profile streaming feature could take logon times to warp speed!

The best thing is, you may already be entitled to WEM and CPM but aren’t aware, or you may be aware but haven’t implemented it yet, for one reason or another. Either way, please get in touch with your Citrix Account Manager or Citrix Systems Engineer if you are unsure, or need any advice/guidance; we are here to assist.

It is important to also bear in mind that the Windows logon process is not the only cause of excessive logon times. There are many other potential environmental causes, including, but not limited to environment sizing and configuration, AD health and complexity, hardware/hypervisor configuration issues, storage configuration issues, OS problems, anti-virus consideration, application problems, and so on.

All of these factors could affect logon times and need to be considered.

Stay tuned for Part 3!

---

Citrix TechBytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.

Click here for more TechBytes and subscribe.

Want specific TechBytes? Let us know! tech-content-feedback@citrix.com