Jump to content
Welcome to our new Citrix community!
  • 0

Platform Layer and GPO Practices and Portability


Ricardo Espada1709161179

Question

Hello Community,

 

We have an environment with Two Sites and Two Domains on each site, CVAD 7.x and PVS environments.

 

We have one ELM Appliance where we develop all the layers and then Publish the layered Images to the different Sites/Domains.

 

Our Initial Scenario:

  • Each site and domain has their unique OU structure and GPOs.
  • One of those GPOs is the RDS Licensing Server configuration and DDC. Each Site has their own DDCs and Licensing servers etc.
  • We had one platform layer per site and domain so at least four Platform layers. 
  • The platform layer was joined in the Same OU as the resulting VDA's. Thus caching all GPO's. and their configuration.
  • It worked but it meant we had to maintain several platform layers.

 

New Scenario

  • We created One Platform Layer per domain this reduces the amount of layers to be maintained to two, one per domain
  • This platform Layer is joined to an OU with no GPO and Inheritance disabled to make it portable across sites.
  • This means no GPOs are being cached, Consistent Platform Layer
  • Final Layered Image is publish to PVS, Targets boots up and picks all GPOs from the site/domain
  • Worked great until...

 

The Big Bang:

RDS Time bomb hit us, all site went down at the same time.

During RCA we learned that once the servers gets the licensing server GPO it needs to be rebooted at least once, else it does not talk to the RDS licensing server to generate to X509 Certs under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\ with out this basically the server wont acquire RDS licenses. So because the target does not know of any policies until it boots basically we had a literal time bomb.

 

So right now we deleted the time bomb key at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod and is buying us 120 days.

 

We are thinking of implementing a process of booting the published layered image at least once in R/W from PVS by creating a maintenance version to a non prod target which is on the same OU as Prod VDA's so that it get the policies specific to the site/domain and shut it down, promote the version and set it on production before applying it to the production targets.

 

Anyone has experienced this or can provide feedback or has other ideas and recommendations.

 

I don't think Citrix spells out that you have to cache GPOs in any document for App Layering just the need of joining the domain and logon once with a domain account.

 

Although I do see on https://www.carlstalhood.com/app-layering-os-layer/#platformlayer @CarlStalhood seems to point this out.

 

Hopefully  @Rob Zylowski1709158051 can chime in..

 

 

 

 

Link to comment

4 answers to this question

Recommended Posts

  • 0

Hi Ricardo,

 

I have not actually heard of this problem before.  Normally I prefer for GPOs to be applied at boot and not during platform layer creation because the latter can cause conflicts when changes are made to GPOs.  I always create a text file in the kmsdir folder called rungpupdate.txt which tells the ksmsetup.cmd file to run gpupdate /force during boot.  I dont know if that would help your issue.  License servers are almost always applied via GPO so it would be weird if a reboot was required after assigning license servers so I wonder if its more of a timing issue and that your users are logging on before the gpo has been applied.  I would try the rungpupdate.txt and if that doesnt work see if rebooting the remote desktop services service after a gpupdate is run works.  If it does you could edit the rungpupdate script to restart that service after updating the policies.

Link to comment
  • 0

Hi Rob,

 

Thanks for chiming in... interesting response, the fact that this is how you do it makes me wonder what is causing our issue.

 

We do force the GPO's to apply at startup and we can see them being applied and confirm that the RDS GPOs are applied by looking at

HKEY_LOCAL_MACHINE\ SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\LicenseServers

HKEY_LOCAL_MACHINE\ SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\LicensingMode 

 

Would using rungpupdate.txt be lower level than that? Other thing I can think is using delay start for the RDS services... but based on your feedback that should not be required.

 

I believe it we could restart the RDS services it would work, but what we have come to find is that if we restart the services it wont allow any connection to the VDA, this is what left us with the restart requirement. 

 

We have been able to reproduce the behavior consistently, so maybe I should get back to my ticket with Citrix to troubleshoot this further?

Link to comment
  • 0

No the rungpupdate.txt will just trigger a gpupdate /force when the boot script runs.  I am not sure how you are forcing it but maybe its the same way you can create that file using the optimize.hta.  I would try restarting the service.  If that fixes your issue then its easy enough to script into the boot process.  There are several ways you can control when users are allowed to connect to the VDA.  You can use a SettlementPeriiodbBeforUse (see here) or i sometime set the Citrix Desktop Service to disabled in my image then in the gpupdate script I change it to manual and start it.  That way it wont register until you know the updates have been applied.  You can also restart the Remote Desktop Service before starting it. 

 

You can also go back to separate platform layers which is likely what support will say.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...