Saturday, November 22, 2014

Notes on requesting and applying Citrix NetScaler VPX licenses on the My Citrix portal

I’ve found that many of my clients and colleagues get confused when trying to request Citrix NetScaler licenses which doesn’t surprise me because I felt the same way the very first time I tried to do it myself so I thought it would be good to write this short blog post to point anyone who asks me for clarification.

As shown in the following screenshots from the My Citrix portal:


… the NetScaler licenses are bounded to the Host ID of the appliance and there have been times in the past where I’ve been asked whether this was the host name which is actually incorrect.  The Host ID of the appliance is really a MAC address of one of the interfaces of the appliance.  The following are methods that can be used to locate the Host ID.

Method 1 – Via NetScaler GUI

Simply log into the administration web console of the NetScaler and review the System Information tab will show the host ID as shown in the screenshot below:


Method 2 – Via Shell

To retrieve it via command line, simply either access the console or SSH to the appliance, get into the Linux context by typing shell then executing the command:

lmutil lmhostid -ether


Method 3 – Via Hypervisor

What I’ve noticed is that the interface owning the host ID used for the license has always been the first network card assigned to the appliance:




Now that we have the Host ID of the appliance, proceed by entering it into the Host ID field of the license allocation webpage (make sure you do not include the colons) to generate a license file.


Friday, November 21, 2014

Lync 2013 Client has PowerPoint, Whiteboard, Poll and Q & A greyed out


You’ve successfully deployed Lync Server 2013 and began testing features in the Lync 2013 client but quickly noticed that the following options are greyed out:

  • PowerPoint
  • Whiteboard
  • Poll
  • Q & A



While there could be various reasons why these options would be greyed out, one of the more obvious reasons is that you forgot to check the checkbox:

Conferencing (includes audio, video, and application sharing)

… during your Lync front-end server deployment:


To correct the issue, simply launch the topology builder and enable the feature


Once the option is enabled, publish the topology, launch the Lync Server 2013 – Deployment Wizard and rerun the Setup or Remove Lync Server Components to install the missing components:



Once completed, the options should now be available:


Wednesday, November 19, 2014

Deploying Microsoft Lync 2013 audio and video with Citrix XenApp 6.5

Those who may have come across my previous post about integrating Lync 2013 audio and video redirection to the local client:

Deploying Microsoft Lync 2013 audio and video within a Citrix XenDesktop 5.6 VDI

… may know that although the requirement for XenDesktop 5.6 is to use the XenDesktop 7 VDA, which renders XenDesktop 5.6’s Desktop Director unusable because it does not support 7.x VDAs, XenApp 6.5 published desktops is a supported configuration as outlined in the following Citrix document:

XenDesktop, XenApp and Citrix Receiver Support for Microsoft Lync 2013 VDI Plug-in

I haven’t actually been working with XenApp 6.5 over the last few months and so never tested the configuration but as I to do so today for a client with the legacy architecture, I thought I’d write this short blog post about the configuration.

Environment Information

Citrix XenApp Version: 6.5
Hotfixes: Rollup 3


Lync Client: 2013
Version: 15.0.4454.1506
MSO: 15.0.4420.1017
Bit: 32-bit


Citrix Receiver: 4.2

Step #1 - Update Citrix Receiver on the HP t610 thin client to version 4.0

Begin by checking the existing version # of the Citrix Receiver installed onto the client connecting to the XenApp 6.5 server and update it to a version later than 4.1.02.

Step #2 - Enable EnableMediaRedirection on Lync 2013 Server

Ensure that the Lync Client Policy of users who will be redirecting to local devices has EnableMediaRedirection enabled.  The environment for this demonstration has all the users using the Global policy so executing the Get-CsClientPolicy -identity Global cmdlet will show the following


**Note in the above screenshot that EnableMediaRedirection is not enabled.

Proceed by using the following cmdlet to enable it:

Set-CsClientPolicy -identity Global -EnableMediaRedirection $true


Executing the Get-CsClientPolicy -identity Global cmdlet will now show the following:


Step #3 - Install Microsoft Lync VDI Plug-in on the client connecting to XenApp


**Note that at the time of writing this post, only the 32-bit version of the Microsoft Lync VDI Plug-in is supported and will work for redirecting audio and video.  The 64-bit plug-in is not supported and will not work as described in the following Citrix article:

XenDesktop, XenApp and Citrix Receiver Support for Microsoft Lync 2013 VDI Plug-in

Citrix Receiver for Windows requires the 32-bit version of the Microsoft Lync VDI Plug-in on the device, even on a 64-bit Windows machine. The 64-bit version is not compatible with Citrix Receiver for Windows since the bitness of the VDI Plug-in must match the bitness of the Receiver.


Proceed to download the Microsoft Lync VDI 2013 plugin 32-bit and install it onto the thin or thick client that will be used to connect to the virtual desktop:

Restart the thin client and you’ll notice that when you connect to your VDI, you will see a new green small icon at the bottom right hand corner with a white checkmark:


Clicking on it will show the following:

Lync is all set to use your local audio and video devices.


Note that unlike the thin client I was working with in my other post, I did not have to set the following registry keys on the Windows 7 full desktop I was using:


"ConfigurationMode"=dword:00000001" <—DWORD (32-bit) Value

"ServerAddressInternal"="yourLyncServer.domain.local" <—String Value

"ServerAddressExternal"="" <—String Value

I believe the reason why is because the desktop I was using to connect to XenApp already had Lync 2013 installed on it and although the registry key above did not contain any of the items that had to get manually added to the thin client, the redirection still worked.  It is likely that these registry keys would need to get created if the computer was not joined to the domain.

Sorry about the brevity of this post but I just wanted to quickly demonstrate that this configuration also works with XenApp 6.5.

Monday, November 17, 2014

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

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.

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).


Thursday, November 13, 2014

Changing Citrix XenDesktop and XenApp 7.5 / 7.6 default tab for Apps and Desktops

I’ve been asked several times over the past few months about how to change the default view for a StoreFront portal to display the Apps tab instead of the Desktops tab as shown in the following screenshot:


The configuration is actually quite simple and can be found at the following Citrix eDoc:

Configuring Receiver for Web Using the Configuration Files

The way to change the ordering of the tabs is to simply locate the following line:

<uiViews showDesktopsView="true" showAppsView="true" defaultView="desktops" />

… in the web.config file of the Receiver for Web site:


Begin by logging onto your StoreFront server (you will need to do this for any others you may have in the environment) and navigate to the inetpub directory:



Open the web.config file with notepad:


… and locate the following line:

<uiViews showDesktopsView="true" showAppsView="true" defaultView="desktops" />


To change the default tab from Desktops to Apps, change the defaultView= field as such:


Save the web.config file and repeat the same for any StoreFront servers participating in serving this portal. Once complete, you should see the changes when you log into the Citrix portal:



I’ve also been asked quite a few times about how to limit the Desktops tab view to certain users so I’ll include it in this post as well.

You can’t make this modification in the GUI so proceed by launching PowerShell on your Delivery Controller and execute:

Add-PSSnapin Citrix*


Execute Get-BrokerEntitlementPolicyRule to list the Delivery Groups configured:


The attributes we’re interested in are:

  • IncludedUserFilterEnabled
  • IncludedUsers

The IncludedUserFilterEnabled essentially turns on the filtering of the Desktops tab to select users while the IncludedUsers attribute specifies who is allowed to view the Desktops tab.  The screenshot above already has the filter turned on and has specified that only Domain Admins are allowed to view the tab but if it wasn’t set, the cmdlet you would use to enable and set the filter is:

Import-Module Citrix.XenDesktop.Admin

Add-PSSnapin Citrix.*

Set-BrokerEntitlementPolicyRule –Name “<desktopDeliveryGroup>” –AddIncludedUsers “<groupAllowedtoViewDesktopsTab>” -IncludedUserFilterEnabled $true

Once the cmdlet has succssfully ran, proceed by executing the Get-BrokerEntitlementPolicyRule cmdlet again to verify the changes.

Wednesday, November 12, 2014

Attempting to “Get Device Image” for a Wyse Z90QQ7P Thin Client from within Dell Wyse Device Manager Version 5.0 errors with: “Flash is corrupted or improper repository/network configuration”


You attempt to use the Get Device Image for a Wyse Z90QQ7P Thin Client from within Dell Wyse Device Manager Version 5.0 but receive the following error message:

==================Imaging Failed=====================

ERROR: Error while uploading MBR file. Http Error code: .

ERROR STAGE: MBR validation

REASON: Flash is corrupted or improper repository/network configuration.

SOLUTION: Disable anonymous authentication if enabled on software repository under MyWDM virtual directory or check the device flash.


Activating OS partition …



As the Wyse Z90QQ7P was the new model that was just released, I was unable to find a solution through searching the internet so I ended up reaching out to Wyse technical support and was told that we had to install a WDM 5.0 MR pack to resolve the issue.  At the time of writing this, 2 maintenance releases was available:

  1. WDM5.0_MR1_WRK_HF050026414
  2. WDM5.0_MR1.1_WRK_HF050027314


I tested installing MR1 first then MR1.1 and can confirm that both of them resolves this issue.


Tuesday, November 11, 2014

Determining IP address and hostname of end point device connected to a VMware Horizon View virtual desktop

A client with a VMware View infrastructure that services various offices around the world recently asked me if there was a way to determine what the hostname or IP address of the thin client his users’ were using to connect to the virtual desktops.  Having worked with Citrix and VMware’s desktop virtualization products over the past 2 years, I immediately remembered that Citrix’s Desktop Director provides such information but wasn’t sure whether VMware’s Administration console did and after browsing around, I realized it wasn’t there.  I went ahead and started searching on the web and only found forum posts that you would have to parse through the View Connection server(s) logs.  This wasn’t ideal because the logs aren’t easy to read as it is all text that extends far wider than even my retina Mac can keep on one line.

After putting this on hold while I worked on other priority item, I finally had the time to revisit this yesterday and knowing that I didn’t have any luck through the hour I used to research this before, I went ahead and posted on the VMware forums:

Determining the IP and Name of the end point device connected to a virtual desktop

A fellow user immediately answered with the solution and that was to look in the following portion of the registry on the VMware View virtual desktop:

HKEY_CURRENT_USER –> Volatile Environment:


The keys we were interested in are the following:

  • ViewClient_IP_Address
  • ViewClient_Machine_Name

… but as shown in the screenshot above, there is so much more useful information such as the View Connection broker used (handy to troubleshoot load balanced environments), the logon server (troubleshoot domain controller issues), protocol type (what protocol the user is connected to the desktop with) and much more.

Seeing how I had issues finding this information, I hope this post would make it easier for anyone else looking for this information and may be searching with words I used that did not yield results.