12/31/2022 0 Comments Citrix xenapp 6.5 health check scriptLogon to the XenApp server AppCenter console and select Policies. To create a HMR policy, complete the following procedure: However, User configuration settings within IMA-based policies are applied immediately. IMA policies are subject to the same AD policy refresh cycle for computer configurations. The Policy Processing and Precedence is shown in the following figure:īy default the policy refresh interval is 90 minutes for AD GPOs.įorce a policy update with the gpupdate /force command.īy default both users and computer configuration settings are updated. It is important to understand the following policy precedence and implementation because Citrix policies can take precedence with Windows Group Policies. In XenApp version 6.0 and later, the HMR settings are set through policies. HMR has been an option for Enterprise and Platinum customers since XenApp version 4.5. That work must be done by manually deleting those values from the master image before sealing it, or else they'll have to be manually deleted from each and every clone made from that image.This article describes how to create a Health Monitoring and Recovery (HMR) policy in XenApp 6.5 AppCenter.īackground It is necessary to create a HMR policy in XenApp 6.5 AppCenter to perform recovery processes and proactively monitor XenApp environments. However, it is true that Microsoft's support policy still requires the proper use of SysPrep when preparing images it just won't have any impact on the SusClientID. Generally speaking, SysPrep doesn't affect any *application* settings, so I'm actually quite surprised at that statement. SysPrep does not impact the contents of HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate in any way, and the use of SysPrep has no bearing whatsoever on WSUS. I will have to say here, emphatically, that Mark is incorrect in this statement. Although if you look into doing PV ensure the underlying disk system is up to par and that you follow best practices! I've seen some awesome PV deployments when done right, and some horrid situations when done wrong. With that many servers Provisioning server for XenApp could also prove very useful (believe Platinum licensing includes PV for XA). http:/ / / proddocs/ topic/ xenapp6-w2k8-install/ ps-image-prep.html This tool helps reset things like the STA and other important registry keys, etc. Ensure that when you change it that you also update the CAG.įor any further cloned XenApp 6.5 servers you should look into XenApp Server Configuration Tool to clone. Typically we set this to the MAC address, I've heard of others setting it to the hostname as well. To double check that each server has a unique STA navigate to C:\program files (x86)\Citrix\System32\nfigįind the line with UID=STAxxxxxxxxx and ensure that the xxxxxxxxx is a unique value. You may find that the cloned machines share STA ID's and can thus cause SSL errors (believe SSL 38). "Note that Sysprep resets other machine-specific state that, if duplicated, can cause problems for certain applications like Windows Server Update Services (WSUS), so Microsoft’s support policy will still require cloned systems to be made unique with Sysprep"Īnother issue you may run into is with Citrix use of STA if you are using Web Interface and Access Gateway / Secure Gateway for external access. They've allegedly introduced other 'duplicate SusClientID detection' code in the WUAgent, and my personal observation is that it only works about 10% of the time.Īs Mark Russinovich points out having duplicate SIDs isn't the end of the world as once thought (note that cloning for a non-sysprep'd image for a DC IS a big issue).Īlso, the last sentence of Mark's post he says that this does effect WSUS: The "AccountDomainSid" value actually worked quite well at preventing and eliminating duplicate SusClientIDs, and for some unknown reason, the WUAgent team removed that capability from the WUAgent v7.0, and nothing has been the same (or worked right) since. Also, the WUAgent v7 introduced the "SusClientIDValidation" registry value, which also needs to be cleared (and is likely missing from any scripts written prior to 2007). Most notably, in WSUS v2 the two registry values "AccountDomainSid" and "PingID" were eliminated from WSUS v3 (Actually, they're WUAgent v5.8 and v7.x values, but no real need to be pedantic here). The only caveat I would throw out is that some of those scripts were originally written for WSUS v2, and things have changed in WSUS v3. If you find a script written by Torgeir, you can pretty much trust it. Torgeir was a scripting god for WSUS back in the early days (2005-2007). I have found all kinds of scripts written by him having to do with WSUS on the net. That particular script was written by Torgeir Bakken.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |