Desktop is Currently Not Available - User Has No Session

[epa80]

We have 1 user who is seeing an issue when he attempts to go to a specific pool that used to work fine for him. Now though, when he clicks on the pool after authenticating with his Horizon client, he gets the message "This desktop is currently not available. Please try connecting to this desktop again later, or contact your system administrator.". If he switches to other endpoints (even even HTML Access), he gets the same message. If I use my account, from these same endpoints, I get in fine. I did verify that this user does NOT have any current sessions on the pool. Is it possible something in the ADAM DB is saying this user is signed on/hung up, and is not clearing?

Horizon 7.3.2. Using Cloud Pod. 4.7 Client, 4.8 Client, Wyse ThinOS, and Chrome HTML Access clients have been attempted.

[BC559]

• Sounds like this is not applicable since you logged on from the same endpoint but I have seen this issue when:
  • The customers are using the Recent Connections as opposed to actually launch Server URL.
  • When there were actually no available Desktops in the Pool.
• I would also suggest launching the Admin Console on all of your Connection Brokers and validate they numbers all look the same on the dashboard and status looks same across the board. This will rule out a sync issue with the ADAM Databases between the Connection Brokers.

[epa80]

Yeah it's not the recent connections option for us. He's attempted from endpoints like a Wyse thin client, where it's a fresh started up connection. Not like a Windows or Mac client where it's even offering the recent connections.

I did check the Brokers, we have 7, and one at a time, all are in sync.

We also have plenty of available VMs. We have connections into this pool all throughout the day, with 10% of of the pool always powered up and available. Still, the only user with this issue is this ONE user consistently. Never anyone else.

Support asked us to remove him from the global entitlement and entitle him manually to the pool. I did the manual entitlement but, I didn't remove the GE access as it's a bit convoluted. Still working that out. That being said, even with a local entitlement, he has the issue.

I've attached a screenshot of what he gets when attempting to login via the Wyse thin client. I'd love to find out if that number (I assumed a GUID) is hung up somewhere. I've asked him to login again today, and see if the same VM is offered. This screenshot was from yesterday, June 14th.

Thanks for your help.

[epa80]

Just had the user connect again, and he did indeed receive the same error with the same GUID (or what I assume is the GUID). These tests were performed over 24 hours apart.

[sjesse]

Try and get him logon, have it fail, and get the logs from client. In the %programdata%\vmware\vdm\logs folder I think there is a debug log. Search for his name and there should be an error that might help narrow it down. I'm pretty sure that log should show him starting to logon but something interupts it. I'd look at using AD groups for entitlements too, I'm using ad groups for global and local entitlements. That way if I need to swap someone out its pretty straight forward.

[sjesse]

Also is he connecting from an unique place, one that may have a firewall rule in the way?

[techguy129]

Is there by chance a Problem Machine from that pool that has his session stuck?

[techguy129]

Try running this in the View PowerCLI to see if you can locate the problem VM. If you find it, I'd delete it.

Get-DesktopVM | ?{$_.machine_id -eq '17120395-4754-49a5-98eb-b56109326f3a'}

[epa80]

He has actually tried from outside our secure network, as well as inside it, both with the same results. I have actually logged in from the literal same thin client on his desk to this pool without issue. That kind of knocked the endpoint device out of the equation for me. It's just him, and it had been fine for about 2 years. We THINK this started about a month ago during a network failure we had. He was connected that day, we had a major issue with a network firewall, and he swears it's ever since then. That's why I'm not so sure about messing with the entitlements since nothing changed, but, I'll try anything when I get back together with him.

[epa80]

No problem desktops at all in that pool unfortunately. We also scanned through the pool to see if any were in an odd state that wouldn't show as a problem desktop, and nothing there either. I did run the command you provided, but, no results came back. That really throws me through a loop. I swore that would at least give me a VM back, even if not a PD, and I'd blow it away and have him test again. No such luck though, no return.

I did correct the line though. You had 4754 as part of the GUID in your command, but it was actually 4745. Still, nothing. The search continues.

[epa80]

Minor update:

We tried creating a brand new Global Entitlement, assigning it to the same desktop pool, as well as the same Active Directory user groups that the previous GE had. I guess the long shot hope was that somehow/someway, the GE was corrupted (even though this only affected 1 user out of hundreds). Alas, it did nothing, the same results.

I've provided broker and client logs to support, waiting on their analysis. One step we may try this week, is flip the Horizon environment to out OTHER data center. Our current prod is running in our DC2 environment. The GE is stretched across both DCs, but, we're usually only live on one side at a given time. I feel very confidently that when we enable the DC1 pool, and disable the DC2 pool, this user is going to connect fine once again.

We shall see.