When trying to connect to a XenDesktop 7.x published resource, e.g. an puplished application or published desktop, you may receive the following error: Unable to launch as the application is not currently available:

With a subsequent Event Log entry in the XenDesktop 7.x Controller’s Application Event Log, Source: Citrix Broker Service, Event ID 2100: Citrix Broker Service failed to validate a user’s credentials on an XML service:

This is due to the Citrix Broker Service no trusting an XML request made for that resource. XenDesktop 7.x requires to trust XML requests sent to the Delivery Controller in order to broker a connection to the published resource. Therefore you need to configure the XML trust by running the following commands using Windows PowerShell on your Controller server:

asnp Citrix*

Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $True

Get-BrokerSite

Verify that TrustRequestsSentToTheXmlServicePort is set to $true.

Further reading:

• CTX200157 – How to Configure Citrix Receiver Pass-Through Authentication for StoreFront or Web Interface
• CTX132461 – Error: “An error occurred while making the requested connection”
• CTX140045 – Domain Pass-through to StoreFront Cannot Launch XenDesktop
• Citrix Receiver Error – unable to launch as the application is not currently available

The post Citrix Receiver 3.x and 4.x – Unable to launch as the application is not currently available appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

After upgrading Citrix Director to v7.6.300 in order to implement the newly added Framehawk Support I ran into an error after launching Citrix Director: An internal error has occurred. For assistance, contract your administrator (including typo):

This error is complemented by an Event ID 1310, Event Source: ASP.NET 4.0.30319.0, in the Application Log on the Controller server:

In my case in turned out that I had modified C:\inetpub\wwwroot\Director\LogOn.aspx in order to pre-populate the domain field as per CTX139896. As I had a backup of the LogOn.aspx file I simply returned to the original one – et violá – it worked again.

After that I tried to edit the LogOn.aspx file again by searching for:

<asp:TextBox ID=”Domain” runat=”server”

and replacing it with:

<asp:TextBox ID=”Domain” Text=”mydomain” readonly=”true” runat=”server”

After saving the file and refreshing the Citrix Director Logon Page at http://<DirectorServerFQDN>/Director it worked as expected.

Make sure you upgrade to v7.6.300 as described by Citrix:

• Download Director, and run the MSI file, DesktopDirector.MSI or DesktopDirector_x64.MSI.
• Install CitrixGroupPolicyManagement.MSI, which is available in the Citrix Policy folder on the XenApp and XenDesktop installation media.
• Configure Director with the Delivery Controller, use the DirectorConfig.exe tool available in C:\inetpub\wwwroot\Director\tools. For more information, see CTX137990.
• Register ASP.net with IIS. To do this, run the command C:\inetpub\wwwroot\Director\tools>DirectorConfig.exe /registerdotnet
• Install or upgrade the WMIProxy on the VDA, and restart the machine. WMIProxy_x64.MSI and WIMIProxy_x86.MSI are included in the Director 7.6.300 download files. Note: The Framehawk virtual channel will be shown as “Not Compatible” with a VDA with Framehawk enabled, if the WMIProxy is not upgraded.
• Upgrade XDPoshSnapin_Hotfix on the Delivery Controller, then restart Studio. XDPoshSnapin MSI is available with the Director files downloaded in step 1. This is required for Delegated Administrators and Custom Administrators to view the Framehawk virtual channel information.

Further reading:

• Citrix Blogs – Citrix Director 7.6.300 : Framehawk Support
• Citrix Product Documentation – Director
• CTX137990 – Citrix Director – DirectorConfig Tool
• CTX139896 – How to Pre-populate Domain Name for Citrix Director Logon Page

The post Citrix Director v7.6.300 Upgrade – An internal error has occurred. For assistance, contract your administrator. appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

Upon upgrading Citrix Profile Management to v5.2.1 on one of my Workers and rebooting my users were unable to connect to that server. It came down to a Load Evaluator Index of 10000:

Citrix Studio showed 1 Failed Server OS Machine:

Further searching pointed me to an Event ID 1101, Event Source: Citrix Broker Service, in my Controller’s Application Event Log:

The Citrix Broker Service failed to broker a connection for user ‘DOMAIN\User’ to resource ‘Windows Explorer’. The Citrix Broker Service cannot find any available virtual machines.

Well, quite obvious, as the Load Evaluator Index of 10000 equals a Full Load and prohibits any Citrix related logons (though RDP connections are still possible).

How to get the current Load Evaluator Index?

As there is no qfarm /load available anymore with XenDesktop 7.x due to the switch from IMA to FMA architecture you have to use Windows Powershell instead. Run the following commands on your Controller server in order to get the Load Index of your Workers:

Add-PSSnapin *Citrix*

Get-BrokerMachine -SessionSupport MultiSession -Property ‘DNSName’,’LoadIndex’,’SessionCount’

Digging through the Event Logs of my Controller and affected Worker even more (as a first measure) I found several Event IDs 1039, Source: Citrix Broker Service, in my Worker’s Application Event Log, stating issues with Performance Counters unable to load:

• The Citrix Desktop Service failed to initialize a performance counter. Load management associated with this counter will be disabled.
  Counter details:
  Category ‘Processor’, counter ‘% Processor Time’ and instance’_Total’
  Error details:
  Exception ‘System.InvalidOperationException’ of type ‘Category does not exist.’
• The Citrix Desktop Service failed to initialize a performance counter. Load management associated with this counter will be disabled.
  Counter details:
  Category ‘Memory’, counter ‘Available MBytes’ and instance”
  Error details:
  Exception ‘System.InvalidOperationException’ of type ‘Category does not exist.’
• The Citrix Desktop Service failed to initialize a performance counter. Load management associated with this counter will be disabled.
  Counter details:
  Category ‘PhysicalDisk’, counter ‘Avg. Disk Queue Length’ and instance’_Total’
  Error details:
  Exception ‘System.InvalidOperationException’ of type ‘Category does not exist.’

I then ran lodctr /R within a Command Prompt on the affected Worker in order to rebuild Windows Performance Counters:

After a successful rebuilt I restarted the Citrix Desktop Service on the Worker – et violá – the Load Evaluator Index came down:

All back to normal.

Update 2016-01-18:

Have a look at Citrix eDocs as well. The article Load Management policy settings might help as well, as I once had a Worker with a published application that consumed a lot of memory. Thus my Physical Memory Usage history showed that almost 95% have been consumed and rendered the server unavailable due to Full Load.

Further reading:

• Hosted Shared Desktop on XenDesktop 7.1
• Citrix eDocs – Load Management policy settings
• Citrix Blogs – Get XenDesktop load balancing information using the SDK

The post Citrix XenDesktop 7.6 – Hosted Shared Desktop shows Load Evaluator Index of 10000 after reboot appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

Citrix XenDesktop 7.x – Black Screen when connecting to Published Desktop

When connecting to a Windows Server 2008 R2 Published Desktop (provisioned as a VM, not a physical machine) with XenDesktop 7.x you might receive a black and blank Desktop, no Desktop Icons are shown, and the Desktop stays that way:

Whereas connecting with RDP works normally, as long as the users are members of the local group Direct Access Users.

There are no significant Warnings and/or Error messages in the corresponding server’s Application and/or System Event Log. Everything seems to look and work as expected. In my case the error started showing up after moving the VM from one Hyper-V server to another Hyper-V server.

Having a look into the Citrix\Device\Redirector Application Log in Event Viewer showed an Event ID 261, Event Source: Redirector:

Citrix Device Redirector service could not complete an I/O Redirector Bus operation.

This can happen due to the following reasons:

• network issues between XenDesktop Worker hosting VDA and NetScaler/StoreFront
• wrong graphics card driver in VM when using VMware as a Hypervisor
• having ghost devices in Device Manager resulting in orphaned drivers on your Windows Server OS
• having HDX 3D Pro enabled on a physical host during installation of the VDA though not having a compatible graphics card inside
• Secure Boot is enabled on your Hyper-V Server for the affected VM
• VDA is corrupt

As per Citrix (CTX135782):

Problem Cause
There are several that could have caused the issue.
A majority of them are related to drive mappings or folder redirections in logon scripts, user profiles and/or GPOs, which point to an incorrect location or experience delays mapping during the logon process.

Possible solutions:

1. Network Issues

As per Microsoft KB314825:

“On a TCP/IP-based wide area network (WAN), communication over some routes may fail if an intermediate network segment has a maximum packet size that is smaller than the maximum packet size of the communicating hosts–and if the router does not send an appropriate Internet Control Message Protocol (ICMP) response to this condition or if a firewall on the path drops such a response. Such a router is sometimes known as a “black hole” router.”

Locate and fix a possible Black Hole Router. Furthermore regard these best practices for your servers:

• Power Management on the corresponding NIC has been disabled
• TCP Autotuning has been disabled by executing
  • “netsh interface tcp set global autotuning=disabled”
  • “netsh interface tcp set global rss=disabled”
  • “netsh interface tcp set global chimney=disabled”
• DEP has been disabled by executing “bcdedit.exe /set {current} nx AlwaysOff”

2. Graphics Card Driver

When using VMware as a Hypervisor change the default graphics card driver coming with VMware tools. The resolution is to uninstall the WDDM or VMware SVGA driver from the affected VM and install Microsoft SVGA driver instead. Refer to CTX124877 and CTX123952:

Have a look at Jan Hendriks’ blog as well: XenDesktop 7.6 Black Screen issue with VMWare SVGA 3D Driver

3. Remove Ghost Devices

1. Open a cmd prompt with elevated rights
2. Execute”SET DEVMGR_SHOW_NONPRESENT_DEVICES=1″
3. Execute “devmgmt.msc”
4. Click View => Show Hidden Devices
5. Expand every single node and remove/uninstall any ghost device found
6. Reboot server

4. Disable HDX 3D Pro

HDX 3D Pro can only be used on physical machines as long as a compatible graphics card has been installed. In case you provisioned your servers from a base image that somehow utilized this feature in the first place it might come down to the black screen issue when connecting with HDX/ICA. Simply uninstall the VDA from the affected machine, reboot the server, and then reinstall the VDA again. This should suffice.

5. Disable Secure Boot (Hyper-V only)

Shut down the affected VM and execute the following command in Powershell on your Hyper-V Server:

Set-VMFirmware –Vmname <VMName> –EnableSecureBoot Off

In case Secure Boot is enabled on the affected VM the symptoms of a black screen will appear thus rendering the server useless. When trying to install the VDA on a VM with Secure Boot enabled you’ll receive a warning message pointing you to CTX137731. Though the message can be ignored and the installation process continued this is not recommended:

6. Reinstall VDA:

Simply uninstall VDA from the affected server, reboot the server, and then reinstall the VDA.

7. Set the Registry Key Logon:

Add or set the following registry key on the XenApp/XenDesktop server(s) to resolve the issue:

• Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Logon
• Name: DisableStatus
• Type: REG_DWORD
• Value: 00000001

My solution:

As for me I had to disable Secure Boot for the affected VM. After that everything worked normal again. I simply forgot to disable Secure Boot after moving the VM from one Hyper-V server to another Hyper-V server.

There are a couple of different registry tweaks available that I usually apply to my Citrix Workers via GPO Preferences as well:

• CTX139375
• CTX135782
• CTX200841

Further reading:

• CTX139375 – Blank Screen During Log On or Log Off Server OS Machines
• CTX124877 – Unable to Connect to XenDesktop Virtual Desktop Agent on Vista or Windows 7 with WDDM Driver
• CTX123952 – Unable to Connect to XenDesktop Virtual Desktop Agent on Windows 7 with VMware Tools ESX 4.0 Update 1
• CTX135782 – Black or Blue Screen When Connecting to Published Desktop
• CTX200841 – Sessions Disconnecting on XenDesktop 7.x and NetScaler 10.x with Session Reliability Enabled
• CTX142036 – Hotfix ICATS760WX64009 – For VDA Core Services 7.6 for Windows Server OS (64-bit) – English
• CTX137731 – VDA Issues using Remote PC on Windows 8 and Secure Boot Enabled
• KB2590550 – The desktop does not load and only displays a black or blue background after you log on to a computer that is running Windows 7 or Windows Server 2008 R2
• KB314825 – How to Troubleshoot Black Hole Router Issues
• Citrix XenDesktop 7.1 Slow Logon Black Screen

The post Citrix XenDesktop 7.x – Black or Blank or Blue Screen when connecting to Published Desktop appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

Almost everybody has struggled with the now infamous Error 1030 (The connection to “ApplicationName” failed with status (1030)) when connecting with Citrix Receiver for Windows to XenDesktop through NetScaler and StoreFront. There even is an whole armada of articles available out there, totally dedicating their content to troubleshooting this quite generic network error indicating that the connection has failed. Just google it!

The solution to this error? Well, it depends…

The most common issues based on experience are:

• required ports blocked in your firewall, especially TCP 1494 and TCP 2598
• STA configuration mismatch in NetScaler and StoreFront
• NetScaler licensing issues (Basic Mode vs SmartAccess Mode)
• DNS name resolution issues
• Proxy configuration issues
• SSL issues regarding StoreFront’s server certificate being issued by a private CA that is not trusted by the endpoint
• launch.ica file issues

As Carl Stalhood once pointed out here:

1030 usually means one of the following:

• STAs are invalid. STAs on StoreFront don’t match the STAs on the NetScaler Gateway
• Firewall is blocking TCP 1494 and TCP 2598 from the NetScaler SNIP (not the VIP) to every internal VDA
• StoreFront did not recognize it as a Gateway connection and is giving out the internal IP of the VDA instead of the gateway address

You can look in the ICA file to make sure it’s trying to use the  Gateway: http://support.citrix.com/article/CTX115304

In my case it turned out that I received the 1030 error as soon as I added my AppController’s STA URL to the StoreFront configuration under the “NetScaler Gateway” node in the “Secure Ticket Authority” option. As far as I know this is required for a XenMobile implementation but as for me it suffices adding the AppController STA URL in NetScaler. This behaviour can be reproduced at any time:

To get a more detailed error description when connecting, try to disable Desktop Viewer Toolbar as per CTX131867:

The StoreFront Services Receiver for Web configuration can be modified as follows to disable Desktop Viewer Toolbar:

1. Log on to StoreFront Services server
2. Open C:\inetpub\wwwroot\Citrix\<StoreWeb>\web.config with Notepad
3. Change showDesktopViewer=”false”
4. Save the changes

After adjusting the web.config file I received the following error instead of the generic 1030 message:

This error message pointed me in the direction of my AppController as it displayed its STA ID. Upon investigating I found the aforementioned misconfiguration in StoreFront’s NetScaler Gateway settings.

Furthermore you could disable Session Reliability (equals to Common Gateway Protocol (CGP) running on Port 2598) in StoreFront in order to receive a more meaningful error message:

1. Log on to StoreFront Services server
2. Open StoreFront MMC
3. Navigate to NetScaler Gateway node
4. Select your NetScaler Gateway in the middle pane
5. Click Secure Ticket Authority in the right pane
6. Disable checkbox for Enable Session Reliability and click OK

Another time the firewall was blocking ports TCP 80, 443, 1494, and TCP 2598 from the NetScaler SNIP (not the VIP) to my internal VDA, i.e. Citrix Workers. As soon as the corresponding firewall rules had been adjusted it worked.

2015-10-20 Update:
Once again I had problems pointing to DNS name resolution issues, i.e. you have to ensure that besides the aforementioned ports necessary for smooth communication you have to consider DNS. All Controllers, Workers, and StoreFront servers need to be resolvable by NetBIOS names and FQDN from a client point of view. A client utilized access to XenApp published resources through StoreFront from another network and Active Directory Domain by connecting both networks via VPN. All required ports were available, but we missed to enable a successful name resolution mechanism for client computers in the source domain connecting to Citrix resources in the target domain. Consider multiple DNS Suffices and DNS Suffix Search Lists as well.

2016-07-04 Update:
In case you’re using a Proxy Server in your Environment (or con’t use any Proxy alltogether): keep in mind that wrong Proxy Settings in WebInterface and/or launch.ica can cause an Error 1030 as well. Prior to StoreFront v2.x there was no GUI Option to edit any client-side Proxy Settings for Citrix Receiver, thus leaving you with adjusting the default.ica configuration file. For StoreFront v3.x onwards read this thread from Citrix Discussions. You have to set ProxyType=None in both the [WFClient] and [Application] sections of default.ica configuration file. With WebInterface v5.x you can adjust client-side Proxy Settings in the WebInterface Management Console by highlighting your XenApp and/or XenApp Services Site and chosing Client-Side Proxy in the Action pane (for details check out p153 of the WebInterface 5.4 Documentation [PDF]). And have a look at David’s article on this issue as well.

As you can see there is no all encompassing solution to this error, instead leaving you to further investigate and keep the aforementioned hints in mind.

Further reading:

• CTX133773 – Troubleshooting 1030 Error on Windows 7 Image
• CTX135009 – Error: The connection to Windows Desktop failed with status 1030
• CTX132723 – Case Study: Error 1030 Reported during Logon Attempt to XenDesktop Session
• CTX131867 – Desktop Viewer Toolbar Affects XenApp Published Desktops Using StoreFront Services Receiver for Web
• CTX115304 – How to Save the Launch.ica File to a Client Computer
• CTX137254 – Error 1030 on External Access with Proxy
• Citrix Discussions – 1030 or 1110 error when accessing the desktop via NetScaler
• Citrix Discussions – The Connection to desktops failed with status (1030)
• David R Figueroa – StoreFront & 1030 Errors
• Citrix Error: The connection to *** failed with status 1030
• The connection to “Desktop” failed with status 1030
• Citrix Discussions – StoreFront Client-Side Proxy Settings

The post Citrix Receiver for Windows – The connection to “ApplicationName” failed with status (1030) – Updated appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

Citrix Receiver for Mac – Session Printer Mapping Issues – Printers don’t show or won’t get mapped

Update: Have a look at Carl’s article as well: Print Driver for Non-Windows Clients

As per Citrix CTX140208 and CTX139020:

When non-Windows Receivers connect to a Windows 2012 Server with Universal Print Driver (UPD) options configured for client printers, the Post-script (PS) and PCL drivers might not be available, therefore the printers will not get auto-created. As a workaround, to use the Citrix UPD for non-window Receivers, like Mac and Linux, install appropriate drivers on the server manually:

• PS driver = HP Color LaserJet 2800 Series PS
• PCL4 driver = HP LaserJet Series II
• PCL5c driver = HP Color LaserJet 4500 PCL 5

With my Windows Server 2012 R2 I ran into some issues. While trying to add the aforementioned Printer Drivers manually I realized that something was wrong:

As you can see from the screenshot the button Windows Update is unavailable. This left me with investigating why that is the case. After a little bit of research I ended up with two possible solutions:

1. Configure the corresponding registry settings for Windows Update
2. Install a local printer and chose the appropiate model/driver as listed above

Configure Windows Update via Registry:

1. Run registry editor. Click Start then type regedit and press Enter
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DriverSearching
3. Change value of REG_DWORD DontSearchWindowsUpdate to 0
4. Change value of REG_DWORD DontPromptForWindowsUpdate to 0
5. Run a Command Prompt. Click Start then type cmd and press Enter
6. Execute gpupdate /force

Furthermore I found this in the comments here:

HKLM\Software\Policies\Microsoft\Windows\DriverSearching – REG_DWORD – searchorderConfig = 0
This removes that Windows Update button from the Add Printer Wizard. You can either set this key to “2”, or just delete the key to restore the Windows Update button.
This is the “Disable automatic updates of drivers from Windows Updates” feature above.

Install printer locally:

Whereas adding just the required drivers left me with no Windows Update button to click, I found this article pointing me in the right direction:

I had the same issue, but found it only occurred when I was trying to add a network printer. When I try to add a local printer the button shows up. So….. I installed a local printer, allowed Windows Update to download the new drivers and then deleted the local printer. Next I add the network printer again, but this time, because the list of drivers has been refreshed, I didn’t need the Windows Update button because my printer is now in the list.

Upon reading CTX140208 once more it became obvious and clear that I didn’t read the article with the required attention to detail, as it clearly states:

1. From the Windows Server 2012, choose Add a printer from Devices and Printers.
2. Continue through the wizard as if you are adding a local printer though it is not attached.
3. Click Add a local printer > select LPT1: (Printer Port) > click Windows Update.

Silly me!

2015-11-09 Update:

As Alexander Gassner pointed out here I could have checked my Device Installation Settings as well, as they tend to prohibit the Windows Update functionality too:

• either go for Control Panel | Change Device Installation Settings
• or search for Change Device Installation Settings

• Select both No, let me choose what to do + Always install the best driver software from Windows Update
• and hit Save Changes

I launched Print Management console, drilled down to the Printers node, right-clicked it and chose Add Printer:

Then selected Add a new printer using an existing port with LPT1:

Then selected Install a new driver:

The Windows Update button was finally there, I hit it, and waited for the updated drivers to get downloaded:

Afterwards I was able to select the required drivers and install the required printers:

As Citrix pointed out in CTX139020, “if there are two versions of this driver displayed, choose the Microsoft version“.

In the end it looked like this:

Further reading:

• CTX128594 – Citrix Universal Print Driver Component Drivers in Citrix Presentation Server 4.5/XenApp 5.0 and XenApp 6.x
• CTX120811 – Printing with the Mac 10.x ICA Client Explained
• CTX140208 – Non-Windows Clients may not Autocreate Printers on Windows Server 2012 using the Citrix UPD
• CTX139020 – Configuring Virtual Machines for Mac Client Printer Mapping with Windows 8.x
• Citrix Discussions – XenDesktop 7 on Server 2012 with Mac OSX Receiver
• Support Knowledge Center – Receiver for Mac

The post Citrix Receiver for Mac – Session Printer Mapping Issues – Printers don’t show or won’t get mapped appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

This one’s quite easy, actually. Did you ever wonder how to remove those GoTo Icons from your StoreFront Store and/or Start Menu Shortcuts?

Open your StoreFront Console, navigate to your Store node, select the corresponding Store, and click Integrate with Citrix Online in the right hand pane:

Disable all GoTo applications and confirm with OK:

Refresh your Applications with Citrix Receiver and they’ll be gone.

The post Citrix StoreFront – Remove GoToMeeting et al from Published Applications appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

Starting with Citrix XenDesktop 7.x there have been some features that have been deprecated by Citrix, such as LPT and COM Port Mapping, which are not working as expected or properly after upgrading to VDA 7.x. I stumbled upon this quite annoying issue as soon as I upgraded my existing Citrix XenApp servers to the latest XenDesktop 7.x, i.e. Hosted Shared Desktops with Virtual Desktop Agents v7.x.

As for me my legacy servers, that is Citrix Presentation Server 4.5, had COM Port Mapping/Redirection enabled, in order to provide access to a locally installed COM Port devices (data logger reading devices) for XenApp published applications. This worked fine as long as the system has not been touched by any means. While migrating to XenDesktop 7.x (with all new shiny Windows Server 2008 R2 and Windows Server 2012 VMs), I had to install and upgrade all previously used applications in order to make them work on the new Microsoft O/S. Even the data logger reading application made it to Windows Server 2012, as an upgrade was available. But from then on I had quite some trouble getting the COM Port Mapping/Redirection feature back to work as it previously did…

As you might have noticed there is a Citrix Policy setting in Citrix Studio that says:

• Client COM Port Redirection
• Auto Connect Client COM Ports

I eagerly configured those policy settings in order to allow and redirect COM ports, but it didn’t work. These settings simply did nothing! I realized that these settings only take effect if used with XenDesktop versions up to v5.6 FP1. With later VDAs, such as v7.x, it doesn’work anymore. I did some digging and found something in Citrix eDocs titled Features not in this release:

COM Port Mapping — COM Port Mapping allowed or prevented access to COM ports on the user device. COM Port Mapping was previously enabled by default. In this release, COM Port Mapping is disabled by default. For details, see Configure COM Port and LPT Port Redirection settings using the registry.

And further:

Policy settings for COM Port and LPT Port Redirection have been deprecated from the Studio, and moved to the registry, and are now located under HKLM\Software\Citrix\GroupPolicy\Defaults\Deprecated on either your Master VDA image or your physical VDA machines.

Alas! A solution to my problem. Mind that all registry keys depicted in the following table are of type REG_DWORD:

Further reading:

• Citrix Discussions – Citrix XenDesktop 7.x – Client Drive and COM Port Mapping not working properly
• Citrix Discussions – COM Port Redirection
• Citrix eDocs – Configure COM Port and LPT Port Redirection settings using the registry
• Citrix Blogger – Citrix COM Port Mapping (Part I) Old and New Ways
• Citrix Blogger – Citrix Com Port Mapping (Part II) Just the Old Way
• CTX238200 – How to Troubleshoot Client Drive Mapping
• CTX983798 – Purpose of CMSTART command
• CTX127614 – Differences in Client Drive Mapping between XenApp 6.0 and 6.5, Presentation Server 4.5, and XenApp 5.0
• Eaglan’s Blog – Client Drive Mapping failing

The post Citrix XenDesktop 7.x – Client Drive, LPT and COM Port Mapping not working properly appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

I came upon this quite frequent issue with my XenDesktop 7.8 Hosted Shared Desktop environment based on Windows Server 2008 R2. Folder Redirection via GPO is in place, whereas Citrix User Profile Management is not used.

I tried the following to no prevail:

• remove C:\Users\Default\AppData\Local\Microsoft\Windows\userclass.dat (which did not exist on my system in the first place)
• related to Desktop Experience, i.e. C:\Windows\System32\TSTheme.exe (removed Users group from Reading the executable, renamed the executable)
• Microsoft Hotifx KB2661001 for Windows Server 2008 R2
• disabling Windows Search service
• modified the XenApp server to force IPv4 to take precedence over IPv6 (already disabled IPv6 as described in KB929852 in the first place)
• analyzed potential Folder Redirection issues
• adding DisableStatus=00000001 in HKLM\SOFTWARE\Wow6432Node\Citrix\Logon as per CTX135782
• and all else described at Citrix XenApp – Long logon times and potential fixes

Group Policy Logon Delay

As per Carl Stalhood – Citrix Group Policy Logon Delay Workaround:

Citrix Discussions Xenapp 7.9: Wait for local session manager: “I have a Xenapp 7.9 environment on Windows 2012 R2. When logging in through Citrix I got message “Wait for local session manager” for 20-30 seconds. When logging in to the server with RDS, I do not have to wait for this.”

“Add the following 2 registry keys to your 7.9 VDA server – then try connecting to it using ICA to see if the issue still occurs:

Add reg keys in “HKLM\SOFTWARE\Citrix\GroupPolicy”

• REG_DWORD: “CacheGpoExpireInHours” – Value = 5-24 (# of Hours) ***start with value of 5***
• REG_DWORD: “GpoCacheEnabled” – Value = 1

Restart the machine after adding these registry keys and attempt an ICA connection (at least twice) to see if that helps the Login delay.”

Multi-Homed DCs

In case you have multi-homed Domain Controllers, i.e. with at least two NICs and thus two different IP addresses, and of which one NIC happens to be connected to a non-routable network, this might cause this issue as well (pls read Please wait for the Local Session Manager). If the NIC connectecd to the non-routable network is goig to register its IP address with DNS and your XenApp server tries to connect to this exact same IP address in return (through DNS name resolution), the connection attempt would time out eventually and then authenticate against another, reachable DC. To remedy this situation do as described in KB975808:

• Ensure Register this connection’s addresses in DNS is unchecked on the NIC’s TCP/IP Advanced IP Settings under the DNS tab
• Issue the command netsh int ipv4 add address <Interface Name> <ip address> <subnet mask> skipassource=true

My Troubleshooting Methodology

As none of the above worked for me I had to further investigate the issue. I started with analyzing the actual Logon Process and Logon Duration with both ControlUp’s Analyze_Logon_Duration.ps1 and Citrix Director.

In order to run the script make sure that Audit Process Tracking has been enabled as per Citrix Blog and KB921468, otherwise you could receive error messages stating Could not find Network Providers events (requires audit process tracking) or Could not find Pre-Shell (Userinit) events (requires audit process tracking) when running the Powersell script:

With Citrix Director I found out that my Logon Duration took 43sec, especially the Interactive Session part of the Logon Process:

Interactive Session is defined as per Citrix eDocs as follows:

This is the time taken to “hand off” keyboard and mouse control to the user after the user profile has been loaded. It is normally the longest duration out of all the phases of the logon process and is calculated as follows:

Interactive Session duration = Desktop Ready Event Timestamp (EventId 1000 on VDA) – User Profile Loaded Event Timestamp (EventId 2 on VDA)

The following Citrix Blog explains the Interactive Session part of the Logo Duration in detail. It mentions another article which suggests adding a registry value in order to reduce the startup delay further:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Serialize
REG_DWORD: StartupDelayInMSec
Value: 0

Well, it worked in that particular case in that it reduced my Logon Duration a little bit more. But not to a point where it seemed acceptable for my users.

In the end I uninstalled the following, just recently released maligned Microsoft Updates:

• KB3161949 (Network Shares became unavailable)
• KB3164033 (caused printing issues due to updating GDI.dll)
• KB3164035
• KB3159398 (caused issues with GPO Processing)

After rebooting my affected server the issue went away, as my Logon Duration (especially Interactive Session) came down to a total of 17sec:

Further investigation was therefore not possible at this point of time. I’ll keep a look at it and will update this article accordingly. And have a look at the Links at the bottom of my blog as well.

As per Xenapp 7.9: Wait for local session manager adjusting the following registry settings might improve performance as well:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows
Name: AppInit_DLLs
Type: String
Value: mfaphook64.dll
Old Value: C:\Program Files\Citrix\System32\mfaphook64.dll

HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows
Name: AppInit_DLLs
Type: String
Value: mfaphook.dll
Old Value: C:\Program Files(x86)\Citrix\System32\mfaphook.dll

Further reading:

• KB2661001 – “Please wait for Local Session Manager” message remains for several minutes when you disconnect from a computer that is running Windows Server 2008 or Windows Server 2008 R2 during the logon process
• TechNet – Analyze Session Logon Duration
• XenAppBlog – Optimize Logon Times – Part 1: Citrix Director
• Citrix XenApp – Long logon times and potential fixes
• CTX133595 – Slow Initial Login When Using Folder Redirection
• Citrix Discussions – Please wait for Local Session Manager
• Citrix Blogs – Troubleshooting Slow Logons via Powershell
• Citrix Blogs – Logon Duration explained
• Slow Boot Slow Logon (SBSL), A Tool Called XPerf and Links You Need To Read
• Who broke my user GPOs?
• Citrix Blogs – Interactive Session of Logon Duration in Citrix Director – Explained
• Citrix Blogs – Citrix Logon Times – Rule of 30
• Citrix eDocs – Diagnose user logon issues
• The Complete Guide to Understanding the Citrix Logon Process for XenApp/XenDesktop (registration required)

The post XenApp/XenDesktop – “Please Wait For Local Session Manager” message when logging into RDS appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

Just recently I was tasked to identify all Citrix Receiver Versions connecting to a Citrix XenDesktop 7.x environment.

For starters, to get information on current sessions issue the following PowerShell cmdlets on your Citrix Broker Server:

Add-PSSnapin *Citrix*
Get-BrokerSession | Select MachineName,UserName,ClientPlatform,ClientVersion,*Protocol* | Out-GridView

To get hands on every single information of your current Broker Sessions simply run:

Get-BrokerSession | Out-GridView

Now, in terms of historical session and connection information you have to query the OData API (http://<ServerBrokerFQDN>/Citrix/Monitor/OData/v2/Data), as with the Get-BrokerSession cmdlet you only get information on current sessions. So in case you’re looking for historical reports and data, which you cannot find in the Director Web UI, you could simply create a custom report with Microsoft Excel by connecting to the Data Feed.

This leaves me with recommending the following Citrix Blog Article, that explains how to

• connect and read the available OData Data Feed from your Citrix Broker Server,
• read the content of the Connection table and import it into an Excel Sheet,
• limit the data’s timeframe we’re looking at,
• add a PivotChart, and
• filter the required data.

The result might look something like this:

You can then tinker with the different tables available through the Data Feed in order to achieve the resultant data set required for your purpose. As opposed to the aforementioned Citrix Blog you could select the following tables to even get information on Citrix Receiver Versions, Client Names, and corresponding User Names:

• Connection
• Session
• User

Just have a look at the underlying SQL DB and its Database Diagram in order to reveal the tables’ relationships:

Then you should be able to rebuild these relationships within Microsoft Excel and get the resultant set of data including corresponding user names:

Otherwise you could create a corresponding View directly within SQL Server Management Studio on the server hosting your XenDesktop SQL Monitoring database. I created one and called it v_ReceiverVersions, thus allowing me to access the data through Excel as well. The custom View includes the aforementioned tables

• Connection (MonitorData)
• Session (MonitorData)
• User (MonitorData)

SELECT MonitorData.Connection.ClientName, MonitorData.Connection.ClientVersion, MonitorData.Connection.BrokeringDate, MonitorData.[User].Upn
FROM MonitorData.Connection INNER JOIN
MonitorData.Session ON MonitorData.Connection.SessionKey = MonitorData.Session.SessionKey AND
MonitorData.Connection.Id = MonitorData.Session.CurrentConnectionId INNER JOIN
MonitorData.[User] ON MonitorData.Session.UserId = MonitorData.[User].Id

This setup allows me to filter the available data (i.e. set to the required period in time by utilizing the BrokeringDate) by either choosing ClientName, ClientVersion or UPN:

The data available in Citrix Director is dependent on your Citrix License, which in turn determines your usage data retention within Citrix Director. As per Citrix:

• All editions: Director – real-time monitoring and basic troubleshooting (up to 7 days of data)
• XD7 Platinum: EdgeSight performance management feature – includes #1 + historical monitoring (up to a full year of data through the monitoring SQL database)
• XD7 Platinum + NetScaler Enterprise: EdgeSight performance management and network analysis – includes #2 plus 60 mins. of network data
• XD7 Platinum + NetScaler Platinum: EdgeSight performance management and network analysis – includes #2 plus unlimited network data

Further reading:

• Citrix Discussions – Querying client Receiver versions?
• Citrix Blogs – Creating Director Custom reports for Monitoring XenDesktop
• Citrix Blogs – XenDesktop 7 Monitor Service – What Data is Available?
• Citrix Blogs – Citrix Director: Analyzing the Monitoring Data by Means of Custom Reports
• Citrix Blogs – XenDesktop 7: Director and EdgeSight explained!
• Citrix – XenApp and XenDesktop 7.12 Features Matrix

The post Citrix XenDesktop 7.x – Query Citrix Receiver Versions connecting to your environment – XLS Report appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

After upgrading Citrix Director to v7.6.300 in order to implement the newly added Framehawk Support I ran into an error after launching Citrix Director: An internal error has occurred. For assistance, contract your administrator (including typo):

This error is complemented by an Event ID 1310, Event Source: ASP.NET 4.0.30319.0, in the Application Log on the Controller server:

In my case in turned out that I had modified C:\inetpub\wwwroot\Director\LogOn.aspx in order to pre-populate the domain field as per CTX139896. As I had a backup of the LogOn.aspx file I simply returned to the original one – et violá – it worked again.

After that I tried to edit the LogOn.aspx file again by searching for:

<asp:TextBox ID=”Domain” runat=”server”

and replacing it with:

<asp:TextBox ID=”Domain” Text=”mydomain” readonly=”true” runat=”server”

After saving the file and refreshing the Citrix Director Logon Page at http://<DirectorServerFQDN>/Director it worked as expected.

Make sure you upgrade to v7.6.300 as described by Citrix:

• Download Director, and run the MSI file, DesktopDirector.MSI or DesktopDirector_x64.MSI.
• Install CitrixGroupPolicyManagement.MSI, which is available in the Citrix Policy folder on the XenApp and XenDesktop installation media.
• Configure Director with the Delivery Controller, use the DirectorConfig.exe tool available in C:\inetpub\wwwroot\Director\tools. For more information, see CTX137990.
• Register ASP.net with IIS. To do this, run the command C:\inetpub\wwwroot\Director\tools>DirectorConfig.exe /registerdotnet
• Install or upgrade the WMIProxy on the VDA, and restart the machine. WMIProxy_x64.MSI and WIMIProxy_x86.MSI are included in the Director 7.6.300 download files. Note: The Framehawk virtual channel will be shown as “Not Compatible” with a VDA with Framehawk enabled, if the WMIProxy is not upgraded.
• Upgrade XDPoshSnapin_Hotfix on the Delivery Controller, then restart Studio. XDPoshSnapin MSI is available with the Director files downloaded in step 1. This is required for Delegated Administrators and Custom Administrators to view the Framehawk virtual channel information.

Further reading:

• Citrix Blogs – Citrix Director 7.6.300 : Framehawk Support
• Citrix Product Documentation – Director
• CTX137990 – Citrix Director – DirectorConfig Tool
• CTX139896 – How to Pre-populate Domain Name for Citrix Director Logon Page

The post Citrix Director v7.6.300 Upgrade – An internal error has occurred. For assistance, contract your administrator. appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

Upon upgrading Citrix Profile Management to v5.2.1 on one of my Workers and rebooting my users were unable to connect to that server. It came down to a Load Evaluator Index of 10000:

Citrix Studio showed 1 Failed Server OS Machine:

Further searching pointed me to an Event ID 1101, Event Source: Citrix Broker Service, in my Controller’s Application Event Log:

The Citrix Broker Service failed to broker a connection for user ‘DOMAIN\User’ to resource ‘Windows Explorer’. The Citrix Broker Service cannot find any available virtual machines.

Well, quite obvious, as the Load Evaluator Index of 10000 equals a Full Load and prohibits any Citrix related logons (though RDP connections are still possible).

How to get the current Load Evaluator Index?

As there is no qfarm /load available anymore with XenDesktop 7.x due to the switch from IMA to FMA architecture you have to use Windows Powershell instead. Run the following commands on your Controller server in order to get the Load Index of your Workers:

Add-PSSnapin *Citrix*

Get-BrokerMachine -SessionSupport MultiSession -Property ‘DNSName’,’LoadIndex’,’SessionCount’

Digging through the Event Logs of my Controller and affected Worker even more (as a first measure) I found several Event IDs 1039, Source: Citrix Broker Service, in my Worker’s Application Event Log, stating issues with Performance Counters unable to load:

• The Citrix Desktop Service failed to initialize a performance counter. Load management associated with this counter will be disabled.
  Counter details:
  Category ‘Processor’, counter ‘% Processor Time’ and instance’_Total’
  Error details:
  Exception ‘System.InvalidOperationException’ of type ‘Category does not exist.’
• The Citrix Desktop Service failed to initialize a performance counter. Load management associated with this counter will be disabled.
  Counter details:
  Category ‘Memory’, counter ‘Available MBytes’ and instance”
  Error details:
  Exception ‘System.InvalidOperationException’ of type ‘Category does not exist.’
• The Citrix Desktop Service failed to initialize a performance counter. Load management associated with this counter will be disabled.
  Counter details:
  Category ‘PhysicalDisk’, counter ‘Avg. Disk Queue Length’ and instance’_Total’
  Error details:
  Exception ‘System.InvalidOperationException’ of type ‘Category does not exist.’

I then ran lodctr /R within a Command Prompt on the affected Worker in order to rebuild Windows Performance Counters:

After a successful rebuilt I restarted the Citrix Desktop Service on the Worker – et violá – the Load Evaluator Index came down:

All back to normal.

Update 2016-01-18:

Have a look at Citrix eDocs as well. The article Load Management policy settings might help as well, as I once had a Worker with a published application that consumed a lot of memory. Thus my Physical Memory Usage history showed that almost 95% have been consumed and rendered the server unavailable due to Full Load.

Further reading:

• Hosted Shared Desktop on XenDesktop 7.1
• Citrix eDocs – Load Management policy settings
• Citrix Blogs – Get XenDesktop load balancing information using the SDK

The post Citrix XenDesktop 7.6 – Hosted Shared Desktop shows Load Evaluator Index of 10000 after reboot appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

Citrix XenDesktop 7.x – Black Screen when connecting to Published Desktop

When connecting to a Windows Server 2008 R2 Published Desktop (provisioned as a VM, not a physical machine) with XenDesktop 7.x you might receive a black and blank Desktop, no Desktop Icons are shown, and the Desktop stays that way:

Whereas connecting with RDP works normally, as long as the users are members of the local group Direct Access Users.

There are no significant Warnings and/or Error messages in the corresponding server’s Application and/or System Event Log. Everything seems to look and work as expected. In my case the error started showing up after moving the VM from one Hyper-V server to another Hyper-V server.

Having a look into the Citrix\Device\Redirector Application Log in Event Viewer showed an Event ID 261, Event Source: Redirector:

Citrix Device Redirector service could not complete an I/O Redirector Bus operation.

This can happen due to the following reasons:

• network issues between XenDesktop Worker hosting VDA and NetScaler/StoreFront
• wrong graphics card driver in VM when using VMware as a Hypervisor
• having ghost devices in Device Manager resulting in orphaned drivers on your Windows Server OS
• having HDX 3D Pro enabled on a physical host during installation of the VDA though not having a compatible graphics card inside
• Secure Boot is enabled on your Hyper-V Server for the affected VM
• VDA is corrupt

As per Citrix (CTX135782):

Problem Cause
There are several that could have caused the issue.
A majority of them are related to drive mappings or folder redirections in logon scripts, user profiles and/or GPOs, which point to an incorrect location or experience delays mapping during the logon process.

Possible solutions:

1. Network Issues

As per Microsoft KB314825:

“On a TCP/IP-based wide area network (WAN), communication over some routes may fail if an intermediate network segment has a maximum packet size that is smaller than the maximum packet size of the communicating hosts–and if the router does not send an appropriate Internet Control Message Protocol (ICMP) response to this condition or if a firewall on the path drops such a response. Such a router is sometimes known as a “black hole” router.”

Locate and fix a possible Black Hole Router. Furthermore regard these best practices for your servers:

• Power Management on the corresponding NIC has been disabled
• TCP Autotuning has been disabled by executing
  • “netsh interface tcp set global autotuning=disabled”
  • “netsh interface tcp set global rss=disabled”
  • “netsh interface tcp set global chimney=disabled”
• DEP has been disabled by executing “bcdedit.exe /set {current} nx AlwaysOff”

2. Graphics Card Driver

When using VMware as a Hypervisor change the default graphics card driver coming with VMware tools. The resolution is to uninstall the WDDM or VMware SVGA driver from the affected VM and install Microsoft SVGA driver instead. Refer to CTX124877 and CTX123952:

Have a look at Jan Hendriks’ blog as well: XenDesktop 7.6 Black Screen issue with VMWare SVGA 3D Driver

3. Remove Ghost Devices

1. Open a cmd prompt with elevated rights
2. Execute”SET DEVMGR_SHOW_NONPRESENT_DEVICES=1″
3. Execute “devmgmt.msc”
4. Click View => Show Hidden Devices
5. Expand every single node and remove/uninstall any ghost device found
6. Reboot server

4. Disable HDX 3D Pro

HDX 3D Pro can only be used on physical machines as long as a compatible graphics card has been installed. In case you provisioned your servers from a base image that somehow utilized this feature in the first place it might come down to the black screen issue when connecting with HDX/ICA. Simply uninstall the VDA from the affected machine, reboot the server, and then reinstall the VDA again. This should suffice.

5. Disable Secure Boot (Hyper-V only)

Shut down the affected VM and execute the following command in Powershell on your Hyper-V Server:

Set-VMFirmware –Vmname <VMName> –EnableSecureBoot Off

In case Secure Boot is enabled on the affected VM the symptoms of a black screen will appear thus rendering the server useless. When trying to install the VDA on a VM with Secure Boot enabled you’ll receive a warning message pointing you to CTX137731. Though the message can be ignored and the installation process continued this is not recommended:

6. Reinstall VDA:

Simply uninstall VDA from the affected server, reboot the server, and then reinstall the VDA.

7. Set the Registry Key Logon:

Add or set the following registry key on the XenApp/XenDesktop server(s) to resolve the issue:

• Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Logon
• Name: DisableStatus
• Type: REG_DWORD
• Value: 00000001

My solution:

As for me I had to disable Secure Boot for the affected VM. After that everything worked normal again. I simply forgot to disable Secure Boot after moving the VM from one Hyper-V server to another Hyper-V server.

There are a couple of different registry tweaks available that I usually apply to my Citrix Workers via GPO Preferences as well:

• CTX139375
• CTX135782
• CTX200841

Further reading:

• CTX139375 – Blank Screen During Log On or Log Off Server OS Machines
• CTX124877 – Unable to Connect to XenDesktop Virtual Desktop Agent on Vista or Windows 7 with WDDM Driver
• CTX123952 – Unable to Connect to XenDesktop Virtual Desktop Agent on Windows 7 with VMware Tools ESX 4.0 Update 1
• CTX135782 – Black or Blue Screen When Connecting to Published Desktop
• CTX200841 – Sessions Disconnecting on XenDesktop 7.x and NetScaler 10.x with Session Reliability Enabled
• CTX142036 – Hotfix ICATS760WX64009 – For VDA Core Services 7.6 for Windows Server OS (64-bit) – English
• CTX137731 – VDA Issues using Remote PC on Windows 8 and Secure Boot Enabled
• KB2590550 – The desktop does not load and only displays a black or blue background after you log on to a computer that is running Windows 7 or Windows Server 2008 R2
• KB314825 – How to Troubleshoot Black Hole Router Issues
• Citrix XenDesktop 7.1 Slow Logon Black Screen

The post Citrix XenDesktop 7.x – Black or Blank or Blue Screen when connecting to Published Desktop appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

Almost everybody has struggled with the now infamous Error 1030 (The connection to “ApplicationName” failed with status (1030)) when connecting with Citrix Receiver for Windows to XenDesktop through NetScaler and StoreFront. There even is an whole armada of articles available out there, totally dedicating their content to troubleshooting this quite generic network error indicating that the connection has failed. Just google it!

The solution to this error? Well, it depends…

The most common issues based on experience are:

• required ports blocked in your firewall, especially TCP 1494 and TCP 2598
• STA configuration mismatch in NetScaler and StoreFront
• NetScaler licensing issues (Basic Mode vs SmartAccess Mode)
• DNS name resolution issues
• Proxy configuration issues
• SSL issues regarding StoreFront’s server certificate being issued by a private CA that is not trusted by the endpoint
• launch.ica file issues

As Carl Stalhood once pointed out here:

1030 usually means one of the following:

• STAs are invalid. STAs on StoreFront don’t match the STAs on the NetScaler Gateway
• Firewall is blocking TCP 1494 and TCP 2598 from the NetScaler SNIP (not the VIP) to every internal VDA
• StoreFront did not recognize it as a Gateway connection and is giving out the internal IP of the VDA instead of the gateway address

You can look in the ICA file to make sure it’s trying to use the  Gateway: http://support.citrix.com/article/CTX115304

In my case it turned out that I received the 1030 error as soon as I added my AppController’s STA URL to the StoreFront configuration under the “NetScaler Gateway” node in the “Secure Ticket Authority” option. As far as I know this is required for a XenMobile implementation but as for me it suffices adding the AppController STA URL in NetScaler. This behaviour can be reproduced at any time:

To get a more detailed error description when connecting, try to disable Desktop Viewer Toolbar as per CTX131867:

The StoreFront Services Receiver for Web configuration can be modified as follows to disable Desktop Viewer Toolbar:

1. Log on to StoreFront Services server
2. Open C:\inetpub\wwwroot\Citrix\<StoreWeb>\web.config with Notepad
3. Change showDesktopViewer=”false”
4. Save the changes

After adjusting the web.config file I received the following error instead of the generic 1030 message:

This error message pointed me in the direction of my AppController as it displayed its STA ID. Upon investigating I found the aforementioned misconfiguration in StoreFront’s NetScaler Gateway settings.

Furthermore you could disable Session Reliability (equals to Common Gateway Protocol (CGP) running on Port 2598) in StoreFront in order to receive a more meaningful error message:

1. Log on to StoreFront Services server
2. Open StoreFront MMC
3. Navigate to NetScaler Gateway node
4. Select your NetScaler Gateway in the middle pane
5. Click Secure Ticket Authority in the right pane
6. Disable checkbox for Enable Session Reliability and click OK

Another time the firewall was blocking ports TCP 80, 443, 1494, and TCP 2598 from the NetScaler SNIP (not the VIP) to my internal VDA, i.e. Citrix Workers. As soon as the corresponding firewall rules had been adjusted it worked.

2015-10-20 Update:
Once again I had problems pointing to DNS name resolution issues, i.e. you have to ensure that besides the aforementioned ports necessary for smooth communication you have to consider DNS. All Controllers, Workers, and StoreFront servers need to be resolvable by NetBIOS names and FQDN from a client point of view. A client utilized access to XenApp published resources through StoreFront from another network and Active Directory Domain by connecting both networks via VPN. All required ports were available, but we missed to enable a successful name resolution mechanism for client computers in the source domain connecting to Citrix resources in the target domain. Consider multiple DNS Suffices and DNS Suffix Search Lists as well.

2016-07-04 Update:
In case you’re using a Proxy Server in your Environment (or con’t use any Proxy alltogether): keep in mind that wrong Proxy Settings in WebInterface and/or launch.ica can cause an Error 1030 as well. Prior to StoreFront v2.x there was no GUI Option to edit any client-side Proxy Settings for Citrix Receiver, thus leaving you with adjusting the default.ica configuration file. For StoreFront v3.x onwards read this thread from Citrix Discussions. You have to set ProxyType=None in both the [WFClient] and [Application] sections of default.ica configuration file. With WebInterface v5.x you can adjust client-side Proxy Settings in the WebInterface Management Console by highlighting your XenApp and/or XenApp Services Site and chosing Client-Side Proxy in the Action pane (for details check out p153 of the WebInterface 5.4 Documentation [PDF]). And have a look at David’s article on this issue as well.

As you can see there is no all encompassing solution to this error, instead leaving you to further investigate and keep the aforementioned hints in mind.

Further reading:

• CTX133773 – Troubleshooting 1030 Error on Windows 7 Image
• CTX135009 – Error: The connection to Windows Desktop failed with status 1030
• CTX132723 – Case Study: Error 1030 Reported during Logon Attempt to XenDesktop Session
• CTX131867 – Desktop Viewer Toolbar Affects XenApp Published Desktops Using StoreFront Services Receiver for Web
• CTX115304 – How to Save the Launch.ica File to a Client Computer
• CTX137254 – Error 1030 on External Access with Proxy
• Citrix Discussions – 1030 or 1110 error when accessing the desktop via NetScaler
• Citrix Discussions – The Connection to desktops failed with status (1030)
• David R Figueroa – StoreFront & 1030 Errors
• Citrix Error: The connection to *** failed with status 1030
• The connection to “Desktop” failed with status 1030
• Citrix Discussions – StoreFront Client-Side Proxy Settings

The post Citrix Receiver for Windows – The connection to “ApplicationName” failed with status (1030) – Updated appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

Citrix Receiver for Mac – Session Printer Mapping Issues – Printers don’t show or won’t get mapped

Update: Have a look at Carl’s article as well: Print Driver for Non-Windows Clients

As per Citrix CTX140208 and CTX139020:

When non-Windows Receivers connect to a Windows 2012 Server with Universal Print Driver (UPD) options configured for client printers, the Post-script (PS) and PCL drivers might not be available, therefore the printers will not get auto-created. As a workaround, to use the Citrix UPD for non-window Receivers, like Mac and Linux, install appropriate drivers on the server manually:

• PS driver = HP Color LaserJet 2800 Series PS
• PCL4 driver = HP LaserJet Series II
• PCL5c driver = HP Color LaserJet 4500 PCL 5

With my Windows Server 2012 R2 I ran into some issues. While trying to add the aforementioned Printer Drivers manually I realized that something was wrong:

As you can see from the screenshot the button Windows Update is unavailable. This left me with investigating why that is the case. After a little bit of research I ended up with two possible solutions:

1. Configure the corresponding registry settings for Windows Update
2. Install a local printer and chose the appropiate model/driver as listed above

Configure Windows Update via Registry:

1. Run registry editor. Click Start then type regedit and press Enter
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DriverSearching
3. Change value of REG_DWORD DontSearchWindowsUpdate to 0
4. Change value of REG_DWORD DontPromptForWindowsUpdate to 0
5. Run a Command Prompt. Click Start then type cmd and press Enter
6. Execute gpupdate /force

Furthermore I found this in the comments here:

HKLM\Software\Policies\Microsoft\Windows\DriverSearching – REG_DWORD – searchorderConfig = 0
This removes that Windows Update button from the Add Printer Wizard. You can either set this key to “2”, or just delete the key to restore the Windows Update button.
This is the “Disable automatic updates of drivers from Windows Updates” feature above.

Install printer locally:

Whereas adding just the required drivers left me with no Windows Update button to click, I found this article pointing me in the right direction:

I had the same issue, but found it only occurred when I was trying to add a network printer. When I try to add a local printer the button shows up. So….. I installed a local printer, allowed Windows Update to download the new drivers and then deleted the local printer. Next I add the network printer again, but this time, because the list of drivers has been refreshed, I didn’t need the Windows Update button because my printer is now in the list.

Upon reading CTX140208 once more it became obvious and clear that I didn’t read the article with the required attention to detail, as it clearly states:

1. From the Windows Server 2012, choose Add a printer from Devices and Printers.
2. Continue through the wizard as if you are adding a local printer though it is not attached.
3. Click Add a local printer > select LPT1: (Printer Port) > click Windows Update.

Silly me!

2015-11-09 Update:

As Alexander Gassner pointed out here I could have checked my Device Installation Settings as well, as they tend to prohibit the Windows Update functionality too:

• either go for Control Panel | Change Device Installation Settings
• or search for Change Device Installation Settings

• Select both No, let me choose what to do + Always install the best driver software from Windows Update
• and hit Save Changes

I launched Print Management console, drilled down to the Printers node, right-clicked it and chose Add Printer:

Then selected Add a new printer using an existing port with LPT1:

Then selected Install a new driver:

The Windows Update button was finally there, I hit it, and waited for the updated drivers to get downloaded:

Afterwards I was able to select the required drivers and install the required printers:

As Citrix pointed out in CTX139020, “if there are two versions of this driver displayed, choose the Microsoft version“.

In the end it looked like this:

Further reading:

• CTX128594 – Citrix Universal Print Driver Component Drivers in Citrix Presentation Server 4.5/XenApp 5.0 and XenApp 6.x
• CTX120811 – Printing with the Mac 10.x ICA Client Explained
• CTX140208 – Non-Windows Clients may not Autocreate Printers on Windows Server 2012 using the Citrix UPD
• CTX139020 – Configuring Virtual Machines for Mac Client Printer Mapping with Windows 8.x
• Citrix Discussions – XenDesktop 7 on Server 2012 with Mac OSX Receiver
• Support Knowledge Center – Receiver for Mac

The post Citrix Receiver for Mac – Session Printer Mapping Issues – Printers don’t show or won’t get mapped appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

This one’s quite easy, actually. Did you ever wonder how to remove those GoTo Icons from your StoreFront Store and/or Start Menu Shortcuts?

Open your StoreFront Console, navigate to your Store node, select the corresponding Store, and click Integrate with Citrix Online in the right hand pane:

Disable all GoTo applications and confirm with OK:

Refresh your Applications with Citrix Receiver and they’ll be gone.

The post Citrix StoreFront – Remove GoToMeeting et al from Published Applications appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

Starting with Citrix XenDesktop 7.x there have been some features that have been deprecated by Citrix, such as LPT and COM Port Mapping, which are not working as expected or properly after upgrading to VDA 7.x. I stumbled upon this quite annoying issue as soon as I upgraded my existing Citrix XenApp servers to the latest XenDesktop 7.x, i.e. Hosted Shared Desktops with Virtual Desktop Agents v7.x.

As for me my legacy servers, that is Citrix Presentation Server 4.5, had COM Port Mapping/Redirection enabled, in order to provide access to a locally installed COM Port devices (data logger reading devices) for XenApp published applications. This worked fine as long as the system has not been touched by any means. While migrating to XenDesktop 7.x (with all new shiny Windows Server 2008 R2 and Windows Server 2012 VMs), I had to install and upgrade all previously used applications in order to make them work on the new Microsoft O/S. Even the data logger reading application made it to Windows Server 2012, as an upgrade was available. But from then on I had quite some trouble getting the COM Port Mapping/Redirection feature back to work as it previously did…

As you might have noticed there is a Citrix Policy setting in Citrix Studio that says:

• Client COM Port Redirection
• Auto Connect Client COM Ports

I eagerly configured those policy settings in order to allow and redirect COM ports, but it didn’t work. These settings simply did nothing! I realized that these settings only take effect if used with XenDesktop versions up to v5.6 FP1. With later VDAs, such as v7.x, it doesn’work anymore. I did some digging and found something in Citrix eDocs titled Features not in this release:

COM Port Mapping — COM Port Mapping allowed or prevented access to COM ports on the user device. COM Port Mapping was previously enabled by default. In this release, COM Port Mapping is disabled by default. For details, see Configure COM Port and LPT Port Redirection settings using the registry.

And further:

Policy settings for COM Port and LPT Port Redirection have been deprecated from the Studio, and moved to the registry, and are now located under HKLM\Software\Citrix\GroupPolicy\Defaults\Deprecated on either your Master VDA image or your physical VDA machines.

Alas! A solution to my problem. Mind that all registry keys depicted in the following table are of type REG_DWORD:

Further reading:

• Citrix Discussions – Citrix XenDesktop 7.x – Client Drive and COM Port Mapping not working properly
• Citrix Discussions – COM Port Redirection
• Citrix eDocs – Configure COM Port and LPT Port Redirection settings using the registry
• Citrix Blogger – Citrix COM Port Mapping (Part I) Old and New Ways
• Citrix Blogger – Citrix Com Port Mapping (Part II) Just the Old Way
• CTX238200 – How to Troubleshoot Client Drive Mapping
• CTX983798 – Purpose of CMSTART command
• CTX127614 – Differences in Client Drive Mapping between XenApp 6.0 and 6.5, Presentation Server 4.5, and XenApp 5.0
• Eaglan’s Blog – Client Drive Mapping failing

The post Citrix XenDesktop 7.x – Client Drive, LPT and COM Port Mapping not working properly appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

I came upon this quite frequent issue with my XenDesktop 7.8 Hosted Shared Desktop environment based on Windows Server 2008 R2. Folder Redirection via GPO is in place, whereas Citrix User Profile Management is not used.

I tried the following to no prevail:

• remove C:\Users\Default\AppData\Local\Microsoft\Windows\userclass.dat (which did not exist on my system in the first place)
• related to Desktop Experience, i.e. C:\Windows\System32\TSTheme.exe (removed Users group from Reading the executable, renamed the executable)
• Microsoft Hotifx KB2661001 for Windows Server 2008 R2
• disabling Windows Search service
• modified the XenApp server to force IPv4 to take precedence over IPv6 (already disabled IPv6 as described in KB929852 in the first place)
• analyzed potential Folder Redirection issues
• adding DisableStatus=00000001 in HKLM\SOFTWARE\Wow6432Node\Citrix\Logon as per CTX135782
• and all else described at Citrix XenApp – Long logon times and potential fixes

Group Policy Logon Delay

As per Carl Stalhood – Citrix Group Policy Logon Delay Workaround:

Citrix Discussions Xenapp 7.9: Wait for local session manager: “I have a Xenapp 7.9 environment on Windows 2012 R2. When logging in through Citrix I got message “Wait for local session manager” for 20-30 seconds. When logging in to the server with RDS, I do not have to wait for this.”

“Add the following 2 registry keys to your 7.9 VDA server – then try connecting to it using ICA to see if the issue still occurs:

Add reg keys in “HKLM\SOFTWARE\Citrix\GroupPolicy”

• REG_DWORD: “CacheGpoExpireInHours” – Value = 5-24 (# of Hours) ***start with value of 5***
• REG_DWORD: “GpoCacheEnabled” – Value = 1

Restart the machine after adding these registry keys and attempt an ICA connection (at least twice) to see if that helps the Login delay.”

Multi-Homed DCs

In case you have multi-homed Domain Controllers, i.e. with at least two NICs and thus two different IP addresses, and of which one NIC happens to be connected to a non-routable network, this might cause this issue as well (pls read Please wait for the Local Session Manager). If the NIC connectecd to the non-routable network is goig to register its IP address with DNS and your XenApp server tries to connect to this exact same IP address in return (through DNS name resolution), the connection attempt would time out eventually and then authenticate against another, reachable DC. To remedy this situation do as described in KB975808:

• Ensure Register this connection’s addresses in DNS is unchecked on the NIC’s TCP/IP Advanced IP Settings under the DNS tab
• Issue the command netsh int ipv4 add address <Interface Name> <ip address> <subnet mask> skipassource=true

My Troubleshooting Methodology

As none of the above worked for me I had to further investigate the issue. I started with analyzing the actual Logon Process and Logon Duration with both ControlUp’s Analyze_Logon_Duration.ps1 and Citrix Director.

In order to run the script make sure that Audit Process Tracking has been enabled as per Citrix Blog and KB921468, otherwise you could receive error messages stating Could not find Network Providers events (requires audit process tracking) or Could not find Pre-Shell (Userinit) events (requires audit process tracking) when running the Powersell script:

With Citrix Director I found out that my Logon Duration took 43sec, especially the Interactive Session part of the Logon Process:

Interactive Session is defined as per Citrix eDocs as follows:

This is the time taken to “hand off” keyboard and mouse control to the user after the user profile has been loaded. It is normally the longest duration out of all the phases of the logon process and is calculated as follows:

Interactive Session duration = Desktop Ready Event Timestamp (EventId 1000 on VDA) – User Profile Loaded Event Timestamp (EventId 2 on VDA)

The following Citrix Blog explains the Interactive Session part of the Logo Duration in detail. It mentions another article which suggests adding a registry value in order to reduce the startup delay further:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Serialize
REG_DWORD: StartupDelayInMSec
Value: 0

Well, it worked in that particular case in that it reduced my Logon Duration a little bit more. But not to a point where it seemed acceptable for my users.

In the end I uninstalled the following, just recently released maligned Microsoft Updates:

• KB3161949 (Network Shares became unavailable)
• KB3164033 (caused printing issues due to updating GDI.dll)
• KB3164035
• KB3159398 (caused issues with GPO Processing)

After rebooting my affected server the issue went away, as my Logon Duration (especially Interactive Session) came down to a total of 17sec:

Further investigation was therefore not possible at this point of time. I’ll keep a look at it and will update this article accordingly. And have a look at the Links at the bottom of my blog as well.

As per Xenapp 7.9: Wait for local session manager adjusting the following registry settings might improve performance as well:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows
Name: AppInit_DLLs
Type: String
Value: mfaphook64.dll
Old Value: C:\Program Files\Citrix\System32\mfaphook64.dll

HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows
Name: AppInit_DLLs
Type: String
Value: mfaphook.dll
Old Value: C:\Program Files(x86)\Citrix\System32\mfaphook.dll

Further reading:

• KB2661001 – “Please wait for Local Session Manager” message remains for several minutes when you disconnect from a computer that is running Windows Server 2008 or Windows Server 2008 R2 during the logon process
• TechNet – Analyze Session Logon Duration
• XenAppBlog – Optimize Logon Times – Part 1: Citrix Director
• Citrix XenApp – Long logon times and potential fixes
• CTX133595 – Slow Initial Login When Using Folder Redirection
• Citrix Discussions – Please wait for Local Session Manager
• Citrix Blogs – Troubleshooting Slow Logons via Powershell
• Citrix Blogs – Logon Duration explained
• Slow Boot Slow Logon (SBSL), A Tool Called XPerf and Links You Need To Read
• Who broke my user GPOs?
• Citrix Blogs – Interactive Session of Logon Duration in Citrix Director – Explained
• Citrix Blogs – Citrix Logon Times – Rule of 30
• Citrix eDocs – Diagnose user logon issues
• The Complete Guide to Understanding the Citrix Logon Process for XenApp/XenDesktop (registration required)

The post XenApp/XenDesktop – “Please Wait For Local Session Manager” message when logging into RDS appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

Just recently I was tasked to identify all Citrix Receiver Versions connecting to a Citrix XenDesktop 7.x environment.

For starters, to get information on current sessions issue the following PowerShell cmdlets on your Citrix Broker Server:

Add-PSSnapin *Citrix*
Get-BrokerSession | Select MachineName,UserName,ClientPlatform,ClientVersion,*Protocol* | Out-GridView

To get hands on every single information of your current Broker Sessions simply run:

Get-BrokerSession | Out-GridView

Now, in terms of historical session and connection information you have to query the OData API (http://<ServerBrokerFQDN>/Citrix/Monitor/OData/v2/Data), as with the Get-BrokerSession cmdlet you only get information on current sessions. So in case you’re looking for historical reports and data, which you cannot find in the Director Web UI, you could simply create a custom report with Microsoft Excel by connecting to the Data Feed.

This leaves me with recommending the following Citrix Blog Article, that explains how to

• connect and read the available OData Data Feed from your Citrix Broker Server,
• read the content of the Connection table and import it into an Excel Sheet,
• limit the data’s timeframe we’re looking at,
• add a PivotChart, and
• filter the required data.

The result might look something like this:

You can then tinker with the different tables available through the Data Feed in order to achieve the resultant data set required for your purpose. As opposed to the aforementioned Citrix Blog you could select the following tables to even get information on Citrix Receiver Versions, Client Names, and corresponding User Names:

• Connection
• Session
• User

Just have a look at the underlying SQL DB and its Database Diagram in order to reveal the tables’ relationships:

Then you should be able to rebuild these relationships within Microsoft Excel and get the resultant set of data including corresponding user names:

Otherwise you could create a corresponding View directly within SQL Server Management Studio on the server hosting your XenDesktop SQL Monitoring database. I created one and called it v_ReceiverVersions, thus allowing me to access the data through Excel as well. The custom View includes the aforementioned tables

• Connection (MonitorData)
• Session (MonitorData)
• User (MonitorData)

SELECT MonitorData.Connection.ClientName, MonitorData.Connection.ClientVersion, MonitorData.Connection.BrokeringDate, MonitorData.[User].Upn
FROM MonitorData.Connection INNER JOIN
MonitorData.Session ON MonitorData.Connection.SessionKey = MonitorData.Session.SessionKey AND
MonitorData.Connection.Id = MonitorData.Session.CurrentConnectionId INNER JOIN
MonitorData.[User] ON MonitorData.Session.UserId = MonitorData.[User].Id

This setup allows me to filter the available data (i.e. set to the required period in time by utilizing the BrokeringDate) by either choosing ClientName, ClientVersion or UPN:

The data available in Citrix Director is dependent on your Citrix License, which in turn determines your usage data retention within Citrix Director. As per Citrix:

• All editions: Director – real-time monitoring and basic troubleshooting (up to 7 days of data)
• XD7 Platinum: EdgeSight performance management feature – includes #1 + historical monitoring (up to a full year of data through the monitoring SQL database)
• XD7 Platinum + NetScaler Enterprise: EdgeSight performance management and network analysis – includes #2 plus 60 mins. of network data
• XD7 Platinum + NetScaler Platinum: EdgeSight performance management and network analysis – includes #2 plus unlimited network data

Further reading:

• Citrix Discussions – Querying client Receiver versions?
• Citrix Blogs – Creating Director Custom reports for Monitoring XenDesktop
• Citrix Blogs – XenDesktop 7 Monitor Service – What Data is Available?
• Citrix Blogs – Citrix Director: Analyzing the Monitoring Data by Means of Custom Reports
• Citrix Blogs – XenDesktop 7: Director and EdgeSight explained!
• Citrix – XenApp and XenDesktop 7.12 Features Matrix

The post Citrix XenDesktop 7.x – Query Citrix Receiver Versions connecting to your environment – XLS Report appeared first on blog - Alexander Ollischer | Citrix | Microsoft.

Citrix XenDesktop 7.x – Citrix Session Printers are not visible via Control Panel, Devices And Printers

Affected System: Windows Server 2012 R2 as well as Windows Server 2016

Citrix Environment: XenDesktop 7.15 LTSR CU2

In my case the solution came down to missing services running on my XenDesktop servers due to hardening the servers prior to provisioning them. I ran a couple of hardening scripts, which disabled a lot of so-called unnecessary services which resulted in the aforementioned issue. The affected services are:

• Device Install Service (DeviceInstall)
• Device Management Enrollment Service (DmEnrollmentSvc)
• Device Setup Manager (DsmSvc)

They were disabled and I had to revert them to the default setting, i.e. 

• Device Install Service (DeviceInstall) | Manual (Trigger Start)
• Device Management Enrollment Service (DmEnrollmentSvc) | Manual 
• Device Setup Manager (DsmSvc) | Manual (Trigger Start)

After resetting the services via Group Policy everything worked as expected.

Further reading:

• CTX213540- Citrix Session Printers are not visible via Control Panel, Devices And Printers
• Citrix Discussions – Session Printers not showing in Control Panel XA7.16
• Citrix Virtual Apps and Windows Server 2016 – Optimisation Script
• Windows Server 2012 R2 Optimisation Script

The post Citrix XenDesktop 7.x – Citrix Session Printers are not visible via Control Panel, Devices And Printers appeared first on blog - Alexander Ollischer | Citrix | Microsoft.