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 know what you’re doing and don’t need my rambling, you can get what you want from here.
If not: I (and countless others) have spoken at length about AutoHotkey and why you should be using it. For the uninitiated, it is an extremely powerful and easy-to-learn scripting language that you can use to fix just about any problem you throw at it. You can use it to automate all your repetitive, boring tasks and even create entirely new workflows. Case in point: this article.
After the third or fourth time typing date += 1,months in a script and coming up empty, I decided I needed to implement this apparently nonexistent functionality. I did few Google searches for this purpose and was met with a similar lack of success, so I figured I’d share my results here.
This function will take an arbitrary date and add (or subtract) a given number of months from it. If you want to return the date three months from today, throw today’s date and a positive 3 at the function. If you wanted to return what the date was 3 months ago, just make it a negative 3 instead. It’s fully fleshed out in the comments if you are interested.
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.
“OneSign could not authenticate you” is a rather generic error that can be the result of any number of different discrepancies. There are specific workflows that can cause it to appear even when everything is configured appropriately on the back-end, and there are several reasons that a user might encounter it aside from these. Unfortunately, Imprivata does not offer more specific error codes that you might identify the root of the problem with any ease. Sifting through logs has a tendency to be as confusing as clarifying, so I thought I’d put together a more concrete guide to troubleshooting this problem.
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.
Troubleshooting problems with respect to AppSense policy can be difficult. There are a lot of different, equally valid approaches, and your problem might be easily resolved if you could just choose the right one. While getting AppSense to work is rarely a cumbersome task, there are a variety of ways that it can break. Here’s a few questions you need to ask if you find that your Environment Manager configuration is not doing what you think it ought to do.
Hypothetically, setting up your policies properly is enough to allow for User A to login to a desktop, get his Citrix virtual desktop, and then lock the machine confident that his session is secure and inaccessible to User B who logs in next. Unfortunately, as of this writing (and version 4.8, hotfix 1), that’s not always the case.
If you find that, unlike the ideal situation above, you notice that Citrix Receiver stays open during the switch and User B is able to see User A’s session after the fact (Followed shortly by a second Receiver session opening over top of the first), there are a few things to consider. First, take a look at your policy.