It would seem everyone out there is happy with just merging their VHDs and getting back to work, but not me, no sir! I want things back the way they were! It took me about half a day to get this, so hopefully, this will save you some time for more important things, like tetris!

Steps

1. Create same number of pre-existing snapshots using the Hyper-V MMC.
2. Replace new snapshots with old snapshots while renaming the old to the same as the new, except the file extension should be “vhd” instead of “avhd”. The reason we’ll see later, but the Hyper-V tool to repair VHD chains auto-appends .vhd! (Grr Hyper-V Team, grr!)
3. Repair the vhd’s. Because of our renaming we’ve broken the differencing chain. To fix this, go to open Hyper-V, go to the VM’s Settings and then the hard drive. Change the VHD to the new one (simply changing the extension should work) and click “inspect disk”. This will walk you through fixing the chain.
4. Modify the ACL to include the VM specific account. This you must to in Powershell since the Explorer GUI can’t seem to find the account. I don’t know why and there may be a way, but I’m to lazy to dig into it and this works. (Below you can find some sample code.) The account to add from the old VHD, is the one that starts with “NT VIRTUAL MACHINE” and ends with a GUID.

   ##START POWERSHELL CODE
   #get the old vhd's permissions
   $vm_perm = (get-acl .\old.vhd).access | where { $_.IdentityReference.tostring().contains("NT VIRTUAL MACHINE") }
   
   #Load the new vhd's acl into memory
   $newvhd = get-acl .\new.vhd
   
   $newvhd.AddAccessRule($vm_perm)
   
   $newvhd | set-acl .\new.vhd
   ##END POWERSHELL CODE

5. Open all the VM’s XML setting files and make sure that any settings related the the VHD’s is correct. This should only be the filename. If you need to edit these files be sure to turn off the Hyper-V Management Service, this will not affect the VM’s running, only the managing of them. The XML files can be found wherever you made the VM.
6. You should now have a restored VM with the snapshot tree! Woo! Go you!

My original code didn’t take into account spaces in the file path, so when a user on XP tried to update the app, it would try to copy itself to “C:\documents” and fail. Since I’d already distributed the previous version, I couldn’t go about fixing it without also creating a tool to replace copies that were on computers already. So I oped for hacking it in the newest version.

Since the file path was given to the updated app when it runs, I simply needed to make my update code smarter….sort of, smarter may be to generous. I simply looped through the arguments until I hit one that ended with “.exe” and then used the result as the path to update to. Below is the code, which in future version will probably be commented out.

if (!System.IO.File.Exists(hargs["update_path"].ToString()))
{
    int i = Array.FindIndex(args, (delegate(string s) { if (s.ToLower() == "-update") { return true; } return false; })) + 1;
    string[] path = new string[0];
    for (i = i; i < args.Length; i++)
    {
        Array.Resize(ref path, path.Length + 1);
        path[path.Length - 1] = args[i];
        if (args[i].EndsWith(".exe"))
        {
            hargs["update_path"] = string.Join(" ", path);
            break;
        }
    }
}

However, I still needed a way for the application to get updated when I finished another version. I couldn’t rely on the users to check if they had the newest version since they could care less as long as it worked. I also didn’t want to put a lot of work into a distribution system specifically for an application that was a beta and not everyone needed even when it was completed. This meant that I needed to have the whole distribution/upgrade structure contained in one file that everyone was going to be running.

Roadblock, I found out that an application can’t overwrite its own file while its running. It makes sense for that to happen, but it makes it harder to upgrade yourself when it’s only you.

So how did I do this? Well since the newest version will be placed on a network folder, I figured that when the application finds a newer version, it will run the network copy and that instance will do the need upgrades. This presented a challenge though since I had to somehow create a version that could update itself before I could make a version that could update itself. Quite a chicken and egg conundrum!

What I ended up doing was create several different version of the exe and testing the upgrade code in chunks. Testing part of it here and there, constantly changing between the main app functionality and the upgrade code. #if and #endif preprocessor directives and different compile profiles came in really handy in defining different things depending on if I was running the upgrade or regular portions.

Well enough chitchat, time for code, which hopefully for those who program, should be understandable.

//method definition
//static void Main(string[] args)

//Look through the command line arguments and set some stuff up.
//Update the exe arguments.
hargs.Add("update", Array.Find(args, (delegate(string s) { if (s.ToLower() == "-update") { return true; } return false; })));
if (hargs["update"] != null && args.Length > 1)
{
	hargs.Add("update_path", args[Array.FindIndex(args, (delegate(string s) { if (s.ToLower() == "-update") { return true; } return false; })) + 1]);
}

//Updating executable?
if (hargs["update"] != null && hargs["update_path"] != null)
{
	//Make sure we know that it exists!
	if(System.IO.File.Exists(hargs["update_path"].ToString())) {
		System.IO.File.Copy(Application.ExecutablePath, hargs["update_path"].ToString(), true);

		//Start it up and exit this bitch!
		System.Diagnostics.Process.Start(hargs["update_path"].ToString());
	}
	return;
}
else
{
	if(System.IO.File.Exists(network_exe_path))
	{
		System.Diagnostics.FileVersionInfo newversion = System.Diagnostics.FileVersionInfo.GetVersionInfo(network_exe_path);
		if (newversion.FileVersion.CompareTo(Application.ProductVersion) > 0)
		{
			DialogResult dr = MessageBox.Show("There is a new version available. Download now?", "Update available", MessageBoxButtons.YesNo);
			if (dr == DialogResult.Yes)
			{
				System.Diagnostics.Process.Start(network_exe_path, "-update " + Application.ExecutablePath);
				return;
			}
		}
	}
}

“network_exe_path” is the network copy of the file and points to a UNC path (\\server\folder\app.exe). As you can see, this code doesn’t care what the local copy is named and will updated it regardless.

On top of these limitations, I also need the tools to be able to stand alone, one file to download and one to run. Which is something that scripts just can’t always provide since there are just too many variables in getting them to run. Executables on the other hand can be compiled so that everything it needs, it has. Something of which is a feature I need so that my users have only one thing to worry about.

Cisco:
show mac-address-table

Dell:
show bridge address-table

Since Lee Holmes’ comments, I’ve updated the file and function with some of the suggestions he gave. Unfortunately, the <# #> help syntax throws a bunch of errors in V1, so I had to revert to my old ways.

@'
<#
.Synopsis
	Create a random string of letters.
.Description
	Create a random string of letters (upper and lower) and numbers for
	use in passwords.
.Parameter Length
	How long do you want the password to be? (Default is 8.)
.Example
	PS> createPassword 10

.ReturnValue
	[string]
.Link

.Notes
NAME:      Verb-Noun
AUTHOR:    Josh Erickson
LASTEDIT:  1/21/2009
#Requires -Version 2.0
#>
'@ | out-null

function createPassword {
	param(
		[int] $length = 8
	);

	if($length -eq $Null) {
		$length = 8;
	}

	$tmppwd = @();
	$rand = new-object system.random -argumentlist $(date).tick;

	for($i = 0; $i -lt $length; $i++) {
		#caps 65, 90
		$a = $rand.next(0,100);
		if($a -lt 33) {
			$tmppwd += ,[char]$rand.next(97,122);
		} elseif($a -ge 34 -and $a -lt 66) {
			$tmppwd += ,[char]$rand.next(65,90);
		} else {
			$tmppwd += ,[char]$rand.next(48,57);
		}
	}

	[string]::join("",$tmppwd);
}

It’s a Powershell script, but I’m sure you smart people out there can make a neato interface for it with your Vb Script or C#, or even port it! You can get the source here.

MergeXML

Break down of a week.

1. Sunday
   1. Church (2-3)
   2. Homework or Rest (Remainder)
2. Monday
   1. Work (8)
   2. School (2)
   3. Bible Study (2-3)
   4. Homework or Rest (Remainder)
3. Tuesday
   1. School (8-9)
   2. Work (2-3)
   3. Tae Kwon Do (1)
   4. Homework or Rest (Remainder)
4. Wednesday
   1. Work (8-9)
   2. School (1-2)
   3. Tae Kwon Do (1)
   4. Homework or Rest (Remainder)
5. Thursday
   1. Work (6-7)
   2. School (3-4)
   3. Tae Kwon Do (1)
   4. Homework or Rest (Remainder)
6. Friday
   1. Work (8-11)
   2. Homework or Rest (Remainder)
7. Saturday
   1. Work (5-6)
   2. Homework or Rest (Remainder)

Note that the Rest in “Homework or Rest” includes relaxing and hanging out.

So anywhere from 58 to 70 hours of my week are taking in doing school, work, TKD, or something church related! Considering I set aside roughly 7-8 hours a night for sleep which leaves about 16 hours left to everything else. So each day I have is divided roughly between work 50%, school/homework 35% and rest 15%.

I can’t wait for school to be over.