Ben’s Tech Blog

It isn’t possible to create a checkpoint with SCVMM beta1 for VMs that are running. The obvious solution is to write a script to stop the VM first, then create the checkpoint and start it again. I’ve written a script that does exactly that, and it does it for all running VMs.

When I first looked at the checkpoint feature I was dissapointed that there wasn’t an option to add a description. I’ve discovered that while it’s not possible to add and view descritptions through the GUI, you are able to do it using PowerShell.

The following script stops all running VMs, creates a checkpoint with a description, then starts the VMs again.

$VMs = Get-VM -server localhost | where{$_.VMState -eq 'Running'}
$StopVMs = $VMs | Stop-VM
$CheckpointResult = $VMs | New-VMCheckPoint -description "CheckPoint created from script"
$StartVMs = $VMs | Start-VM

You won’t be able to view the description through the GUI, but you can see it if you retreive the checkpoint information via the Get-VMCheckpoint cmdlet:

Get-vmcheckpoint -server server1

Note that server1 is the SCVMM server, not a VM. The cmdlet will list all checkpoints for all VMs that are managed by SCVMM. There is a -VM option, but it doesn’t work with beta1 (along with a lot of other options) There is a way to get around this limiation however, and that is to get the VM object first and then use the Get-VMCheckPoint cmdlet. You can do this for other commands like Start-VM and Stop-VM as well. Here’s an example, including the output:

PS C:\> $VM = "wnlabap101"
PS C:\> $VMObject = Get-VM -server localhost | where{$_.Name -eq $VM}
PS C:\> $VMObject | Get-VMCheckPoint -server localhost

VM : WNLABAP101
ObjectType : VMCheckpoint
Accessibility : Public
Name :
Description :
CreationTime : 12/03/2007 1:25:08 PM
ModifiedTime : 12/03/2007 1:25:11 PM
AccessedTime : 12/03/2007 1:25:11 PM
MarkedForDeletion : False
MostRecentTask :
ServerConnection : Microsoft.VirtualManager.Monad.Remoting.ServerConnection
ID : 899be449-6130-41ba-bbe9-ba47ae907981

Well I promised that I’d post again soon, and I think 2.5 hours later fullfills that promise! Now that I have the basics down, I looked at creating the most obvious script - “Start all VMs that are stopped”. I did a lot of googling and couldn’t find any examples, so I worked it out myself - not that it is very complex at all. Here are the 2 lines of code that will start all stopped VMs:

$StoppedVMs = Get-VM -server localhost | where{$_.VMState -eq 'PowerOff'}
$StartResult = $StoppedVMs | Start-VM

It’s very straight forward; the first line creates a collection of VMs that are stopped. The second line starts each VM based on that collection. I used $StartResult simply to suppress the output created by the Start-VM cmdlet. The next script that I am planning to create will stop a VM, create a checkpoint and then start it again.

When I first fired up Powershell I was searching for the SCVMM related cmdlets but couldn’t see them. I ran Get-Command to list all the cmdlets but I didn’t see any related to VMs. I saw a reference to a Get-VM command after doing some googling, but when I tried to run the command it failed with:

PS C:\> get-vm
'get-vm' is not recognized as a cmdlet, function, operable program, or script file.
At line:1 char:6
+ get-vm <<<<

This was becuase I had started powershell using the shortcut from the PowerShell 1.0 start menu folder and not the shortcut from the Microsoft System Center Virtual Machine Manager 2007 start menu folder.

If you take a look at the shortcut’s target, you can see that it is starting powershell with the -PSConsoleFile switch:

"C:\Program Files\Windows PowerShell\v1.0\powershell.exe" -PSConsoleFile "D:\Program Files\Microsoft Systems Center Virtual Machine Manager 2007\bin\cli.psc1" -NoExit

So it appears that the SCVMM cmdlets are loaded from the cli.psc1 file that is included in the shortcut target, and that would explain why my first attempt at executing Get-VM didn’t work.

Once I started using the correct shortcut I started to explore all of the SCVMM related cmdlets. Get-Command is a good way to do this. You can also use Get-Command *vm to list all of the commands that end in “vm”. This however won’t list all of the commands related to SCVMM as not all of them are associated with VM functions. For example there are also cmdlets associated with Virtual Hard Disks.

I’ve listed all of the SCVMM cmdlets below. To generate this list I used Get-Command | CLIP which outputted all of the cmdlets to the clipboard. I then pasted the restults in notepad and removed all of the non-SCVMM commands by comparing them against the same results that I generated from the standard powershell console (by using the standard shortcut).

Add-VFD
Add-VirtualDisk
add-vmhost
add-vmhostnetworkadapter
Copy-HardDisk
discardsavedstate-vm
discover-vmhost
Get-DVDDrive
Get-FloppyDrive
Get-HardwareConfig
Get-ISO
Get-LibraryServer
Get-MachineConfig
Get-NetworkAdapter
Get-OperatingSystem
Get-OSConfig
Get-Script
Get-SelfServicePolicy
get-step
get-task
Get-Template
Get-VFD
Get-VirtualDisk
get-virtualnetwork
Get-VM
Get-vmcheckpoint
get-vmhost
Get-VMHostGroup
get-vmhostnetworkadapter
Get-VMHostRating
get-vmhostvolume
Move-VM
Move-VMHost
Move-VMHostGroup
New-DVDDrive
New-HardwareConfig
New-MachineConfig
New-NetworkAdapter
new-OSConfig
new-p2v
New-patchcache
New-SelfServicePolicy
New-Template
new-virtualnetwork
New-VM
New-vmcheckpoint
New-VMHostGroup
refresh-vm
refresh-vmhost
Remove-DVDDrive
Remove-HardwareConfig
Remove-ISO
Remove-NetworkAdapter
Remove-OSConfig
Remove-Script
Remove-SelfServicePolicy
Remove-Template
Remove-VFD
Remove-VirtualDisk
remove-virtualnetwork
Remove-VM
Remove-vmcheckpoint
remove-vmhost
Remove-VMHostGroup
remove-vmhostnetworkadapter
restart-task
restart-vm
Restore-vmcheckpoint
resume-vm
savestate-vm
Set-DVDDrive
Set-FloppyDrive
Set-HardwareConfig
Set-ISO
Set-NetworkAdapter
set-OSConfig
Set-Script
Set-SelfServicePolicy
set-server
Set-Template
Set-VFD
Set-VirtualDisk
set-virtualnetwork
Set-VM
set-vmhost
Set-VMHostGroup
shutdown-vm
start-vm
stop-task
stop-vm
Store-VM
suspend-vm


Normally, if you want to learn more about a command, you can use get-help and specify the command. However if I use Get-Help Get-VM I get an error:

PS C:\> get-help get-vm
Get-Help : Error loading help content for Get-VM from file "Monad.ImgLibCmdlet.
dll-Help.xml". Details: Monad.ImgLibCmdlet.dll-Help.xml.
At line:1 char:9
+ get-help <<<< get-vm

I beleive this is because the help file for the command hasn’t been written yet (it is only Beta1 after all!). This is consistent with the fact that the help file for the SCVMM console is mostly empty too. I discovered another way to find out more information about each command. Using Get-Command lists a ‘Definition’ column, but most of the text is truncated. However, if you use the Format-List option it will output all of the text:

PS C:\> get-command get-vm | format-list

Path :
AssemblyInfo :
DLL : D:\Program Files\Microsoft Systems Center Virtual Machine Ma
nager 2007\bin\Monad.ImgLibCmdlet.dll
HelpFile : Monad.ImgLibCmdlet.dll-Help.xml
ParameterSets : {__AllParameterSets}
ImplementingType : Microsoft.VirtualManager.Monad.Cmdlets.GetVMCmdlet
Verb : Get
Noun : VM


This helped me get a bit further with scripting SCVMM, becuase some of the cmdlets prompt for values unless you specify them. For example, if you use Get-VM it will prompt for a server value:

PS C:\> get-vm

cmdlet get-vm at command pipeline position 1
Supply values for the following parameters:
Server:

The server value required is the name of the SCVMM server. You can pipe the name by issuing the command with the -server option, e.g get-vm -server "labscvmm01". This will allow you to actually use the command in a script.

That’s all I’ll cover in this post, but I have more to add so watch this space!

I’m currently setting up a Microsoft System Center Virtual Machine Manager (SCVMM) environment. I can see that there are quite a few things that I’d like to script (starting and stopping VMs, creating checkpoints etc) so it’s time to start playing around with PowerShell.

One of the first things that I noticed was that I wasn’t able to run .ps1 scripts due to the execution policy. By default, only interactive commands can be run in PowerShell; all scripted commands are restricted. You can however change this to one of these settings:

Restricted
- Default execution policy.
- Does not run scripts.
- Interactive only.

AllSigned
- Runs scripts.
- All must be signed by a publisher that you trust.

RemoteSigned
- Runs scripts.
- Downloaded files must be signed by a publisher that you trust.

Unrestricted
- Runs scripts.
- No digital signature is required.

(note that I pasted the settings from the help text that generated by running Get-Help Set-ExecutionPolicy)

To get started, I set it to RemoteSigned by running the following command:

set-executionpolicy RemoteSigned

Once I set the execution policy I was able to run .ps1 files. To run a .ps1 file, open notepad and paste in a powershell command, for example write-host "test", then save the file with a .ps1 extention, for example test.ps1. To run the script, open PowerShell and type in the full path name of the file. Note that you can ommit the extension:

PS C:\> c:\scripts\test
test

If you are already in the correct directory (which you can change by using cd\ c:\scripts then you can just issue .\test:

PS C:\Scripts> .\test
test

So that’s it. I’ll post some more examples specific to SCVMM once I’ve got some scripts working.

We recently had hundreds of users leave our organization due to a takeover and we needed to remove each user from all of their distribution lists and security groups. Although we wanted to remove the users from all groups, I wanted to ensure that we had a record of what groups they were members of in case we needed to add them back in. The script that I created removes the user from all of their groups, but first records the list of groups they are member of and exports the list into a report file. We’ve already had two cases where we disabled a user and removed them from all groups and was later informed that the user’s termination date had been moved forward so their account needed to be reinstated. The user’s previous group membership listed in the report file made it very easy for us to add them back into the groups that they should belong to while they are still with the company.

I’ve added the script here.

I’ve added 2 scripts that I created recently to the scripts page. Check out the links below.

VBScript - Export a list of Mail Enabled Public Folders visible in the GAL
VBScript - Export a list of all Mailboxes with their home Server, Storage Group and Database.

I have added a script that I created last week to search for text in Outlook message attachments.

VBScript - Search Outlook Message attachments

The windows scripting host (WSH) allows administrators to execute scripts to automate administrative tasks, execute network login scripts and query systems for information - just to name just a few of it’s benefits.  I regularly write and run scripts; in fact I sometimes wonder how I got by before I ventured into the scripting realm.  The problem with the windows scripting host however is that it can be a launch-pad for malicious code.  Some administrators choose to disable the use of WSH on workstations and servers to prevent malicious code from executing.  While this makes a lot of sense from a security standpoint, it severely cripples your ability to automate admin tasks, and if you’re using vbscript based login scripts then you’re going to have a real problem. 

A far better approach is to use software restriction policies to dictate which scripts are permitted to run.  Software restriction polices are a new feature available in Windows Server 2003 and Windows XP that are set via Group Policy.  You’ll find the software restriction policy under Computer Configuration/Windows Settings/Security Settings/Software Restriction Policy. 

Software restriction policies are designed to control the execution of all executables, not just scripts.  There are 4 types of software restriction rules; I’m going to focus on the 3 that are beneficial to locking down the Windows scripting host.  To implement the rules, you simply create them in the Additional Rules folder.  Note that the folder already contains 4 default rules.

Path Rules:

Perhaps the simplest to implement, path rules let you either allow or disallow executables to run based on the path that they are launched from.  For example, you could disallow the execution of .vbs files (and the various extensions associated with script files) but permit those files that are in particular network share to run.

In this Example, you would create the following rules:

You could also use path rules to disallow vbscript files from running but allow them to run from your netlogon shares so that vbscript based login scripts could run:

Note that Microsoft’s recommendation is to avoid using environment variables where possible, as environment variables can be changed by the user to point to a different path.  If you choose not to use the %logonserver% environment variable you may want to consider using your domain controllers’ names instead. This may be cumbersome if you have a large number of DCs, but you do have the ability to use wildcards in path rules, so if all of you domain controllers where named DC1 - DC100 you could implement a policy similar to the following:

I’m comfortable in using the %logonserver% variable, and would be happy to use the first example in a production environment.

Hash Rules:

Hash rules have their advantages, however for locking down WSH they don’t provide too much flexibility.  Using a hash rule, you can allow or disallow the execution of files based on their content.  When you create a hash rule, a “hash” of the file is calculated.  Each time an executable is run, a hash of the file is compared with the hash stored in the policy.  In the case of locking down WSH, you could create a path rule to disallow all vbscript files, and then create a hash rule for each script that you want to allow.  While this may be suitable if you are using a single login script that rarely changes, or if you use only a handful of admin scripts that rarely change, it isn’t ideal for environments where scripts frequently change or like me you write new scripts every week.  The advantage to using hash rules over path rules though is that you can modify the filename and the hash will not change.  You can also run the script from any path;  as long as you don’t change the actual script itself you won’t need to modify the rule.

Example of hash rule to allow approved scripts:

Certificate Rules:

Certificate rules are an excellent way to lock down WSH to only allow approved scripts to run.  With a certificate rule, you import a digital certificate into a rule and then digitally sign each script that you want to approve with the same certificate.  The advantage to using certificate rules over path or hash rules is that the contents, path or filename of the script can change without preventing the approved script from running. 

The downside to using certificate rules is that you either need to purchase a digital certificate from a trusted public CA or install your own CA server and issue a certificate from there.  In both cases, the CA needs to be defined in the ‘Trusted Root Certification Authorities’ on your workstations and servers.

Importing the certificate

Once you have obtained a certificate to sign your scripts, you need to import the certificate into the rule.  This is fairly straight forward, you simply create the rule, then browse to the certificate file (*.cer, *.crt).

Signing Scripts

Strangely enough, you actually need to use a script to signs scripts.  The following is an example of a script that signs the C:\Scripts\script.vbs script with a certificate called Ben Christian.  The certificate must first be imported into the certificate store of the machine that you run the script on.

set objSigner = WScript.CreateObject(”Scripting.Signer”)
objSigner.SignFile “C:\Scripts\script.vbs”, “Ben Christian” 

Like the other rules, to implement a certificate rule to allow signed scripts to run, you would first create path rules to prevent the various script extensions from running.

Example of a certificate rule to allow approved scripts:

Using Certificate rules is probably the most secure way to lock down WSH with software restriction policy.  If certificate rules seem too cumbersome to implement, path rules are a good way to go.  In any case, implementing software restriction policies to lock down WSH on your client and server machines is better than doing nothing, and is an ideal balance between security and convenience.

I created a new script today to force AD replication between a number of servers.  I’ve explained how the script works on the script page, check it out if you’re interested.

VBScript - Force AD Replication

I’ve created a page for script examples and have posted a script there.  I’ll add some more in the near future.

VBScript - Toggle proxy server