I worked with a customer recently where they wanted their users to receive nothing but their application shortcuts on their published desktops, and for them also to be prevented from creating or removing anything. Historically, this antipathy towards customization of the desktop had started when users began to copy huge files and folders to their desktops and bloated their roaming profiles, and only got worse when users began to use desktop folders as storage areas instead of network drives, and as a result some high-profile loss of documents had occurred. I tried to convince them that allowing users to create shortcuts and other items on their desktops might be a good idea – after all, in these days of shared storage and super-fast network connections, desktops (redirected or local) shouldn’t suffer from slow loading at all – and they just needed to educate their user base in the creation of shortcuts to folders rather than folders themselves. But they were dead set against it; when a user logged in, they wanted the relevant application shortcuts deployed based on AD group membership, and nothing was to be customized at all.
OK, so that’s what they want, that’s what they get! The question of how to do it was next raised. We had been deploying shortcuts for this client through Environment Manager onto mandatory profiles, so the first solution mooted was to let the shortcut creation run, and then lock down the NTFS permissions on the user’s Desktop folder using a script. This, while appearing effective in testing, just didn’t sit right with me. With 1200 users logging in and creating Desktop folders in their profiles, only to then lock each and every one of these folders into Read-Only mode – it seemed like a waste of time and disk space. Granted, their shortcuts would be unique, but everything else would be identical. The idea seemed to be nothing but an unnecessary use of resource.
 |
| Screenshot showing how we originally tried to do this. Note on the left that the node calling the script is nested inside the node creating the shortcuts, which contained a condition and action for every application. Nesting the nodes ensures that the shortcut creation node finishes before the Desktop folder gets locked. The script locking it was actually done in batch using cacls.exe, but could be done in any number of ways. |
So I tried to think of a way to do this a bit more elegantly. I thought about Folder Redirection. And then I thought about applying NTFS permissions to redirected folders. And then I realized it was dead easy – just redirect all the users to the same Desktop folder, and lock the shortcuts, not just the folder, using individual NTFS permissions for every file.
First of all we did the horrible bit – creating a shared folder on the network called SharedDesktop, and creating a shortcut in here for every application the client used (about 130, as I remember). Then we went through and changed the permissions on every shortcut so that only the application group had Read access to it. The permissions on the SharedDesktop folder looked like this, Administrators:F and Users:RX
And the permissions on each shortcut item in the folder looked something like this, Administrators:F and Application Group:RX
Now with that soul-destroying task out of the way, we simply had to configure a quick Folder Redirection action in Environment Manager using Action | File and Folder | Folder Redirection. If you’re not an AppSense user, you can easily do this with Group Policy Objects. Just remember to Security Filter the GPO by a group, otherwise everyone who logs on to the server will get the same redirected desktop settings (including Administrators).
And once we had this in place, we’d replaced two nodes which contained a total of 131 Conditions and 131 dependent Actions with one node that contains just one condition and one dependent action – with exactly the same results!
When the users started to log on to test, it all worked exactly as the client wanted – application shortcuts deployed dependent on AD group, desktops fully locked into Read-Only mode, and as an added bonus, a very snappy logon time. The idea that they’d get only the shortcuts that their user accounts had the NTFS permissions to see worked flawlessly. The only reservation I had about it was that it was slightly non-standard, so we made sure we put a very detailed comment into the Description field of the Folder Redirection action. But it just goes to show that there’s often a much slicker and easier way to get environments configured the way people want them, if you just take a few minutes to give it a bit of thought.
Update – as mentioned in the comments section, it may be worth mentioning that Access-Based Enumeration needs enabling for this to work correctly. In later versions of Windows it should be enabled automatically if I remember correctly – but if you’ve still got file servers on Windows 2003, you may need to enable this on the share you’re using to host the shortcuts.
Share
