Workarounds For When “Add Virtual Hard Disk Wizard” Fails (Which Seems To Be All The Time…)

Adding new fixed sized VHDs using the Add Virtual Hard Disk Wizard in the Hyper-V console for some reason has stopped working for me on just about all my installs, with no errors logged. The VHD is created, but the progress slider bar never progresses and it will sit there, forever. It’s got to the point where I don’t use it and haven’t the time to debug the underlying cause.

A GUI-friendly way to work around this problem is to point Computer Management at the Hyper-V host and use Disk Management to Create the VHD.

Another way of doing this quickly is by using VHD Tool – although this doesn’t zero out the VHD and can leak information from the Hyper-V host and previous virtual machine’s disks into the newly created VHD. It is a great tool for lab work though.

Diskpart can also be used to create the VHD from the command line on the Hyper-V host. The command to do this is:

create vdisk file=”d:\path\to\file.vhd” maximum=<size in MB> type=fixed

UPDATE: So apparently I'm getting this error on networks where the domain controllers are still running Windows Server 2003 and an authoritative restore of Active Directory has been performed. The fix for this is to install MSKB 939820 on all the Windows Server 2003-based domain controllers in the affected domain. Interestingly I only found this trying to resolve a System Center Essentials 2010 installation.

Cannot Install RSAT on Windows 7 with SP1

If you try and install Remote Server Administration Tools for Windows 7 on a Windows 7 PC with SP1 installed, you’ll get the following error: "The update is not applicable to your computer."

Either install RSAT prior to installing SP1 or wait until Remote Server Administration Tools for Windows 7 with SP1 is released in Spring 2011 (March-May for those of us who are Northern Hemisphere challenged).

Internet Explorer 8 Beta 1's Not Much Better

OK, try the same thing with IE8 Beta 1. This time I only opened 4 tabs, then closed them down.

Task Manager:

 

Same thing with Firefox 2.0, after loading exactly the same pages and closing them in exactly the same order:

Task Manager:

Yeah, I know, not scientific. But I'd like my RAM back. Especially considering it's running on Vista.

As an aside, the time between closing the "empty" IE7 window last night and the iexplore.exe process finally exiting was ~30min. And before anyone asks the Temporary Internet Files folder was not set to be emptied on exit.

Must get another 2GB of RAM for my laptop. Plus a faster hard drive.

Which begs the question - when are we going to start seeing >4GB laptops? And >8GB non-server motherboards? Because it's clear to me that the big software developers of this world are living in fantasy land and are far more concerned about their profits, time to market and the cost of developers (probably in that order too) rather than what the user actually wants.

The memory bloat is everywhere - office apps, PDF viewers, anti-malware, OSes...

I think for all the waiting I've done for bloatware this year I could have spent the time finding the extra 1KB I need for my BBC B to display a decent windowing system :-)

I think I'll just go back to my book. Hey, when did Sci-Fan get so big? 500+ pages, trilogies that run to 10+ books...... <sound of rant fading into the lounge>

I'm reading The Wheel of Time by Robert Jordan - up to book 9. I really, really need an upside to something right now...

Internet Explorer 7 - Poor Memory Management

OK, I've had an IE window open for about a week now. I've closed down the 50-odd tabs I had open (would have had another 200-odd tabs open during that time though not concurrently), leaving it with an empty tab:

What does Task Manager think about it?

Hmm... My Firefox 2.0 footprint was smaller than that...

IE8 Beta might be getting an install shortly...

SBS2003 Remote Web Workplace, Console Access and That Awful /admin Change

OK, those of us that have worked with SBS2003 for quite some time tend to put Remote Web Workplace (RWW) right up there on our list of favourite SBS features.
The best feature I like is the pre-authenticated access to enable RDP proxy to the servers in the SBS network (although the use of port 4125 can be a pain behind some firewalls). The "Log on to or resume the console session of the remote computer" allows me to effectively remotely manage the server as though I was on site.

This is particularly useful when dealing with programs that require Session 0 - commonly known as console - access (for a concise description of terminal services history and session 0, see the Terminal Services Sessions: Then and Now article or the Wikipedia Terminal Services entry).
Over the last few months, I'd been finding that the Patch Tuesday reboots on the boxes I'd been RWW'ing to had resulted in hung systems, similar to what Susan Bradley's September 2006 blog entry records. Today, I saw the Ask the Performance Team's blog entry on The Reboot that Wasn't. This seemed to detail exactly what was going on with me, but I'd been enabling the "Log on to or resume the console session of the remote computer" option. So surely this wasn't my problem - or was it?
So I did some digging. I picked a Windows Vista RTM box, a Windows Vista SP1 box, a Windows Server 2003 SP2 box and a Windows Server 2008 box. I tried RWW'ing to my SBS 2003 box on each of them with the "Log on to or resume the console session of the remote computer" option set.
The results were as follows:

Windows Server 2003	Session 0
Windows Vista RTM	Session 0
Windows Vista SP1	Session 1
Windows Server 2008	Session 1

What's going on here? Shouldn't that be Session 0 for all those RWW clients?
No, not exactly. The problem we're seeing here is that the Remote Desktop Client (version 6.1) found in Windows Vista SP1 and Windows Server 2008 has dropped the /console switch and replaced it with /admin. The description of this change can be found in MSKB 947723 and also at the following Terminal Services Team Blog entry (same entry as the KB article, but with user comments). This change also extends to the programmatic interfaces that RWW uses.
As I commented in the Terminal Services Team Blog entry, this change was unwarranted, as the /console switch could have been left alone and have the code handle graceful fallback from the security-enhanced console access in Vista SP1 and Windows Server 2008 to the Session 0 access in Windows XP and Windows Server 2003.
So, the Terminal Services team has broken console access from RWW. Doesn't say much for the QA process when an entire product feature that relies on the Remote Desktop Client isn't tested for regression.
So what can be done to mitigate this? Well, you can use something like CopSSH on the SBS box and ssh to it, then use an ssh tunnel to connect to the SBS box using RDP (a how-to guide can be found on this Remote Desktop and SSH page). Or you can allow direct RDP access to the SBS 2003 box, which is very useful if you're running the Premium Edition and using ISA Server as you can leverage the ISA Server lockdown mode - which means you get RDP access when ISA's in lockdown and you can also tighten up RDP access to a restricted set of computers when ISA's running normally. For Standard Edition, or non-ISA Premium Editions, RDP restriction should be done by your firewall device.
For a hardware solution, something like an iBoot remote power management device might be useful to help with those hang on shutdown problems.
Anyway, patching over RWW can be problematic - see the Repeat after me.... you don't patch over RWW blog entry and the Some months you can't patch over RWW blog entry for some reasons why patch over RWW is bad.