Storefront Verbose Logging

To enable Verbose Logging in Storefront 2+ you have to run these commands in Powershell in the Storefront server:

Add-PSSnapin Citrix.DeliveryServices.Framework.Commands
Set-DSTraceLevel –All –TraceLevel Verbose

Then you need to restart these services, or reboot the server:

  • Citrix Configuration Replication
  • Citrix Credential Wallet
  • Citrix Default Domain Services
  • Citrix Peer Resolution Service
  • Citrix Subscriptions Store

After a while you’ll see the logs starting to fill up in:

C:\Program Files\Citrix\Receiver Storefront\Admin\Trace

And to disable the Verbose Logging run the following commands in Powershell:

Add-PSSnapin Citrix.DeliveryServices.Framework.Commands
Set-DSTraceLevel –All –TraceLevel Off

Storefront 2.6 – Additional URLs

A common setup is to use the same internal as external URL. The best way to accomplish this is to setup a load balancer and content switch vserver in Netscaler where you point the internal URL to. This way you can handle the redirection from the root (https://remote.domain.com/) to the Store address (https://remote.domain.com/Citrix/MyStoreWeb) for web access properly.

This works good as long as you’re accessing resources from a web browser. However, when the native receiver is used you get an error message saying “Select an account to continue”. This is because the storefront does not recognize the url you are accessing from as allowed.

To fix this you need to open this file with notepad:

C:\inetpub\wwwroot\Citrix\Roaming\web.config

Search for the tag “<allowedAudiences>”.
Here you find that the BaseURL of the storefront is already present, i.e:

<add name=”https-internalsf.domain.com” audience=”https://internalsf.domain.com/” />

Copy this row and insert in right after, and alter the address so it corresponds with the desired URL. The end result should like something like this:

<allowedAudiences>
<add name=”https-internalsf.domain.com” audience=”https://internalsf.domain.com/” />
<add name=”https-remote.domain.com” audience=”https://remote.domain.com/” />
</allowedAudiences>

Now you should be able to connect the native receiver to the Storefront via a Load Balance or Content Switch vServer.

Netscaler – Optimal Gateway Routing

For authentication at Netscaler but routing directly between backend and client, i.e. when user is in the LAN but authentication shall be done at the Netscaler.

Edit the web.config file for the specific store (c:\inetpub\wwwroot\citrix\storename). Search for <optimalGatewayForFarmsCollection /> and replace with:

<optimalGatewayForFarmsCollection>
<optimalGatewayForFarms enabledOnDirectAccess=”true”>
<farms>
<farm name=”farmname” />
</farms>
</optimalGatewayForFarms>
</optimalGatewayForFarmsCollection>

For each farm, add additional <farm name=”farmname” /> tags.

For routing through a specific gateway, replace with:

<optimalGatewayForFarmsCollection>
<optimalGatewayForFarms enabledOnDirectAccess=”true”>
<farms>
<farm name=”farmname” />
</farms>
<optimalGateway key=”_” name=”deploymentname” stasUseLoadBalancing=”{true | false}” stasBypassDuration=”hh:mm:ss” enableSessionReliability=”{true | false}” useTwoTickets=”{true | false}”>
<hostnames>
<add hostname=”netscaler_gateway_fqdn:port” />
</hostnames>
<staUrls>
<add staUrl=”https://stapath/scripts/ctxsta.dll” />
</staUrls>
</optimalGateway>
</optimalGatewayForFarms>
</optimalGatewayForFarmsCollection>

The <optimalGateway …> configuration can be used from the lines above where there is a <gateway …> tag for each Netscaler Gateway you’ve configured in Storefront already. Easy way to get the key, staUrl, etc.

CP_XenOnXen

Allow VMs when XenServer is virtual

Not applicable for production environments, but for lab purpuse this is excellent!

Assuming you have a MySQL server on the management server, login as root on the management server.
Type in: mysql to open the mysql console.
Type in: insert into cloud.configuration (category, instance, component, name, value, description) VALUES (‘Advanced’, ‘DEFAULT’, ‘management-server’, ‘xen.check.hvm’, ‘false’, ‘Allow XenServer on XenServer HVM’);

This makes the CloudPlatform not check for the HVM type.

CitrixVDA

VDA stays Unregistered at XenDesktop Controller

The Virtual Desktop Agent (VDA) have an option during installation where you have to point out the XenDesktop Controllers by hostname, IP address or just by pointing out the XenDesktop Farm. If you happen to point out the farm it is most likely to not get registered at the XenDesktop Controller in Studio. The solution, apart from reinstall and making another choice, is to manually point the XenDekstop Controllers out. This solution has it’s benefits and can be used in several other situations. For example if you’ve put a couple of hours down to get the Master Image ready and already had MCS create your pool, if you happen to change the hostname or IP address of the XenDesktop Controller(s), etc.

So what you need to do is alter or create the following Registry key:

1. Navigate to HKLM\Software\Citrix\VirtualDesktopAgent

2. Alter/create the key ListOfDDCs (REG_SZ)

3. Type your XenDesktop Controllers hostnames (FQDN) or IP address. If you have several you separate them with one space, i ex “host1.domain.local host2.domain.local”.

Note: If you typed in the hostnames, you also need to do the 4th step, otherwise you’re done:

4. At the same location (HKLM\Software\Citrix\VirtualDesktopAgent) create a key named UseCnameLookup (REG_DWORD) with the value 1. (1 = Enabled, 0 = Disabled)

This can be set via GPO and distributed to the XenDesktop Controllers via Computer Group or by adding the specific computers to that GPO.
If you read the pages in my reference you’ll notice that Citrix has a separate location for the x86 and the x64 platform. I have tried the x64 instructions on a x64 platform, but didn’t get it working, while the x86 instructions (the above) worked for both platforms. This applies to XenDesktop 7.1, so it may have changed for the most recent version 7.5.

Reference:
http://support.citrix.com/article/CTX137960
http://support.citrix.com/article/CTX118976

DropDownMenu

Drop down menus alignment

I recently came across a funny scenario where, in a XenDesktop 7.1 environment, the drop down menus are on the wrong side of the cursor. The reason for this is the Tablet PC functionality in Windows 7+ where it looks at what type of display you are using and try to give you the most user friendly experience, even though you don’t have a Tablet PC. Now, because we’re in a XenDesktop environment it turned out that the display is “Unkown”, therefor it does a little bit whatever instead of using the most resonable option…

To fix this for a single user you do the following:

1. Run this command: shell:::{80F3F1D5-FECA-45F3-BC32-752C152E456E}

2. Click on Other

3. Change Handedness from Right handed to Left handed

4. Click on OK and you’re done!

 

To fix this via GPO do the following in the registry:

Add or Update the property MenuDropAlignment (REG_SZ) and set 0 to drop on the right side of the mouse, and 1 to drop on the left side of the mouse. You need to add/update the property on both of these locations:

HKCU\Control Panel\Desktop

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows

Done!