I often go to execute a stsadm command and find it is not in the path on the server I am working on, so I looked for a while of a way of adding it permanently through powershell and then realised it's a straightforward task with .NET code. The following will add the BIN folder within the program files structure to the PATH environment variable at local machine level so that all users will benefit.

   1:  $envpath = [environment]::GetEnvironmentVariable("Path","Machine")

   2:  $binpath = $env:Programfiles + "\Common Files\Microsoft Shared\web server extensions\12\BIN"

   3:  if ($envpath.contains($binpath) -ne $true ) {

   4:  $envpath = $envpath + ";" + $binpath

   5:  [environment]::SetEnvironmentVariable("Path",$envpath,"Machine")

   6:  Write-output "BIN Path added."

   7:  }

   8:  else

   9:  {

  10:  Write-output "BIN Path already added."

  11:  }

I have added a check to not add it if it is already present as the traditional method of using

SET PATH=%PATH%;C:\Program files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN

ends up with multiple copies of the BIN path in the variable and only applies for the current session.

Since I last posted on this James O'Neill has released an updated version of the library for Hyper V. He's now up to 1.00b over on codeplex.

There are a number of additions and amendments which caught me out initially as a parameter name had changed and caused my script to return all the virtual machines rather than just the one I expected... but the library is more complete and now I'm extending my collection of scripts for making the provisioning of test and staging servers more automated I expect that will be very welcome.

For those that haven't yet looked at Powershell, please do. Aside from being an extremely powerful means to interact with SharePoint and control items that are not available from the web UI, it is more than likely that as with Exchange, Powershell will be the means of interacting with SharePoint v.next (as opposed to stsadm)

Some links to interesting resources and example scripts....

http://www.u2u.info/Blogs/karine/Lists/Posts/Post.aspx?ID=9

http://darrinbishop.com/blog/archive/2007/04/08/54.aspx

http://blogs.flexnetconsult.co.uk/colinbyrne/PermaLink,guid,1665700b-e0de-4b8a-bb1c-014d6fbcf2db.aspx

Powershell download

http://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx

Useful Powershell editor

http://www.powergui.org

Well, James O'Neill has updated his library on codeplex again, but there is still a function missing that I needed. In our environment we create multiple machines and I wanted a way to create them in a specific directory, now I know I could set the default location and then create it, but I prefer to just specify a path and go from there.

I started from Ben Armstrong's code at Virtual PC Guy's Weblog and then modified the code after the VM name is set to also specify the location of the folder it will be created in.

[code:xml]

# Setthe VM name
$newVSGlobalSettingData.psbase.Properties.Item("ElementName").value = $VMName

# New code - Set Folder location
$VMFolder = "E:\DevVMs\"
$newVSGlobalSettingData.psbase.Properties.Item("ExternalDataRoot").value = $VMFolder + $VMName

[/code]

It took a little while to find the correct property to set, and I don't think that ExternalDataRoot is particularly obvious but the documentation at MSDN was helpful. In the example above, it puts the VM files in E:\DevVMs\VMName.

For our scripts I then used the HyperV Library to configure the VM with CPUs, RAM, disks and network connections.

Managing VMs from PowerShell requires the use of lots of WMI calls but fortunately for us James O'Neill has come to the rescue with a PowerShell script that makes managing HyperV as easy as the rest of PowerShell with straightforward commands like Get-VM. He has produced a PowerShell script much like an include file that you can use to make life easier.

The source is up on codeplex at http://www.codeplex.com/PSHyperv 

And for those who haven't figured out how to do an include in a PowerShell script here you go, you dot source it. Just add the following line to the top of your script.

[code:xml]

. [path to script]\hyperv.ps1

[/code]

Personally I have tinkered and removed the directory listing of all the added functions. Once I got used to the structure of the commands it saved me hundreds of lines of WMI handling and calls. The only task I haven't been able to get it to do is create the VM in a specific directory. I have now manged it with direct WMI calls so I'll go back and try with these extensions either to add to them or use them to manipulate what I need, but that will have to wait for a future post.

I've been continuing to work on our development environment and staging servers looking at ways to automate things and Powershell seems to be the way to go. I found a great collection of functions ready to use that James O Neill has posted to codeplex, but last week I ran into some problems with them. Using the Get-VM function gave me no output as did a number of other get- functions.

It took a while as i gradually worked through the code trying to see where it was going wrong - debugging a new language is always a liitle bit challenging as you learn what the different syntax and constructions do, but very beneficial in terms of learning how it works. Anyhow eventually i got to the point where i could get the WMI objects to return only the host machine and none of the virtual machines. At this point something clicked, I can't remember what it was now, but I realised that I was running powershell under the administrator account but without elevated privileges. I ran a new instance of powershell "as administrator" and pulled in the hyperV.ps1 file. Typed Get-vm and hey presto the list appeared of all my VMs. 

Whilst I appreciate what Microsoft is trying to do with UAC, I am beginning to wonder how many more times i am going to get caught out by it and whether we will all just end up turning it off!