The article describes how you can tweak the security modules of Workspace Manager to help you gain better control over your windows environment, specifically the Windows Desktop folder. One of the key things that admins have been struggling with over the years is how to control that damned explorer desktop! Given the opportunity the users will store everything they can on the desktop, hence making your life as an admin even more miserable :)
A few notes before we begin:
- Working knowledge of Workspace Manager is required.
- If you want the fast track without the flowery screenshots, scroll down to the bottom of this article.
- The described scenario only works with the Windows Shell in Workspace Manager, so you cannot do this with the oldschool PowerMenu desktop.
The most often applied solution in the field to the described problem above, is redirecting shell folders via registry or policies, redirecting the desktop folder to the users homedrive. This is all and well, perhaps except for the fact that network traffic is generated every time any data is placed here. Redirection works great – especially if we could minimize the amount of data which is affected. This is what we’re going to look at here.
You can also completely restrict users from placing anything on the desktop. While this may work well in a Server Based Computing environment, your laptop and workstation users are likely to slap you silly in the hallway if you impose this kind of restriction on their computers. If you want to go this route, you can opt to use the built-in Workspace Manager shell and forget about this article.
A third and perhaps better alternative is using a nifty combination of Workspace Manager File and Folder security combined with some smart authorizations, to allow them to drag shortcuts to everything out onto the desktop. Net result? The users can have shortcuts to anything they want, and you do not have to worry about huge desktop folders.
This has the added bonus that the shortcuts in the user’s homedirectory folder can be quickly sync’ed to a laptop using the built in File Synchronization feature of Workspace Manager 2010 and up. So, let’s have a look at how we put this together:
1) Set up an environment variable to determine the homedirectory.
(Note: You can click all shrinked screenshots in this post to see their original size)
The variable above is strictly not necessary to create. Do it anyway, as it makes things nice and dynamic. Go to Configuration Management | PowerLaunch | Environment Variables:
2) Set up the desktop blocking rule.
Now we need to configure the rule for File and Folder security which will block everything. The trick is obviously later to authorize the right stuff, but for now go to Security Management | Files and Folders and enable it.
Consider if you want to have logging enabled – if you are in a large production environent, plenty of users might try dropping data on their desktops – you probably don’t care about that, as Workspace Manager will keep things under control.
Also, it might be a good idea to notify the users. Checking the “Notify user about security events” will give them a nice “Sorry Dave, you can’t do that” kind of message. The rule which is displayed in the listbox, denoted with a shield icon, is configured by hitting the Add button.
You might note that the path refers to the homedrive and might ask; “Hey, I thought you wanted to avoid redirecting?” – Nope, not neccessarily. In this example we’ll just augment the redirection with some security. Second, if you want to use Read-Only Blanketing, you actually will need to redirect the desktop, as enabeling Read-Only Blanketing will override File and Folder security on specific folders, namely the desktop folder as it’s part of the user’s profile. Note it is important to add the * after the desktop folder.
3) Set up the proper authorizations
Go to Security | Global Authorized files. Add the followwing 5 rules. Please make sure to match the exact Authorized operations, using the proper checkboxes when defining the rule.
The rule for ‘new shortcut’ is to allow the user to invoke the shortcut wizzard (rightclick desktop, new, shortcut). Note that .URL files also are allowed, which means the user is allowed to drag-n-drop a website shortcut directly out from the browser of your choice. Explorer.exe and Rundll32.exe both needs read access to the desktop folder, if not things go haywire. Nuff said.
UPDATE: In Vista and newer operating systems, you have other processes that read the desktop. Since this is no big issue, replace the two last rules in the screenshot above with one that allows * to read %reshomedrive%\windows\desktop\* instead.
4) Redirect the desktop using Workspace Manager
If you are using Read-Only Blanketing in Workspace Manager, it is necessary to redirect the desktop folder away from the default location in the user’s profile. The reason for this is that the Read-Only blanketing security subsystem pre-authorizes certain paths in order to ensure maximum compatibility. One of these paths is %userprofile%. The problem with that is that a) the path is hardcoded into Workspace Manager and b) it takes precedence over the File & Folder Security subsystem.
Create a new global registry setting, by going to Composition| Other | User Registry. Use the Add Registry button to create a new reghack. Inside the Workspace Manager registry buffer, select Registry | Import from the menu. Save reghack below to a .reg file and import it into Workspace Manager. Don’t worry about all them spooky Hex numbers. It will look just fine when imported with comments and all. If you don’t like the paths, edit them accordingly.
Warning: If you are running in an environment where users will hop between sessions running Windows XP and Vista/Win7, you need to be aware of a caveat: When you redirect the desktop shellfolder to the home directory, you will effectively have both operating systems looking into the same folder at the same time. Vista, Win7 and Server 2008 use high-quality icons, while XP and Server 2003 cannot. As Workspace Manager renders the workspace in accordance with the local desktop, you will have a situation where icons on the desktop may change. This will likely happen if you first log on to a xp box and thereafter log on to a win7. This can potentially be avoided by making a sub-desktop folder per operating system, but then things start to get complicated, and any shortcuts you created on one OS won’t be shared with the other. For the remainder of this article I’ll be sharing the desktop and ignoring the icon problem as it’s going to disappear with XP.
5) Making sure the right folders exist in the users homedirectory
This last part is to make sure everything fits together. As both the security rules and the registry settings refer to the %reshomedrive%windowsdesktop, it’s important that this folder exists. You can make sure this is the case by using Workspace Manager directory maintainance. Here we can setup the file and directory structures we want the user to have in their home directory. Workspace Manager can do tonnes of other stuff here, including changing contens of ini files, datestamping files, etc. For now we will just use Workspace Manager to create the necessary folder structures. Go to Configuration Management | PowerLaunch | Directory Maintainance | Home Directory | Maintainance.
In directory maintainance, create the folder structures you want using the New Folder button. These folders will be created automagically by Workspace Manager the next time you log in, unless you have modified the settings in Home Directory Maintainance | Home Directory | Settings.
6) Add registry setting to compensate for explorer file extension problem
This step is the updated part which was omitted previously. The buildingblock has been updated accordingly. If you have already imported the buildingblock in it’s former version, you can download the registry file to import into Workspace Manager below. So what’s this step all about? Well, when redirecting the Explorer desktop to another folder, you may experience getting a security warning when clicking on the shortcuts on the desktop, even though they have been generated by Workspace Manager. This is fortunatly easy to circumvent by allowing .URL and .LNK as trusted file extensions. Normally one would probably frown on such, however when running things inside the Workspace Manager environment, we don’t have to worry about it, as we got 5 layers of security to ward off any foreign code sneaking in anyway.
To make a long story short, download the missing reghack here: (file is renamed to .re_g) There, that’s it! – A really cool and slick way for Workspace Manager admins to managing what the users can do on their windows desktop.
Okay, as promised there is also a really super quick way of doing all this. RES Buildingblocks! If you’re not familiar with these, this is the time! Both Workspace Manager and Wisdom offers a really cool way of exporting settings from one environment to another.
Before you download any building block, two words of warning:
- ALWAYS test foreign (i.e. not made by yourself) buildingblocks. Build an empty Workspace Manager database and import things there and test them out.
- NEVER import unknown buildingblocks into a production environment.
Unpack it somewhere where you have a Workspace Manager console running. Go to the File | Import menu. It will show a dialog box like this one:
Hit OK and all the stuff above will be imported into the database. Have fun – Post a comment if you have questions.