Skip to content

Upgrading Citrix NetScaler 10.5 to 11–SharePoint Websites might fail to load

During the last weeks I was facing a really strange problem. After upgrading a NetScaler from Version 10.5 to 11 one specific SharePoint Website was not accessible any longer. Either it looked like this – so it was not completely loaded:
(As you can see the browser showed “ERR_CONNECTION_ABORTED”.)

Sometimes it even directly stopped when “Is loaded” was shown.

Interestingly other websites – opened through the same NetScaler – worked without any problems. Furthermore there were no specific Actions / Policy bound to the Virtual Server – it was just a load balancer.

We tested different things and even debugged our Backend-Systems. Unfortunately we didn’t find any problems. Luckily one day I discussed the problem with a Citrix SE. He told me that he was facing the same problem when the NetScaler Insight Center (and so AppFlow) was used to monitor a Virtual Server. I checked the Insight Center and guess what – the Insight was enabled for the Website which failed to load after the NetScaler Upgrade.
netscaler insight center

So i disabled the monitoring – upgraded the NetScaler – checked the website – Problem fixed Smile
I still don’t get why AppFlow prevents loading a load balanced WebSite – but if you have problems like that just try to disable AppFlow.

Microsoft Exchange 2016 and 2010 coexistence – Outook shows login promt

During a migration from Exchange 2010 to Exchange 2016 I was facing a strange problem. Users with a Mailbox on 2016 always received a login prompt when they started Outlook.

The problem only happened for users that had access to public folders (still hosted on Exchange 2010) or mailboxes that also had not been migrated. If you start to google for the problem, the first hint you get is to change the Outlook Anywhere Authentication on Exchange 2016 (the default now is Negotiate) to NTLM. Ok – let’s check the current settings with PowerShell (Exchange Management Shell) for each CAS-Server:

Get-OutlookAnywhere –server SERVERNAME

Exchange 2016:
Already Ntlm – so let’s check 2010:
As you can see this was still Basic.

Interestingly the Exchange 2010 Shell shows the option ClientAuthenticationMethod – while the 2016 Shell shows InternalClientAuthenticationMethod AND ExternalClientAuthenticationMethod.

Time to change the Exchange 2010 CAS to NTLM Authentication:

Set-OutlookAnywhere -Identity "SERVERNAME\Rpc (Default Web Site)" -ClientAuthenticationMethod ntlm

Restart IIS to make sure the setting is applied (CMD – IISRESET):

Unfortunately this didn’t fix the problem Sad smile So time to look for other solutions. I then found Hotfix 2990117 from Microsoft which exactly described our problem. I downloaded the hotfix – but the installation “failed”. There was no error message nor anything else – the installation just started fine but never finished. Luckily the Hotfix also describes a workaround:

Open the IIS Manager on the 2010 CAS and go to Application Pools => DefaultAppPool and choose Advanced Settings on the right side.

Go to Identity and press “…”.

Now switch the setting to NetworkService.

After this confirm the settings with OK (twice) and press Recycle on the right side in the IIS Console (when the Default-App-Pool is selected). To make sure everything is applied correctly I also did an IISRESET. First I only changed the setting on the 2010 CAS-Servers – than also on 2016. But guess – still the same problem :/

Time to check the information’s that I had until now. All information’s that are available point to an Authentication Problem. Mainly Exchange 2016 uses different methods compared to 2010. So it’s often suggested to change the settings to NTLM. What happens if Outlook uses Outlook Anywhere? It “opens” the RPC Website. Let’s check the Authentication settings for the RPC Website:

Open IIS Manager and go to  Sites => Default Web Site => RPC => Authentication

Now select Windows Authentication =>  Providers.

We can now see that Negotiate is the first configured provider. If we now remember that we had to switch our Outlook Anywhere Settings for Exchange 2016 to NTLM to make it compatible with 2010 this doesn’t sound correct.

So I moved NTLM to the top and restarted the IIS (IISRESET).

I repeated this on every other Exchange 2010 CAS-Server and 2016 Server – and after that the login prompt didn’t occur any longer. To make this a permanent change (and remove Negotiate until all Exchange 2010 Servers are removed) enter the following command for every Exchange-Server:

Get-OutlookAnywhere -Identity "SERVER-FQDN\rpc (Default Web Site)" | Set-OutlookAnywhere -IISAuthenticationMethods "Basic, ntlm"

After switching back the App-Pool-Identity to AppliactionPoolIdentity some clients (especially Outlook 2016) again showed the login prompt – so I think it’s necessary to change both settings.

Creating a Citrix NetScaler Redirect Policy for StoreFront Web

When a user tries to access Citrix StoreFront with a Web browser he needs to know the full path to the (default) WebStore – if no redirection is configured. You can either configure this on each StoreFront Server through the IIS or on a load balancer (eg NetScaler) in front of them. Thus I would like to show you how to configure this redirection on a NetScaler:

1.Open the Load Balancing Virtual Server for StoreFront
2014-10-24 08_45_47-Citrix NetScaler VPX - Configuration - Internet Explorer

2. Under Advanced activate Policies and add one (+).
2014-10-24 08_45_57-Citrix NetScaler VPX - Configuration - Internet Explorer

3.Choose the following configuration:
Policy: Rewrite
Type: Request
2014-10-24 08_46_19-Citrix NetScaler VPX - Configuration - Internet Explorer

4.Select “+” next to “Select Policy” to add a Policy.
2016-02-17 13_15_49-Heizungsverteiler _ Heizung KNX - OneNote

5. Enter a Name for the policy and add a new Action (“+” under Action).

6.Enter a name for the policy and configure the following settings:
Expression to choose target location: HTTP.REQ.URL
Expression to Replace with: “/Citrix/StoreWeb” (If you are not using the default StoreWeb Url replace this with your Url – but only the folder part).
Confirm the settings with Create.

7. With the Action we configured what happens – now we need to configure when the action is applied. Thus you enter the following for the Expression:
To create the Policy with the configured action press Create.

8.The last step is to bind the policy to the Virtual Server (Bind). We do not have to configure anything like Priority because for this only one policy is necessary.

9. That’s it – the policy is now bound to the Virtual Server and users are automatically redirected to the StoreFront Website.

[UPDATE] Printing from the Internet Explorer Print Preview fails with Citrix UPS 7.X


Citrix created a private Hotfix (LC4735v2) that solves the problem.



It looks like there is a bug if you use the Citrix Universal Print Server 7.7 and try to print out of the Internet Explorer print preview. If you open the print preview and try to print the following error message is shown:

There was an internal error, and Internet Explorer is unable to print this document.

ie error

To solve the error, you have to change the Universal driver preference. Create a new Citrix User Policy (or modify one) and move the EMF down – with XPS as the first preference the error does not occur.

universal driver preference

We have created a ticket at Citrix – it looks like different customers have the same problem. A developer is investigation the error. I will update this post when we received a solution from Citrix.

Upgrade to Citrix XenDesktop 7.7 – no Zones shown

After one of my last upgrades to XenDesktop 7.7 the Studio didn’t show the new available “Zones”.

Luckily Kyle Wise had the same problem and already documented how to fix it.

The solution is quite easy – you just need to open PowerShell on a Delivery Controller and enter some commands.

  1. Import the Citrix-Snapins
    Add-PSSnapin Citrix*
  2. Switch to this folder:
    C:\Program Files\Citrix\XenDesktopPoshSdk\Module\Citrix.XenDesktop.Admin.V1\Citrix.XenDesktop.Admin
  3. Run the following script:
    Import-AdminRoleConfiguration .\

After doing this restart the Studio to check out the new available Zones:

Office 2010 Mui leads to big Citrix UPM Profiles

Shortly after going live with a Citrix XenApp 7.6 environment I saw a massive growing of a lot of profiles- Their size was often more than 60MB – even if it was a task worker which only used the ERP Application and Microsoft Word. After checking the UPM Profile I found the reason for the big profiles – it was the Document Building Blocks folder from Microsoft Office under Appdata.
2014-11-24 11_28_01-RDS - DEDAM-SV0432 - Royal TS

(I know that there are some reasons for redirecting AppData but that wasn’t possible here and I had some problems with Programs when AppData was redirected in the past).

Inside the folder the following subfolders had been created:
2014-11-24 11_27_31-RDS - DEDAM-SV0432 - Royal TS

In the environment Microsoft Office was installed with different language packs. For each installed language a separate Document Building Blocks folder was created for each user using Office. In the following Technet Article is described that this behavior is by design. The workarounds is to move the files to a shared folder.

Another possibility is to remove it from the UPM Profile – but this has one side effect. Every time Word is started they are recreated. The easiest way to achieve this in Citrix UPM is to create (or change) a UPM Group Policy and add the folder to the Exclusion list:
2015-06-03 12_20_24-RDS - DEDAM-SV421 - Royal TS

AppData\Roaming\Microsoft\Document Building Blocks

XenDesktop 7.6 Black Screen issue with VMWare SVGA 3D Driver

During the last weeks I was facing a strange black screen problem in a XenDesktop 7.6 environment. A rollout for a new division was planned. An image was created and deployed with MCS. One user was chosen to test if everything is working. During the first few days everything was working fine. But after a few days the user always saw a black screen after logging in – nothing more. Interestingly this only happened when he arrived in the morning. Though after successfully logging in it was possible to logout and login again (to another VM) without any problems. When we tried to reproduce it this was nearly impossible – only sometimes the same problem was happening with our test user. But also this only happened at the first login in the morning.

We started to search for solutions and tried the following ones:

First we activated the Legacy graphics mode and assigned it to the affected VMs.
2015-04-02 15_47_18-RDS - DEDAM-SV421 - Royal TS

Then we disabled the Desktop Composition Redirection.
2015-04-02 16_14_41-RDS - DEDAM-SV421 - Royal TS

Still the black screen occurred. So we changed the Receiver Version (a Thin Client with Linux was used) from 12 to 13 – but it was still the same. So we decided to test it with a Windows Client and Receiver 4.2. But as you expect – still the same.

So it was time for a more intensive debugging.

We changed the following registry entries to make sure there is no problem with the MFAPHOOK:

Path: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows
Name: AppInit_DLLs

Path: HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows
Name: AppInit_DLLs

As you can see in the following screenshots the value always contained the full before path.

2015-02-12 14_23_34-dedam-wv300 win_7-x64-Personalabteilung on

2015-02-12 14_24_26-dedam-wv300 win_7-x64-Personalabteilung on

2015-02-12 14_27_10-dedam-wv300 win_7-x64-Personalabteilung on

After:2015-02-12 14_28_13-dedam-wv300 win_7-x64-Personalabteilung on

The next step was to modify some Graphics Drivers Registry settings. We renamed the following keys to .old and restarted the VMs.



2015-05-06 12_40_25-dedam-ctxwv0509 on

After the reboot the keys had been recreated – with different sub keys.
2015-05-06 12_46_11-dedam-ctxwv0509 on

After trying all of these settings I remembered a case where I had the same problem with XenDesktop 5.x – the solution was to remove the VMWare SVGA-Driver. So we now also removed the driver.
2015-05-06 12_52_01-dedam-ctxwv0509 on

After removing the driver the Graphics-Card was shown as “Default-VGA-GraphicsCard” (with a Warning).
2015-05-06 12_54_20-dedam-ctxwv0509 on

And guess what? The black screen was gone. Furthermore we disabled Legacy Graphics Mode and enabled Desktop Composition Redirection – the black screen issue still didn’t happen any longer.

Citrix Receiver 4.2 – a valid replacement for Receiver 3.x Enterprise (aka Online Plugin)?

At the beginning of December 2014 Citrix released the Receiver 4.2. One of the biggest (and most mentioned) improvements is the better start menu integration (If you want to know how to configure it read this blog article).

The question now is: Is Receiver 4.2 a valid replacement for Receiver 3.x Enterprise?

To make it short – from my point of view it can be a replacement if you plan to use it on your fat clients and can live with some limitations – but not on published (RDS) desktops (or you need to live with bigger limitations). Let’s have a more detailed look why I think Citrix really needs to update / optimize the Receiver as soon as possible.

Fat Clients

Most of the users prefer to start their applications from the start menu – independent if it’s installed locally or published. The ideal world would look like this:
You install the Receiver, configure a GPO and the applications are directly published to the start menu – the user doesn’t need to open the Receiver and is happy. On fat clients this is working with some limitations with Receiver 4.2.

Startup Time / App Enumeration

After logging in the Receiver needs some time to start completely. Furthermore the app enumeration can take really long. There are some optimizations to speed up the App Enumeration a little bit – but only if you remove shortcuts at logoff or exit – it won’t help you if the user logs on for the first time. One way is to create the following registry key:

Name = ReuseStubs
Type = REG_SZ
Value = true

Application Refresh

In the default configuration the automatic refresh (after logging) in is not always working – with Receiver 3.x Enterprise the user logged on and a refresh of the published applications happened.
To activate the same refresh under Receiver 4.2 you need to configure the following registry keys (see CTX140244):

Name: InitialRefreshMinMs
Type: REG_SZ
Value: 1

Name: InitialRefreshMaxMs
Type: REG_SZ
Value: 1

Shorcut Removal

As known from Receiver Enterprise 3.x the Receiver 4.2 can automatically remove the created application shortcuts. The configuration for this has moved from the Webinterface to the Receiver. The easiest way to configure this is to create a GPO with the Receiver ADM files and configure the following settings:

Computer Configuration => Policies => Administrative Templates => Classic Administrative Templates (ADM) => Citrix Components => Citrix Receiver => SelfService => Manage App shortcut


Sounds easy or? It is – it’s only sometimes just not working. This means if someone exits or logs off Receiver the created shortcuts are not removed.

Warning of Removed Applications

Another thing is that the user always receives a notification if an application is no longer available for him. So if you remove the assignment of an application the user receives the following message:
2015-02-02 10_47_49-dedam-wv021 M42 Packaging Dev IP on

After clicking on this message the following is shown (if SelfServiceMode is disabled – otherwise the Receiver is shown and the removed application is greyed out):
2015-02-04 08_15_34-dedam-wv021 M42 Packaging Dev IP on

In CTX140244 you can find the following registry:

Type: REG_SZ
Value: True

After reading the description I thought that this would help me to prevent the above mentioned messages:

To prevent dialog boxes when resources are removed from the server, use the following command syntax:

Well – the setting disables a message – but only the second one so that the user doesn’t need to confirm the removal. The first message is still displayed.


XenApp (RDS) Desktop


All of the above things are also valid if you use the Receiver on a published desktop – but there is one more thing….

If you have a lot of Thin Clients (and I know a lot of environments where that is the case) you usually publish a full Desktop. Some of the assigned applications are installed on the same server while others are installed on different ones. The start menu is cleared. The user only sees the applications assigned to him (published through Receiver) and not all of the installed applications.
In the past the Receiver (3.x) checked if the application is installed locally and then starts it directly while the other are started remotely (also called remoting). This was easy to handle: Install application, clear start menu, publish application.

With Receiver 4.2 this isn’t working any longer – the application is always started remotely – even if it’s installed on the local server. To fix this some configurations need to be done:

  1. Create a folder on the Server with a shortcut for every application that is installed locally (of course only for the ones you plan to publish)
  2. Create the following Registry-Key
    • HKLM\SOFTWARE\Wow6432Node\Citrix\Dazzle
    • Type: REG_SZ
    • Name: PreferTemplateDirectory
  3. Change the application properties of every application that is installed on the published desktop and add the following description:
    • Replace SHORTCUTNAME with the name of the local saved shortcut (Step 1).

Though you can see it’s a lot more to do until you have the same behavior like with Receiver 3.x Enterprise.

Furthermore you need to know that if the Receiver detects a local shortcut it copies and renames this one to the Start Menu – it’s not a new Shortcut created with the settings of the published applications. This means if you change an application property (e.g. parameters) you always need to change this in the published application and in the local saved shortcut. Not nice…

During the last tests and implementations I figured out that after configuring the above mentioned settings – to prevent remoting – only some of the applications are published from the receiver to the start menu. After checking the edocs I saw the following statement:

Before installing an application on a user’s computer, Receiver searches for the specified patterns to determine if the application is installed locally. If it is, Receiver subscribes the application and does not create a shortcut. When the user starts the application from the Receiver window, Receiver starts the locally installed (preferred) application.

Interestingly in this blog post Thomas Fuhrmann says shortcuts are automatically created:

When using such a template directory (which can also be a network share) Citrix Receiver first checks in thatdesignated folder for a matching shortcut and then copies this shortcut to the start menu.

Sounds like even Citrix doesn’t know if shortcuts are copied – or not. During my tests shortcuts were only copied to the start menu when no application category was configured. As soon as this was configured – to structure the applications into folders – the shortcut was not longer published.
2015-01-23 13_56_29-RDS - DEDAM-SV421 - Royal TS

Until now I only found one solution for this; Remove the shortcut creation (on the published desktop) from the receiver and replace it with a simple script – until Citrix publishes a Receiver version which is working in all conditions. I am not a PowerShell Guru – so if you know how to make it better – just send me an information and I will update the script. The script first checks for existing shortcut and removes them to make sure that if an application is no longer assigned to a user it’s not visible any more. Then it creates the folders and shortcuts.

#Get Current User Informations and configure path to start menu
$CurrentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$WindowsPrincipal = New-Object System.Security.Principal.WindowsPrincipal($CurrentUser)

#Remove Existing Shortcut Folders
if (Test-Path "$StartMenuFolder\Programs\FOLDERNAME\" -PathType Container)
    Remove-Item "$StartMenuFolder\Programs\FOLDERNAME\" -Recurse

#Create Application Shortcut Example
if ($WindowsPrincipal.IsInRole("GROUP NAME") -eq "True")
    if (!(Test-Path "$StartMenuFolder\Programs\FOLDERNAME\" -PathType Container))
        New-Item -ItemType directory -Path "$StartMenuFolder\Programs\FOLDERNAME\"
    Copy-Item "C:\SHORTCUTPATH\SHORTCUTNAME.lnk" -Destination "$StartMenuFolder\Programs\FOLDERNAME\SHORTCUTNAME.lnk"


As you can see Citrix made some improvements (compared to the first 4.X releases) to get the receiver as good as it was before – but there are still a lot of things left. Hopefully Citrix will release a nice, fast and easy configurable Receiver in the near feature (and you know – the hope dies last). Actually I don’t understand why such an important component in the whole Citrix universe doesn’t get more attention.

Citrix Receiver 4.x Store configuration through Group Policy fails

In one of our last deployments we tried to configure the necessary Citrix Receiver Store Configuration on our VDAs through a Group Policy. Unfortunately it was not working. The GPO was applied – but no store was configured.

The interesting part of the problem was that on other clients the same GPO was working – the user logged on and the store was configured – like it should be. We first started to remove the Citrix, run the Receiver Cleanup Utility and reinstall the Receiver. But it was still the same problem – the store was not configured automatically.

After checking the differences between the clients we found a difference in the registry. On the working client the following registry (with the Store information) was available:


2014-11-07 11_52_33-OneDrive

This key was missing on the other client:

2014-11-07 11_54_05-dedam-ctxsv0009 win_2008r2-default-maintenance on

We exported the key from the working client and imported it on the not working client. If now a user logged on the Store was automatically configured – like it should be.

The question now was: Why is this key missing? Time to delete the key again and run a gpupdate /force to make sure all Group Policies are applied correctly. Check the registry again and – wohoo – the key is available. So everything looked fine – until we rebooted the VDA – the key was lost again. 
Interestingly other Receiver Configurations (like disabling SelfServiceMode) through the same GPO were applied correctly.

Though it was time to check what happens during the boot with procmon. Inside the procmon log we found some interesting results – the registry key was first created from the Microsoft GPO service and then deleted by the Citrix Group Policy engine.

2014-11-07 11_54_54-dedam-ctxsv0009 win_2008r2-default-maintenance on

Time to open a support ticket at Citrix. After some discussions and more testing we found the reason for the problem:
The Delivery Controllers had been configured through a GPO. This means that the VDA can only connect to the site after this GPO was applied. If the Citrix Group Policy engine starts and the VDA is not already connected to a Site every Citrix Policy is deleted. One of the deleted settings was the Receiver Store configuration (although that should be independent from other Citrix Policies). Interestingly other Receiver specific settings were not deleted.

Citrix developed a fix for this problem though that the Receiver Store configuration is not any longer deleted. Hopefully it will be integrated in the next Group Policy Client Side Extensions hotfix. If you have the same problem open a support case and ask for fix LC11637.

Installing a SSL Certificate on a Citrix NetScaler Insight Center Appliance

If you plan to connect your Citrix Director Installation to a NetScaler Insight Center Appliance and would like to use a HTTPS connection you need to exchange the SSL Certificate on the appliance again a trusted one.

The first step is to create a host entry for your NetScaler Insight Center Appliance (NSICA) on your internal DNS server. Then you need to create a certificate (split into a PEM and a KEY file) with the FQDN of your NSICA. After you have created the certificate open the NSICA configuration and switch to CONFIGURATION => NETSCAKER INSIGHT CENTER => SSL CERTIFICATE FILES2014-09-10 10_15_28-Citrix NetScaler Insight Center - Configuration - Internet Explorer

Click on ACTION and choose UPLOAD.
2014-09-10 10_15_52-Citrix NetScaler Insight Center - Configuration - Internet Explorer

Browse to your PEM File of the Certificate and Upload it to the NSICA.
2014-09-10 10_26_53-Citrix NetScaler Insight Center - Configuration - Internet Explorer

The PEM File should now be listed under “sdx_default_ssl_cert”.
2014-09-10 10_27_28-Citrix NetScaler Insight Center - Configuration - Internet Explorer

Switch to SSL KEYS and choose UPLOAD again.
2014-09-10 10_27_46-Citrix NetScaler Insight Center - Configuration - Internet Explorer

Browse for the KEY File of the Certificate and upload it.
2014-09-10 10_28_09-Citrix NetScaler Insight Center - Configuration - Internet Explorer

Like before the KEY File is now listed under “sdx_default_ssl_key”.
2014-09-10 10_28_30-Citrix NetScaler Insight Center - Configuration - Internet Explorer

After uploading the PEM and KEY file you need to navigate to SYSTEM => INSTALL SSL CERTIFICATE.
2014-09-10 10_29_14-Citrix NetScaler Insight Center - Configuration - Internet Explorer

Choose the just uploaded PEM and KEY File and confirm it with OK.
2014-09-10 10_30_35-Citrix NetScaler Insight Center - Configuration - Internet Explorer

After a necessary reboot the SSL Certificate is active and you can connect your Director to the NetScaler Insight Center Appliance using HTTPS.
2014-09-10 10_36_54-Citrix NetScaler Insight Center - Configuration - Internet Explorer

%d bloggers like this: