Choosing ”HTML5 Receiver” vs ”Native Receiver” dynamically through Netscaler Rewrite Policies

After a user has authenticated on a NSGW vServer, the user will either be prompted to select which Receiver Type (HTML5 vs Native) he/she wants to use, or a choice will be made automatically depending on how well the user’s web browser manages to detect a local Citrix Receiver install. See below picture for an example of the prompt I’m referring to.

You can however get rid of below prompt, and at the same also have a mechanism that selects which Receiver Type that should be for a particular user or scenario. This is achieved through Netscaler Rewrite policies.

How does it work?

In a normal scenario, after the Receiver Type has been selected (either automatically or by user), then the cookie ‘CtxsClientDetectionDone=true’ will be created in the user’s web browser. If Native Receiver has been chosen, then the cookie ‘CtxsUserPreferredClient=Native’ will also be created. By using Rewrite Policies we can create these two cookies by ourselves for the user, and therefore suppress the prompt for the user and automatically choose which Receiver Type to use.

If HTML5 should be used, then we only want to apply the Rerwite policy ”RWP-RES-DISABLE-RECEIVER-CHECK” to suppress the prompt. When Netscaler sees that the cookie ‘CtxsUserPreferredClient’ Cookie is missing, it will default to HTML5 Receiver (this is dependent on your Storefront configuration – see further down). If we want to force the Native Receiver, we also apply the rewrite policy RWP-RES-SET-NATIVE-RECEIVER” to create the cookie ‘CtxsUserPreferredClient=Native’.

In below scenario, I have defined an Expression for my Rewrite Policy ‘RWP-RES-SET-NATIVE-RECEIVER’ to only apply if the user is connecting from IP subnet 10.240.5.0/24. You can also use ”HTTP.REQ.HEADER(\”User-Agent\”).CONTAINS(\”Chrome\”)” to only apply it to Chrome Users, or use most other type of Expressions. I tried to use HTTP.REQ.USER.ATTRIBUTE(1) and HTTP.REQ.USER.IS_MEMBEROF(\”GroupName\”) expressions, but it seems that these expressions will always evaluate to false for a Rewrite Policy bound to a VPN vServer, so they don’t work, which is a shame.

 

 

For the choice between Native Receiver and HTML5 Receiver to work, you will need to configure your Storefront so that both HTML5 and Native Receivers are possible, like below picture. If you configure ”Always use Receiver for HTML5” instead of ”Use Receiver for HTML5 if local Receiver is unavailable”, then it doesn’t matter that the cookie ‘CtxsUserPreferredClient=Native’ exists. Similarly, if you configure ”Install locally” instead of ”Use Receiver for HTML5 if local Receiver is unavailable”, then Native Receiver will always be used.

If you want want the dynamic choice between HTML5 and Native Receiver, then don’t use ”Use Receiver for HTML5 if local Receiver is unavailable” and only create the ‘CtxsClientDetectionDone’ cookie to suppress the unnecessary prompt for the user.

Feel free to email me at rasmus.kindberg@xenit.se if you have any suggestions or questions related to this blog post.



Automate tasks with use of XenServer Powershell Module

Working with backups of your virtual machines is obviously essential. Working with exports in XenServer can some times be time consuming, particularly with bigger virtual disks attached to your virtual machine. In this scenario I will show you an alternative to manually export via XenCenter, by doing it with Powershell to an remote server using XenServer Powershell module.



Flickering Desktop Icons and re-directed folders

This blog post will only cover a scenario with Microsoft Windows Server 2016 Remote Desktop Services (RDS) and re-directed folders where flickering icons appear. Other solutions may apply to different scenarios.
Since the release of Windows 10 / Server 2016 and their different releases 1607, 1703, 1709 and 1803 there has been several issues regarding flickering icons on the Start-menu, in File Explorer and taskbar.

SCENARIO

During the deployment of Citrix Virtual Apps and Desktops 7.15 on Windows Server 2016 with published Desktops and re-directed Desktop folder, users could experience that the desktop icons kept flickering continuously. The more shortcuts, folders or files on the Desktop the more prevalent the issue was. Constantly blinking icons on the desktop looked like refreshing the desktop with F5 or Ctrl+R and would also flash when browsing network shares.

My first thought was to activate ”Always show icons, never thumbnails” in Folder Options since there seemed to be a constant query to network shares where the re-directed Desktop folder resided.

File Explorer - Options

File Explorer – Options

File Explorer - Always show icons

File Explorer – Always show icons

INVESTIGATION

The moment I clicked on View in Folder Options the desktop icons ceased flashing in my session. Dwelling deeper with Procmon investigating what actually happens when opening View tab in Folder Options I found out that explorer.exe queries a registry key in the users HKEY_CURRENT_USER registry. If the registry entry does not exist it will be created.

  • HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{031E4825-7B94-4dc3-B131-E946B44C8DD5}
Explorer query and creation of registry key

ProcMon – Explorer.exe query and creation of registry key

SOLUTION

With the knowledge that the registry key was missing and creating they key would stop the icons from flashing for users on Windows Server 2016 RDS, the appropriate solution was to use Group Policy Preferences (GPP) that created the registry key for users during logon (run in logged-on users’s security context) and apply it to Windows 2016 RDS servers.
Gorup Policy Preferences - User Configuration - Registry

Gorup Policy Preferences – User Configuration – Registry

Apply to Current User

Apply to HKEY_CURRENT_USER and set Key Path

Run in logged-on users security context

Run in logged-on users security context

Step 1: Create a USER GPP that will be applied to affected targets

Step 2: Create a Registry Item

Step 3: Add registry key

  • Hive: HKEY_CURRENT_USER
  • Key Path: SOFTWARE\Classes\CLSID\{031E4825-7B94-4dc3-B131-E946B44C8DD5}
  • Tab Common: [v] Run in logged-on user’s security context (user policy option)

If you have any questions regarding above solution, or ideas on how to handle above in a better way, please contact me at viktor.glinski@xenit.se or post a comment below.



Netscaler: ADFS protected by AAA – How to handle SAML POST requests

A limitation with Netscaler AAA is that it cannot handle FormData sent in a POST request to a Netscaler LB vServer that is protected by a AAA vServer. What happens is that the Form data in the POST will not be included when the user is redirected back to the LB vServer after AAA authentication. This becomes relevant in scenarios where you have a SAML ServiceProvider (SP) that is configured to do a login POST to an SAML IdentityProvider (IDP) and that IDP is protected by Netscaler AAA.

Below is the process flow:
1. User browses to the SAML SP address https://app1.somedomain.com/saml/login, which in this scenario is the URL that initiates the SAML logon process
2. The SP gives the user a SAML request and the user’s browser performs a POST against the IDP URL https://adfs.mycompany.com/adfs/ls/ with this SAML Request as the Form data.
3. The address https://adfs.mycompany.com points to a Netscaler LB vServer which is protected by AAA, so when Netscaler sees the incoming GET request above it will redirect the user to https://aaa.mycompany.com for AAA authentication (we assume the user has not authenticated against this AAA vServer this web session).
4. User performs AAA authentication, and is afterwards redirected back to the original URL https://adfs.mycompany.com/adfs/ls. HOWEVER, the SAML Request Form data is now missing.
5. User will land on https://adfs.mycompany.com/adfs/ls and receive an error message, because the ADFS server doesn’t know how to handle a request that doesn’t have any SAML form data.

 

Important notes:

  • Form Data passed along with a POST to a LB vServer, such as ADFS, that is protected by AAA will be ‘dropped’ when the user is redirected back to the LB vServer after successful AAA authentication. This only applies if the user has not authenticated against the AAA in the current web session (ie the user does not have a NSC_TMAS cookie). We will make use of this later on.
  • Query values included in a POST are not ‘dropped’, so this flaw is limited to Form data only.

 

Solution/work-around:
The easiest solution is to simply ask the SAML SP to use Redirect instead of POST for the SAML authentication process, but if that is not an option (the SAML SP’s backend code or configuration doesn’t support SAML Redirect) then below is a work-around I’ve been using. Basically what you do is that you store the original SP URL, https://app1.somedomain.com/saml/login, in a cookie in the user’s browser and in step 5 the user will be redirected back to this URL again.

Below is the process flow with a work-around implemented for POST:
1. User browses to https://app1.somedomain.com/saml/login, which in this scenario is the url that initiates the SAML logon process
2. The SP gives the user a SAML request and the user’s browser performs a POST against the IDP URL https://adfs.mycompany.com/adfs/ls/ with this SAML Request as the Form data.
3. The address adfs.mycompany.com points to a Netscaler LB vServer which is protected by AAA, so when Netscaler sees the incoming GET request above it will redirect the user to https://aaa.mycompany.com for AAA authentication.
3b. NEW: When the user is redirected to https://aaa.mycompany.com now, a Rewrite policy will trigger that will create a cookie ”ADFSPostCookieURL” for the user, and this cookie will contain the value ”https://app1.somedomain.com/saml/login”.
4. User performs AAA authentication, and is afterwards redirected back to the original URL https://adfs.mycompany.com/adfs/ls.
5. NEW: We have a Responder policy on our ADFS LB vServer that checks if the path is ”/adfs/ls” and if the cookie ”ADFSPostCookieURL” exists, and if both are true then we read the value in cookie ”ADFSPostCookieURL” and Redirects the user to that URL.
6. User is redirected back to https://app1.somedomain.com/saml/login, which will restart the SAML logon process
7. The SP gives the user a new SAML request and the user’s browser again performs a POST against the IDP URL https://adfs.mycompany.com/adfs/ls/ with this SAML Request as the Form data.
8. A key difference now is that the user already has done AAA authentication this web session and thus has a valid AAA cookie, and won’t be redirected to https://aaa.mycompany.com for authentication. The POST against https://adfs.mycompany.com/adfs/ls/ will therefore happen successfully and the ADFS backend server will see the SAML Form data since that has not been dropped by AAA redirect.
9. Assuming the SAML Request ticket is valid, the ADFS server will give the user a SAML Response ticket and redirect the user to https://app1.somedomain.com/myApp and the user is now logged on to this 3rd party site successfully.

 

Takeaways:

  • Our workaround revolves around storing the original url (https://app1.somedomain.com/saml/login) in some way so we can access it later, and requesting a SAML Request ticket twice from our SAML SP because in the second round we will not be bothered by AAA authentication.
  • Above solution is a bit hacky and involves requesting double SAML tickets from the SP, and there are a lot of Redirects involved, but it works well from an end-user perspective and it enables us to support SAML Post in conjunction with AAA.

 

If you have any questions regarding above solution, or ideas on how to handle above scenario in a better way, please contact me at rasmus.kindberg@xenit.se.

 

 

Below is the Netscaler configuration:



Specific computer model not joining the domain.

I recently had an issue with a specific computer model not joining the domain. The Task Sequence had not been updated for a while, and we had not done any significant changes to the environment. With other computers working flawlessly, we had issues with a HP EliteDesk 800 G3 DM 35W not joining the domain for some unclear reason. This was the start of an interesting discovery.

The issue began when this EliteDesk 800 G3 wouldn’t join the domain. Usually when a Task Sequence finishes, the computer reboots and you see a login screen, stating the domain and asking for credentials, as shown in this picture.

Usual image after a successful Task Sequence

This time the EliteDesk didn’t show any domain, just asking for local Administrator credentials. My first guess was network drivers, so I started by updating the boot image with fresh network drivers for EliteDesk 800 G3. Even with up-to-date drivers the computer wouldn’t join the domain. I started going through the SMSTSLog, BDD.log, checked if something had failed during the Task Sequence. No errors were found. But still, the computer would not join the domain.

I started digging deeper and went through the “panther\UnattendGC\setupact.log” and the “debug\NetSetup.log”. It was here where I started to find some interesting issues.

We have an environment built around an OU structure based on location and computer type (desktop, laptop or virtual machine). The ComputerTypeOU property is saved in to a variable used in the Task Sequence. What OU the computer is added to is decided in the CustomSettings.ini-file. 

In both the setupact.log and NetSetup.log I found out that no value was saved in the “%ComputerTypeOU%”-variable.

NetSetup.Log of EliteDesk 800 G3 DM 35W

My initial thought was that the log prints the string without any value connected to the variable, but after going through the same logs on a newly installed computer, that had no issues joining the domain, I quickly found out that I was wrong. The variable should definitely contain the value generated by the CustomSettings.ini file.

NetSetup.Log of EliteBook Folio 9480m

As shown in the first image, the EliteDesk 800 G3 did for some reason not receive any value to this variable. I started going through logs once more, trying to find out why this computer was unable to fetch the required value.

Since we unfortunately do not have an OU named “%ComputerTypeOU%” in the domain, and the Join Domain-account was unable to create one, the computer did not join the domain because of the account used in our Task Sequence having insufficient rights.

But why this variable was missing its value was the main question. I started going through logs again, and this time I had something to look for instead of searching for the unknown. The BDD.log gave me a good overview of all the client properties. I compared a domain joined client with the EliteDesk 800 G3. Here I stumbled upon an interesting fact. The EliteDesk did not report as a laptop, a desktop nor a server, as shown below.

BDD.Log of a EliteDesk 800 G3 DM 35W

BDD.Log of a EliteBook Folio 9480m

 

Since the EliteDesk 800 G3 did not report any of the values needed for our structure, the solution was to add Model to the Priority list and associate EliteDesk 800 G3 with the “ComputerTypeOU”-property set to workstations.

After adding the Model property to the CustomSettings.ini file, the EliteDesk 800 G3 joined the domain flawlessly after running a Task Sequence.

This might not be the best solution to this matter, but it sure is a practicable fix. If anyone has a preferable solution, feel free to email me at johan.nilsson@xenit.se



Citrix Synergy 2018 highlights

Synergy is Citrix main event and Xenit are of course on site to try out new features and solutions. The conference includes both a business-oriented and technical track for customers and partners. Måns Hurtigh, Simon Gottschlag (CTP), Adam Clark and Linus Lindström from Xenit are on site to test the latest Citrix products and features. Citrix CEO, David Henshall opened Synergy by talking about their key strategic priorities for 2018. Mainly there are three key areas that Citrix is talking about:

 

  • Unify Citrix portfolio to simplify user and IT experiences
  • Accelerate to the cloud to help companies work the way they want
  • Expand to new areas to meet the demands of the future

 

David Henshall continued by speaking about Citrix’s goals and strategies for 2018. Citrix announced several items this year that focuses on expanding Citrix Cloud with more features and unifying their already market leading products. A lot of new product and features were introduced:

 

  • Citrix Workspace App
  • Workspace Self-service with ServiceNow
  • Autoscale for Google Cloud
  • Citrix endpoint management capabilities
  • Citrix Cloud for Azure Government
  • Citrix Cloud App Control
  • SD-WAN Server for managed service providers (MSP)
  • Citrix Intelligent Traffic Management

 

Citrix Synergy 2018, David Henshall

On Summit 2017 Citrix talked about unifying there whole product series. It sure seems that Citrix is continuing down this path. Citrix slogan this year is ”The future is now”. Be sure to check out all new cool features in from this years Citrix Synergy.

 



Upgrade Task Sequence (1803) with BitLocker active

With the new 1803 feature update for Windows 10 we got some new and exciting commands for the Windows Setup that we can use in a upgrade task sequence in SCCM to be able to upgrade without suspending BitLocker. For more information about the 1803 feature update, please see this blogpost.

With these new Setup commands you can set a specific value in your task sequence that will try to keep BitLocker active or force it to be active during the upgrade. You can also use the AlwaysSuspend option but as the word explains this will actually suspend BitLocker and that’s not what we want in this post. The different commands are as follows:

  • /BitLocker TryKeepActive
  • /BitLocker ForceKeepActive
  • /BitLocker AlwaysSuspend

In your upgrade task sequence you need to set the variable OSDSetupAdditionalUpgradeOptions to one of the options above depending on how you want the upgrade to handle BitLocker. In this scenario we are using the /BitLocker TryKeepActive value that will attempt to do the upgrade without suspending BitLocker, but if the upgrade fails, Windows Setup will suspend BitLocker and complete the upgrade.

Please note that there are some requirements to get this setup to work.

  • The device being upgraded should be Windows 10 1709 or higher.
  • The Windows device needs to be using Secure Boot and have a TPM.
  • BitLocker needs to be using a TPM protector only.
  • The user profile folder can’t be on a separate volume that is also BitLocker protected.

 

If setup correctly you will find that the command line for the Windows Setup upgrade will add the /BitLocker TryKeepActive to it, as shown below. This can be viewed in the smsts.log.

 

If you have any questions, feel free to email me at tobias.sandberg@xenit.se.



Palo Alto introduces new feature to support Terminal Service (TS) Agent on Windows Server 2016

In the latest release of Palo Alto Networks Terminal Service Agent 8.1.1, we were introduced to a new feature where it is now supported to install the agent on Windows Server 2016.

This is a very welcome feature that a lot of us have been waiting for. There are no other features added to this version or the one before.

This release is also compatible with all the PAN-OS versions that Palo Alto Networks still support.

For more information see:

Where Can I Install the Terminal Service (TS) Agent?

Release Notes – Terminal Service Agent 8.1



Spring Creators update (1803) for Windows 10

Microsoft released the next feature update on April 30th 2018 that we all have been waiting for. The Spring Creators update (Version 1803) for Windows 10.

It comes with a bunch of new features and I will list some of them that you can benefit from in a deployment perspective.

 

Windows Autopilot

Now enables locking the device during provisioning during the Windows Out Of Box Experience (OOBE) until policies and settings for the device get provisioned.

This means that by the time the user gets to the desktop, the device is secured and configured correctly and can be used right away.

Windows 10 in S mode

The new Windows 10 mode suitable for affordable, cloud-ready devices that offers simple, secure and efficient use for tailored solutions like kiosk, digital sign and task work.

In S mode you will get the following features:

Windows Setup

The ability to control BitLocker under setup with the following commands:

OS uninstall period

Control the OS uninstall period with Intune or DISM.

Windows 10 Subscription Activation

Now supports Inherited Activation that allows Windows 10 virtual machines to inherit activation state from their Windows 10 host.

Feature update improvements

Reduced the time it takes to install the feature update with up to 63% from the Creators Update.

 

Read more about the newest version here.

Very important to notice is the features that Microsoft has removed or not developing anymore. Please see this article for all information about that.

 

Our recommendation is to download this update right now and deploy it to your designated test group. This is an important step to find out if any of your business applications have compatibility issues with the new feature update so you take actions as fast as possible. When you are done with the testing and the feature update (1803) goes Business Ready (usually in a couple of months), you are ready to roll out the update to the rest of the company so everyone can take benefit of the new features.

 

If you have any questions, feel free to email me at tobias.sandberg@xenit.se.

 



Use PowerShell & Windows Update to force drivers to be downloaded from the Internet in a Task Sequence

Working with client driver packages for me is related to a never-ending story. Drivers are frequently being updated and results in manually handling updates of Driver Packages in Configuration Manager. But since some computer manufacturers are releasing updates through Windows Update, so we thought; What if you can use a Task Sequence to force Windows Update to look for updates and drivers over the Internet instead of using manually handled Driver Packages? So I decided to try with a Surface Book.

With help from the PowerShell Module PSWindowsUpdate, created by Michal Gajda (downloaded from TechNet), and with a post from Waingrositblog, I had all the necessary bits forcing a Surface Book to download drivers from Windows Update, over the Internet, while running a Task Sequence. I started by modifying the steps, created by Waingrositblog, in the Task Sequence steps a bit. I found having one step running a PowerShell script instead of three steps, two of which was running cmd lines, more suitable.

This image illustrates the Task Sequence step.

I added the update step just after applying Windows- and Network Settings, where we usually apply driver packages.

The RPS (Run PowerShell) – Microsoft Update step is running the following script:

To verify the success of the script I went through the WindowsUpdateLog.Log and found that during the Task Sequence, a lot of drivers were installed. Here I would like to use PCI drivers as an example. As shown in the image below, the WindowsUpdateLog successfully downloaded and applied the drivers.

This is the WindowsUpdateLog.Log generated after successfully running the Update Drivers sequence.

I also tried the running the Task Sequence without the Windows Update / Driver script and found out the device had conflicts with the PCI drivers. These drivers is just used as an example in this process, there are several conflicts and other drivers missing as shown in the image below.

This image illustrates conflicts with, among others, the PCI drivers after not running the Update Drivers sequence.

This image illustrates when the drivers are applied.

As shown in these images, the Install Driver step running in the Task Sequence finds the correct and necessary drivers. After a Task Sequence successfully has gone through no exclamation marks are found in the Device Manager.

Some computer manufacturers are using Windows Update as a secondary source for updates, and because of this some drivers can be out of date. This is a reason why the Surface is a great example of using Windows Update for drivers since Microsoft release their updates, up to date.

If you have any questions, opinions or improvements, feel free to email me at Johan.Nilsson@Xenit.se