Attaching Microsoft Project 2010 and Visio 2010 AppStacks to a virtual machine causes applications to display the message: “Microsoft Office cannot verify the license for this product. You should repair the Office program by using Control Panel.”

Problem

You have installed Office 2010 directly onto your base virtual machine master image then continue to create two separate AppStacks in VMware App Volumes.  With the AppStacks created, you proceed with assigning Microsoft Project 2010 to a VMware Horizon View VDI but notice that the following error message is presented when you try to launch Project 2010 or Visio 2010:

Microsoft Office cannot verify the license for this product. You should repair the Office program by using Control Panel.

Attempting to launch word no longer works either:

Unassigning either the Visio 2010 or Project 2010 AppStack removes the error.

Solution

As per the VMware App Volumes User’s Guide (https://www.vmware.com/pdf/app-volumes-26-users-guide.pdf) on page 47:

There are strict guidelines on how many AppStack with Office components can be attached at a time:

App Volumes with Microsoft Office 11

App Volumes supports KMS based licensing for Office. As result, MLF ISO media (available from the Microsoft Volume Licensing Service Center) must be used. KMS server/license details can be added during the provisioning process (by running ospp.vbs with appropriate options), or the default KMS discovery process will be used along with the default KMS license keys typically embedded in MLF ISO media.

The entire suite of Microsoft Office applications stores its product and license information in a common data file. No special user interaction is required and this process is completely seamless to the user. All product information is stored in a single data file. The following limitations exist:

To deliver Office applications via App Volumes, all Office applications must be in a single AppStack.
Note: Use Windows 2008 R2 based RDSH for best functionality results.

Note: To ensure search works with Outlook across different virtual machines, disable the "Windows Search" service. Email search will still work with the service disabled.

Only one AppStack with Office components can be attached at a time. However it can be
used in many different configurations.

Example 1: Office in the base, and Visio as an AppStack
Example 2: Office in the base, and Project as an AppStack
Example 3: Office in the base, and Visio AND Project together as one AppStack
Example 4: Office and Visio in the base, and Project as an AppStack
Example 5: Office and Project in the base, and Visio as an AppStack
Example 6: Office, Visio, and Project as ONE AppStack

Hope this helps anyone who may come across this issue.

Configuring Citrix NetScaler VPX to publish StoreFront services for Citrix Receiver, Android and Apple device access

One of the questions I get asked quite often is how to properly configure the NetScaler to publish StoreFront services for Citrix Receiver, Android and Apple device access so I thought I’d write a quick blog post demonstrating this.

Before you begin, it is important to be aware that Android and Apple devices are very sensitive to the certificate presented by the NetScaler and what I’ve found most times is that while it may seem you are presented with the option to accept an untrusted certificate, attempting to launch an application would fail with various errors.  If you are not familiar with linking certificates, please see the following blog post:

Android and Apple devices is presented with an “Invalid Server Certificate” warning and are unable to launch applications published through a NetScaler VPX
http://terenceluk.blogspot.com/2015/04/android-and-apple-devices-is-presented.html

Begin by creating a new Session Profile for Citrix Receiver access:

The settings for the Network Configuration tab would look as such:

The Client Experience tab would be configured as such:

The Security tab would be configured as such:

The Published Applications tab would be configured as such:

Note that the Web Interface Address should point to the Store URL which does not end with a “Web” for the URL.

With the Session Profile created proceed to the Session Policies tab and create a new policy and select the Session Profile that was created earlier:

Note that the Expression used is:

REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver

**More information about expressions can be found at the following Citrix documentation:

Configuring Session Policies and Profiles for CloudGateway
http://support.citrix.com/proddocs/topic/access-gateway-10/agee-clg-session-policies-overview-con.html

Complete the configuration by binding the new Session Policy to the Virtual Server:

Note that the Priority does not matter because the Expression does not actually overlap.

You should now be able to access StoreFront resources via the Citrix Receiver, Android or Apple devices.

Attempting to commit changes to new Windows Server 2012 R2 server throws the error: “STATUS_SUCCESS”

Problem

You’ve deployed a new Windows Server 2012 R2 KMS server and completed configuring a KMS host key in the Volume Activation Tools wizard:

You proceed to commit the changes:

… but receive the following error:

The following error has occurred. Please resolve the error and try again.

Description:

STATUS_SUCCESS

Solution

The reason why this error is thrown is because the default value for the KMS TCP listening port is specified with the value of 0:

To correct the issue, change the value to the default 1688 KMS port as such:

Proceeding to commit the changes will be successful once the port is defined:

Once the wizard completes, ensure that the KMS server is activated properly by executing the following command:

slmgr.vbs /dlv

To verify that the VLMCS DNS record is published, use the following command:

nslookup -type=srv _vlmcs._tcp.<yourDomain>.com

If you notice that a VLMCS record is not created, you can either manually create the record as such:

… or configure the proper permissions if you notice an error logged in the applications logs similar to the following:

Log Name: Application

Source: Security-SPP

Event ID: 12293

Level: Error

Publishing the Key Management Service (KMS) to DNS in the 'tokiomillennium.com' domain failed.

Info:

0x8007232D

Attempting to activate an Active Directory-Based Activation throws the error: “Access is denied.”

Problem

You attempt to activate a new Windows Server 2012 R2 KMS server as an Active Directory-Based Activation:

… but receive the following error:

The following error has occurred. Please resolve the error and try again.

Description:

Access is denied.

Solution

The reason this error is presented is because the KMS server is not a domain controller.  The following TechNet article describes the requirements for setting up an an Active Directory-Based Activation KMS server:

Activate using Active Directory-based activation
https://technet.microsoft.com/en-us/library/dn613828.aspx

Configuring LDAPS / SSL for Citrix NetScaler LDAP authentication with Active Directory

I recently been asked about how to configure a NetScaler to authenticate against a domain controller when publishing XenApp / XenDesktop environments to utilize secure LDAP (LDAPS) via SSL and after realizing I’ve never written a blog post, I thought I’d do so.

The node in the NetScaler administration console we’re interested in is the Servers tab located in System –> Authentication –> LDAP:

Clicking on the Add button will bring up the following configuration options where we’re interested in using the port 636 for LDAPS rather than the unsecured 389 for LDAP and option SSL instead of PLAINTEXT:

Prior to actually configuring the NetScaler settings, begin by configuring the Active Directory domain controllers the NetScaler appliance will be authenticating against.  I won’t go into the details to configure them for LDAPS as I’ve written a blog post about it before so I’ll simply include the post here:

Configure LDAPs an Active Directory Domain Controller for LDAP over SSL Connections
http://terenceluk.blogspot.com/2013/10/configure-ldaps-active-directory-domain.html

Once the domain controllers have been configured with a LDAPS certificate and verified to be accepting SSL encrypted connections navigate back to the Servers tab located in System –> Authentication –> LDAP and fill out the fields as such:

Note that the Port has been specified to be 636 while the Security Type has been specified as SSL in the screenshots above.  Proceed with configuring additional Servers as required based on the amount of domain controllers you would like to authenticate against and once completed, bind them to the appropriate Virtual Servers in the NetScaler Gateway –> Virtual Servers objects.

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

One of the questions I get asked a lot when demonstrating this configuration to fellow colleagues, is if we have to import the root certificate of the certificate that the domain controllers will be using if the Certificate Authority (CA) is an internal Microsoft Certificate Services Authority and what I’ve noticed is that the authentication still works even if you skip this step.  I personally like to be on the safe side so I would go and import it onto the NetScaler anyways.

April 13, 2015 Update: As one of the comments from my original post notes, it is actually important to import the certificate because failing to do so would cause devices such as tablets (Androids and Apple) to present a:

Cannot verify this server’s certificate.

… or:

Invalid Server Certificate

This server certificate is not trusted.

Do you wish to accept this certificate and connect to the server anyway?

Contact your help desk if you are unsure.

For more information, check out the following blog post:

Android and Apple devices is presented with an “Invalid Server Certificate” warning and are unable to launch applications published through a NetScaler VPX
http://terenceluk.blogspot.com/2015/04/android-and-apple-devices-is-presented.html

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

Begin by going onto any one of the servers in the domain that has the Root CA certificate in the Trusted Root Certificates store and export the certificate as a Base-64 encoded X.509 (.CER) format:

Note that a Base-64 encoded X.509 (.CER) contains readable text in the exported file as shown in the following screenshot:

… while a DER encoded binary X.509 (.CER) contains binary code as such:

With the Root CA certificate exported, proceed by logging onto the NetScaler and navigating to Traffic Management –> SSL –> Certificates:

Clicking on the Install button will bring up the following menu:

As with all the other certificate menus on the NetScaler, I often find it confusing so the following is what you need to fill in if you are importing a certificate without a private key:

Certificate-Key Pair Name: A logical name you’d like to call this certificate (type in anything you like)

Certificate File Name: Click on the browse button, upload and select the .CER file you’ve exported

Key File Name: <blank> <—we’re not importing a certificate with a private key so there is no password

Certificate Format: PEM

Password: <blank> <—we’re not importing a certificate with a private key so there is no password

Clicking on the Install button will complete the import.

Note the differences between a certificate that the NetScaler has the private key (the middle certificate) and a certificate that the NetScaler does not have the private key (the one at the bottom).

Android and Apple devices is presented with an “Invalid Server Certificate” warning and are unable to launch applications published through a NetScaler VPX

Problem

You have successfully published a Citrix Receiver rule on the NetScaler and confirmed that a Windows PC can access Citrix published applications with a Citrix Receiver but you notice that Androids and Apple devices are presented with the following warning while logging on:

Invalid Server Certificate

This server certificate is not trusted.

Do you wish to accept this certificate and connect to the server anyway?

Contact your help desk if you are unsure.

… and although they can continue the login process by tapping the Accept button, they are presented with the following error when attempting to launch applications:

Cannot validate SSL certificate

Cannot verify this server’s certificate.

Solution

The reason why devices such as Androids and iPads present this error is because it cannot verify the presented certificate’s certificate chain.  Devices other than traditional Windows PCs do not have the trusted certificate chains installed by default and while it is possible to try and install the certificate onto the devices themselves, that solution is not practical in any environment with more than a few devices to manage.  The way to address this issue is to actually install the trusted chain of Root and Intermediate issuing CA certificates onto the NetScaler then link it to the certificate that used by the NetScaler to secure traffic.

Begin by using a browser and navigate to the Citrix portal and open the certificate properties:

Note that the Issued by field indicates this certificate was issued by the certificate authority QuoVadis Global SSL ICA G2 in the screenshot above.  Proceed and navigate to the Certification Path to display the full certificate issuing chain:

As shown in the Certification path above, the certificate chain is comprised of the QuoVadis Root CA 2 Root CA that issues the QuoVadis Global SSL ICA G2 Intermediate CA that issues the server certificate that the NetScaler is using to secure traffic to the server.  The two certificates we need to download are the QuoVadis Root CA 2 Root CA that issues the QuoVadis Global SSL ICA G2 intermediate CA.

Performing a quick search on Google returns the following URL that includes the links to download either the the DER or PEM of the certificates:

https://www.quovadisglobal.com/QVRepository/DownloadRootsAndCRL/InstallingSSL.aspx

Proceed to download the PEM for both the Root and Intermediate certificates by copying the text for each certificate and saving them as .cer files:

Upload the two certificates to the NetScaler:

Continue and import the certificates:

Fill in the following:

Certificate-Key Pair Name*: <a logical name that makes sense such as QuoVadis-Global-SSL-ICA-G2>

Certificate File Name*: Select the .cer file that was uploaded

Key File Name: Leave Blank

Select PEM format

Password: Leave Blank

The rest should be left as default.

Click on the Install button and you should now see the intermediate certificate installed:

Repeat the same procedure for the Root CA:

With the 2 certificate installed, the final stage is to link the chain together by right clicking on the server certificate and select Link:

If the correct intermediate issuing CA certificate was uploaded, the NetScaler should automatically detect it and have it set in the drop down menu:

With the server certificate linked, proceed and link the intermediate certificate to the root:

With the certificate chain linked, your tablet device such as iPads or Androids should no longer present the certificate warning and will be able to launch published applications: