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.