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.

Embedding Video for a Sharepoint List Item into Dispform.aspx

So, you want some details? First, here's what we're looking to create. It's a modified version of dispform.aspx. The list item actually has about a dozen fields, but the only ones I'm interested in displaying are the four you see at the top, as well as displaying the related video.

To start, I created a new form and applied the dispform formatting to it--don't just modify the existing dispform.aspx, or you're asking for trouble. There's plenty of resources telling you how to do this; just google sharepoint designer new dispform.

If you're familiar with the way dispform.aspx works, you might notice something strange about my page design. If you're not, here's the simple version; the fields at the top of the window and the "Created" and "Last Modified" fields at the bottom (as well as both "Close" buttons" are actually all part of one data view. I wanted to throw my custom content right in the middle, but I don't know how to (or even if you can) break that view up.

So, I did the next best thing. First, I put in a single row, two column table at the very bottom of the page. This was easiest to do in Code view, by just typing the table code in between the "" tag and the tag. For my purposes, I made the table width 100%, and the width of the first column 60% (but your formatting may demand something else--or maybe even more or fewer columns; you'll see why below). Then, I copied the entire WebPartPages:DataFormWebPart tag (basically 99% of the file) to the clipboard, and pasted it *after* my new table, but before the final tag. So, I just duplicated my Data View of the list item.

Now, if you switch back to Design view, you'll see the list item duplicated (along with Close buttons, created and modified information, etc) with a small table in between. But we're not done with the duplication yet. If you save the file and attempt to browse to it on your Sharepoint site, it'll blow up. Each item on a page requires a unique GUID, and while Sharepoint Designer will render the content, Sharepoint cannot.

So, we need a new GUID. Again, there's plenty of online tools to generate them for you. Find the "id" parameter in your second (pasted) WebPartPages:DataFormWebPart tag (the value starts with "g_"), and put your new GUID in that field. Note how it needs to be formatted, with a leading g_ and the dashes replaced by underscores. Then about two lines below that for "SharePoint:SPDataSource" and change it's id (this one isn't a guid; it's just text) by adding a "1" and the end of it.

Now we need to get rid of some of the duplicate data. Since I didn't want to display any of the field values in the bottom "copy", I just selected the table that all of the values were in and deleted it. You may want to just hide it instead, which is what I did with everything else I didn't want to show up.

To hide something on the page (make it so Sharepoint doesn't render it in the browser), you either set it to Visible=False (for those tags that support it), or you change it's style. Most everything here is in a table, so the style method is easiest. To hide a certain field from displaying, select the row it's in (don't forget about the tag chain above your page in Sharepoint Designer--just select your field and use the chain to work your way up to selecting the row), and change it's style property to "display=none". Just do this for everything you don't want to display (or display twice).

At this point, we haven't even touched video, but we're ready. My page required the video and "related links" be inserted. The related links (named "External Resources" on the example above) is a simple data view web part. In fact, the video is a data view web part as well. I brought up the Web Parts task pane and inserted new web part zones into each of the cells of the table I created at the beginning of this post. I created my data view web part for the links following the instructions in the link I posted yesterday. I just stopped after creating the filter, because I wanted this one to be a data table.

I created another data view web part in the other web part zone, again, following the same instructions. But this time I needed the XSL for changing it from an HTML table to an embedded video player. Getting the XSL to work was difficult, to say the least, and since this is getting SOOO long, I'm going to explain why in my next post. Instead of explaining the XSL here, I'm just going to give it to you straight up. The only thing that should be in any way custom to this is the field I store the Video URL in; the video URL is stored in a column called (ironically) "Video URL". This URL can be any valid URL that points to a Windows Media file. Changing it to support Youtube would be pretty straight forward, and I'll talk more on that later. But for now, here's the XSL file--just copy it and paste it into a new file in your Sharepoint site, and follow Greg Chan's instructions on pointing your data view to it. With this you don't need to worry about anything that he says in regards to modifying the XSL for the data view part--basically just create the data view so that it returns the record (in a table) that you want, and then change it's XSL template in it's properties.

(I'm having trouble getting the XSL file to upload; I'll include it in the next post)

Why is my programming starting to look like a card from Grandma?

I've typed so many X's and O's in the past day my eyeballs are swimming. I'll post more about it later. It seems like I'm spending most of my time now pretending to understand x?l. I miss the days of

10 Print "Hello, World"
20 Goto 10

Short version is that I've finally got my weekly topics for the 2009 Organizational Push working. Since it doesn't look like my employer will really be able to make money this year, we're going to try to get everyone a little more organized. Every week I'll be publishing a new "topic", which will really just be little more than some tips and (usually) a brief video about a certain way of getting more organized. "Bite Sized Information" has been my motto the past two months.

All of this stuff will be published with Sharepoint. I've got a pretty standard List that will contain an entry for each topic; I really didn't want to create a new web part page for each item to display related links and the embedded video, though. But I've had a heck of a time figuring out how to modify dispform.aspx to include custom content. I got part way a while ago, figuring out how to modify the form (or modify a copy--I'm too smart to modify the original...well, I am now :) ) to include a web part zone. With that I can do a data view web part to display related links and other list items.

The tough part was the video--I wanted to embed it, while still having the embedded player load the video from the "Video URL" column of the particular list item. After spending about 6 hours pouring over a related Sharepoint Developer Blog Entry by Greg Chan, I figured it out. I can now embed a player and have it use the video file referenced in the list item. That means I can just format one page, rather than 48.

Next post I'll share how it works. It'll be a biggy.