There’s an excellent article about delegating Hyper-V permissions using Azman (Authorization Manager) which has recently proven invaluable for me. We’ve been using VMM for a while, but the only real use case we have is to impose a simple segregation between our “production” development systems and our test systems (to avoid testers accidentally powering off the CI server, for example).
VMM is really overkill for this, and after upgrading to VMM 2012 I found that it no longer even managed to set permissions properly. (All our users hate the VMM self-service portal and want to use the Hyper-V MMC anyway…)
One part of the process detailed in that article which I wanted to improve on was the VBS scripts used to set the Scope for VMs. The permission model relies on assigning VMs to scopes (and then assigning users to those scopes with particular permissions profiles). The latter can be done with the Azman UI (or, I am sure, via scripting of some kind via WMI). The former can only be done via scripting. Since I do most of my Hyper-V management using PowerShell I wanted a simple solution to keep it all in one place.
So I wrote a simple PowerShell module with two methods, Get-VMScope and Set-VMScope. Get-VMScope lists the scope for the given VM (either pass a string with the name or a wildcard pattern, or pipe in an object with either a “VMName” or “ElementName” property – e.g. you can pipe in the VM objects which are returned by the psHyperV module. Set-VMScope takes a (single) VMName/ElementName and you set the Scope using the -Scope parameter.
No documentation (yet), but it’s fairly self-explanatory!
One issue I found while migrating from VMM 2012 to using this was that snapshots contain a scope property which will override the global one whenever the machine is reverted. This can be overcome by re-snapshotting, or manually editing the snapshot XML file, or running a script/task to set the scope whenever the machines are reverted automatically. This problem will gradually go away as the machines get rebuilt of course.