VMware Horizon Community
epa80
Hot Shot
Hot Shot
Jump to solution

Published App Fails on Initial Launch

We're seeing a weird issue where, after an app is published in our Horizon 7.13 RDSH farm, on initial launch of the app, we see an error of the app being unavailable as seen here:

loading_failed.png

Oddly enough, if you click the "Try Again" button in the upper right, after like 3 or 4 attempts, the app will load fine. Coincidentally (or not), if a user connects to that farm server after, the issue doesn't happen. It just seems to be on 1st launch of a republished farm, and the app doesn't matter. It follows across several different apps we published.

In Windows event viewer, right at the time of launch, I DO see errors on RD licensing server issues. We provide RDS licensing to our servers for a GPO.

term_services_error.png

As you can see though, when I login on the problem farm host with my domain creds, I see the licensing is working fine:

rd_licensing.png

The servers hosting the apps are Server 2012 fully patched up, running a 7.13.1 Horizon agent. We did see this on 7.10.2 as well, and the hope was 7.13.1 would resolve it, but, no such luck.

We have opened an SR with support, but, not much luck yet. Looking to see if anyone in the community has happened upon this. Thanks in advance. 

Reply
0 Kudos
1 Solution

Accepted Solutions
BenTrojahn
Enthusiast
Enthusiast
Jump to solution

OK now on that same machine, logon with a domain account.  I dont recall if i did that console or RDP...  it was a few weeks ago since i went through it.  It should then checkout an RDS license and  populate with x509 cert values... if it doesn't try again or troubleshoot RDS licensing.

Once that is populated with a license, i bet your next HZ blast session will work.

edit:  if memory serves, pretty sure you can dump those cert/license values.  Might have to  in-guest reboot or restart RDS services to replicate.

EDIT2:  saw this was  reposted as solution recently.  I did fix this issue permanently.  Its been a couple years so the details are at least a little fuzzy but the issue was because the RDS license mode was not set in the golden image but came down via GPO.  Setting RDS license mode in local policy/registry and clearing the time bomb was the real fix.  

View solution in original post

Tags (1)
Reply
0 Kudos
19 Replies
SurajRoy
Enthusiast
Enthusiast
Jump to solution

This do not seems to be View agent issue.

However, you can refer to https://intelligentsystemsmonitoring.com/knowledgebase/windows-operating-system/event-id-remote-desk...

Also set the Power Policy of the VDI machine / Master image to High Performance and set display never to sleep

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

Thanks for the reply/link.

I checked and we are indeed set to High Performance already:

epa80_0-1633354271818.png

I did look at the power settings as well, and it does say to turn off the display at 15 minutes. We can change that to never, but, I think that's simply the display, not really sleeping the CPU. Like I said though, we'll give it a try.

epa80_1-1633354337786.png

One thing to note: I compared these settings with our XenApp deployment of the same app on Server 2012 (same OU and basically same image), and the settings in both cases are identical to my RDSH gold. Those XenApp servers don't see this behavior.

Reply
0 Kudos
SurajRoy
Enthusiast
Enthusiast
Jump to solution

Thanks for the update.

Did you follow any documentation as how to prepare RDSH server for hosted App.

https://www.carlstalhood.com/vmware-horizon-7-master-rds-host/ 

Also you can clone any one of the RDSH server / Master image and create a Manual Desktop pool and check if the issue is happen while taking a desktop session as well or it is limited to hosted app only.

Check if the issue is specific to PCoIP or Blast

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

Support came back with an initial log review, and thinks something may be going on with the load balancing. I asked for clarification, as I wasn't sure they meant the load balancing of the farm itself, or the actual load balancer in front of Horizon (we use F5). I believe it's the farm, but, waiting to verify.

I see this in the logs which seems to link to that:

"1 server(s) were rejected because A server with greater capacity was available."

I'm not sure what the farm would be so sensitive since there's nothing using this farm right now. We have 4 servers behind this published app, and only 3 users from my own team for testing are entitled.

Reply
0 Kudos
SurajRoy
Enthusiast
Enthusiast
Jump to solution

Connection server load balance the session using some load balancing mechanism.

To check you can disable all RDSH host on the Farm EXCEPT 1 and then check. This will make sure no load balancing take place and hence will force the session with that 1 available RDS host. If the issue do not occur, then yes, it is related to load balancing.

Also you can enable 1 RDS host at a time and check which one is causing issue.

For more info please refer to https://docs.vmware.com/en/VMware-Horizon-7/7.13/horizon-published-desktops-applications/GUID-6EDE18... 

 

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

I should mention I have seen this behavior in OTHER farms for other published apps as well. I feel like there must be something at the base image level I'm doing wrong.

Reply
0 Kudos
BenTrojahn
Enthusiast
Enthusiast
Jump to solution

I have this problem too for quite a while and have not yet been able to find a good solution.  The issue is that the fresh instant clone RDSH  is not licensed YET and is not until a domain user authenticates.   You can "fix" this in testing by logging into the RDSH console as a domain user.  There wont be any further license issues after that.  

Login with local admin and you wont see a x509 cert which should be the RDS license .  Login with a domain user and you can see the x509 license entries created:    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM

BenTrojahn_0-1633443827068.png

My suspicion is that this is a product of starting with a non-domain joined image.

 

As I am writing this, i wonder if a scheduled task w\runas creds at server boot would be sufficient. 

thanks i'm going to try that!

 

EDIT2: your pic of the error does not match the described symptom.   I think the screen shot you have might be a DNS and/or ADAM repl timing error.  At least it was in my environment. 

this is the error most likely a RDSH licensing that indicates a not yet licensed after first boot.  Either way you should be able to verify the license issue in the registry

BenTrojahn_1-1633444709714.png

 

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

Much appreciated reply. Yeah, my gold image IS already domain joined, so, that shouldn't be the issue. But your comment about DNS/ADAM reply is an interesting one. I'm going to repub the farm and let the hosts sit for about an hour then try launching the app, just as a test.

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

No such luck. I went ahead and repubbed the farm around 3:04PM our time, let everyone come back as available, and then let the hosts sit for a good 30 minutes. This should be OVERLY guaranteeing that ADAM replication/DNS is good IMO.

Anyway, waited and then launched the app, got the typical screenshot I originally posted. I HAMMERED try again in rapid succession probably 15 times, same error each time. I closed the Horizon client, waited a second or 2, launched the app again, boom right in.

I have 4 servers in this farm. Based on the logs, my initial launch that failed over again was trying to use server #4. Strangely enough, when it worked, it ALSO was server #4. This should also rule out load balancing as an issue I would think?

Looking in the logs at the time I had failures, I again see RD licensing hits:

epa80_0-1633463703136.pngepa80_1-1633463718920.png

If it's a licensing issue, I'm not getting it. These get the same RD Licensing GPO we apply to Citrix XenApp servers get in their own OU. They work without issue.

No idea if this is a clue: when I consoled to all 4 RDS hosts, the 1st 3 (where I didn't go launching the app) defaulted to login locally even though they are domain joined. The 4th, where I failed then launched ok, was defaulting to the domain as default login. This may mean nothing at all, just mentioning it.

 

Reply
0 Kudos
BenTrojahn
Enthusiast
Enthusiast
Jump to solution

simply disabling the all but 1  or using a test farm of 1 server/pool should rule that out.

 

on a fresh machine, what does this key look like?  Use local admin account to view HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM

EDIT: fixed key path.

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

Removed server #1 from the farm and let it re-provision. Logged in as local admin and got this when checking the key you mentioned, pretty bare:

epa80_0-1633483573466.png

 

Reply
0 Kudos
BenTrojahn
Enthusiast
Enthusiast
Jump to solution

multitask fail!!   i meant RCM... 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

Doing some more testing, I republished the hosts with a minor change, and tried again. Same behavior. Noticed in Horizon help desk this. I'm sure it was also in the Horizon logs I provided to support. Seen it sparingly in the past, but, not sure it's full explanation.

epa80_0-1633486332288.png

Coincidentally, a few seconds later I attempted the app again, and as usual it launched fine. To the very same server listed in the error as not having Blast available.

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

Ah gotcha. Checked there:

epa80_0-1633486484486.png

 

Reply
0 Kudos
BenTrojahn
Enthusiast
Enthusiast
Jump to solution

OK now on that same machine, logon with a domain account.  I dont recall if i did that console or RDP...  it was a few weeks ago since i went through it.  It should then checkout an RDS license and  populate with x509 cert values... if it doesn't try again or troubleshoot RDS licensing.

Once that is populated with a license, i bet your next HZ blast session will work.

edit:  if memory serves, pretty sure you can dump those cert/license values.  Might have to  in-guest reboot or restart RDS services to replicate.

EDIT2:  saw this was  reposted as solution recently.  I did fix this issue permanently.  Its been a couple years so the details are at least a little fuzzy but the issue was because the RDS license mode was not set in the golden image but came down via GPO.  Setting RDS license mode in local policy/registry and clearing the time bomb was the real fix.  

Tags (1)
Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

So I went a bit further. I removed the 4 hosts from the farm 2 at a time and let them re-create. I then logged into to all 4 via the console with my domain account. Checking the regkey, I found the same on all 4. No x509 values in the RCM key:

epa80_0-1633487775970.png

 

However, all of them in the license diagnoser tool are all green:

epa80_1-1633487869861.png

I went and tried to launch my app, it tried to send me to Server #4, and gave me the failure error. I clicked try again a few times, nothing. Closed Horizon. Launched the app again, it sent me to Server #4 again but this time worked. I logged into the console on server #4 as myself and checked the key:

epa80_2-1633488234737.png

 

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

I went and did the same steps again: removed the hosts 1 at a time from the farm, let them re-create. When all were available, I rebooted each one at a time. Thought maybe give them a kick in the butt. nada. After reboot I launched the app, went to server 2 with an error, closed Horizon, launched Horizon and picked the app, went to server 2 and the app launched. Keys present. Throwing in the towel for this evening, I'm starting to see double.

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

Went ahead this morning and booted up my gold image to try something. I usually only used the local admin account to prep it (it is domain joined though), but I thought why not login with my domain account, get that key populated, then remove my profile. Sounded easy enough.

I logged in 3 times via the console with my domain account, the keys never came. Ran a gpupdate, still no keys. So I said ok I'll RDP to it. When I did that, I was met with this:

epa80_0-1633524025635.png

Note: I went back to this, and after I hit ok and RDP closed. I launched it again, and it logged in fine. So it goes back with the above, multiple tries works.

Now that the gold image has those keys, I went ahead and logged in locally as admin and removed my domain account profile to keep it clean. I am republishing now on this snap which should have the RCM keys. Let's see how this goes.

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

Holy cow it seems to work. Now hopefully that doesn't cause other issues, but, for now it seems good. Republishing the hosts on that new snap that includes the keys brought down after I logged in via my domain account has launched fine on several tests.

Now to figure out how to consistently get the published app to launch in the foreground, but, that's for a different day. 🙂

Reply
0 Kudos