This is the second article in a series (#1 here), which highlights important differences between how AppSense DesktopNow and RES Workspace Manager 2012 works in practice. While it was suggested in the commentary that I had to search for a topic where RES WM had the biggest difference to AppSense DesktopNow, I assure you that this was not the case: There are plenty of other examples waiting to be written and we’re just getting started…
In some enterprises, managing shortcuts is an important part of managing the user experience. Add VDI, RDSH/Terminal Services, and traditional desktop environments to the mix and presenting a common and unified user experience becomes even more important. While today’s end users are more computer-savvy than yesterdays, shortcuts can sometimes get deleted and users can still get confused when inconsistencies arise. Both AppSense DesktopNow and RES Workspace Manager 2012 have the ability to manage shortcuts. Let’s take a detailed look into the technical aspects and considerations in setting up and maintaining shortcuts with both products.
For the purpose of comparison, just like in the previous article we have established a simple scenario to implement in both products. The scenario is:
“A sales department needs a mandatory shortcut to their intranet page, placed on their desktop, with a custom icon file. As a general best practice to avoid dead shortcuts, we also want to check if the executable exists.”
AppSense DesktopNow
Within AppSense DesktopNow, shortcuts are configured using Environment Manager. The steps covered here are performed in the Environment Manager Console. After creating a Node and determining which trigger to use (logon/logoff, process start/stop, network connect/disconnect, etc.) the first few steps are spent establishing “Conditions”.
Step 1 – As the shortcut must only be available to the Sales Department, a “Condition” based upon group membership must be created:
Step 2 – The shortcut should only be shown if the application used by the shortcut exists on the computer. We set a “Condition” based upon the existence of a file – in our example this would be “iexplore.exe” – Again this is just an example as we are pretty sure IE is there as an OS component, but this is a good generic step to implement as another browser perhaps could be required instead of IE. Also this example could be applicable to a completely different type of app.
Step 3 – Now it’s time to create the actual shortcut. Here we establish an “Action” to create the shortcut:
In the above example there is a couple of things to consider. First, when creating a shortcut, the “Apply permanently” checkbox is checked by default. The AppSense documentation states that; “Shortcuts created though Environment Manager are automatically removed from managed endpoints at logout. If the Apply Permanently checkbox is selected, the remove is not applied and the shortcut remains on the endpoint.”
You want to be real careful with the Apply Permanently option, as it poses a dilemma: If checked, the shortcut will be delivered and will remain on the endpoint regardless of the condition above. AppSense DesktopNow only evaluates its conditions once. So if this box is checked, and later on you change around a user’s group membership, the shortcut remains. Depending on how the environment is setup, the users may receive the dreaded “Broken Shortcut”
There is a second item to consider: What about our custom icon file? Fact: AppSense Environment Manager does not store icon files inside its configuration. In our scenario, our only options are to use the default blue “E” from the iexplore.exe application or to point to an .ico file on an SMB share or local drive:
Third, consider what happens when .ICO files are stored an SMB share, what happens to users who are disconnected (for example laptop users)? If .ICO files are stored locally on a drive, how are those files managed – especially in large enterprises with potentially thousands of endpoints or multiple images? What if an .ICO file is missing or gets accidentally deleted? The answer is obvious: The users will get the “Broken Shortcut” icon again. The shortcut would still work, but visually it appears as if it is broken. If it appears broken, the users think it’s broken and they will start calling the helpdesk and are probably not productive at that point.
Step 4 – When you have made your decisions above, you want to establish a “Self Heal File” action just in case you do not want the shortcut to get accidentally deleted:
Note, one could consider adding another step here to create a self-healing action for the .ICO file. Either way, the end result hierarchy should look like this:
Steps 5-8 – At this point, we follow the usual common denominator steps inside AppSense DesktopNow, which are necessary to go through anytime a configuration change is made:
- Save the configuration to the “Management Server” within the Environment Manager Console
- Jump over to the “Management Console and assign the newly saved EM configuration to a “Deployment Group” if it has not already been done.
- Review and “Submit” new configuration to push it to all endpoints within the “Deployment Group”
These steps are outlined in more detail in steps 6-8 in my previous article.
Discussion Point: AppSense DesktopNow Sales vs. Practice
Before we continue, I feel it is important to mention that within AppSense DesktopNow, there is more than one approach to accomplish the same thing – this seems the case when a given feature within Environment Manage appears to be slow. In a AppSense Users Group discussion, we notice an AppSense employee on the technical services side of the house suggests abandoning Environment Manager shortcut delivery all together in favor of the “File Copy In/Out” action within Environment Manager, or even adding VBScript code (!)
“The API call in windows to create a shortcut is actually pretty slow. While the functionality is built into the console the faster option is to put the shortcuts on a network share and then use copy file actions.”
The above is a quote from the APUG post (available here, or see the screenshot on the right).
RES Workspace Manager 2012
Understanding the nature of RES Workspace Manager 2012 underscores the key difference between it and AppSense DesktopNow. Spelling it out, RES Workspace Manager 2012 manages the workspace on endpoints. AppSense DesktopNow delivers configurations on endpoints. Delivering shortcuts is a good example for illustrating this.
The scenario is the same as was given to AppSense DesktopNow. Let’s recap it: We have a Sales Department who need a mandatory shortcut to their intranet page placed on their desktop, with a custom icon file. The icon must remain on the desktop even if the user deletes it.
After opening the RES Workspace Manager Console and selecting the “Composition” main section, we perform the following steps within the “Applications” node of the tree.
RES Step 1 – We create a new managed application and fill in the following fields: Title (will be the name of the shortcut), command line, and parameters.
Edit the “Desktop” dropdown field and select “Set mandatory shortcut”. This prevents the shortcut from being removed. While the user can delete the shortcut file, it will re-appear on the next refresh. It’s equivalent to how the “Self Heal File” action is applied in the previous AppSense DesktopNow example.
Note1: In the dialog above, when you hit Tab after filling in/browsing the executable, RES Workspace Manager auto-completes the working directory and reads in the default icon. We will however change that below.
Note2: The Desktop and other shortcut locations have the ability to create voluntary shortcuts as well, i.e. they are created once and if the user deletes them, they stay gone. However, be mindful of a snafu with the voluntary mode; it only works for new applications. If you edit an existing app, no voluntary shortcut will be created.
RES Step 2 – On the managed application’s “Settings” tab, we check the “Hide application if executable was not found”. This is equivalent to the AppSense “File Exist” condition within DesktopNow. It should be mentioned that we can set this option as a default for new WM managed apps, thus eliminating this step all together.
RES Step 3 – Browse and select our custom icon file:
Note: It is important to mention that the icon file can be extracted from any executable, DLL or directly from a .ICO or library file. Once selected, the icon is stored within the RES Workspace Manager’s datastore and henceforth automatically cached in the RES DBcache on every endpoint. This part of the RES WM architecture simply eliminates the risk of the before-mentioned “Broken Shortcut” situation.
RES Step 4 – Configure Access Control so only the users in the Sales Department receive the shortcut. We do this under the Access Control side-tab on the RES managed app.
Once we click “OK” we are all set. At this point, the new shortcut is applied to all RES Workspace Manager managed endpoints during the next refresh.
As mentioned in my previous comparison, it isn’t what AppSense DesktopNow or RES Workspace Manager 2012 does – it’s how they do it that matters. For us technical worker-bee’s in the field, the tools that add simplicity to our complex enterprise environments are generally the best tools.
In the coming months, I will be providing additional comparisons on some of the more significant features of both products as we further explore how they work instead of what they do. Once the information is presented, feel free to draw your own conclusions.