RDS vs. XenApp

I read a great article today from Thomas Kötzing (@Koetzing) regarding feature comparison between Server 2012 Remote Desktop Services and Citrix XenApp 6.5 for delivery of user workspaces. I highly recommend anyone considering deployment of server-based computing take a look. He really hits the nail on the head with regards to need comparison for features between the two in the SMB marketplace.

Director Modifications - Where was that GUI again?

In some instances there may come the need to modify the configuration of Citrix Director. This Help Desk and Monitoring web portal doesn't offer any up front way to change configuration settings. This is where the DirectorConfig Tool steps in.

The DirectorConfig Tool is a command line utility from Citrix that allows various configuration changes to Citrix Director. Perhaps the most common task it is used for is to configure HDX Insight.

The tool comes pre-installed on Director servers at C:\inetpub\wwwroot\Director\tools.

The follow actions can be accomplished with the tool:

1. Configure HDX Insight
2. Unconfigure HDX Insight
3. Change the XenDesktop Site
4. Change the Delivery Controller used for discovery
5. Remove user configuration files
6. Upgrade Director
7. Register ASP.net
8. Enable Remote Assistance

StoreFront / Gateway Logoff Error

On occasion you may run into logoff errors for Citrix StoreFront or Citrix NetScaler Gateway similar to the one below.

If any apps are still running, please exit them manually.

I have found two reasons thus for this error to potentially happen. Each has their own time and place as well as a resolution. There is a third resolution as well, that was a bug several years ago with VDI-In-A-Box. This third resolution is actually a workaround, and depending on your environment, may not be suitable.

---

Scenario/Fix 1

• In this scenario Receiver for Web is configured for domain pass-through authentication. If this or smart card authentication are in use and XenDesktop Site settings are not configured to trust XML communications (default config) then the error above can be observed.

1. Load PowerShell on a Delivery Controller
2. Add the Citrix cmdlets:
   Add-PSSnapin *cit*
3. View your Site information. It is expected that the trust status is false:
   Get-BrokerSite
   
4. Adjust your trust status:
   Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true
5. Verify you are now trusted for XML communication:
   Get-BrokerSite
   

---

Scenario/Fix 2

• In this scenario StoreFront is configured for multiple Delivery Controllers across different Sites. One of the sites is down resulting in no Delivery Controller to respond. This will usually be seen in the Event Viewer>Citrix Delivery Services log on StoreFront servers as Event ID 4012. Both the enumeration process and the logoff process (if terminating or disconnecting sessions) will reach out to all configured sites in StoreFront. While enumeration does not present an error to users, log off will do so if StoreFront cannot verify active sessions to disconnect or terminate. This could be very common in Cold DR or Development environment scenarios where everything is passed through one StoreFront portal.

1. Verify all XenDesktop sites are responding.

---

Scenario/Fix 3

• This scenario is not actually a scenario but a work around. As alluded to in the second section above, the error occurs when StoreFront tries to utilize WorkSpace Control and disconnect or log off users sessions but fails. This fix for this is to change your default behavior.

1. In current versions (3.5 or newer) of StoreFront, launch the console and navigate to Receiver for Web Sites>Manage Receiver for Web Sites>Configure.
2. Select WorkSpace Control
3. Change the Logoff action to None:
   
4. With the setting at None, no controllers will be contacted and thus no errors shown to the client.
5. Don't forget to replicate settings to your Server Group.

If you are on a version of StoreFront that does no have GUI configurable WorkSpace Control settings, you can access the web.config file in your IIS home and change the highlighted line below.

Go to C:\inetpub\wwwroot\Citrix\<StoreName>Web and open the web.config file.

<workspaceControl enabled="true" autoReconnectAtLogon="true"

            logoffAction="none" showReconnectButton="false" showDisconnectButton="false" />

XenDesktop 7.6 - Limiting Desktops

One of the biggest issues (complaints) about earlier versions of XenDesktop 7.x was that you had to present desktops to all users of a delivery group. The truth to this is that you can actually limit this - however it is not part of the GUI until the latest releases of the 7.x platform.

If you are in need of limiting who gets desktops, you need to break out your PowerShell SDK for XenDesktop and look at the Entitlement Policy for your Delivery Group. You can enable the User Filter and in turn assign users or groups to get the desktop.

Below is a sample of this change. Note that you have to have a Delivery Group with Desktops enabled for this to work.


Add-PSSnapin *Cit*

Get-BrokerDesktopGroup *

#Note the Uid of the Delivery Group you are interested in limiting - in this case my sample Uid is 32

Get-BrokerEntitlementPolicyRule -Uid 32 | Set-BrokerEntitlementPolicyRule -IncludedUserFilterEnabled $true -IncludedUsers "MyDomain\MyUserGroup"

#The above will set the entitlement policy object to be enabled and add my limiting group

Get-BrokerEntitlementPolicyRule -Uid 32

#Verify the settings you just configured

Pesky Icon Data

I ran into an issue with a Citrix XenDesktop environment where application settings had to be recovered but unfortunately none of the Encoded Icon Data was available so all applications had the default citrix application icon with Uid of  1.

I had to get a little creative with PowerShell to get the application's  icon data back. Unfortunately if there were custom icons, this wouldn't work - but in a time of recovery beggars can't be choosers.

The below script will take each application located on a server from a delivery group (I only had one here, but this could be upgraded to walk multiple) and extract the first available icon from the executable of the published application, create the encoded icon data, and then assign the application to that new icon. In my case this took care of most of the applications. I had a couple published batch files that I tweaked after the fact - but this was much nicer than going through the GUI and manually adjusting every application in the environment.

Add-PSSnapin *Cit*

$applications = $null
$applications = Get-BrokerApplication * | Where-Object {$_.IconUid -eq 1}

$sessionhost = $null
$sessionhost = Get-BrokerDesktop * | where-object {$_.MachineUid -eq 1}

$manuallyfix = $null

foreach($app in $applications){
if($app.CommandLineExecutable -like "C:*")
    {
    $localpath=$null
    $localpath=$app.CommandLineExecutable.TrimStart("C",":")

    $path = $null
    $path = "\\"+$sessionhost.HostedMachineName+"\C$"+$localpath

    $icon = $null
    $icon =get-ctxicon $path -index 0

    $newicon = new-brokericon -EncodedIconData $icon.EncodedIconData

    write-host $app.browsername "changing to Icon Uid: " $newicon.uid
    Get-BrokerApplication $app.browsername | Set-BrokerApplication -IconUid $newicon.uid

    }else
    {$manuallyfix+=$app.name+"`n"}

}

write-host "`n`nManually fix these apps: `n"

$manuallyfix