Launching XenApp 7.6 desktop published through NetScaler appliance throws the error: "The connection to "" failed with status (Unknown client error 1110)."

Problem

You attempt to launch a XenApp 7.6 desktop published through NetScaler appliance:

… but notices that you are presented with the following error message:

The connection to "<YourXenAppGroup>" failed with status (Unknown client error 1110).

Solution

One of the common reasons why this error would be thrown is if there is a misconfiguration or lack of Secure Ticket Authority (STA) configured in the load balancing virtual server on the NetScaler appliance.  To correct this issue, launch the properties of the load balancing virtual server representing the StoreFront servers, review the Published Applications settings and ensure that STA Servers are configured:

The message: "One of your on-premises Federation Service certificates is expiring..." is presented when you log into the Office 365 portal at https://portal.office.com

Problem

You’ve recently noticed that you receive the following message when logging into the Office 365 portal at https://portal.office.com:

One of your on-premises Federation Service certificates is expiring. Failure to renew the certificate and update trust properties within 27 days will result in a loss of access to all Office 365 services for all users.

You’ve checked your on-prem hosted ADFS server’s certificate and verified that it has not expired:

Solution

The following are 2 options I found after browsing the internet looking for an answer:

Option #1 – Manually renew the certificate

"One of your on-premises Federation Service certificates is expiring" message in the Office 365 portal

https://support.microsoft.com/en-ca/kb/2992335

Option #2 – Wait and allow certificate to auto renew

The following forum topic was responded by a Microsoft support representative indicating that the certificate should auto renew:

https://community.office365.com/en-us/f/613/t/173158

The day that I checked on the certificate was April 20 and launching the AD FS Management console on the ADFS server…

… then navigating to AD FS > Service > Certificates showed that the certificate was expiring on June 1 which was more than 20 days before the expiration date:

What I ended up doing was set up a calendar reminder on the 19 day before June 1 to check back and when I did on May 13, I noticed that the ADFS server had indeed renewed the Token-decrypting and Token-signing certificate the day before on May 12:

Logging onto Office 365 via https://portal.office.com also confirmed that the warning message was no longer displayed:

Unable to configure port group properties on distributed switch in vSphere Web Client

I’ve recently ran into an issue at a client’s vSphere 5.5 environment where I was unable to configure any properties of a port group on the distributed switches.  The properties of the environment are as follows:

vCenter Server version: 5.5.0, 3252642

ESXi version: 5.5.0, 3116895

I would attempt to use the vSphere Web Client as suggested by the following VMware documentation that demonstrates how to:

Filter Traffic on a Distributed Port or Uplink Port in the vSphere Web Client

http://pubs.vmware.com/vsphere-55/index.jsp?topic=%2Fcom.vmware.vsphere.networking.doc%2FGUID-55F4EC3B-B3F1-4D7A-9DCE-578C817BBA3F.html

… but quickly notice that setting the Status from Disabled:

… to Enabled:

… does not activate the configuration settings below.  Clicking on the OK button to save the configuration and then navigating back in shows that the Status is still set to Disabled:

Proceeding to any of the other tabs such as Advanced or Traffic shaping yields the same results:

After restarting vCenter and not having much luck in determining what the issue was, I opened a call to VMware to get a support engineer to assist.  The engineer did a few checks and wasn’t sure why this was happening so he got me to log in via the vSphere client to make a change to the Traffic Shaping settings which were successfully applied:

Then we went back into the vSphere Web Client to try changing the port group settings and quickly noticed all of them worked:

I asked the engineer if this was a bug and he said no so I’ll assume it is just a glitch.  Hope this helps anyone out there who may encounter this issue as I was not able to find any information about this on the internet.

Importing PFX certificate from Microsoft Windows Server into Citrix NetScaler VPX

One of the most common Citrix NetScaler questions I’ve been asked by colleagues and clients is how to import a PFX certificate from a Microsoft Windows Server into Citrix NetScaler and while there is a KB from Citrix demonstrating this process via the GUI:

How to Convert PFX Certificate to PEM Format for Use with NetScaler
http://support.citrix.com/article/CTX136444

… there did not appear to be any instructions performing this via the command line so this post serves to demonstrate the process.

Step #1 - Export the certificate to PFX

Begin by logging onto the server with the certificate installed, launch the certificate store (certlm.msc) and export the certificate with the private key as a PFX:

Step #2 (Optional) - Export the certificate to CER

Exporting the certificate as a CER file without the private key is optional as you can create the CER file from the PFX file on the NetScaler but if you are performing the export from the Microsoft server, go ahead and create this file as well:

Note that you should export the file as Base-64:

Step #3 - Upload PFX and CER file

With the files exported, proceed to upload them to the NetScaler’s /nsconfig/ssl directory with either WinSCP or via the web management portal by navigating to Traffic Management > SSL then click on Manage Certificates / Keys / CSRs:

Use the Upload button to upload the files:

Step #4 (Optional) - CER file

If you’ve exported the certificate without the private key as a .cer file then this step could be skipped but if you had no control over the export and was only given a .pfx file then you can execute the following commands to generate the .cer file on the NetScaler:

shell

cd /nsconfig/ssl

openssl pkcs12 -nokeys -in certificate.pfx -out certificate.cer

You should now see a .cer file:

Step #5 - Generate .KEY file

The next file we will need to generate is the key file (also known as pem) using the uploaded PFX that contains the private key. Proceed by executing the following commands:

shell

cd /nsconfig/ssl

openssl pkcs12 -nocerts -nodes -in certificate.pfx -out tempcertificate.key -des3

openssl rsa -in tempcertificate.key -out certificate.key

rm tempcertificate.key

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

***Note that the reason why we needed to create a tempcertificate.key file is because the following error would be thrown if we do not use the openssl rsa command to remove any hidden space control characters:

ERROR: Invalid private key, or PEM pass phrase required for this private key

See the following Citrix Knowledge Base article for more information:

ERROR: "Invalid private key, or PEM pass phrase required for this private key" on NetScaler Appliance
http://support.citrix.com/article/CTX134233

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

The commands displayed above is the equivalent of the operations performed in the GUI demonstrated in the following screenshots:

Step #6 – Installing Certificate onto the NetScaler

With the .key and .cer file on the NetScaler we can now proceed to install the certificate by executing the following command:

add ssl certKey www-contoso-com -cert certificate.cer -key certificate.key -password P@ssw0rd -expiryMonitor ENABLED -notificationPeriod 30

You can view the property details of newly installed certificate by executing the following command:

show ssl certKey www-contoso-com

The commands displayed above is the equivalent of the operations performed in the GUI demonstrated in the following screenshots:

Unable to start Microsoft CA service after migrating from Cryptographic Service Provider (CSP) to Key Storage Provider (KSP)

Problem

You’ve successfully completed the steps required to migrate your Microsoft CA (Certificate Authority) from Cryptographic Service Provider (CSP) to Key Storage Provider (KSP) after performing the steps outlined in the following TechNet guide:

Migrating a Certification Authority Key from a Cryptographic Service Provider (CSP) to a Key Storage Provider (KSP)
https://technet.microsoft.com/en-us/library/dn771627.aspx

However, you receive the following error when you attempt to start the CA service:

keyset does not exist 0x80090016 certificate services

Reviewing the System logs shows that the following is logged:

Event ID: 7024
Level: Error

The Active Directory Certificate Services service terminated with the following service-specific error:

Keyset does not exist

Solution

While there could be various solutions to correct the issue, one of the method that worked for my situation was to launch the CA’s Local Computer store, navigate to Personal > Certificates, delete all of the imported CA certificates:

Then rerun step #5 in the TechNet article:

https://technet.microsoft.com/en-us/library/dn771627.aspx

Migrate the CA certificate and private key to a KSP:

a.Run the following command:

Certutil –csp <KSP name> -importpfx <Your CA cert/key PFX file>

For example: Certutil –csp “Microsoft Software Key Storage Provider” –importpfx c:\Backup\CorpSubCA.p12

Once the CA’s certificate along with their private keys are reimported, the CA service should now start.

Using Citrix NetScaler Rewrite Action and Policy to prevent the Location HTTP header from exposing internal IP addresses

I was recently asked by a client to fix an issue with their Exchange 2013 Outlook Web Access webpage where an HTTP request to the site would expose the internal IP address of the Client Access Server in the Location HTTP header as shown in the following test performed with NMAP (https://nmap.org/download.html):

ncat 76.8.35.111 80
GET / HTTP/1.0

HTTP/1.1 301 Moved Permanently
Cache-Control: no-cache
Pragma: no-cache
Location: https://10.10.10.93/owa/
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Date: Thu, 05 May 2016 00:08:13 GMT
Connection: close
Content-Length: 0

The client referenced the following Microsoft KB but the article references an older version of IIS:

https://support.microsoft.com/en-us/kb/218180

After researching about the issue and not finding a way to correct this in IIS, I decided to use the Citrix NetScaler load balancer we were already using to publish OWA to rewrite the header to use the FQDN. The following are steps required.

Begin by creating a new Rewrite Action with the following configuration:

Name: act_location_header

Type: REPLACE

Expression to choose target location: HTTP.RES.HEADER("Location")

Expression to Replace with: https://webmail.domain.com/owa/

Once the Rewrite Action is created, proceed with creating a Rewrite Policy with the following configuration:

Name: pol_location_header
Action: act_location_header
Undefined-Result Action: -Global-undefined-result-action-
Expression: true

With the Rewrite Policy created, proceed with assigning it to the HTTP (not HTTPS) OWA Load Balancing Virtual Server that serves to redirect user requests to HTTPS:

Choose Policy: Rewrite
Choose Type: Response

Select the pol_location_header Rewrite policy:

Leave the rest of the settings as default and click on the Bind button:

Redoing the test will now show the Location header replaced with the FQDN: