Citrix PVS and Managed Service Accounts gMSA

I’m a big fan of Managed Service Accounts because they are much more secure and aren’t easily exploited by human beings.  Basically, Active Directory controls the account with it being responsible for changing passwords.  While use of gMSA (group managed service accounts) is sometimes hit or miss, I didn’t find much on recent use with Citrix other than a vague “we support this” statement.

Carl Webster had a much older attempt with PVS (not sure whether he tried again or not) and I wanted to ensure that this worked on PVS 7.7 (just released).

You’ll need a couple of things

I would leverage a tool for creating and managing gMSA that I got here.
(note: for a quick guide on setting this up, I would look through Derek Seaman’s blog).

Add you PVS server to the list otherwise it won’t work. (I only have 1 PVS server right now, I’m in rebuilding mode…)

For SOAP, you’ll need to make this account a member of the local admins on the PVS server (when you add the account, make sure you select “service accounts” for objects.

For SQL, I am using 2014 with availability groups.  Check out Derek’s blog for a great walkthrough on this.

Your database should have been created already (use the dbscript.exe to manually create the database in PVS)

Grant the permissions needed to your gMSA on the SQL database (I create the account on both database servers just in case (when I test the failover))

Testing failover should work and you will also notice the services are running

XenApp, PVS, Hyper-V and NIC issues – 1494 not listening

While spinning up about 100 xenapp servers on hyper-v, I utilized a PVS isolated stream network.  This network, on Hyper-V, needs to use the legacy NIC.  It is a different subnet than the backoffice network, which utilizes the 10GE NIC.

For some reason, several of my XenApp servers seem just fine except they won’t connect (RDP works fine).  I let Citrix support take a shot at this but here is what I found.

netstat -a shows the 1494 port listening on the wrong NIC.  This often occurs if the NIC needs to be recreated (I have no idea why some VMs have a #2 or #3 NIC, I plan to take care of that later).

I tried to use many CTX articles to figure this out, but nothing I tried seemed to work (this included editing the httpd.conf, setting DNS lookups, NIC binding, ICA listener configs).  Nothing would seem to change the IP of the 1494 listener.

http://support.citrix.com/article/CTX126871
http://support.citrix.com/article/CTX128254
http://support.citrix.com/article/CTX131554
http://support.citrix.com/article/CTX105793
http://support.citrix.com/article/CTX131831
http://support.citrix.com/article/CTX128115

Getting a bit frustrated, I stepped back and figured something must be locking that port.

netstat -a -b

Shows me TermService is using 1494.  I restart TermService and all troubles just disappeared.

Thinking this through, what happens is if the VM needs to create the 10GE NIC (for whatever reason) it doesn’t wait to start TermService, which means TermService locks 1494 and doesn’t let IMA/XTE use it, no matter what you say in the ICA configuration settings.  In fact, ICA Configuration isn’t correct when it reports what Network Interface it listens on, it seems it doesn’t know (even all NICs isn’t correct).

In any case, I paused and stepped back.  Looking further into the issue, XenApp could not get the right IP for some of the VMs and this led me to look at DNS.  The customer had a master domain (where the infrastructure servers resided) and a child domain, where the XenApp servers resided.  Due to stale records on the DNS of the primary domain (3rd party DNS/DHCP provider) I had to force DNS lookups on the infrastructure servers to use the child domain first (eliminating a bad DNS entry in the root domain).  Magically everything worked.

I actually noticed this post in draft mode today and just added the part at the end realizing the issue had been resolved.  If the DNS/domain setup is strange, ensure lookups are working before going too much further.

Citrix PVS – Hiding the Boot Menu

I hadn’t really thought much about it but on a deployment realized there must be a better way!  For those of you who work with PVS and update/test the versioning feature in PVS 6.+, you know that you must be on the console and press 1 + Enter at some boot menu to get maintenance target devices to boot from the maintenance image.  I have no idea why you would assign a maintenance image to a maintenance target device and not want it to boot from that but I’m sure there is a reason.  In any case, it always seemed odd you need to console in to do that.

I decided to look for a better way and this may be old news to some of you.

Brian Cahill in the Citrix Forums informs of a way to set a registry key to skip the menu.  Restart the stream service once you make the change and you should be good to go!

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

You can set the following registry key on all the PVS servers.
HKLM\Software\Citrix\ProvisioningServices\SkipBootMenu DWORD

Value Behavior
0 or not defined Normal behavior <default>
1 Don’t send a boot menu to device. Automatically pick the first item that would been on menu and act as if it was the only version assigned.