Editor’s introduction: I have the pleasure today of welcoming Paul Newton as a guest writer here at RESguru.com! Paul has been in IT for 20 years, with the last 15 years spent in the systems management area. Paul is experienced with AppSense, SCCM, AdminStudio, App-V, Citrix and of course RES Software. He has worked in several large and medium sized enterprises in healthcare, energy, and broadcasting.
In the following article, Paul touches on an interesting subject which is sure to get the attention of the usual suspects ;) Over the years, there’s been a couple of more or less useful comparisons between what the merry folks respectively at AppSense and RES Software do, when it comes to managing the user’s persona/profile/environment/workspace (take your pick). The problem with most comparisons is that they basically end up just being a longwinded list of check boxes of who can do what.
The inherent problem with said approach is this: Whoever “dares” to create such a checkbox comparison between any two or more competing vendors, is likely to have at least two vendors breathing down their neck, as the vendors all essentially want to look their best and have every last darn checkbox filled. For a long time, I’ve been advocating another approach: Presuming Vendor X and Vendor Y’s product can do the same things overall – logically the focus must shift from what CAN be done to HOW IT IS DONE.
As for vendor marketeers, this approach is obviously a lot tougher to deal with, especially if your product interface generally speaking is weak, unstructured or down right complicated to use. For the record, I am not referring to any particular vendor indirectly here – these are objective terms to meter by. Of course it is any vendors prerogative to protest that things aren’t being done right, if there is an easier way that has been overlooked. Either way, this cuts the non-technical folks out of the discussion, so us folks on the factory floor, the engineers can better figure out what product we want to use and recommend.
Long story short, this is the approach Paul Newton has taken in this article, which I hope will be the first of several. Let us hand it over to Paul from here:
The title of this article could be boiled down to this: Complexity vs. Simplicity. For the sake of understanding a given administrative process, what could be simpler than mapping a drive letter? From a networking administration perspective, mapping a drive letter is a simple task, but that combined with things have a tendency to get complicated real fast when you have many moving parts (and many network drive rules) in a large environment. Today, let us compare the “how’s” between AppSense Desktop Now and RES Workspace Manager 2012. Mapping the drive is one thing, but also consider this: When you are serving up multiple network drives to the user, you probably also want to clean things up a bit and get rid of those pesky “username on sharename” strings next to the drive letter in Explorer, right? To sum things up we want to accomplish the following:
Map a network drive for a group and set a friendly name on it.
First up: The following are the steps to go through in order to create a mapped drive incl. Friendly Name within AppSense Desktop Now – aka Environment Manager:
Step 1 – Go to the AppSense Environment Manager Console and create a Group Membership Conditon.
Step 2 – Create a Map Drive “Action” within the Environment Manager console. So far so good, nothing out of the ordinary; we specify a driveletter and a UNC path.
Step 3 – Subordinate the Drive Mapping Action under the Group membership condition. This subordination means the drive mapping only will be performed if the membership condition in this case tests true.
Step 4 - Create a Registry Set Value “Action” to define the Friendly Name. This is where things get funky: You will need to figure out the name and location of the required registry key yourself. It is not pre-populated in any way.
Step 5 – Subordinate the Registry Set Value “Action” underneath the Map Drive “Action”. In this example, it means “When this drive is mapped, also do this registry change”. The whole thing should look like this by now:
Step 6 – Save your Environment Manager Configuration to the Management Server using the Environment Manager Console.
Step 7 – Now you need to hop over to a different console, the Appsense Management Console. Here you will need to assign the Environment Manager configuration you saved in the previous step to the appropriate Deployment Group (if it has not already been done).
Step 8 – “Review and Submit” the new EM Configuration and deploy it to the group.
Now we understand the configuration process using the method provided by AppSense. Now let’s look at how we do the very same drive mapping and FriendlyName configuration in RES Workspace Manager 2012. Let’s be clear, we are not counting steps, we are just looking at what needs to be configured.
RES Step 1 – Configure the drive mapping and friendly name on this properties tab. You fill in the drive letter, UNC path and Friendly Name at the same time.
RES step 2 – Assign Access Control, i.e, who will get this drive mapping. This is the equivalent of steps 1 and 3 with AppSense. Here you browse after (in this case) the Home Drive Mapping Group and assign it.
At this point, after hitting OK, there really isn’t more you need to do as the console operator in RES Workspace Manager. Perhaps you might be rightfully contemplating when it takes effect. You might be familiar with the Refresh event in Workspace Manager, and perhaps be ready to protest; “Hey, why aren’t you showing that Refresh as a RES step!?” The reason is to be found in the RES Workspace Manager Architecture. The moment you hit the OK button in the above example, the configuration item (in this case a drive mapping) is stored into the RES Workspace Manager datastore and automatically pulled down by the RES Service on each agent, (optionally via Relay Servers). At that point it’s just a matter of when the next login or app launch event occurs for the drive to be mapped. These events do not implicate any additional clicking by the console operator, which is why we stop there.
For both vendors product, the available options for triggering are similar: Launching apps, logging on, reconnecting to sessions, etc. As mentioned, RES Workspace Manager has it’s Refresh event, to which many things can be tied. AppSense can tie triggers to similar things. To be honest I believe the only place where AppSense has a slight leg up on RES in this area, is the ability to trigger configuration items when a process terminates.
On the other hand, RES offers further flexibility in Workspace Manager 2012 by letting you pick the timing of the mapping. As shown above, you can for example choose to wait for [a mapping] task to finish before continuing, which is great if there are things further down the line dependent on the mapping. Otherwise, if you uncheck this box, the drive will be mapped asynchronously (in english: whenever), which further cuts down on login time.
To sum things up: It’s really all up to You, the architect, the designer, the engineer, the admin. Take this example above on how a relatively simple configuration goal is set up on these two platforms. Don’t take my word for it, try things out yourself. If you’re trying to decide between Appsense and RES, just do the homework: Set up a lab with both products (or any other for that matter) and set your self some clearly definable results. Measure on how it was to configure. Now multiply that with 500 other settings that need to go into a production environment – does it look easy or not? Your gut feeling at this point is probably right…