Where'd that desktop icon go?

There's a few things going on behind the scenes when I virtualize someone's desktop. I make a few changes to their user setup to better accomodate the virtualization--I make sure that roaming profiles is turned on, and I redirect the Desktop, Application Data, and My Documents folders to the user's home share, rather than to their profile.

I've done this before, though, so when I noticed lately that I could create an icon or a file somewhere in these folders and it *didn't* show up, something seemed strange. Turns out it's the fact that I'm also putting these onto a DFS share that's causing the issue.

But, just like I said in my last post, someone else has run into this before; in fact, Microsoft has it documented already:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;823291

That doesn't help, though, once the user's roaming profile has been turned on (unless I want to go to each user and make that registry change--yikes!). So someone else was kind enough to post a Group Policy adm file for making the change to all users.

http://http://www.eggheadcafe.com/software/aspnet/30059864/explorer-folder-is-not-re.aspx

Followthrough, followthrough, followthrough

I love it when people actually finish a discussion. I'm firmly convinced that I will never run into a problem that no one else has ever seen. My Googling supports this notion--I can't think of an error message or strange situation I've seen on a computer that hasn't resulted in links to other people asking about the same problem.

I'm also convinced that I'll never run into a problem that hasn't already been solved by somebody...but this is where it gets trickier. It seems that most people never return to where they sought help and say what solved the problem. It's annoying--you know they probably fixed it...but they don't think to share how.

I have been annoyed lately by Word asking me to save changes to the underlying template of every document I open. And I found a discussion (the link goes to one of those newsgroup archiving sites that litters everything with ads) where someone had the same issue. I got to the bottom of page 2 and started to feel dejected--was it going to happen again?

This time, No! Not only did the last page contain a suggestion that wound up solving the problem, but it solved my issue as well (in this case, the Microsoft Office Live addin was dorking things up--it's uninstalled now). Thank you mysterious person on the Internet for actually keeping everyone in the loop!

And this week's Dummy of the Week award goes to...

I thought that I had something wrong with either my file server, the SAN, or my VDI implementation--things usually seem to run just fine, but I did some file copies to my My Documents folder today and they took forever.

Turns out I had AD setup wrong and DFS was connecting me to a file server across the WAN (connected at 3mb). Wow, this is so much faster now...

Turn an existing Windows XP system into a VMWare View Terminal, Addendum: What I might do different

I've been playing with this setup all week, and I had a couple of ideas that I've wound up using. I wanted to keep the instructions to the "base" setup, though, so I'll list here the things that I've changed.

1. Keep the Roaming Profile from going back to the server
I actually thought of this while I was typing up step 3, but I didn't want to go back and edit step 2. Anyway, what happens if someone, somehow changes the setup for your limited access user? Unless you lock things down quite a bit, they can start up task manager and get into Regedit--or they could get a lot of data into the profile and make it too large to download over a WAN connection.

To keep my limited access user profile "clean", I first made a backup of it (duh). Then I went back into the GPO for the Terminals OU and set Administrative Templates\System\User Profiles\Prevent Roaming Profile changes from propogating to the server to Enabled. This means that any changes made to this profile from a system in the Terminals OU will not be saved. I can still log into that user from another system outside of this OU and make changes if necessary.

There is also a policy for deleting the local copy of a profile when that user logs off--if all of your systems are local, this would probably work. If you have laptops that you'll do this with, though, I wouldn't turn on that specific setting.

2. Maybe Explorer as a Shell isn't so bad?
I know, this seems to contradict the entire point of this series of posts--but stick with me. Again, if your computers are all on the LAN/WAN, this probably doesn't matter. But if you've got a laptop you want to setup in this way, it'll be useless--the View client can work through an SSH tunnel (if you've configured the server to support it), but the user won't have access to the Wireless configuration to connect to any public hotspots.

What I have decided to do is switch back to using Explorer.exe as the shell (just remove the Shell line you put into the user profile in Step 3, so it defaults back to the default system shell), setup my .vbs file from Step 2 in the Startup group in the Program menu for the limited access user, and then modify the heck out of the Start menu and Taskbar configuration. I removed everything from the desktop, everything but Interet Explorer from the Start Menu (and you could remove that as well) and set the Taskbar to auto-hide.

The change is small, but it opens a world of possibilities. You can now access the stuff in the system tray, including Wireless. Any system tray apps that might enable touchpad scrolling or volume controls now work as well. The user can fire up Internet Explorer--yeah, it means they can surf locally, but since many public WiFi hotspots require you to go into a browser and agree to certain terms of service (or put in a password), a browser is pretty much a necessity.

The other thing this does is makes the View client accessible if the user clicks the Minimize button on the shadow bar--without Explorer running, you've got to Alt-Tab to get back after minimizing.

3. Building new bare images
We use Windows Deployment Services to push desktop images to systems when I build them. One of my goals is to be able to build View terminals using this as well--maybe even getting the images small enough that I can rebuild a system over the WAN.

I always pre-stage my computer accounts in the directory, so that they get the appropriate GP stuff right away. This has been hit-or-miss for View terminals; either the settings won't show up until I do a gpupdate/force, or they show up right away and prevents the scripting from running that the Deployment Toolkit uses to build the system.

The best solution so far has been for me to pre-stage the computer account in a different OU (or let it create the computer account in the Computers OU). When the Deployment scripts are finished, I move the computer account into the Terminals OU, run gpupdate /force on the workstation, and reboot it.

Turn an existing Windows XP system into a VMWare View Terminal, part 4: Enabling AutoAdminLogon

At this point, you've got your limited access user, your OU in the directory where all of the computer accounts for your "Terminals" will be located, and some GP settings on that OU to make the machines administerable. Now we need to return to that GPO and configure systems in that OU to log in automatically as our limited access user.

Rather than repost everything, I used the ADM file from here. If you're not familiar with using ADM files, the link contains some help--if you're still not sure after that, then this topic might be over your head.

I'm not a fan of using the ForceAutoLogon setting (I left it at 0); if this is turned on, the system will auto-logon any time a logon screen comes up. With it off, you can press Ctrl-Alt-Del and log off the system, and then manually log in as a different user if the need comes up. Enabling AutoAdminLogon will log the system on as the specified user when it's first turned on, but that's it (until it's rebooted).

Add this ADM file to your GPO (make sure you follow the instructions for changing the filter) and put in the appropriate settings.

At this point, all that *should* be required is putting the client computer into this OU, and rebooting the system. I've had spotty luck with that--your odds are much better if you can have just about anybody (an ordinary user should work; an Admin should work better) run "gpupdate /force" to get the machine to pick up the new GPO settings.

When the system boots, it will install the VMWare View client (with our custom settings from step 1), and then automatically log in as the limited access user. This will force the system to download the roaming profile and then startup the View client as the default shell. When the user exits the View client, they get asked if they want to shut down the computer--if they don't, the View client starts again. All things considered, a pretty self contained system.

I'm going to post an "Addendum" style post to discuss some of the caveats and things that I've changed since I did this the first time.

Turn an existing Windows XP system into a VMWare View Terminal, part 3: Building the limited user profile

Now, I'll be the first to admit that you can do everything below in group policy (with the proper .adm files). And I might wind up doing that in the end. But setting everything up in a roaming profile is a little more straight forward, at least for now.

You've already setup your limited access user (I called mine "svcsusr", and I'll use that name below). Go back into that user ID setup and configure its "Profile Path" property to point to an appropriate network location. Then, on a machine with the View client installed (and preferably nothing else--it'll keep the profile to a minimum size), log in as svcsusr. Don't do this on a machine setup in the OU from Part 2--the roaming profile changes won't get sent back to the server from those machines.

We need to change a few registry settings on this user. We'll change the default shell from Explorer to the View client. We'll also disable the user's ability to lock the system. Why do that? If our end user locks the system using Windows Key+L, it'll lock both the virtual desktop *and* the local desktop. Since the local desktop is logged in as svcsusr, the end user will have to have the password for svcsusr to unlock it (not to mention it's just annoying). If we prohibit svcsusr's ability to lock the workstation, only the virtual desktop will be locked.

Open regedit and go to HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System. We're going to modify the "DisableLockWorkstation" value--you'll most likely have to create it (create it as a DWORD Value). Set it to 1 to keep svcsusr from locking the workstation.

Then, go to HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. Create a new String Value in here called "Shell". The default Shell on the system is explorer.exe, and it's defined in HKLM--if the user doesn't have a customized Shell value, it runs the HKLM shell. We're going to give svcsusr a customized shell. But we haven't created it yet...

There's two options here. First option is to just put the path to the View client executable in here. This will work--but when the user shuts down the View client, the system will just sit there with no interface until someone hits the power button. I started off using the instructions here, which just restarts the View client over and over again. I decided that I wanted something a little more fully featured.

Create a new folder in the "Application Data" folder of your user (for mine, c:\documents and settings\svcsusr\application data\) and call it "Scripts". Then create a new file in this Scripts folder called viewshell.vbs. Open it in Notepad and put in the following:

dim wshshell
dim shutdowncmd

set wshshell = createobject("wscript.shell")

do
wshshell.run chr(34) & "c:\program files\vmware\"_
& "vmware view\client\bin\wswc.exe"_
& chr(34), 0, true

shutdowncmd = msgbox("You appear to have shut down the Virtual Desktop Client"_
& " Do you wish to shut down the computer?", vbyesno, "Shutdown")

loop until shutdowncmd <> 7

wshshell.run "shutdown.exe -s -f -t 05", 0, 0

We could probably do this as a batch file as well, but I liked the VBScript approach from the VMWare blog post, so I stuck with it. Now, we put this into Application Data because that is part of the user profile that will roam around to all machines. Since the actual profile location may vary by system, set the Shell value we created above to be

wscript "%userprofile%\application data\scripts\viewshell.vbs"

Just to make sure that the script works, run that command from a command line as well (just don't shut down when you exit the View client).

Go ahead and log off--your profile will be saved to the network and used anywhere that svcsusr logs on in the future. The next post will be about forcing our "thin client" systems to log in using this ID.

Turn an existing Windows XP system into a VMWare View Terminal, part 2: Push the View Client MSI

Today I'm beginning to setup the Group Policy side of things. Your OU structure may differ, but in mine, I have an OU that will contain only workstations that will get "Thin Client"-ized. There's a couple of settings that will help us push out this to any workstations in the OU.

If you haven't already, go ahead and create the user that will ultimately be the your "limited access" user that automatically logs in to these workstations. We'll do some configuration in the next step, but the user needs to exist for the group policy settings below.

If you're using a new OU (I'd recommend it), you'll need to create a new GP Object and link it to your OU. This is easiest in Group Policy Management (available for download from Microsoft). Right click the OU and click "Create and Link new GPO Here". Give it a good name--remember that GP objects are linked at the OU level, but they all exist in a flat structure in the Directory.

Right click on your new GPO and click Edit. Then go into Computer Configuration/Software Settings and add a new package. Browse for the MSI you created in step 1. Select "Advanced" as the deployment method and click OK. On the package properties window, go to Deployment and check "Install this application at Logon" (if this is greyed out, click on "Assigned" even though it's already selected--it'll ungrey the option). Then click OK.

Here are the other settings that we need to change:
Computer Configuration\Security Settings\Local Policies\User Rights Assignment
Add your limited access user to these rights: Load and Unload Device Drivers, Shut down the system. You'll probably also want to add your Domain Admins group as well, otherwise your limited access user may be the only one who can shut these computers down. (Note: The Device Drivers item isn't related to Shutdown, and might not be necessary at all--I am using it just in case it's needed later for the USB passthrough.

Administrative Templates\Network\Network Connections
Enable the "Prohibit use of Internet Connection Firewall on your DNS domain network" policy.

We'll be back in this policy in the next step to setup the Automatic Logon for computers in this OU.

Turn an existing Windows XP system into a VMWare View Terminal, part 1: Modify the View Client MSI

I'll say this up front--there are probably better ways to do this. I know that a transform could be created and applied, but I chose to cheat and just modify the MSI directly.

Before we can modify the View installer package (.msi file), you first need to download ORCA. There doesn't seem to be a direct link view Microsoft.com, but if you Google "Download ORCA" you should be able to trust the first link returned. It's a very basic installation.

Then, you need to get the MSI. Again, there are probably more efficient ways to do this, but my preferred method is to run the setup executable, and then go to the Temp folder and look at the most recently created folder--it should contain "VMWare View Client.msi" as well as some additional files. Grab everything.

Now open the VMWare View Client.msi file in ORCA. First thing to do is FileSave As and create a new MSI with a new name--don't screw up the original. Then I'm going to hit the individual tables in order that they appear.

Condition table: If the Single Signon feature gets installed, it's going to want to sign into View using your limited access generic ID that we'll address in step 3. That's bad--so let's just make that feature unavailable. The first way I found to do this is to make the feature dependent on 64bit Windows (we're using only 32bit XP). Change the "Condition" item for the "TSSO" feature to "VersionNT64" to do this. (Another option might be to change the "LOGIN_SSO_DEFAULT" and "LOGIN_SSO_DISPLAY" values in the Checkbox table to 0--I haven't tried this.)

Property Table: The VDM_SERVER property contains the default value for the View Server that is filled in by default. If we don't plug this in, the user's won't be able to connect (because they'll never remember the server name). You'll most likely need to add this property (Tables menu, Add Row). Enter VDM_SERVER in the Property column, and the DNS name or IP address of your View server as the value. From this table you can also change the defaults for the Desktop, Start Menu, and Quicklaunch icons...but since there will ultimately be no shell, I figured those didn't matter much.

Go ahead and save your MSI, and put the entire group of files into a network location that all users will have access to. We'll actually push it to the workstation in another step.

Turn an existing Windows XP system into a VMWare View only terminal...using nothing but Group Policy

I'm going to break this post into a few parts, and if my previous blogging experience is any indication, I'll finish it in 9 years when we've all got WiFi directly to our brains and none of it will matter.

We're giving a serious look to VDI (Virtual Desktop Infrastructure). In keeping with my minimalist workstation management goals, I want to essentially make the local workstations nothing but a thin client, with nothing to manage. Once the workstation is doing nothing but running the View client (as a non-admin user), it becomes pretty much irrelevant what patches, updates, or anything else are installed on it.

This gets broken down into 4 different steps:

1. Modify the VMWare View Client installer MSI to contain your default settings (for us, disable the single signon feature and plug in the default View server).
2. Push this modified MSI out to applicable workstations via Group Policy
3. Build a limited access user with a roaming user profile. This profile will have the View client set as the default Shell (replacing explorer.exe), so nothing else can be run.
4. Enable AutoAdminLogon on the applicable workstations (again, via group policy) to force workstations to log in as this limited access user.

Step 1 is a pain...but I'll provide the detail you need in the post on the topic. Step 3 could actually be done via group policy as well, but I found it easier to just build the roaming profile.