Prior to Windows 8, the multi-monitor taskbar was not even a native feature in the world of Microsoft. They have finally added it, but for whatever reason, did not make it possible to add a clock on the second monitor. I might find myself in the minority here, but for whatever reason, I instinctively want to glance in the lower-right of my visible screen space to see the time. Barring any tweaks or workarounds put in place beforehand, I will find no clock there, and then have to shift my gaze left to see the time. First world problems? Sure. But solving those is pretty much the point of this blog.
I have touched on the subject of troubleshooting zero clients for Imprivata usage before. However, I have been reminded in recent weeks about something I neglected to cover, and which probably deserves its own post anyway. I am referring to a commonly recurring problem that arises when one attempts to mix Imprivata, zero clients, and proximity cards.
Under certain circumstances, attempting to use proximity cards to “tap out” of an active virtual session on a zero client fails. That is, the card reader beeps, but the session remains open. I have also seen other strange behavior as well, such as a user being able to “tap over” his or her own session–where Imprivata locks the zero client and then logs them back in as themselves. Furthermore, this issue does not seem to be exclusive to View or XenDesktop, and obviously, neither of these scenarios is acceptable. Thankfully, the fix is a simple registry change in your master image.
The Windows 8 music OSD is a nice little feature of the oft-criticized operating system. The fact that it is so often criticized comes from a whole handful of little complaints about UI choices that are not always defensible. Case in point, the only built-in way to reveal the OSD is by using the volume change buttons. While this might make sense on a tablet or smartphone (I love my Nokia Lumia 920), it is less justifiable on the full OS. A member of the /r/windowsphone community recently asked if there were any way to make this music OSD appear without modifying the volume. The short answer is: technically, no. But we can accomplish effectively the same goal with a simple little workaround with thanks to AutoHotkey.
Running a Java application with a verified digital signature is generally a pretty safe operation. Odds are you will indeed want to “always trust content from this publisher,” and once you indicate as much, the prompt disappears. The question is, how do we prevent it from occurring at all?
Technically speaking, there isn’t a way to suppress it. That is, you can’t configure Java to run these verified applications automatically regardless, with the registry, group policy, or otherwise. However, that is not to say we can’t hide the prompt from users anyway–it’s just a matter of addressing the discrepancy that invokes it. Essentially, we have to tell the machine to “always trust content from this publisher” in advance. It doesn’t suppress the prompt so much as it pre-answers it, and it unfortunately means you have to account for every Java application used in your environment, but the endgame is the same.
Though normally accomplished with the Internet Options GUI, you can also modify IE’s “Check for newer versions of stored pages” setting with the registry.
Where the 3 value, in this case, sets it to the third value of “Automatically.”
One of the limitations of using AutoHotkey to control Google Chrome comes in the form of determining the active tab. I have seen this brought up in a number of different places online and have seen some clever means of accomplishing this goal, including looping through all the different tabs and determining the names of each before acting on any of them. Though this would admittedly provide more control, it strikes me as heavy-handed and inelegant.
One commonly overlooked but absolutely critical piece of an Imprivata implementation is the ability to reset active directory passwords, expired or otherwise. It’s one of those things that tends to fade into the background in the midst of other pursuits and resolutions, but if it isn’t accounted for, it can cripple an entire environment. As soon as users’ passwords start expiring, and they are told they need to reset them before they can login, an incomplete or incorrect configuration on the appliance can result in users getting completely locked out of their desktops, relegating them to downtime procedures or worse.
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.
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.