You may already be aware that Citrix doesn’t natively support a simultaneous logoff for a user’s published app and desktop sessions. In point of fact, this problem is likely better addressed through effective Citrix policies surrounding idle logoffs. However, I had a customer with enough users and resource bottlenecks to justify this workflow, and so I’ll leave this for anyone else who might relate. Just in case it needs to be said: this entire process assumes your users are accessing their published apps exclusively from published/virtual desktops. This strategy will bring nothing but chaos to any other situation. Lastly, the solution described here will make use of an environment manager–in my case: Ivanti/AppSense.
A couple of years ago, I wrote a post about preventing Internet Explorer and Media Player from pinning to the taskbar. It was a fairly simple solution, and the post continues to generate traffic to this site. Unfortunately, though, the methodology died with the Windows 7 era, and none of the advice even applies anymore. I considered updating that post with this new information, but decided this would better serve.
This method is, unfortunately, a bit more intrusive. It does, however, have the advantage of actually working. It will suffice not only for IE and Media Player, but Explorer.exe as well. My old post might work better for you if you’re on an older Windows. Should those steps fail you, though: these will not.
Dragon Network Edition–Nuance’s ubiquitous dictation software–is powerful, to be sure. But, like any powerful tool in IT, it’s full of quirks and secrets, and a few of them can ruin your day if you’re not careful.
Dragon comes with the ability to maintain user profiles on the network, and this has some inherent advantages. For example, a user’s dictionary modifications and personal preferences will follow them from machine to machine. That’s essential for a person who touches multiple computers every day. Unfortunately though, Dragon does not do the best job of handling this workflow natively. By which I mean, if a doctor logs into Dragon on Computer A, fails to log out, and then attempts to log in again on Computer B… some weird stuff can happen. Profiles can become inaccessible, or even corrupted.
I spent much of last year bouncing around from one music subscription service to another. In trying Google Play Music, Spotify, Deezer, and Apple Music, I would always come up with a handful of nice things to say about each… followed by a long list of total dealbreakers. Google Play had amazing integration of my long-curated library of tracks with their upload feature, but the UI is clunky, slow, and full of bugs. Apple Music let me integrate their library fairly seamlessly with my own in iTunes, but their Android app was unusable. Spotify’s integration of your personal library is approaching nonexistent. The direction of the company and UI seems to belie a desire to remove it completely.
I shared this workflow a couple of years back, and it’s since become one of the most referenced articles on this blog. It’s something that has been a part of just about all of my AppSense deployments since its inception. However, as time passed, the configuration evolved to be much cleaner, and I thought it was time for an update. So, without further adieu, here’s how we can manipulate AppSense to act only when a session roams from one endpoint to another. As an added bonus, we’ll even look at how to run them only when that session roams to a new department, building, or area.
Scenario: User A logs into a session on a thin/zero client, then walks away for 10 minutes without disconnecting. Imprivata, configured to secure the idle workstation at that time, attempts to lock the machine. The box returns to the local login screen, but the username and domain are pre-populated, and new users cannot login over User A before manually signing them out of the local device. In other words, the device is behaving like an Imprivata Type 1 (Single-User) machine. Ostensibly, it looks like Imprivata is preventing new users from logging in.
What follows is applicable only to Windows 7 / Server 2008R2. Certain updates to Windows (even to those versions) may have invalidated this advice, but I am leaving this article here in case it still works for some.
Beyond this, there is a more reliable option that you can read about here. I am confident this newer strategy will work on all versions of Windows.
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.
BGinfo, in case you’re by some chance unfamiliar, is a Microsoft utility for displaying session information on the wallpaper. It is often used on both servers and desktops for the purpose of quickly identifying the current Windows user, the name of the machine, and any other handy information one might want to have at hand. However, in one of Imprivata’s most common use cases, a generic account is used to enter the Windows environment, while a type-2 (kiosk) OneSign agent acts as an authentication gateway for each SSO user who shares that machine.
In this scenario, displaying the currently logged-in Windows user in BGInfo is a bit of a moot point, as it will always be the same for everyone. It doesn’t give any actual indication as to who is presently using the device. The problem is that, by default, there is no environment variable or single point for BGinfo to reference in order to display the current SSO user–that is, the one who just authenticated to Imprivata. Thankfully though, it’s not hard to set this up.
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.