Time again to deal with dumb ass error messages that lead you down a rat hole to nowhereland. Google and Bing paved a wide path... to nowhereland. So, I have to figure this problem out on my own.
Problem 1. Someone send me a disk image as a VHD (hyper-V virtual disk file). Oh yay. What the hell am I supposed to to with that? Hyper-V 2.whatever on 2012 is screwing my clock up like mad on my VM. Realtime media does not like the clock jumping into the future every 15 seconds. So, I am forced to use VMware. Why did I digress? because I can't simply load this machine image in Hyper-V and run it. I need to burn it back to a physical drive. I was hoping for a Ghost image which is something I already deal with.
Solution 1. Actually, it was better than I hoped for. I did a little research on Microsoft site and found I could write a VHD file back to a physical machine. All I had to do was install the Windows Deployment Server (WDS) on my Windows 2012 server. As is typical with Microsoft, it is almost easy. It loosk east enough but you have to dig through a shitton of online documentation to figure it out; so I did.
So, I get WDS installed and add my install images (.vhd) files. Now all I need is the damn boot image. It takes a couple of hours of trial and error on every damn Microsoft server DVD I have only to just download an ISO and write it to a flash drive using the MS Windows 7 tool. Finally I can "create a boot image". I do this for both x86 and x64 just in case.
WDS allows me to create a bootable flash drive with the boot image. This worked quite well with no web mining needed.
Problem 2. Boot the physical computer on the flash drive. Client starts just fine. I had the foresight to connect the server to the same subnet as the WDS server. All I needed was a 30' CAT6 cable and $50 to go but a CAT6 cable. Sure CAT5E would do but why not spend 3X for Cat6 when you can. The client authenticates to the WDS server just fine. I see all the images I created. Going oddly well. Pick the 300GB image only to find there is not a volume with enough space.
Solution 2. The two 300GB disks are RAID1 mirrored. Reboot, hack my way through the Dell RAID controller until I have a spanned volume of 580GB. Reboot and boot from the flash drive again (Takes a friggin month for all these firmwares to initialize). Clinet authenticated, I pick my image, pick my volume and the vhd is cleanly written to the volume. All my worries about drivers and other HAL issues are moot. It actually worked rather well!
Problem 3. Now comes the real pain in my ass. I loosely document the process and hand it off to a peer to finish up the other 4 servers. Shortly thereafter comes problem 3 that plagued me 3 days. Every time we try to authenticate to server 2, a failure window with "Network
path was not found" as
the reason. I use Shift-F10 to get a command window and verify the network is OK, I can reach the server. I can use net use to map a drive. I can use wdsmcast and wdsclient to probe the WDS server.
Several reboots, several hacking the hardware, poke, prod, nothing. Scan the WDS server, logs are crap, events are crap, everything is fine but it doesn't work. Bing and Google fail me.
Solution 3. I get to thinking. "What if the developer is a douche purist"? You know these kind. They express their pompousness by pontificating the difference between a web site and a URL. Suppose his pompousness is suggesting that everything is a "Network" and all my rooting around on my 2012 server was a rat hole. I have established it is NOT a network or authentication problem.
Back to the command prompt (Shift-F10). Using diskpart.exe I examine the volumes. I observe what I expect. Disk volumes, partitions and disk drives. How is this different than before? My Ah Ha moment! Each of the machines we made work, we had to delete the volume in the RAID controller and create a new one. Hence one large drive and no partitions. Of course, this can't be that simple. the error message is "Network Path was not found". Ah. but it is. i assume the developer decided all devices are part of a network even though they are local devices or some crap like that.
So, my solution was... Delete the volume in diskpart (probably just the partition is all that was needed but go big or go home) reboot and the it works perfectly from there. It was the process of deleting the volume in the RAID controller and creating the bigger drive that ensured all partition and volume configuration was wiped.
come the command like I did the following:
select volume X
Leave it to me to write 1000 words when I could have done it in a couple tweets.
I ran into a a problem where the client boot only displays the X64 images. I needed to install a X86 Windows 2003 server image.
Turns out that the boot.wim I am using is X64 based so the client will only show X64 install images. I poked around the WDS 2012 server long enough to try right clicking the X86 boot image and creating a Discover Image. I created a new boot.wim and replaced the boot.wim on my bootable flash drive.
Sure enough it boots to the X86 image.
Note: Make sure your hard disk is the first drive in the BIOS boot order.
Also Note: Drive cannot be partitioned or formatted. The WDS client will fail with the stupid Network Part not found error when it really means it needs a raw, partitions disk. Dumbass engineers and unhelpful error messages and not allowing me to delete the partitions from the client.
It got worse, not better. WDS Discover client basically copied the VHD to the server and did not expand the files. It turned out to be an extremely poor choice to image and restore a system. Norton Ghost, with all it's challenges, would have been the much better choice.
Eventually, I mounted the VHD as a drive on the WDS server, booted the client computer to command line (using a bootable flash drive with the Win2K8 install on it) and mapped a drive to the shared Drive/Mounted VHD on the WDS server. I then used xcopy to copy all the files. This takes forever but mostly worked. We had some issues with the recovery partition being assigned drive C: screwing up windows for a bit but the was quickly solved (reassigning drive letters).
X64 seemed to worked quite well, but stay away from x86 systems!
Post a Comment