Wer die Powershell Module von SCVMM und die Community Module zu Hyper-V gleichzeitig benutzen will, bekommt bei einigen Funktionen einen Konflikt.

Eigentlich sind alle Funktionen vom SCVMM eindeutig mit einem SC bezeichnet. So heißt die Funktion, um das Objekt einer Virtuellen Maschine zu erhalten get-SCVirtualMachine. Wahrscheinlich aus historischen Gründen gibt es aber eine Alias namens “get-VM” auf diese Funktion.

Die CodePlex Hyper-V Funktionen haben keinen gesonderten Namensraum. Hier heißt die Funktion für die Virtuelle Maschine einfach get-VM. Dies wäre nicht so schlimm, wenn die Funktion nicht auch intern fleißig genutzt wird. Möchte man die CodePlex Funktionen nutzen, um Differenzielle Disks zu erstellen (etwas  was der SCVMM auch in 2012 nicht anbietet), so funktioniert dies nicht mehr, wenn beide Module geladen sind.

In diesem Blogpost werde ich die Arbeit mit den neuen Custom Properties im SCVMM 2012 vorstellen.

In Vergangenheit gab es eine Reihe von vordefinierten Custom Properties (1-10). Mit SCVMM 2012 gibt es beliebige Erweiterungsfelder, die als Objekt abgebildet sind und an Virtuellen Maschinen, Hosts, Clouds und anderen Objekten hängen können.

Diese Objekte kann man in Powershell mittels get-SCCustomProperty abrufen. Diese Objekte beinhalten aber noch keine Werte, sondern stellen nur die Schlüssel dar. Die eigentlich eingestellten Werte hängen in einer Hashtable an den zu erweiternden Objekten, also z.B. an der jeweiligen Virtuellen Maschine in der Hashtable Eigenschaft CustomProperty. Möchte man den Wert der selbsterstellten Eigenschaft “Kostenstelle” abfragen, so kann man dies über

Ich habe gerade das Glück etwas mehr mit Powershell und System Center Virtual Machine Manager 2012 (SCVMM, RC) zu arbeiten. Daher werde ich hier wieder ein paar Codesnippsel posten, um bestimmte Funktionen zu automatisieren:

die erste Funktion soll eine neue Cloud für Hyper-V erzeugen . Zusätzlich wird ein neue Rolle für diese Cloud angelegt, die nur VMs verwalten darf.

#creates a new cloud and a corresponding usergroup
function createCloud([string]$name,[string]$hostgroupname)
{
   #retrieving first GUID for creating the new cloud
     $job= ([System.Guid]::NewGuid().toString())
   #define Cloud limitations (here: no limit)
     Set-SCCloudCapacity -JobGroup $job -UseCustomQuotaCountMaximum $true -UseMemoryMBMaximum $true -UseCPUCountMaximum $true -UseStorageGBMaximum $true -UseVMCountMaximum $true
   #setting the used network (here: the network has the same name as the cloud)
     $resources = @()
     $resources += Get-SCLogicalNetwork -Name $Name
   #defining that the cloud can be used on hyper-v server
     $addCapabilityProfiles = @()
     $addCapabilityProfiles += Get-SCCapabilityProfile -Name "Hyper-V"
   #adding the settings to the cloud with the defined GUID
     Set-SCCloud -JobGroup $job -RunAsynchronously -AddCloudResource $resources -AddCapabilityProfile $addCapabilityProfiles
   #adding the cloud to the hostgroup
     $hostGroups = @()
     $hostGroups += Get-SCVMHostGroup -Name $hostgroupname
   #creating the cloud and the rest from the first job :-)
     New-SCCloud -JobGroup $Job -VMHostGroup $hostGroups -Name $Name -RunAsynchronously

#creating the usergroup
   #GUID for the second job
     $job= ([System.Guid]::NewGuid().toString())
   #the roleis for the newly created cloud
     $scopeToAdd = @()
     $scopeToAdd += Get-SCCloud -name $name
   #the user of this role can start, stop and shutdown virtual machines in the cloud and start a remote control
     Set-SCUserRole -JobGroup $job -AddScope $scopeToAdd -Permission @("RemoteConnect", "Shutdown", "Start", "Stop") -ShowPROTips $false
     $cloud = Get-SCCloud -Name $name
   #add all settings to the role
     Set-SCUserRoleQuota -Cloud $cloud -JobGroup $job -QuotaPerUser -UseCPUCountMaximum -UseMemoryMBMaximum -UseStorageGBMaximum -UseCustomQuotaCountMaximum -UseVMCountMaximum
   #create the role with the job guid
     New-SCUserRole -Name $name -UserRoleProfile "SelfServiceUser" -Description "" -JobGroup $job
}

Die Funktion kann einfach per

Auch diesmal wieder ein Script, um schnell eine statische Gruppen füllen zu können. Als Input wird nur eine Textdatei mit den PC Namen benötigt. Die Gruppe wird ebenfalls als Name hinterlegt.

Add-PSSnapin NwcServices.BlsAdministration
$server="\\enteoWebServiceServer"
$csvfile="C:\Computerliste.csv"
$groupName="Statische Gruppe"
New-PSDrive -Name emdb -psProvider BlsEmdb -Root $server
cd "emdb:\rootdse"
$csv=import-csv $csvfile

$grp=get-emdbgroup -recurse $groupName
if (-not $grp) {
   write-host "ERROR: Software nicht gefunden: " $groupName
}
else
{
   $csv | forEach-Object {
      write-host $_.pc
      $pc=get-emdbcomputer -recurse $_.pc
      $grp.addMember($pc)
   }
}

Die CSV Datei muss als erste Zeile die Überschrift definieren, d.h. eine Zeile mit PC besitzen. Das Skript selber ist wie üblich aufgebaut. Zuerst wird die Verbindung zum Enteo Webservice Server aufgebaut und danach die Zielgruppe gesucht. Wird diese gefunden, dann wird die CSV Datei geladen und aus jeder Zeile der Wert in der Spalte PC genommen. Nach diesem Namen wird gesucht und der gefundene PC der Gruppe hinzugefügt.

Zwischendurch ist es manchmal einfacher beim SCOM direkt die Datenbank abzufragen. Zwar bietet die Powershell auch eine einfache Zugriffsmöglichkeit, dies ist aber nicht immer der schnellste Weg.

Die Datenbankstruktur des SCOM ist relativ selbsterklärend, aber arbeitet stark mit Referenzen durch schwer lesbare GUIDs.

Um sich den Einstieg  etwas zu vereinfachen wurde hier ein paar SQL Abfragen zusammengetragen: http://www.braindumpblog.co.uk/?p=61

(der Blog Post ist zwar schon relativ alt, aber stellt trotzdem noch eine gute Übersicht dar)

Wird Software in Enteo per statischen Gruppen zugeordnet, so ist es bei einem Hardwareaustausch notwendig, die Zuordnungen des alten PCs auf den neuen zu übertragen. Dies kann man natürlich durch manuelles Drag&Drop machen, oder aber über ein kleines Powershell Skript:

param([string]$sourcename="source", [string]$targetname="target")
Add-PSSnapin NwcServices.BlsAdministration
$server="\\enteoserver"
New-PSDrive -Name emdb -psProvider BlsEmdb -Root $server
cd "emdb:\rootdse"
$source=get-emdbcomputer -recurse $sourcename

if ($source)
{
    $target=get-emdbcomputer -recurse $targetname
    if ($target)
    {
        $source.GetAssociatedItems() | where {$_.SchemaDisplayName -eq 'Static Group'} |foreach-Object{
        write-host "Cloning group " $_.Name " from $sourcename to $targetname"
        $_.addMember($target)
        }
    }
    else
    {
        write-host "Target $targetname cannot be found!"
    }
}
else
{
    Write-host "Source $sourcename cannot be found!"
}

Das Skript selber ist recht einfach aufgebaut. Es wird der Quellcomputer gesucht und das Objekt abgefragt, welche Verbindungen es hat.
Diese Verbindungen werden nach dem Typ statische Gruppen gefiltert. Über diese Gruppen wird iteriert und jeweils dem Zielobjekt hinzugefügt.

Heute mal wieder eine kurze Powershell Zeile, um alle in Enteo hinterlegten PnP-IDs in den Driver Packages auszulesen und auszugeben.

Interessant kann diese Liste sein, um sie mit einer Enteo-externen Inventur zu vergleichen oder zu überprüfen, ob eine neue Hardware bereits unterstützt wird.

(Get-EmdbSoftwarePackage -recurse -Filter "SchemaTag=PnpPackage" |

where {$_.PnPEnabledIdList -ne $null}) |

foreach-object{$_.PnPEnabledIdList.Split(",")} > c:\temp\pnpids.txt

Zuerst wird in allen Software Paketen nach dem Typ PnPPackage gesucht. Aus diesen Ergebnissen werden alle Treiber ohne PnP Ids ausgefiltert. Das Ergebnis ist eine kommaseparierte Liste pro Treiber-Paket, die beim Komma getrennt wird. Am Ende steht eine Liste mit jeweils einer PnP Id pro Zeile:

Zentraler Punkt in dem Script ist die Erkennung in welchem status die Installation gerade ist. Folgende Status sind möglich:

• Installation noch nicht eingeplant
• Installation eingeplant aber noch nicht gestartet
• Installation ist angelaufen aber noch nicht beendet
• Installation ist durchgelaufen

Zur Ermittlung dierer Status greifen wir wieder auf das Auslesen von PolicyInstancen zurück. Dazu werden am Anfang einige Policy-IDs definiert, die die verschiedene Status beschreiben:

In diesem Blog-Post werden zwei weitere Komponenten des Scripts vorgestellt: Ping und somit den Status eines Rechners ermitteln und die Ermittlung ob ein Benutzer angemeldet ist.

Je nach dem Status des Systems kann ein Rechner sofort neuinstalliert werden (wenn er aus ist, oder er läuft aber an einem Client kein Benutzer angemeldet ist). Sollte ein Benutzer angemeldet sein, dann darf eine Neuinstallation nur nach einer gewissen Uhrzeit erzwungen werden (z.B. ausserhalb der normalen Arbeitszeit).

Jetzt wo wir einen Rechner per Powershell aufwecken können kommt als nächstes die Funktion um eine Neuinstallation anzustossen und sie wieder abzubrechen.

Der Abbruch ist deswegen relevant, da u.U. das WoL nicht funktioniert. Startet der Benutzer am nächsten Morgen den PC wieder ganz normal an, so würde die Installation direkt startet und er könnte ein paar Stunden nicht arbeiten. Daher stoppt das Script die Installation automatisch, falls sie nicht innerhalb eines bestimmten Zeitfenster gestartet werden konnte.