Zum Hauptinhalt wechseln

Der NTx Blog

Geschichten über Technik, und was sonst noch in der IT passieren kann ...

Blogspace
  

Der NTx Blog > Beiträge > System Center Virtual Machine Manager (SCVMM) R2 Agent in der DMZ, und was das mit WinRM zu tun hat
System Center Virtual Machine Manager (SCVMM) R2 Agent in der DMZ, und was das mit WinRM zu tun hat

Vorweg: Ich finde SCVMM, überhaupt in der R2 Version, wirklich super. Das Produkt läuft sehr stabil und bringt wirklich was, gerade in "dynamischen" Umgebungen, wo virtuelle Maschinen öfter neu erstellt werden oder sich User ihre virtuellen "Spielmaschinen" gar selbst zusammenbauen können sollen.

Andererseits ist es leider auch bei diesem Produkt so, dass manches auf eine Art implementiert ist, dass man sich einfach nur fragen muss, ob das jemals wer ausprobiert hat – abgesehen von den Entwicklern selbst, aber die wissen's ja eh. Das kann nämlich angesichts des "VMM R2 Agent in der DMZ Upgrade Debakels" unmöglich der Fall sein. Wenn dann noch – wie in diesem Fall – eine suboptimale Dokumentation der bestehenden Installation dazukommt, wird aus einer 5-Minuten-Sache schnell ein 8 Stunden Einsatz. Die Ausgangslage:

Auf einer Maschine in der DMZ (dem "DMZHOST") läuft der SCVMM Agent und soll auf den SCVMM R2 Agent upgegradet werden, weil der SCVMM Server selbst bereits auf R2 upgegradet wurde. In diesem Zustand ist der DMZHOST in der Konsole mit einen "Achtung" Symbol verziert und "Needs Attention", weil er eben upgegradet werden sollte.

Wenn Sie bei dieser Maschine in der Konsole auf "Update Agent" klicken, wird der Update-Job gestartet, der endet aber augenblicklich mit einem Fehler:
Error (10436)
Virtual Machine Manager does not support updating an agent on a host that is in a non-trusted domain or on a perimeter network.

Die Lösung steht auch gleich dort drinnen, und zwar:

  1. Host aus der Konsole entfernen
  2. VMM Agent vom Host deinstallieren
  3. VMM R2 Agent am Host installieren
  4. Host in der Konsole hinzufügen

Punkt 1) ist schnell erledigt, Punkt 2) auch. Interessant wird es ab dem Punkt 3)

Wenn jetzt das VMM Agent Setup ausgeführt wird, führt das sofort nach der Eingabe aller Daten zu folgendem überaus erhellenden Fehler-Popup:

Failed to configure the WS-Management service. In the Local Group Policy Editor (gpedit.msc), navigate to Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM), and then ensure that there are no policy settings configured for WinRM Client or WinRM Service.

Nur der Vollständigkeit halber erwähne ich hier, dass natürlich keinerlei lokale Richtlinie für WinRM konfiguriert ist. Daraufhin in einer "elevated" ("als Administrator" ausgeführten) Eingabeaufforderung folgendes festgestellt:

C:\Windows\system32>winrm enum winrm/config/listener
WSManFault
Message = Access is denied.

Error number: -2147024891 0x80070005
Access is denied.

Nach längeren Recherchen bin ich schließlich über diesen Artikel gestolpert, in dem es zwar um eine remote Verbindung auf den Server mittels WinRM geht, der das Problem aber trotzdem behebt, sobald man diesen Registry-Wert hinzufügt:

[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] (DWORD) LocalAccountTokenFilterPolicy = 1

Kaum ist der Wert hinzugefügt und die Policy mit "gpupdate" aktualisiert, funktioniert winrm als Administrator ohne "Access Denied", und die Installation des VMM R2 Agents problemlos. Damit wäre eigentlich alles eitel Wonne, wäre da nicht die – zugegeben lästige – Frage der VMM Agent Setup Wizards nach den Ports für die WinRM- und die BITS-Kommunikation. An dieser Stelle werden 2 Standardwerte angeboten, nämlich

  • 80 – für die Kommunikation des VMM Servers mit dem Agent über WinRM, und
  • 443 – für den Filetransfer mittels BITS

Diese Ports müssen natürlich mit den Einstellungen des VMM Servers übereinstimmen, andernfalls wird dieser mit dem Agent keine Kommunikation zustande bringen, was sich in folgendem Fehler manifestiert:

Error (426)

The agent is not responding on the perimeter network machine DMZHOST because either the agent is not installed; or DMZHOST is not accessible from Virtual Machine Manager server.

Jetzt wäre eine Dokumentation hilfreich, in der steht, welche Ports der Installateur des Systems damals bei der Einrichtung des VMM Servers für die Kommunikation mit den Agents festgelegt hat. Diese Einstellung wird nämlich sicherheitshalber in der VMM Konsole am Server nirgends angezeigt. Wenn man diese Werte nachträglich herausfinden will, muss man

  • entweder in der Doku nachschauen – wenn man eine hat,
  • oder mittels winrm enum winrm/config/listener auf einem anderen Agent nachschauen,
  • oder am VMM Server in der Registry unter HKLM\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings nachschauen

Damit abschließend noch zu folgenden Hinweisen:

  1. Wird der VMM R2 Agent deinstalliert, wird auch der o.a. Registry Wert gelöscht! Wer also nach der Deinstallation des Agents unmittelbar wieder neu installiert, hat ein deja vu Erlebnis.
  2. Bei der Installation des Agents kann man auch ein Zertifikat konfigurieren, mit dem die Verschlüsselung erfolgen kann. Dazu muss man den Thumbprint des Computer-Zertifikats des Hosts (nicht des Servers!) eingeben. Das Zertifikat muss gültig sein, der Subject-Name muss mit dem Host-Namen im Security-File übereinstimmen, und das Zertifikat muss auch am Server gültig sein.

Kommentare

Zu diesem Beitrag sind noch keine Kommentare vorhanden.

 Aktuelle Beiträge

Welche sind die letztgültigen Updates für Office?Neu
Office 365: Probleme mit Anhängen und mehr
Outlook 2013: Die NSA liest mit
Fehler: "The description for Event ID (X) in Source (Y) could not be found..." wenn Event log Einträge an andere Server weitergeleitet werden(Forwarded Events)
Warum es keine gute Idee ist, zwischen Exchange Servern Firewalls zu platzieren...
Exchange 2007 Service Pack Upgrade schlägt bei der Installation der HUB Rolle fehl...
Outlook Sync Issues Folder automatisch leeren...
Windows Phone 7: Ist es nach über einem Jahr eine ernstzunehmende Alternative zu iPhone und Android?
Was Ultrabooks und die Cloud gemeinsam haben und was das mit dem Winter zu tun hat
Datenschutz in der Cloud