This weekend, I was fooling around with my Windows Home Server machine (a very nice HP EX475 MediaSmart Server) and found myself forced to repeatedly reinstall the Windows Home Connector software on one of my client machines. As I would learn from HP Tech Support, I was as much a victim of my own stupidity or lack of careful consideration of my install environment–I’ll tell you what happened to me in a minute, and you can make that call–as I was a victim of limitations in the software itself.
But during my troubles with the WHS connector, I downloaded and read Microsoft’s Troubleshooting WHS Connector Installation document and also grabbed its Windows Home Server Toolkit at the same time (note: this link points to the 32-bit version; a separate download is available for the 64-bit version). The only error this collection of tools and information couldn’t address was a claim of a version mismatch between my client machine and the WHS box itself; because the client actually copies that software from the server, I was mystified as to how this could be the case.
As it turns out, my client is running AVG AntiVirus 8.0 Free edition, and there’s something about this software that prevents the WHS connector from running properly on that machine and talking to the WHS box itself. I could remote desktop to the WHS server from the client, but the connector would hang as soon as it got past the login screen where I provided the administrative password that normally gives me access to the WHS console. As it turns out, something about AVG blocks IP name resolution for the server, because once the HP guy helped me pinpoint the package as the source of trouble–I disabled it, and presto! the console login completed without a hitch–a little further research showed me that adding a line into the hosts file to equate the server name with its IP address would fix the problem. And sure enough, with AVG re-enabled and the host patch in place, everything is now working as it should be.
I hope you’re asking yourself by now: what the heck does this have to do with the WinPE Boot UFD in the title of this blog? As it turns out, the help instructions for cleaning up the mismatch error that the connector troubleshooter was reporting for my notebook PC includes these instructions “On your home computer, delete the %ProgramFiles%\Windows Home Server folder if it exists. Well, it existed all right, but when I tried to delete the directory or its contents, even when using “run as Administrator,” those files stubbornly resisted deletion.
WinPE Boot UFD to the test, and ultimately, to the rescue! First, I had to change the boot device order on my notebook to hit “USB Storage Device” first. With that handled, the laptop opened a standard black-and-white progress bar at the bottom of the display, and indicated “Windows is loading files. . .”. After a wait of about a minue, a standard “copyright Microsoft” light green progress bar flashed up for about 15 seconds, followed by a command window labeled Administrator: X:\Windows\system32\cmd.exe. To delete my resistant files I typed the following commands:
c: :: change to C:\ drive cd "C:\Program Files\Windows Home Server\" :: change to WHS directory del *.* :: delete all files cd .. :: move up one directory level del "Windows Home Server" :: delete WHS directory exit :: Close WinPE (reboots system)
Everything worked like a charm and when I went back to check to the drive with Vista rebooted, sure enough those files and the directory were gone. I’ve blogged earlier about using the Linux-based TRK environment to solve this same kind of problem; it looks like this is the right Windows tool to address the same difficulty without having to venture beyond the Windows umbrella.
I’ll be working with the WinPE Boot UFD every chance I get, and keep reporting back here. If you know of any other good uses, or have an interesting and related story to tell, post a comment and I’ll put in the hopper for future coverage and inclusion, too.