Author: Kasper Johansen

Citrix Receiver versions

Citrix Receiver versions

A few days ago I was asked “how to you know which Citrix Receiver version is being used based on the build number?”. Well you just have to know 🙂

When monitoring your Citrix installation via either the defunct Citrix Edgesight or the more modern Citrix Director, you may be in need of finding out which version of Citrix Receiver is installed on the different end-points devices connecting to your Citrix XenApp or VDI’s

Both Edgesight and Director will show you the Citrix Receiver “product version”, and not the actual version, like Citrix Receiver 4.9.

I have created this small overview of the Citrix Receiver versions and the corresponding “product version”:

Citrix Receiver versions for Windows

Receiver versionProduct Version
3.013.0.0
3.113.1.0
3.213.1.200
3.313.3.0
3.413.4.0
4.014.0.0
4.114.1.0
4.1 CU114.1.200
4.214.2.0
4.314.3.0
4.3.10014.3.100
4.414.4.0
4.4 CU114.4.1000
4.514.5.0
4.614.6.0
4.714.7.0
4.814.8.0
4.9 LTSR CU214.9.2000
4.1014.10.0
4.10.114.10.1
4.1114.11.0
4.1214.12.0

I’ll keep this list updated as Citrix releases new Citrix Receiver versions and try to add the versions from other operating systems as well.

Update – 16-08-2018:

Citrix has release the Citrix Workspace App client which is the successor to Citrix Receiver. The Citrix Workspace App does not have the same version information as Citrix Receiver, as it is now a so called evergreen application. This means that the only version information availbale is going to be in the same format as Microsoft uses, ie Citrix Workspace App 1808, which indicates that this particular Citrix Workspace App version was released in august (08) of 2018.

The latest Citrix Workspace App client can be downloaded here – https://www.citrix.com/downloads/workspace-app/

User Profiles…the struggle is real!

User Profiles…the struggle is real!

During the last couple of years I have seen that managing user profiles in a Citrix environment can be a major PITA. However before going any further, let’s take a few steps back in time.

In the good old days in the world of Citrix, with Windows Server 2008 R2 and Windows 7, everything was nice and quite in the user profile area. We were happily rolling along with Citrix User Profile Manager, telling ourselves that the old, dusty and rather unstable Windows Roaming Profile was a thing of the past and no one would ever be using that again. We were managing User Profiles like a boss, with fine tuned configurations preventing profile bloating, roaming of Internet Explorer cookies and passwords and perhaps roaming different files and folders outside the APPDATA\Roaming folder.

Fast forward to today, or a couple of years ago, Microsoft released Windows 10 and Windows Server 2016 and with them new Windows Profile versions.

Let’s have a quick look at the different Windows Profile versions dating back to Windows XP and Windows Server 2003:

UPDATE – 04/11-17: I have updated the table below to reflect the current Windows 10 versions.

Client Operating SystemServer Operating SystemOperating System VersionProfile Version/extension
Windows XPWindows Server 2003/2003 R2None
Windows VistaWindows Server 2008 V2
Windows 7Windows Server 2008 R2V2
Windows 8Windows Server 2012V3
Windows 8.1Windows Server 2012 R2V4
Windows 10V1507V5
Windows 10V1511 (November Update)V5
Windows 10Windows Server 2016V1607 (Anniversary Update)V6
Windows 10V1703 (Creators UpdateV6
Windows 10V1709 (Fall Creators Update)V6

 

You may have noticed that Windows 10 is currently offering 2 different Windows Profile versions, V5 and V6, and rumors are that the Windows 10 Fall Creators Update may present a V7 Windows Profile. This is where the struggle begins!

UPDATE – 04/11-17: Windows 10 v1709 (Fall Creators Update) did infact NOT present a V7 Windows Profile version. V1709 is still on V6, like v1703 and v1607.

As per this “Windows as a service” guide Windows 10 will receive 2 feature updates per year, a feature update is like the Anniversary Update or the Creators Update and even though Microsoft is boasting of an “outstanding app compatibility”, this isn’t really of much use to us, if they change the profile version. A profile version change will initially trigger a new profile to be created at login which means that we need to do some kind of profile migration between the old profile and the new profile, unless we really like to receive a lot of support calls about missing application settings or that no default printer is set, because something went wrong during the profile version upgrade.

If we are using Citrix Profile Manager this profile version upgrade is handled automatically, however do wo really want to do that? If we shortly revisit the good old times, we didn’t upgrade the user profiles when we migrated from Windows XP to Windows 7 or from Windows 7 to Windows 8 or Windows 10, did we? I sure didn’t and when is comes to traditional profile management I always recommend to do a profile migration NOT an upgrade!

In the good old times, a profile upgrade was always associated with a operating system upgrade. So when we are offered, at the moment, 2 different windows profile versions i Windows 10, in my mind that is the equivalent of an operating system upgrade, which means that the profile needs to be migrated as the functionality and stability of the profile cannot be guaranteed, if it’s upgraded.

In a Windows 10 VDI scenario this presents us with a couple of things to keep in mind. As per above guide, each feature update is maintained with so called quality updates every 18 months, so at least once every 18 months we need to upgrade our Windows 10 VDIs with a feature update. Let’s just assume, and I am NOT saying that this will be the case, but let’s just assume that Microsoft will upgrade the windows profile version every 18 months, this may not be a desirable scenario, as we need to maintain some kind of profile migration feature/script to be able to migrate the settings from the old profile to the new profile with the new version.

Some Citrix setups offer hundreds of different applications where all kinds of settings are saved in all kinds of places eg. files/folders/registry, this means that a potential migration feature/script needs to cover whether the settings of one or more applications needs to be migrated or not in case of a profile version upgrade. As applications come and go or gets upgraded these different places where applications might save their settings, will have to be maintained in what ever migration feature used, which then again means that we need to have a great deal of knowledge of our applications, not just how to install them, but also how and where their settings are saved.

Let’s take a look at how Citrix User Profile Manager can help us, some of the way, when upgrading Windows 10.

This is how a Citrix UPM share looks like, when a user has logged on from a Windows 10 v1511, Windows 10 v1607 and Windows 10 v1703:

This is achieved with the “Path to user store” in a Citrix UPM GPO configured like this:

The !CTX_OSNAME! and the !CTX_OSBITNESS! are both variables that can be used as a part of the profile share path. When these variables are combined you get a very flexible profile share path where a folder is created that corresponds to the operating system and the bitness of the operating system. This means that you would usually never need more than one profile share, when using Citrix User Profile Manager.

This configuration makes sure that a new profile is created when logging on to an upgraded Windows 10 computer with a new windows profile version.

You can omit the !CTX_OSNAME! and the !CTX_OSBITNESS! and point directly at the #SAMAccountName# variable, however this will create a profile folder for the user in the root of the share, which means that you will no longer have a folder named “Win10RS2x64”. If this is the case you now have a profile share that is “locked” to this specific version of Windows 10, that’s not wrong but it may present some issue at some point, as we essentially don’t want Windows or Citrix UPM to do profile upgrades.

One way or another we are in need of some way to transfer and/or migrate settings between different profile versions. You can of course bring out the big guns and go with RES or AppSense as they are perfectly capable of migrating profile and applications settings between different profile versions with their User Environment Management (UEM) solutions.

Liquidware is, compared to RES and AppSense, a smaller player in this area, however they have in their ProfileUnity product a way to migrate profile and application settings between different Windows versions and that of course includes Windows 10 as well. They also have disk based profiles, which really boosts the login performance.

You can of course also create your own profile and applications migration script, I have seen a few so I know they are out there.

To conclude – With Windows 10 we are, in my opinion, entering a new ara where we are basically doing operating system upgrades once every 12-18 months, this adds a bunch of additional tasks to our already long list of Citrix and Citrix related tasks. I think now would be a great time to implement some kind of UEM feature, to be able to manage and maintain the profile and applications settings in different user profile on different operating systems. Citrix User Profile Manager is, in my opinion, now considered the “old solution” together with the traditionel Windows Roaming Profile.

 

Why is FSLogix O365 Container essential when using Office 365?

Why is FSLogix O365 Container essential when using Office 365?

I have worked quite a bit with some of the products in the FSLogix Apps Suite, so it’s only natural that my first blog post is about one of the products in this suite.

FSLogix Office 365 Container is getting a lot of attention at the moment, and for good reason. It’s very easy to setup and dosn’t require much maintenance, once it’s up and running.

Microsoft MVP and Citrix Technology Professional Aaron Parker has written a nice guide on how to install FSLogix Profile Container and Office 365 Container.

For those of you who hasn’t heard of, or worked with, FSLogix Office 365 Container, I’ll provide you with a short introduction to the product.

FSLogix Office 365 Container provides the following:

  • Redirection and roaming of the Outlook OST file
  • Redirection and roaming of the user’s Windows Search Index
  • Redirection and roaming of the user’s OneDrive content

FSLogix is redirecting these features to a VHD/VHDX file/disk on the network. This means that we no longer have to deal with OST files or the OneDrive content in users profiles, OST and OneDrive sync usually means HUGE profiles and resyncs on every logon as OST and OneDrive isn’t roamed. As FSLogix uses the SMB3 protocol, it is possible to use block level transfer instead of file level transfer which is used with the traditional redirection features, this brings in a significant performance increase of the network traffic going in and out of the file server.

Another issue with the OST and OneDrive sync, is that the default paths are in the user’s profile which means that all writes go to the C-drive, and in a non-persistent Session Host or VDI setup we would usually like to have as few writes to the C-drive as possible, because writes consume our write cache which these days are usually in RAM.

Let’s say we have 10 users logging on to a Session Host. Each user has a 50GB mailbox in Office 365, as this is the default mailbox size in Office 365. According to Microsoft, we have to enable “Exchange Cached Mode” (OST file) when using an Exchange mail account in Office 365, to provide a better experience. This means that we now have to consider the amount of mail account data that needs to be synchronized down to the OST file.

Maybe each of the 10 users needs to synchronize at least 5GB of data, this is 50GB of data in total, all writes that goes to the C-drive. Our write cache is now long gone and our Session Host or VDI is currently caching to disk, which usually does not perform as well, as caching in RAM. This is just the user’s OST file, we haven’t even begun synchronizing the OneDrive content.

Microsoft’s solution to the OST issue, is to redirect the OST file to a network share. On the surface that may look like and easy and straight forward approach, however it does present us with a few other things to consider.

Microsoft didn’t design Outlook to store OST files on network drives, Outlook expects the OST file to be available at all times, this may not always be the case if storing an OST file on a network file share. All sorts of things can go wrong in that scenario.

A network outage may cut the connection to the OST file which means that it’s not available, hence Outlook stops working, until the OST file is available. A poor performing file server or storage subsystem may present it selves as if Outlook is not performing at an acceptable level.

Microsoft’s solution also presents another issue. The Outlook mailbox index is not roamed! This means the every single time a users logs on, Outlook and the Windows Search Indexer will start to do an index of the OST file. This may not be that big of an issue with 10 user’s 5Gb OST files, however imagine 20, 30 or maybe even 50GB OST files for hundreds or thousands of users, that may present a huge performance impact on the Session Host or VDI and the file server hosting the OST files.

Again we haven’t even started addressing the issues with OneDrive synchronization. Basically the scenario is the same, however as we cannot control how much data the user synchronizes to the local drive, this means that the amount of data may be way beyond the 50GB mark which just intensifies our current headache with the OST files and  Windows Search Index roaming.

If you are considering to switch to Office 365 or if you are already on Office 365, you may run into the issues mentioned and at the moment FSLogix provides a great and cost-effective solution to a potential major headache.

Feel free to signup for a fully functional 30 day evaluation of FSLogix Apps Suite and have a look at the other great products from FSLogix while you are at it.