First and foremost, I should note that this post will deal specifically with RFIDeas-brand proximity card readers. If you are seeing this problem with any other variety, hopefully I can provide some insight, but I won’t provide a fix. Additionally, this article assumes that you entitle Imprivata users to enroll a single badge at a time, and that you provide them the ability to overwrite their badge enrollment. With all that being said, let’s dig in.
So, you set up your KMS server and you activated the license key for your version of Office. You ran the slmgr.vbs /dlv all command and confirmed that all is configured correctly there. You installed Office on your master image, pointed it at the proper KMS server, re-armed it for activation, and recomposed without ever opening the software. You spun up a fresh virtual desktop, opened Microsoft Word, and found that your version of Office had not been activated. You ran the ospp.vbs /act command and found that KMS did its job, but you thought running that command as part of a startup script seemed like a bad solution to your problem. If all that sounds about right, the good news is that you’re almost there. The fix is simple and, weirdly, hidden in plain sight.
In certain cases, you may notice that an SSO profile for a Citrix-published app works as desired, but not before a user manually gives focus to the window. I have worked at more than one organization where the extra click was a total deal-breaker, and if you find yourself in need of that seamless experience, you’ll be happy to know the fix is no more complex than a couple of registry settings. One needs to be applied to any and all servers being used to publish the apps (to be sure of a consistent experience), and the other to the receiving clients. Appropriately, we are dealing with “Seamless Flags,” and you can find more information about them in articles CTX112499 and CTX101644 on the Citrix support site.
If you are using VMware’s ThinPrint solution to map printers, you may already be aware that the tool will check every 30 seconds for new printers by default. Effectively, ThinPrint is supplied with an interval, and every time that interval passes, it looks for any printers that have been mapped or unmapped from the endpoint. If it finds any changes, it forwards them to the virtual session. After that, it begins the countdown anew, and the cycle repeats.
When using Imprivata with XenDesktop or VDI-In-A-Box, you may find that connecting to a session results in your arriving at the Windows user login screen instead of a desktop. In order for the Imprivata credential passthrough to work in these environments, you need to install the agent via the command line with the following switch:
This will let Imprivata act as a Network Provider (it will appear in the ProviderOrder settings) and will allow for seamless credential passthrough from a Citrix Receiver or RDP client into an SSO-enabled desktop.
If you are deploying a virtual desktop environment in a hospital setting, you can be absolutely assured that a user will, at some point, walk away from a computer and leave a session unlocked.
Without application-level single sign-on, this is a big security hole. With application-level single sign-on, it is a security nightmare, and I don’t doubt that it would constitute a smorgasbord of HIPAA violations. I imagine this is a problem that exists in other arenas as well, but alas, my scope of experience is as-yet limited.
Five posts into this blog and I’ve already had to talk about the Xenith 2 twice. The reasons for this are several: the information is fresh in my mind; the device is newer and lacks extensive documentation on the Googles as yet; I’m trying to stay motivated to keep this little project going by writing often, and I ran into all kinds of problems with these things…
Anyway, in addition to the aforementioned virtual driver error there were a few “gotchas” (as I am told they are called in the biz), so I will keep the exposition short in an attempt to cover everything in a single, hopefully intelligible post.
I am keeping this article here for the sake of posterity. I’ve posted a newer, cleaner, and simpler explanation here. Trust me when I say it’s a better read than what follows.
In Windows XP, one was able to overwrite the Default users NTUSER.DAT with whatever one wanted and it would pretty much work okay. This meant you could just set “Adjust for best performance” in the GUI with one user, and then overwrite the default NTUSER.DAT with this user’s modified verison. This changed with Windows 7, and it hasn’t been that simple since. Getting this setting to apply correctly in a Windows 7, linked clone/virtual desktop environment is far more complex than it should be.