Citrix Receiver for Mac "Cannot start the desktop ... OSStatus -1712"

Solution

In my case there were non-responsive processes on the mac client that were causing the problem. To resolve, I closed out of receiver and closed any active desktop connection. I then brought up the activity monitor (command+space to bring up the search, enter "activity monitor"). There were several Citrix processes, one non-responsive process with the name of the personal desktop that wouldn't load and a few helper processes. I force-quit all Citrix processes, then restarted the receiver client. Connected to desktop successfully at that point.

It may not have been necessary to force-quit all Citrix processes, but it doesn't seem to have had any consequences, they started back up when I reloaded receiver.

Problem / Full Story

Had a user this morning that couldn't connect to their windows desktop over XenDesktop (7.1). User is one of our few Mac (running Mavericks) users, and uses XenDesktop to get to windows applications he needs. When he tried to log in this morning, he got the following error when he tried to connect to his windows 7 machine.

Cannot start the desktop "Personal Desktop"

 Contact your help desk with this information: The application "Personal Desktop" could not be launched because a miscellaneous error occurred. (OSStatus -1712).

Odd thing was, he was able to connect to his Windows 8 desktop just fine. So the connection to the server was working, as was the connection to at least one VM. The Win7 machine was showing up as registered and ready in Citrix Studio on the XenDesktop Controller. Win7 appeared to be responsive when interacting with it through XenCenter. I tried restarting the Windows 7 machine but the error persisted. A brief look through the longs on the Win7 machine and the XDC didn't show any errors, so it seemed like the problem wasn't server-side. Had the user logout/close receiver on his machine and reopen it, but the error continued to occur.

Up in the user's office I brought up the activity monitor and saw the unresponsive process -- see "Solution" above. After killing and restarting all citrix processes the user was back up and running. Rebooting the Mac probably would've had a similar effect.

 

XenDesktop Studio : Add resources - The supplied connection address is invalid

Solution

Turns out, in my case, XenDesktop did not update the connection information correctly when I removed a server from the pool. So the "Connection address is invalid" is not having a problem looking up the servers, but rather the lookup is returning too many addresses. 

The way I found to do this is to uncheck the server in the high availability configuration (it's the only other place the removed server seems to show up). Open Studio and go to configuration > hosting. Click the connection that is having the problem, then right click and select edit connection. Click the edit HA servers button. Uncheck the box next to the server address that matches the one removed from the pool, then click ok.

You should now be able to correctly configure the connection trough the "add connections and resources" menu.

Full Details

I originally did not set up my XenDesktop 7 environment for machine creation services (MCS). I had tried it in 5.6 and found it didn't perform as well as manually doing full clone machines. But I wanted to set up a small environment to give it another shot, so I needed to add the storage and networking that it was going to use (Studio > Configuration > [hosting right-click]add connections and resources). However when I tried to reconfigure my connection I go the following error (the actual error is a bit longer, but this is the important part). 

Update-HypHypervisorConnection : The supplied connection address is invalid. Ch
eck that it exists and is part of the same pool as the connection.
At line:1 char:31
+ Update-HypHypervisorConnection <<<<  -LiteralPath 'xdhyp:\connections\myconnection'
    + CategoryInfo          : InvalidOperation: (:) [Update-HypHypervisorConne
   ction], InvalidOperationException
    + FullyQualifiedErrorId : Citrix.XDPowerShell.HostStatus.ConnectionAddress
   Invalid,Citrix.HostingUnitService.Sdk.Commands.UpdateHypHypervisorConnecti
  onCommand

 For some reason XenDesktop is having trouble managing the pool; thinks it has a bad address. First thing I did was test the connection (Studio > configuration > hosting > [right click connection] test connection). This ran and came back with no errors.

So then I ran this command (which I found via citrix docs as a "related-to" the command that is failing).

PS C:\temp> Get-HypXenServerAddress -LiteralPath 'xdhyp:\connections\myconnection'
http://192.168.0.10
http://192.168.0.11
http://192.168.0.12

This is 100% correct, so the connection object has the correct address (and is returning them correctly). So why the lookup failure. Well... Here I failed a bit in documenting. I ran a command somewhere that showed an error that reported that it was trying to connect to four different server addresses, rather than the correct three; I forgot to write down exactly what command it was - sorry. You should be able to tell by going to "configure HA servers" in the edit connection menu and see what servers are showing up there.

The fourth address that was showing up in the lookup came from a server that I had removed from the pool. Apparently that information did not get updated automatically - or at least not consistently, throughout xendesktop.

Adventures in XenDesktop 7 Powershell/SDK : Getting a full list of users/machines from an access policy

The Command You're Looking For

Get-BrokerAccessPolicyRule -name "<groupname>" | % {$_.<property>}

Example: Get-BrokerAccessPolicyRule name "mygroup_direct" | % {$_.includedusers}

This returns the full list of all included users/groups in the "mygroup_direct" rule.

Explanation

I've been working with get/set-brokeraccesspolicyrule a lot lately. It's super useful for managing what users have access to what desktops from what machines, in a much more exact way than is possible through the studio application.

It's allowed me to do some really nice things from a user experience standpoint, which I may elaborate on a little later.

One big problem I've been running into was getting information back out of these. For instance, I've got some ACLs (APRs?) set based on user AD Group membership. These work fine, but if I add a bunch, then want to double check which groups I've added, it's not quite so straight forward.

Running a command like : Get-BrokerAccessPolicyRule -name "group_direct"

returns this:

ExtensionData                    : System.Runtime.Serialization.ExtensionDataOb
                                   ject
AllowRestart                     : True
AllowedConnections               : NotViaAG
AllowedProtocols                 : {HDX, RDP}
AllowedUsers                     : Filtered
Description                      :
DesktopGroupName                 : <redacted>
DesktopGroupUid                  : 2
Enabled                          : True
ExcludedClientIPFilterEnabled    : False
ExcludedClientIPs                : {}
ExcludedClientNameFilterEnabled  : True
ExcludedClientNames              : {<redacted>}
ExcludedSmartAccessFilterEnabled : False
ExcludedSmartAccessTags          : {}
ExcludedUserFilterEnabled        : False
ExcludedUsers                    : {}
IncludedClientIPFilterEnabled    : False
IncludedClientIPs                : {}
IncludedClientNameFilterEnabled  : True
IncludedClientNames              : {<redacted>client1,client2,client3,client4.
                                   ..}
IncludedSmartAccessFilterEnabled : True
IncludedSmartAccessTags          : {}
IncludedUserFilterEnabled        : True
IncludedUsers                    : {<redacted>group1,group2,group3,group4,...}
MetadataMap                      : {}
Name                             : <redacted>_Direct

Uid                              : 1002

As you can see several of the sections get cut off with a "...". This is super annoying if you're trying to verify that all the groups you think you added are actually there. My typical approach here is to run a command to only display the field I'm looking for so it doesn't get cut off, something like this:  Get-BrokerAccessPolicyRule -name "group_direct" | select includedusers

This doesn't work here though, it returns the same cut off list. After a lot of playing around I finally found what works (See The Command You're Looking For above). It's a simple command, but it's a strange way of having to get information out of the system. Using that command you get output like this:

ExtensionData : System.Runtime.Serialization.ExtensionDataObject
FullName      : <redacted>
Name          : domain\group1
SID           : S-1-1-11-11111111-111111111-111111111-11111***
UPN           :

ExtensionData : System.Runtime.Serialization.ExtensionDataObject
FullName      : <redacted>
Name          : domain\group2
SID           : S-1-1-11-11111111-111111111-111111111-11111***
UPN           :

ExtensionData : System.Runtime.Serialization.ExtensionDataObject
FullName      : <redacted>
Name          : domain\group3
SID           : S-1-1-11-11111111-111111111-111111111-11111***
UPN           :

This information is far more useful, and can be selected,filtered, and sorted from here.

ICA Connection request denied because AutoLogon was not possible and EnforceAutoLogon is active

This is what I spent my morning doing.

So in the ongoing quest to get a XenDesktop 7 environment going. I was having a problem where, when logging in as a non-admin user, the desktop would appear for a split-second -- you could just make out the windows login screen -- before kicking the user back to the XenDesktop login (Wyse Xenith 2 login, in this case).

The only Error in the event log, the one that makes this posts title, was as follows

• Error | ICA Service | EventID: 34 | ICA Connection Request denied because AutoLogon was not possible and EnforceAutoLogon is active.

Googleing this error code returned nothing, 0 results. Googleing the symptoms returns some things, but nothing that solved my problem.

In my case it was simple and stupid. I had put these new machines in an old OU in AD. This OU had, unbeknownst to me, a GPO which denied local login to non-admins (OU was for remote-desktop machines in the past). Removing the GPO fixed everything, go figure. 

If this isn't the case in your situation, the error so far as I can tell, is caused when the pass-through authentication fails. This can be caused by any number of things (like bad GPOs), and there's a lot of good support forum posts about the non-stupid causes of this problem, so I won't go into much detail here. But here's some things I researched that might get you pointed in the right direction.

XenDesktop Passthrough Authentication failure:

http://forums.citrix.com/thread.jspa?threadID=284282

Exact symptoms I described, but with a different cause:

http://forums.citrix.com/thread.jspa?threadID=288813&start=0&tstart=0

Wyse Xenith 2 - Unable to set up connection (err=-5914)

This error, which I mentioned in the post just minutes ago, turned out to be a pretty simple fix. As I also mentioned in the last post, I'm building up a XenDesktop 7 environment to replace our current XenDesktop 5.6 Environment, and I'm trying to document all of the things that I figure out somewhere where other people might benefit from them.

Anyway, like I said, this fix was pretty simple. The error I was getting (This is in the Event Log of the Wyse Xenith 2 client) was :

• xx:xx:xx Error ERR_TCP_CONNECT_ERROR
• xx:xx:xx SSL: Unable to setup connection (err=-5914)

The error displayed user side was simply "Citrix Sign on Failed"

Turns out this is because of a change to the way XenDesktop handles connections, you have to specifically point the Xenith units to the "legacy" URL.

Previously my Xen.ini file looked like this, and this worked fine in XenDesktop 5.6:

pnliteserver=MYDDC.domain  

However, in XenDesktop 7 it needs to be this:

pnliteserver=http://MYDDC.domain/Citrix/Store/PNAgent/config.xml

This URL is defined in the Citrix StoreFront under StoreFront > Stores > Configure Legacy Support. There's a checkbox (enable legacy support) there as well that you'll want to make sure is checked.

After I made that change to the Xen.ini file I was able to connect to the Desktop.

XenDesktop 7 - No Desktops Available

Working on building a XenDesktop 7 deployment to replace our current XenDesktop 5.6 instance. The Controller, XMLBroker,WebStore, and pretty much every component is installed on the same (albeit beefy) server - This deployment isn't big enough to warrant separate servers for everything, just a bunch of Wyse Xenith2 thin clients.

Anyway, I got to configuring the storefront which thankfully seems a lot more straight forward than the web interface in 5.6, except one problem - whenever I log in no I get a message saying "no applications or desktops are currently available to you". I can see in Studio that there should be desktops available, but I don't get them as an option anywhere I log in. 

A few hours of googling around and going through event viewer leads me to the conclusion that there's a problem with the XML Broker Service. I have the following errors in Event Viewer:

• Warning:Citrix Broker Service: EventID:2010: General "The Citrix Broker Service encountered a problem while an XML service attempted to listen for http(s) requests. The Windows HTTP configuration might be incomplete or incorrect. ": Details Access is Denied System.Net.HttpListenerException
• Error:Citrix Store Service:EventID:4003: "All the Citrix XML Services configured for the farm Controller failed to respond to this XML Service transaction"
• Error:Citrix Store Service:EventID:0 : "An error occurred while attempting to connect to the server <this.stupid.server> on port <xxxx>. Verify that the Citrix XML Service is running and is using the correct port. If the XML Service is configured to share ports with Microsoft Internet Information Services (IIS), verify that IIS is running. This message was reported from the XML Service at address . The specified Citrix XML Service could not be contacted and has been temporarily removed from the list of active services."

The long and short of these is : "The XML service didn't start correctly and so the Store Front is failing to connect to it so storefront can't determine what desktops are available". The Details of the first error are useful, because - my knowledge of port binding is limited, but generally sufficient - it suggested that whatever port the XML service is trying to bind to is already in use.

This information leads me to this post on the Citrix forums: 

http://forums.citrix.com/thread.jspa?threadID=334290&tstart=60&start=15

Which suggests changing the http port for the Broker Service. This is done via the command:

This is in the citrix install directory, typically c:\program files\citrix

..\citrix\broker\service\brokerservice.exe -wiport xxxx

I did this, but unfortunately the errors continued. Then I ran the following command and it showed a number of other ports that the XML service is using:

..\service\brokerservice.exe /show

SDK Port: 80
VDA Port: 80
WI Port: 8888
WI SSL Port: 443

Changing all of these ports got the broker service up and running.

The Broker Service automatically restarts itself when you run these commands

 ..\brokerservice.exe -wisslport xxxa

..\brokerservice.exe -sdkport xxxb

..\brokerservice.exe -vdaport xxxc 

At first I changed all four of these, and that caused the desktops to start showing up (After I changed the port of the Delivery controller in StoreFront (StoreFront>Stores>Manage Delivery Controllers).

Unfortunately it also caused all the desktops to unregister from the controller and Studio to break. This is because the vdaport appears to control what port the desktops need to register with and the sdkport controls port the Studio needs to connect on (as well as probably any other management software). Changing those two things back to port 80 things started working more the way I'd expected.

I have yet to actually get a thin to connect -- getting "SSL: unable to setup connection, (err=-5914)" but more on that once I figure it out.