I've been pretty quiet recently because I've been very busy doing (amongst other things) beta testing on what will very likely turn out to be a very big release for AppSense DesktopNow, Environment Manager 8 FR 5, Management Center 8 FR 6 and Application Manager 8 FR 8. It's quite an exciting release, as there are loads of new features and improvements - some of which can be covered adequately in this article, and others that are big enough changes to warrant articles of their own (coming soon!)
I'd just like to start by saying that it's a good sign that so many improvements have been factored in to these releases, particularly in Environment Manager, where most of you will notice the most dramatic changes. Hopefully this is a clear indication that AppSense do listen to their customers and their community, because there are a lot of changes that we've been clamouring to see for a while in this release.
Environment Manager Policy
The lion's share of the changes are to be seen in Environment Manager. I can understand that admins may be a bit uneasy about this, as some of the more major ones are on the Personalization Server end and will need to be tested thoroughly as part of the upgrade process. However, once you realize what potential extra functionality can be brought by utilizing these new features, I doubt that admins will be quite as uneasy about deploying it.
New triggers
One of the main changes you will notice straight away are the new triggers in the AppSense Environment Manager Console. These are way overdue. For years now, AppSense administrators have been using Custom Scripted Actions to wait for the network at Computer Startup and also to delay actions until "after" the logon appears to have finished (see my blog post on the latter here). But with the advent of EM 8 FR 5, we can kiss goodbye to these scripted Actions and do all of this natively.
Firstly, you will see a Network Available trigger under the Computer section. Under the hood, this trigger uses NLA (something I used in PowerShell occasionally for network detection).
Now, as you probably can guess, this isn't clever enough to differentiate between specific network connections, but it sure will make life a hell of a lot easier. I can remember a lot of frustration when AD lookups or file/folder copies would fail because the network was unavailable, even though Group Policy Preferences could copy network-based files with apparent impunity. Using a Wait For Network script became almost standard procedure in some configurations. But now - we can detect boot-time network connectivity with a native Trigger. Add in after this a quick check for the corporate network (by checking a file share, host response, pick your method really), and you should have a reliable way of identifying when a system is online, and whether it it is remote or internal.
Under the User section, you will see even more new Triggers - Pre-Session, Pre-Desktop, and Desktop Created, sounding the death-knell for the scripts and/or executables that everyone leveraged to delay certain Actions until "after" the logon had finished. AppSense have, though, gone beyond what we managed with our customized methods and given us three new triggers to utilize.
The descriptions I found a bit confusing (bear in mind this was the beta version), but this should clear it up...
Pre-Session - actions defined here take place after the user has supplied their logon details and the user profile has been created, but before the user "session" itself specifically starts.
Pre-Desktop - actions defined here take place during the initialization of the user's session, but before the shell actually starts
Desktop Created - actions defined here take place after the shell has started
What we achieved previously with the custom post-logon triggers obviously should be transferred into Desktop Created. Actions defined in the old, pre-8.5 Logon trigger should be replicated in the Pre-Desktop area (in fact, this is where they will transfer to when an older configuration is upgraded). Pre-Session could be used for environment variables, registry settings and group policy objects that perhaps you may previously have hard-coded into the mandatory profile, or to hold anything that you want to process entirely before the Pre-Desktop trigger begins.
When you first upgrade your configurations, you'll be asked if you want to enable these new triggers, or stick with the old ones for now. The change requires a client restart to take effect - but given that this is a major upgrade, I would expect restarts to be done as a matter of course anyway.
New Conditions
We haven't just got new triggers, but new Conditions too. Both of these should prove useful, I have written many custom detections for these in the past, and blogged about them on occasion.
Is Laptop - does exactly what it says on the tin. Shaun points out in the comments that it simply checks for the presence of a battery, so I may do some testing on tablets to see what behaviour it exhibits in those situations, but it replicates the way a lot of us have done it in the past anyway.
Is VDI - this detects whether a machine is running a virtual desktop. This is quite handy, but a bit limited in its scope, as it will only detect Citrix XenDesktop and VMware (Horizon) View at the moment. I would hope this is going to be expanded in future a little.
New session variables
This is a really big improvement (in my opinion, anyway), and it's unfortunately tucked away deep in the console. Using this should hopefully reduce the logon times of almost everyone out there. If you're spoofing the user profile type to dump local profiles at logoff (as a lot of people are), you will have to pull a value out of the HKLM area of the Registry to get the user's SID in order to change the profile type. Most everyone has done this via a scripted method - VB, PowerShell or WMI being the favourites. Of course, everyone who has done detailed analysis of logon times knows that firing up scripted Actions can give you a little bit of drag, so it's often prudent to keep these to a minimum. In EM 8 FR 5, there's a session variable for the user's SID (and a couple of others too) which are now available by default, so simply by using $(UserSID) in your Registry or File Actions, you will be able to avoid having to use a script to extract the SID information in the first place. You can view the available built-in session variables by looking under the Insert menu in a Custom Condition or Action.
I've raised my concern with how "hidden" this nifty little feature is with AppSense and I'm hoping they make it more visible to the administrator in the GA release, because it should improve a lot of the configurations out there.
Mid-session config changes
The "mid-session config" bug can be a major pain (dependent on how unlucky you are). If you're very unlucky, it can cause GPOs, shortcuts, printers and drive mappings to reverse or even disappear. It's normal practice to get around this by keeping config deployment at computer startup or inside change windows, but there's always the chance configurations can be erroneously deployed when users log in. There's also the overhead of staff having to work late to deploy new configurations in specific change windows.
In EM 8 FR 5, there are now options to deal with mid-session config deployment. However, the new options provided almost seem to be in conflict with the Installation Schedule settings in Management Center. I'm wondering if the new settings are intended for enterprises who use other technology (such as SCCM) to deploy configurations rather than those who use the Management Center? It does give some interesting options, though, effectively allowing you to have a configuration-based option to deploy immediately or delay, rather than having this tied to the Deployment Group.
Update - as Shaun Jones pointed out in the comments, the new feature here handles how existing sessions deal with the installation of a new configuration, not when the configuration is actually installed to disk. Both features work hand-in-hand to give you more control.
Update - as Shaun Jones pointed out in the comments, the new feature here handles how existing sessions deal with the installation of a new configuration, not when the configuration is actually installed to disk. Both features work hand-in-hand to give you more control.
 | ||
If you use the "At Logon" option, new logon sessions would load the new configuration, existing sessions would remain using the old (cached) copy and remain unaffected by the change. Thanks to Shaun Jones again for clarification of this via his comments.
Again, please bear in mind this is only the beta release I am referring to and I have fed my opinion back to AppSense, so how this feature is documented may well be improved in the GA release.
Again, please bear in mind this is only the beta release I am referring to and I have fed my opinion back to AppSense, so how this feature is documented may well be improved in the GA release.
New Actions
Not just triggers and Conditions, we have a couple of new Actions too!
Logon/Logoff Message - this allows you to display a custom message at logon or logoff (dependent on which section you use it in), which you can even use multiple times to display different messages at different parts of configuration processing. This may make things look slicker for the user, or keep them aware of what's going on, or perhaps even be of limited use as a troubleshooting tool.
Fast Logoff - this is another trick that has been absorbed into the AppSense EM armoury, the old trick of disconnecting the session to make for a faster logoff time. I blogged on it (I think it was on my first day as a blogger!), but this is another customized function you can now do natively instead.
No more enabling local Group Policy processing
Another important change is that you no longer have to keep local Group Policy processing enabled in order for AppSense EM to be able to run logoff Actions correctly. For a very long time now, EM has avoided being terminated by Windows at logoff time by leveraging Group Policy to call its logoff actions, as Group Policy is allowed as long as it wants to process. This has been changed in EM 8 FR 5 so that there's no need to avoid disabling local group policy processing (killing off yet another of my articles in the process).
Some cool interface changes
There have also been some good changes to the user interface of the console itself...
Expand/Collapse All - allows you to collapse or expand an entire Node or Action subtree with the click of a button
AND/OR indicators - these are now much more intuitive. I've lost count of the number of times someone asked me "what does the blue bit mean?" when they'd just created an OR relationship. Now they look like this, which should stop all the questions
Stop If Fails description - you will also notice from the above image that the cryptic "Stop If Fails" checkbox is now the much-more-intuitive "Stop sub-nodes on fail". Also, a node with "Stop sub-nodes on fail" configured will now have an icon indicating such - not sure what the icon will look like in the final RTM version, but there should be one.
Find/Replace fixed - literally since the first time I worked with version 8.0, I have hated the Find/Replace dialog box with a passion, and particularly the way the Enter button triggers the "Cancel" function. To this day, I still type in a search parameter and hit Enter, only to curse the developers as the dialog disappears. But - no longer! Not only this, but the whole dialog has been vastly improved.
Personalization Override
I never had a lot of dealings with the Personalization Override feature of Process Started Actions, but apparently this now works correctly. So good news for those who've felt the pain of this particular problem!
Personalization Server
Moving forwards, the really big interface and operational changes - the ones that you will notice quite strongly - are to be found in the Personalization Server area of the console.
Desktop Settings and Session Data have now been aggregated under the heading of Windows Personalization. This means that Personalization Server effectively splits into two main areas - Windows Personalization, and Application Personalization. Once you've upgraded, your old Desktop Settings will be displayed as Legacy until such a time as you are ready to remove them.
Windows Personalization allows you to work with what you previously knew as Desktop Settings and Session Data in much the same way you would work with Application Personalization. You create Windows Settings Groups the same way as Application Groups, add files/folders and Registry keys to them, and link them to Personalization Groups. The old Desktop Settings configuration items are all readily available as pre-created Windows Settings Groups, and you can add your own as necessary. But one of the biggest changes is that each Windows Settings Group can have Conditions applied to it - not just the very basic "Windows Family" separation in earlier versions of Personalization Server, but the whole array of Conditions from EM Policy!
 |
| Application and Windows Personalization working together |
 |
| EM Policy Conditions in a Windows Settings Group |
Windows Personalization will need an article of its own to get to grips with everything that you can do with it, but there are many great features in there and a load of things you could achieve with it. For instance, you could now manage Taskbar Pinned Items for Windows 7 and Windows 2008 R2 machines on an individual basis rather than having them lumped together - a major pain when these systems may well have different application sets!
There are improvements elsewhere in Personalization Server as well. The Default Blacklist has been replaced by a global Application Exclusions list. Each Application Group can now have filetypes excluded on a per-group basis, instead of just a global list. You can configure new Personalization Group settings such as pre-caching, so that apps are ready to run when users need them, and sync the Windows Personalization data not just at logon/logoff time, but at Session Lock and Disconnect.
It doesn't stop there - the Pre-Session trigger in Policy also allows EM now to Personalize DPI settings correctly (good news for @byteben). And here's another big one - when an exclusion is configured for an application or group, any data that was saved previously but is now specifically excluded is automatically removed from the Personalization database! Goodbye to custom SQL scripts and widespread usage of APPSENSESPECIAL to get rid of extraneous Personalization data! Add to this better performance and new certificate functionality, and you can see that there's a hell of a lot contained in the Personalization Server upgrade.
I'm going to do an article very soon on Windows Personalization and how you can get things done with it - stay tuned.
Management Center
Multiple instance support
The major change in Management Center (and also, for that matter, Personalization Server) is that they now support multiple instances on the same web servers. Imagine that you've got two AppSense databases, one corporate, one education. To support these currently, you'd need two Personalization Servers and two Management Servers - four servers for your AppSense infrastructure, and that's before you start factoring in any redundancy.
With AMC 8 FR 6, you can now put up to seventeen instances per web server (default plus sixteen others). That could potentially drastically cut down on the number of servers needed to deploy a redundant AppSense infrastructure.
There are also PowerShell cmdlets included for working with multiple instances. I've mentioned to AppSense that PowerShell compatibility is one area I'd like to see a lot more of, and this is further progress in this area.
Custom configuration file location for non-persistent VDI support
Yet another of my articles bites the dust, as AMC 8 FR 6 introduces the capability to configure the AppSense configuration file location on a Deployment Group basis. This will allow non-persistent VDI sessions to redirect it to a persistent disk or location without messing about with mklink, subst or similar commands.
This is another excellent addition, in my opinion, addressing another of AppSense admins' long-standing gripes.
Application Manager
Finally, Application Manager 8 FR 8 will introduce a Change Request feature, which will allow users to request updates to their application whitelists and execution privileges that can be then routed to support and actioned. It will also have a change tracking feature like EM, and other new things besides that probably also warrant a full article from me.
Summary
The new releases of DesktopNow, and most particularly the Environment Manager side, are going to bring huge improvements. But in order to encompass these improvements we will all need to make sure we upgrade carefully and with a good, tested backout plan, as there are a lot of changes going on.
No release date is confirmed yet but I would think that it is going to be within the next month or so, all things being well, so now would be a good time to start thinking about how to plan for an upgrade - and what we are going to use all those cool new features to achieve for our users! But kudos again to the guys and gals at AppSense for addressing a lot of our long-standing gripes - long may this continue.
PS - here's hoping England whop Uruguay tonight in the World Cup, with apologies to any Uruguayan readers I may have picked up.