Nigel Boulton's Blog

Taking Snaphots of all Virtual Machines using PowerCLI

I recently needed to apply a limited distribution patch to a number of Citrix servers, all of which are virtual on VMware ESXi 4.0. I wanted to take snapshots before doing this, to give me an easy backout route if things went horribly wrong. Of course I could always have done this using the VI Client, but that would have meant an awful lot of "mousing about" and clicking to be able to do this for 176 virtual machines.

With PowerCLI this is a cinch, in fact it's pretty much a one-liner! I chose to do this one host at a time, but with a small change to the code below you can easily expand this to encompass a larger chunk, or even all, of your virtual infrastructure.

First, connect to your vCenter Server (and provide the appropriate credentials when prompted):

Connect-VIServer -Server

Then run the following one-liner to take a snapshot of all VMs on a given host:

Get-VMHost | Get-VM | New-Snapshot -Name "Pre patch" -Quiesce

In this case I chose to quiesce the file system first. Other options are available - see the help for the New-Snapshot cmdlet.

Once you have finished with the snapshots, delete them as follows:

Get-VMHost | Get-VM | Get-Snapshot -Name "Pre patch" | Remove-Snapshot

And finally, disconnect from your vCenter Server:

Disconnect-VIServer -Server

How easy is that..?!

My good friends Alan Renouf and Jonathan Medd talk about how useful PowerCLI is for automating repetitive tasks in Episode 20 of the Get-Scripting Podcast, and this is a perfect example of that.

On the subject of the Get-Scripting Podcast, do be sure to check out Episode 20 - the guys interview none other than Jeffrey Snover, Lead Architect for Windows Server at Microsoft, and the man behind Windows PowerShell itself - excellent!

Filed under: PowerCLI, VMware 2 Comments

Checking File Associations with the help of PowerShell Remoting

I recently needed to check the file association for .JPG files across a whole Citrix server estate, as we’d received reports of files of these types not always opening as expected. Because PowerShell remoting is enabled on every server, this was a very easy job..!

The code snippet below is what I used. A script block is run remotely on each server using the Invoke-Command cmdlet. The script block then uses the Get-ItemProperty cmdlet to read the registry to get the default file association for .JPG files (via the “jpegfile” class) and reports OK if it is as expected, or the actual value that is set if not:

1..176 | ForEach-Object {
	$ServerName = "SERVER$_"
	Write-Host "$($ServerName): " -NoNewLine
	Invoke-Command -ComputerName $ServerName -ScriptBlock {
		$Value = Get-ItemProperty "Registry::HKEY_CLASSES_ROOT\jpegfile\shell\open\command" "(Default)" | Select-Object -ExpandProperty "(Default)"
		if ($Value -eq "C:\Windows\System32\rundll32.exe `"C:\Program Files\Windows Photo Gallery\PhotoViewer.dll`", ImageView_Fullscreen %1") {
			Write-Host "OK"
		} else {
			Write-Host $Value

Update: Please see the comment below from Jeffrey Snover. Jeffrey's approach makes use of the concurrency feature of Invoke-Command, which executes the command on 32 servers simultaneously (by default) and so returns the results substantially faster.

In my opinion, PowerShell remoting is by far the best version 2.0 feature. If you don’t already have it enabled across your server estate I’d strongly recommend doing so as it can save hours of effort.

Depending on your environment, there may be a few hoops you have to jump through to get remoting working properly, but it will be time well spent.  PowerShell MVP Jonathan Medd has an excellent post on his blog on Enabling PowerShell 2.0 Remoting in an Enterprise and Ravikanth Chaganti has produced a helpful multi-part PowerShell 2.0 remoting guide.

Be aware though that unfortunately there are some things that can’t be run remotely – a month or two ago I was doing some work with WSUS and discovered that it’s not possible to call the IUpdateSession::CreateUpdateDownloader method remotely for example. Shame!

Filed under: PowerShell 4 Comments

Citrix Access Management Console – “Errors occurred when using [server] in the discovery process.”

I’m sure that, like me, you’ve seen this error message from time to time when attempting to configure and run discovery in the Citrix Access Management Console (AMC): "Errors occurred when using [server] in the discovery process."

Error message with detailsThis doesn’t occur if you add the local computer (as opposed to a remote one) as the server for discovery.

Double-clicking on the error message gives further details, as shown above. The things to check are as follows:

  1. Check that the Citrix MFCOM Service is running on the remote server you have specified for discovery:
  2. Citrix MFCOM service running

  3. Check that the “COM+ Network Access” Role is installed on the remote server. If not, use Server Manager to add it, as shown below:
  4. Adding COM+ Network Access Role

  5. Make sure that the account you are running the AMC as is a member of the “Distributed COM Users” group on the remote server. This is an easy thing to overlook, especially if you are publishing out the AMC to non-admins via XenApp
  6. Adding user to Distributed COM Users group

  7. If it still fails, verify that the necessary traffic is not being blocked by any firewalls between the server running the AMC and the remote server

I have also seen the additional detail report "Enterprise Services are not enabled on this server ([server]). Ensure the server is configured as an application server, and COM+ network access is enabled.". This is slightly more helpful of course…!

Filed under: Citrix No Comments

Delegating and propagating Exchange folder permissions using PFDAVAdmin

Every so often the requirement comes up to be able to give a colleague access to a specific folder hierarchy within my Exchange mailbox. As you may know, this is not easy to do using Outlook - it's fine for one folder but if there are a number of nested subfolders, you have to assign permissions to each of these individually. Life's just too short for that..!

The answer to this is a tool provided by Microsoft - the Microsoft Exchange Server Public Folder DAV-based Administration Tool - "PFDAVAdmin" for short. This is a very powerful tool which should be a key component of any Exchange Admin's toolkit. It can be downloaded from PFDAVAdmin is compatible with Exchange 2000, 2003 and 2007 (for Exchange 2010 it has been replaced by ExFolders).

PFDAVAdmin isn't limited to working with Public Folders as its name suggests. It allows you - among many other things - to propagate Exchange folder Access Control Entries (ACEs) down through a tree, much like you can do with NTFS.

However, as I do this so infrequently the one thing I can never remember is the syntax to use to specify my mailbox location, and the included documentation doesn't help that much - hence this blog post!

Once you have PFDAVAdmin installed and up and running (it needs .Net Framework 1.1 by the way), click File - Connect, and provide the appropriate details:

PFDAVAdmin Connect dialog

PFDAVAdmin Connect dialog

The key thing here being what you need to type into the Connection field. For "Specified mailbox", this needs to be in the format http://<mail_server_name>/exadmin/<your_email_domain>/mbx/<email_address>/ - in the above example this is "http:[email protected]/". Alternatively (assuming you have the necessary rights) you can select the option to connect to All Mailboxes and locate the mailbox in question that way, but of course you might not want to do this in a large organisation with thousands of Exchange mailboxes.

Once you have successfully connected and have PFDAVAdmin's view of the mailbox in front of you, follow these steps:

Folder permissions context menu1. Right-click the desired folder and select Folder permissions

Choose user to delegate to2. Click Add

3. Enter the alias for the user you wish to delegate access to (you will notice that this builds a nice LDAP query as you type) and click Search, followed by OK once the user is found and selected

Add permissions for user4. Select the user in the list

5. Select the desired permissions

6. Finally, click Commit changes

So far, we have only set permissions on the selected (parent) folder, so now we need to propagate these down to all subfolders:

Propagate folder ACEs context menu7. Right-click the folder again and select Propagate folder ACEs

Propagate ACEs selection dialog8. Select the ACE in question and click OK

...that's it! Obviously the usual caveats apply with regard to making sure you have a reliable up-to-date Exchange backup before attempting any of the above. Further information on PFDAVAdmin can be found at

Filed under: Exchange 4 Comments