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 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…