Ein Freund hat mich dann darauf hingewiesen, dass man das Zertifikat sehr wohl exportieren kann. Auf Basis dieser Information schreibe ich hier eine kurze Anleitung wie man das Zertifikat exportieren, zu einem linuxkompatiblen Format umwandeln und dann in Dovecot als von extern erreichbarer IMAP Server einbinden kann.

1. Export

Zum Export meldet man sich einfach auf seinem Homeserver per RDP an. Dazu Administrator als Passwort und sein WHS Passwort verwenden.  Dort im Startmenü per Run/Ausführen mmc.exe starten. Unter File/Datei über Add/Remove Snap-in die Zertifikatskonsole (Certificates) hinzufügen und mit dem lokalen Computer verbinden. Das Zertifikat ist unter Personal\Certificates zu finden. Es sollte den DynDNS Namen des Homeservers haben und von “Go Daddy Secure Certfication Authority” stammen. Sind zwei Zertifikate dieser Art vorhanden, dann sollte man das nehmen, dass beim Zertifizierungspfad keine Fehler aufzeigt.

Im Kontextmenü des Zertifikats (Rechter Mausklick) wählt man über “Alle Tasks” den Punkt Export aus. Im Wizard bestätigt man, dass man den privaten Schlüssel mit exportieren möchte und wählt als Exportformat PFX aus und gibt ein Password ein. Die Datei liegt man an einem Ort ab, auf dem man später von außerhalb des Servers zugreifen kann (z.B. in einer Freigabe unter d:\ServerFolders\…)

2. Transfer zu Linux

Als nächsten Schritt muss man die Datei zu seinem Linuxsystem übertragen. Ich habe hierfür WinSCP verwendet.

3. Umwandlung

Im Allgemeinen ist auf Linux bereits OpenSSL installiert. Diese Software wird verwendet um das Zertifikat umzuwandeln. Dabei wird aus einem Schlüsselpaar eine Datei mit dem Zertifikat und eine Zweite mit dem privaten Schlüssel:

Erzeugen des Zertifikates:

openssl pkcs12 –in whs.pfx -clcerts -nokeys -out whscert.pem

Erzeugen des privaten Schlüssels:

openssl pkcs12 -in filename.pfx -nocerts -nodes -out whskey.pem

Beide Dateien muss man jetzt an einen Ort verschieben auf den Dovecot zugreifen kann. Es bietet sich /etc/ssl/private/ für den privaten Schlüssel und /etc/ssl/certs/ für das Zertifikat an.

4. Verwenden in Dovecot

In Dovecot kann man dieses Zertifikat jetzt wie jedes (z.B. das selbstsignierte) Zertifikat verwenden. In Dovecot 2.0 würde dies in der /etc/dovecot/dovecot.conf so aussehen:

ssl_cert = ssl_key = 

In dem unwahrscheinlichen Fall, dass dies bei einer produktiven Installation passiert, würde ich den sauber Weg empfehlen und den SQL Server wieder deinstallieren und mit der richtigen Collation (=Sortierreihenfolge) neuinstallieren. Die Richtige ist übrigens SQL_Latin1_General_CP1_CI_AS:

Sind noch keine Benutzerdatenbanken auf dem SQL Server installiert, dann kann man auch die Collation direkt mit dem SQL Setup ändern lassen:

Dazu startet man das SQL Setup (z.B. von der DVD) mit folgendem Aufruf (in einer Zeile!):

setup.exe /quiet /action=rebuilddatabase /sqlcollation=SQL_Latin1_General_CP1_CI_AS
     /instancename=MSSQLSERVER /SQLSYSADMINACCOUNTS=BUILTIN\Administrators

Dies ist die minimale Anzahl an Parametern, die man übergeben muss. In diesem Beispiel soll die Stanardinstanz (interner Name MSSQLSERVER) aktualisiert werden. Berechtigung erhält die lokale Administratorgruppe des Servers. Bei einem deutschen Server heißt diese natürlich Administratoren.

Da das Setup silent ausgeführt wird, sieht man auch keine Fehlermeldungen. Wie bei einem SQL Setup üblich, landen die Installationslogs unter c:\programme\Microsoft SQL Server\100\Setup Bootstrap\Log\<datum+uhrzeit>\Detail.log

Hier nochmal die Kommadozeile als Screenshoot:

Dazu verwendet Hyper-V das rollenbasierte Accessmanagement (RBAC) und die dafür verfügbare GUI AzMan. Die Konfigurationsinformationen werden in einer XML Datei unter ProgramData\Microsoft\Windows\Hyper-V\InitialStorage.xml abgelegt. Achtung: Verwendet man den VMM Agent, so wird der Ort der XML Datei auf ProgramData\microsoft\Virtual Machine Manager\HyperVAuthStore.xml geändert!

Ich beschreibe hier die Vorgehensweise, wie man einer zusätzlichen benutzergruppe das Recht einräumen kann auf die Konsole der Virtuellen Maschinen zugreifen zu können:

Zuerst startet man die AzMan Konsole:

Über Stamm der Konsole wählt man den Autorisierungsspeicher (XML-Format) aus:

Wie oben beschrieben liegt die XML Datei auf dem Hyper-V Host unter c:\ProgramData\…

Jetzt kann man eine neue Rollendefinition unter Definitionen\Rollendefinitionen ablegen. In diesem Bespiel nenne ich die Rolle “Connect with VMV”:

In der neuen Definition werden unter Vorgänge die zu vergebenden Rechte festgelegt:

“Allow Input to Virtual Machine” und “Allow Output from Virtual Machine” ermöglicht den Zugriff auf die Console (Output) und die Steuerung von Tastatur und Maus (Input). Eine View-Only Rolle hätte somit nur ein Output Recht. Die Rolle sieht jetzt so aus:

Der Rolle muss jetzt unter Rollenzuweisungen eine Berechtigungsgruppe zugeordnet werden:

Hier kann man lokale Gruppen, Active Directory Gruppen oder auch einzelne Benutzer hinzufügen.

Neue Management Packs im Zeitraum zwischen 22.11.2011 und 31.12.2011

• Keine neuen Managementpacks

Scheinbar liegt die Priorität bei Microsoft momentan auf System Center Operations Manager 2012.

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.

Die direkte Lösung wäre daher, den Alias auf get-SCVirtualMachine wieder zu entfernen.   Neue Aliase sind einfach per “new-Alias” erstellbar. Eine Funktion namens “remove-Alias” existiert aber nicht, da ein Alias für die aktuelle Sitzung definiert und dort auch bis zum Ende bestehen bleibt.

Trotzdem kann man einen Alias mit der generischen Funktion remove-item entfernen. Hier heißt der Alias “Alias:get-VM”. D.h. wie bei der Bezeichnung “ftp:sdfsdf” oder “c:\get-vm” steht Alias: für das Protokoll bzw. den Namensraum, damit die Funktion weiß, an welches Modul sie den Löschbefehl weitergeben muss. Hier ein Beispiel:

$alias= Get-Alias | where {$_.name -eq "Get-VM"}
if ($alias -ne $null) {
   $itemName=$alias.CommandType.ToString()+":"+$alias.name
   Remove-Item $itemName
}

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

$kostenstelle=get-SCCustomProperty –Name "Kostenstelle"
$wert=$vm.CustomProperty.get_item($kostenstelle)

Nachfolgend noch eine etwas “komplexere” Funktion, um alle Custom Properties von der Virtuellen Maschine $vm auf die Maschine $targetVM zu übertragen:

if ($vm.CustomProperty.Count -gt 0)
{
    $vm.CustomProperty.Keys | ForEach-Object{
        Set-SCCustomPropertyValue -InputObject $targetvm -CustomProperty (Get-SCCustomProperty -Name $_) -Value $vm.CustomProperty.get_item($_)
    }
}

In der ersten Zeile wird zur Sicherheit überprüft, ob überhaupt Custom Properties an diesem Objekt hängen (HashTable speichert die Anzahl der Einträge in Count). Danach werden alle CustomProperty Objekte aus der Key Eigenschaft ausgelesen und durchlaufen. Durch set-SCCustomPropertyValue wird das Objekt und der Wert an das Zielobjekt übertragen.

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

createCloud "MeineCloud" "Alle Hosts"

aufgerufen werden.

Neue Management Packs im Zeitraum zwischen 31.10.2011 und 22.11.2011:

• Nix Neues von der SCOM MP Front…

Neue Management Packs im Zeitraum zwischen 10.10.2011 und 30.10.2011

• Windows Server 2000 Operating System 6.0.6958.0
• Windows Server 2003 Operating System 6.0.6958.0
• Windows Server 2008 Operating System (Discovery) 6.0.6958.0
• Windows Server 2008 Operating System (Monitoring) 6.0.6958.0
• Windows Server 2008 R2 Best Practice Analyzer Monitoring 6.0.6958.0
• Windows Server Cluster Shared Volume Monitoring 6.0.6958.0
• Windows Server Operating System Library 6.0.6958.0
• Windows Server Operating System Reports 6.0.6958.0
• MP Guide Core OS 

Diesmal gibt es keine großen Änderungen, sondern nur ein paar kleinere Korrekturen:

• Disabled BPA Rules by default.
• Added appropriate SQL Stored Procedures credentials
• Updated Knowledge of Logical Disks
• Updated Overrides for Logical Disks

http://www.microsoft.com/download/en/details.aspx?id=27844

Kurze Lsite der Änderungen:

• Zentrale Änderung ist der neu hinzugekommene Service Katalog mit Service Requests
• Release Management
• und ein neues Self-Service Portal, dass jetzt auf Silverlight basiert.