

On the non-production systems, some of which aren't redundant (so single PVS, single Controller, etc) I just went ahead and moved them because they're not production. So only one of three Controllers were moved into the Hardened OU. On all the production systems I only moved in one of the redundant servers so we could make sure the change didn't take down the environment. I just implemented a change for a client where we moved a bunch of systems (Controllers, Provisioning, etc) into hardened OU's in an effort to lock down the environment and appease the Security Gods. To get flair with your certification level send a picture of your certificate with your Reddit username in the picture to the moderators.įigured I'd share this in case anyone has come across it or may see it in the future. XenApp Printer Driver Manager - Print Driver Management for XenApp 6.x AD Group Policy Search - Search through AD Policy for that one policy you always forget the location of.VDA Cleanup Utility - Removes/Uninstalls the VDA for servers and workstations.Citrix Supportability Pack - Swiss Army Knife of diagnostic utilities, 49 separate utilities.Citrix Scout - Quick health check on environment, uploads to TAAS site for results.


Suggestions? Advising users to pint sAMAccountName is not in line with the company standard. If anyone who has in AD then their logon is successful. If the same users logon to SF using sAMAccountName then the logon is successful. So SF must be able to authenticate the password. The specific set of users are not using the UPN address, in AD their respective accounts are configured with as specified in AD.Ĭuriously if they input UPN and an incorrect password the SF returns bad username or password. When attempting to authenticate to StoreFront 1912 CU1 using UPN, a specific "set" of users observe: Granted the error I have posted is not uncommon and there are threads on the subject and the web has many articles too, however I have something of a special use case.
