• Sicherheitsupdate für Microsoft .NET Framework 4 (KB2656351)
• Sicherheitsupdate für Microsoft .NET Framework 4 (KB2656368)
• Update für Microsoft .NET Framework (KB2600217)

diese Fehlermeldung im Systemereignisprotokoll (Quelle: Windows Update Agent, Event-ID 20) erhielt:

Installationsfehler: Die Installation des folgenden Updates ist mit Fehler 0×80070643 fehlgeschlagen: Sicherheitsupdate für Microsoft .NET Framework 4 unter Windows XP, Windows Server 2003, Windows Vista, Windows 7, Windows Server 2008 x86 (KB2656351)

Problem

In meinem Fall trat der obige Fehler auf einigen (kurioserweise nicht auf allen!) Maschinen unter Windows Server 2003 (32 Bit) inkl. Service Pack 2, aber auch unter Windows Server 2008 (64 Bit Version) inkl. Service Pack 2 auf. Bei letzterem Betriebssystem lieferte Windows Update einen weiteren Fehlercode 800b010b, welcher mich letztendlich bei meiner Fehleranalyse auf die richtige Fährte führte:

Bei meiner Suche nach dem ersten Fehlercode 80070643 stieß ich auf den folgenden Microsoft Support KB Eintrag. Wie beschrieben lud ich das .NET Framework Cleanup Tool für die Reparatur der .NET Framework Umgebung herunter und führte selbiges mit der Option Cleanup Now aus:

Das Tool entfernt dabei alle .NET Framework Einstellungen (per Auswahl auch auf einzelne Versionen beschränkbar) von dem betroffenen System. In Folge dessen musste ich nun alle .NET Framework Versionen (unter Windows Server 2003 sind das immerhin Version 1.1, 2.0, 3.0, 3.5 und 4.0 inkl. aller Service Packs) neu installieren. Dank internem Windows Update Server (WSUS) kein Problem – doch nach der Installation der oben aufgeführten Updates und mehreren Neustarts erhielt ich die selben Fehlermeldungen erneut – eine Bereinigung und anschließende Neuinstallation behebt das Problem demnach nicht.

Analyse und Ursache

Jedes Windows Update legt bei der Installation ein Protokoll im temporären Verzeichnis des Systems an (%TEMP%\KB<Nummer>.html). In diesem Protokoll wird für die betroffenen Updates immer die gleiche Ursache genannt (hier das Beispiel für KB2656368):

Action: Downloading and/or Verifying Items...
[4/24/2012, 8:54:49] Verifying Digital Signatures: d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp
[4/24/2012, 8:54:49] d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp: Verifying signature for NDP40-KB2656368.msp...
[4/24/2012, 8:54:49] d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp - Signature verification for file NDP40-KB2656368.msp (d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp) failed with error 0x800b010e (Der Sperrvorgang konnte nicht fortgesetzt werden. Die Zertifikate konnten nicht überprüft werden.)
[4/24/2012, 8:54:49] d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp Signature could not be verified for NDP40-KB2656368.msp
[4/24/2012, 8:54:49] No FileHash provided. Cannot perform FileHash verification for NDP40-KB2656368.msp
[4/24/2012, 8:54:49] File NDP40-KB2656368.msp (d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp), failed authentication. (Error = -2146762482). It is recommended that you delete this file and retry setup again.
[4/24/2012, 8:54:49] Failed to verify and authenticate the file -d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp
[4/24/2012, 8:54:49] Please delete the file, d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp and run the package again
[4/24/2012, 8:54:49] Action complete
[4/24/2012, 8:54:49] calling PerformAction on an installing performer
[4/24/2012, 8:54:49] Action: Performing actions on all Items...
[4/24/2012, 8:54:49] Wait for Item (NDP40-KB2656368.msp) to be available
[4/24/2012, 8:54:50] Action complete
[4/24/2012, 8:54:50] Sending Manifest Report
[4/24/2012, 8:54:51] Final Result: Installation failed with error code: (0x800B010B), "Allgemeiner Vertrauensfehler." (Elapsed time: 0 00:00:03).

Es ist erkennbar, dass das im Update enthaltene Paket (NDP40-KB2656368.msp) eine digitale Signatur enthält, deren Überprüfung fehlschlägt. Über die Eigenschaften der MSP-Datei lässt sich diese Signatur anzeigen:

Bei dem Klick auf Details erhielt ich daraufhin den folgenden Fehler:

Lässt man sich nun das Zertifikat des Signaturgebers (Microsoft) anzeigen, so kann Windows die Gültigkeit des Zertifikats nicht bestätigen, da das Programm keine gültige Zertifikatsperrliste von der Zertifizierungsstelle ermitteln kann, die dieses Zertifikat ausgestellt hat.

Die Zertifikatsperrliste (Certificate Revocation List = *.crl) ist eine Datei, über die ein Aussteller abgelaufene und kompromittierte Zertifikate für ungültig erklären kann. Die URL für die CRL ist dabei immer in den Eigenschaften eines Zertifikates verankert. Kann die Sperrliste einmal nicht geladen werden, so geht ein Client im Standard immer von der Ungültigkeit eines Zertifikates aus.

Für die beschriebene Datei gibt es nun 3 in Frage kommende (weil hinterlegte) Sperrlisten:

• http://crl.microsoft.com/pki/crl/products/microsoftrootcert.crl
• http://crl.microsoft.com/pki/crl/products/MicCodSigPCA_08-31-2010.crl
• http://crl.microsoft.com/pki/crl/products/MicrosoftTimeStampPCA.crl

Normalerweise lässt sich die Erreichbarkeit/Verfügbarkeit der jeweiligen CRL durch das Herunterladen prüfen – alle CRLs waren aber erreichbar und konnten erfolgreich heruntergeladen werden. Trotzdem konnte das Zertifikat nicht überprüft werden.

Lösung

Bei der Fortsetzung meiner Suche fand ich schließlich den folgenden, wertvollen Hinweis im Technet-Forum von Microsoft. Eigentliche Ursache für das beschriebene Verhalten sind die System-Einstellungen für die Zertifikat-Überprüfung (Software Publishing State Key Values).

Mit Hilfe des Tools SetReg.exe von Microsoft – welches im Microsoft .NET Framework SDK enthalten ist – lassen sich diese aktuellen Einstellung anzeigen und ändern. Auf den Systemen, auf denen die Updates nicht installiert wurden, zeigte SetReg folgende Werte:

Software Publishing State Key Values (0xc9):
 1) Trust the Test Root........................... TRUE
 2) Use expiration date on certificates........... TRUE
 3) Check the revocation list..................... TRUE
 4) Offline revocation server OK (Individual)..... FALSE
 5) Offline revocation server OK (Commercial)..... FALSE
 6) Java offline revocation server OK (Individual) FALSE
 7) Java offline revocation server OK (Commercial) FALSE
 8) Invalidate version 1 signed objects........... FALSE
 9) Check the revocation list on Time Stamp Signer TRUE
 10) Only trust items found in the Trust DB....... FALSE

Im erwähnten Technet-Eintrag wurde der Punkt 5 Offline revocation server OK (Commercial) als kritisches Element beschrieben. Setzt man diesen über den Befehl

setreg 5 TRUE

auf wahr (allows offline approval for commercial certificates), so lassen sich die Windows Updates ohne Probleme installieren. Außerdem funktioniert danach die Anzeige des Zertifikates des Signaturgebers der MSP-Paketdatei ebenfalls ohne Probleme:

Das Herunterladen des ca. 115 MByte (!) großen .NET Framework SDK für die Ausführung von SetReg kann man sich allerdings sparen, da selbiges Tool lediglich einen Wert in der Registry verändert. In meinem Fall hatte der betroffene Benutzer auf dem System den folgenden Eintrag:

[HKCU\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]
“State”=DWORD:000000c9

Setzt man nun diesen Wert auf

“State”=dword:00022849

so entspricht diese Einstellung den auf der Webseite für SetReg beschriebenen DEFAULT Werten:

Updated Software Publishing State Key Values (0x22849):
 1) Trust the Test Root........................... FALSE
 2) Use expiration date on certificates........... TRUE
 3) Check the revocation list..................... TRUE
 4) Offline revocation server OK (Individual)..... FALSE
 5) Offline revocation server OK (Commercial)..... TRUE
 6) Java offline revocation server OK (Individual) FALSE
 7) Java offline revocation server OK (Commercial) TRUE
 8) Invalidate version 1 signed objects........... FALSE
 9) Check the revocation list on Time Stamp Signer FALSE
 10) Only trust items found in the Trust DB....... FALSE

Nach dieser simplen und kleinen Änderung funktioniert die Installation der Windows Updates KB2656351, KB2656368 und KB2600217 ohne Probleme.

Fazit

Obwohl ich bereits das eine oder andere Problem mit Windows Updates für das Microsoft .NET Framework lösen musste, verlangte der hier beschriebene Fehler einen extremen Zeit- und Arbeitsaufwand (erkennbar am Umfang des Artikels). So habe ich allein für die Suche und Analyse mehrere Stunden investieren müssen. Warum und vor allen Dingen welches Programm den Standardwert für die Software Publishing Key Values von 23c00 (siehe .DEFAULT Benutzerprofil) auf c9 abgeändert hat, bleibt mir ein Rätsel. Umso überraschender ist doch die recht schnelle und einfache Behebung des Problems, mit dessen Lösung ich hoffentlich anderen Leidensgenossen helfen kann.

Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.

Das Ziel bestand darin, einen funktionierenden Trunk zwischen zwei Servern herzustellen und dessen Funktion durch mittels eines entsprechenden Datendurchsatzes zu messen. Da die Server später räumlich getrennt voneinander stehen, sollte die Verbindung über einen Switch zustande kommen.

Zunächst sollte man sich vor Augen halten, dass ein Trunk keinesfalls den maximalen Datendurchsatz einer Verbindung erhöht. D.h. über zwei bzw. vier Gigabit-Verbindungen lässt sich kein Datenstrom mit zwei bzw. vier Gigabit Durchsatz ermöglichen. Über die höhere Anzahl mehrerer logischer Verbindungen lässt sich einzig die gesamte aggregierte Bandbreite besser ausnutzen.

Ein Einstieg zur Thematik befindet sich hier: Link Aggregation und LACP Grundlagen.

Voraussetzungen

Da die zur Verfügung stehende Hardware, in diesem Fall Switches der D-Link DGS-1210-xx Serie sowie die HP Netzwerkkarten HP-NC326i und HP-NC373i, alle das LACP Protokoll unterstützen, sollte dieses zur Anwendung kommen. Wichtig ist, dass alle an der Kommunikation beteiligten Komponenten dieses Protokoll unterstützen.

Bei der Konfiguration des Switches sollte man beachten, dass zunächst das Spanning-Tree-Protokoll (STP) auf allen an LCAP-Trunks beteiligtenden Switchport deaktiviert ist. Das verhindert, dass ggf. Ports aufgrund der automatischen Erkennung von redundanten Pfaden deaktiviert werden. Auf anderen Ports sollte STP aber aktiviert bleiben, um Netzwerkschleifen zu verhindern.

Einrichtung

Es bietet sich an, mit der Konfiguration der Switchports zu beginnen und bisher unbenutzte Ports zu verwenden. Im Fall von D-Link Switches findet man die benötigten Einstellungen unter dem Punkt Link Aggregation. Hier sollte darauf geachtet werden, den Aggregationstyp auf LACP zu stellen. Sofern die Möglichkeit besteht, empfiehlt es sich auch, den LACP-Timer für die Trunk-Ports auf ein kurzes Intervall einzustellen (bei D-Link: Short / 3 sec), damit Verbindungsabbrüche entsprechend schnell erkannt werden und der Failover auf verbleibende Netzwerkverbindungen nach kürzester Zeit erfolgen kann.

Bei der Einrichtung der Netzwerkkarten unter Windows gibt es aber ein paar mehr Fallstricke. Zunächst muss der Treiber die entsprechenden Trunking-Funktionen mitbringen – die Konfiguration erfolgt meist über ein separates Tool. Bei Intel heißt das Werkzeug dafür Intel PROSet, bei Hewlett Packard Network configuration Utility (NCU). Bei Intel-Netzwerkadaptern habe ich zudem schon erlebt, dass das Konfigurationstool nur in den Eigenschaften der Netzwerkkarte auftaucht, wenn man sich auf einer Konsolensitzung befindet. Da bei diesem Vorgang ein neuer, logischer Adapter erstellt wird, der zunächst keine Konfiguration erhält, ist ein direkter physischer Zugang zum Server (oder auch eine Sitzung per IPMI oder ILO) empfehlenswert.

Da bei der Erstellung eines Trunks die Konfiguration der zugrundeliegenden, physikalischen Netzwerkadapter nicht gelöscht wird, kann man in eine “Falle tappen”, wenn man für den neu erstellten, logischen Adapter dieselbe IP-Konfiguration verwenden möchte. Man erhält dann bei der Konfiguration schlicht den Hinweis, dass die eingestellte Adresse bereits vorhanden ist. Nach der Erstellung des Trunks hat man leider keinen Einfluss mehr auf die IP-Konfiguration der physikalischen Adapter so dass man in diesem Fall die nicht mehr benötigten Einstellungen direkt in der Registry entfernen muss:

HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces

Hier gibt es für jeden Netzwerkadapter einen Unterzweig mit den entsprechenden Einstellungen. Mithilfe der IP-Adresse hat man den entsprechenden Adapter schnell identifiziert und kann die Einstellungen

• IPAdress
• SubnetMask
• DefaultGateway

bereinigen.

Will man das Problem komplett umgehen, kann man auch die Einstellungen des physikalischen Adapters vor der Bildung des Trunks auf DHCP zurücksetzen (und ggf. vorher die Netzwerkverbindung trennen).

Ähnliches gilt bei der Auflösung eines Trunks. Man kann hier die gewünschte, spätere IP-Konfiguration der physischen Netzwerkadapter durchaus vorkonfigurieren, damit das System nach der Auflösung des Trunks direkt erreichbar ist. In meinen Tests wurde der logische Netzwerkadapter für den Trunk immer komplett aus der Registry entfernt.

Für einen Trunk gibt es noch einige, oft herstellerspezifische Optionen. Wichtig ist, dass auch dier LACP-Modus ausgewählt wird. Bei HP-Netzwerkkarten heißt die Option 802.3ad Dynamic with Fault Tolerance. Die zur Verfügug stehenden Optionen werden in folgenden Artikel ausführlicher beschrieben (mit zahlreichen Referenzen zu den entsprechenden Dokumentationen der Hersteller). Leider lässt sich die IP-Konfiguration des logischen Netzwerkadapters nicht vor dessen Aktivierung definieren, so dass dieser immer mit Standardeinstellungen (i.d.R. DHCP) aktiv wird. Ansosnten lässt sich der logische Netzwerkadapter wie jede andere Netzwerkkarte konfigurieren und verwenden.

Analyse und Messung

Um den Datendurchsatz zu messen, habe ich mich des Tools iperf (bzw. jperf) bedient. Bei iperf handelt es sich um ein Kommandozeilentool für Datendurchsatzmessungen per TCP oder UDP, jperf ist ein Java-basierter, grafischer Aufsatz dafür. Beides kann im Paket hier bezogen werden: http://code.google.com/p/xjperf/.

Für den Test muss mindestens ein System immer als Datenquelle und eines als Datensenke fungieren. Da in der grafischen Oberfläche die verwendeten Kommendozeilenoptionen für iperf ausgegeben werden, kann man diesen einfach auf die benötigten Systeme kopieren und anpassen. Damit vermeidet man gleichzeitig unnötige Java-Installationen.

Ich habe bei meinen Tests jeweils mit

• 16 Einzelverbindungen je Client zu Server Verbindung gearbeitet und jeweils 
• vier Quellserver auf
• ein Ziel

oder vice versa Daten verschicken lassen.

Ergebnisse

Wie sich bei meinen Tests sehr schnell herausstellte, findet eine Verteilung der Datenpakete stets nur in Senderichtung des Servers aus statt. Anfragen werden stets nur über einen dedizierten Port beantwortet. D.h. für den Beispielfall eines Backup-Servers, der Daten von verschiedenen Agents erhält, bringt das Szenario keinerlei Vorteile, ebenso wie für einen Dateiserver mit einem hohen Anteil an Schreibanforderungen. Für einen klassischen Dateiserver im KMU-Umfeld, der hauptsächlich als zentrale Datenablage für Dokumente, Zeichnungen und Nutzerprofile dient, kann das Trunking hingegen eine Entlastung bedeuten. Hier gilt es separat zu untersuchen, ob das Netzwerk wirklich der begrenzende Faktor ist und nicht etwa das zugrundeliegende Speichersystem, da viele verteilte Anfragen mehrerer Clients als zufällige E/A Anfragen auf dem Plattenspeicher landen, was bei Systemen mit wenigen Spindeln (was gerade im KMU Umfeld nicht unüblich ist) schnell zu Engpässen führt.

Testergebnisse mit 2-fach Port-Trunk

Eine letzte, festgestellte Eigenart möchte ich aber auch nicht vorenthalten: Mir ist es nur gelungen, über einen Gigabit an Daten über eine Switchverbindung zu transferieren, wenn die Verbindung physisch mindestens doppelt soviele Schnittstellen beinhaltet wie die Clients, d.h. in meinem Fall 4 Ports pro Switch. Ich vermute hier eine Eigenart der eingesetzten Hardware (D-Link DGS-1210-Serie), welche auch nur wenig Konfigurationsoptionen bezüglich der Verbindung erlaubt. Um genau zu sein, kann zwischen statischen und LACP-Trunking unterschieden werden sowie der Signalisierungszeitraum entweder auf 60 oder 3 Sekunden, sowie die einzelnen Ports bei der Verwendung von LACP zwischen aktiv und passiv umgeschaltet werden. Mir ist es nicht gelungen, für das Verhalten eine passende Erklärung zu finden. Abschließend habe ich nochmal mit einem Port-Trunk über vier physikalische Netzwerkadapter getestet, wobei sich bei diesem Test jeweils zwei Zielserver auf demselben Switch wie der Fileserver, sowie zwei weitere auf einem anderen Switch (angebunden über einen LACP-Trunk mit 2 Mitgliedern) befanden:

Testergebnisse mit 4-fach Port-Trunk

Erkennbar ist, dass die Skalierung bei vier Ports in meinem Szenario schon deutlich schlechter wird. Ich führe dass hauptsächlich auf die eben beschriebene Eigenart der Switchverbindung sowie zurück. Die D-Link Switche setzen LACP grundsätzlich auf der Basis von MAC-Adressen (Layer2) ein. Andere Geräte erlauben zusätzlich LACP Links auf der Basis von IP-Adressen (Layer3) oder TCP-Ports (Layer4) zu verteilen, was aber auch kontrovers diskutiert wird.

Fazit

Als Fazit aus diesen kurzen Tests möchte ich festhalten, dass Port-Trunking nur einen sehr eingeschränkten Nutzwert hat. In den meisten Fällen dürfte dieser in keinen Verhältnis zum erhöhten Implementierungsaufwand stehen, vor allem wenn die Einführung in eine bereits bestehende Umgebung erfolgt. In reinen Speichernetzen mit blockbasierten Speichergeräten erfolgt die Lastverteilung über mehrere physikalische Verbindungen im Regelfall über Multipath-Treiber, welche wesentlich weniger Einschränkungen besitzen.

Laut Microsoft Knowledge Base KB967482 ist die Ursache für diesen Fehler das nicht erweiterte Active Directory Schema für den Einsatz eines Read-Only-Domänencontrollers (RODC). Dies wird mit dem Kommandozeilen-Tool adprep erledigt:

adprep /rodcprep

Selbiger Befehl lieferte allerdings die folgende Fehlermeldung:

Lösung

Auch für diesen Fehler hat Microsoft aber eine Erklärung im Knowledge Base Artikel KB949257: Das Tool adpred versucht für jede Anwendungspartition innerhalb der Gesamtstruktur den Infrastrukturmaster zu aktualisieren -

1. ist die Partition nicht mehr vorhanden,
2. oder der Infrastrukturmaster wurde herabgestuft oder ist offline,

so schlägt der Versuch fehl. Ist die Partition vorhanden, so lässt sich der Fehler durch Korrektur des Attributes fSMORoleOwner via ADSI-Edit beheben:

• Verbindung mit Standardmäßiger Namenskontext herstellen
• Eigenschaften des Objektes CN=Infrastructure, DC=[Domain],DC=[TLD] aufrufen

Im Attribut fSMORoleOwner muss nun der verfügbare, aktive Domänencontroller nach folgenden Schema eingetragen werden (Server, Standort, Domain und TLD entsprechend abändern):

CN=NTDS Settings,CN=[Server],CN=Servers,CN=[Standort],CN=Sites,CN=Configuration,DC=[Domain],DC=[TLD]

In meinem (Fehler-)Fall enthielt der eingetragene Wert die Zeichenkette “\0ADEL:…”, welche auf eine gelöschte Replikationsverbindung verwies. (Tatsächlich hatte ich eine ursprünglich manuell erstellte Replikationsverbindung in den Active Directory-Standorte und Dienste gelöscht, da zwei weitere automatisch generierte Verbindungen bestanden.)

Dieser Wert ist innerhalb von ADSI-Edit auch rückwärts kontrollierbar: Im Namenskontext Konfiguration muss dieser Eintrag unter CN=Sites, CN=<Standort>,CN=Servers,CN=<Server>,CN=NTDS Settings zu finden sein.

Alternativ lässt sich auch das im KB-Artikel 949257 enthaltene VBS-Skript fixfsmo.vbs nutzen, welches nach dem Abspeichern wie folgt aufgerufen werden muss:

cscript /nologo fixfsmo.vbs DC=DomainDnsZones,DC=[Domain],DC=[TLD]

In meinem Fall wurde im Anschluss adprep /rodcprep fehlerfrei durchgeführt, der Aufruf von dcdiag lieferte ebenfalls keine Fehler mehr.

Wie war noch gleich die Konfiguration des Knotens (IP Adresse, Netzwerkkonfiguration, SSL Zertifikat usw.)?

Lösung

Eine Sicherung der Konfiguration ist seitens VMware von Haus aus vorgesehen. Dazu benötigt man das VMware vSphere Command-Line Interface (vSphere CLI). Darin enthalten sind einige Perl-basierende Skripte, mit denen unterschiedliche Konfigurationsänderungen an ESXi Host vorgenommen werden können. Für das Backup der Konfiguration eines ESXi Servers lautet der Aufruf beispielsweise:

vicfg-cfgbackup –server <esx-host> -s c:\backup.tgz

Das Tool fragt noch nach dem Benutzernamen und Passwort, beide Werte können aber gleich als Option mit angegeben werden. Für die Automatisierung könnte man sich nun ein Skript schreiben, in dem leider

• Passworte im Klartext enthalten sind und
• keine Protokollierung erfolgt.

Software ESXi Configuration Backup

Doch es gibt ein geniales kleines und freies Programm, welches eine vollautomatische, zyklische Sicherung der ESXi Host-Konfigurationsdaten ermöglicht: ESXi Configuration Backup 1.1 von Thibaut Lauziere.

Installation

Das Programm ist sehr kompakt (ca. 3 MByte) und muss zur Installation lediglich in einen beliebigen Ordner entpackt werden. In meinem Fall habe ich den Ordner

C:\Program Files (x86)\ESXi Configuration Backup

gewählt.

Konfiguration

Der oben beschriebene Ordner enthält das Programm Configuration Manager.exe, über das die initiale Einrichtung vorgenommen wird – alle Daten werden im Unterordner settings in den Dateien servers.ini und settings.ini abgelegt. Alle Passwörter sind dabei verschlüsselt gespeichert und nicht lesbar.

Für jeden ESXi Server sind der Hostname, das Login und zugehörige Passwort anzugeben (Reiter Server). Dabei können beliebig viele Server registriert werden. Im Reiter Settings muss nun noch das Sicherungsverzeichnis und Aufbewahrungsfrist gesetzt werden – zusätzlich wird der korrekte Pfad zur installierten vSphere CLI bestätigt.

Im Anschluss kann bereits das erste Backup manuell durchgeführt werden.

Arbeitsweise

Der Aufruf des Tools erfolgt letztlich über die ausführbare Datei ESXi Configuration Backup.exe im zentralen Ordner. Jedes Backup wird um Unterordner logs protokolliert (Format <jjjj>-<mm>-<dd>.log). Im oben eingestellten Zielordner wird pro Tag (Fomat <jjjj>-<mm>-<dd>.zip) eine ZIP-Datei erstellt, die alle Konfigurationen aller ESXi Server und deren Versionen enthält.

Automatisierung

Der automatische Aufruf des Tools erfolgt wiederum über die im Betriebssystem integrierte Aufgabenplanung. Als Aktion muss unter Programm starten lediglich der Aufrufpfad für die ESXi Configuration Backup.exe angegeben werden.

In meinem Fall starte ich das Programm täglich als SYSTEM-Account unter der Bedingung das die Netzwerkverbindung (über der die ESXi Server erreichbar sind) verfügbar ist.

Wiederherstellung

Zu jedem Backup gehört immer auch eine Wiederherstellung. Für eben diese muss man auf das Tool allerdings verzichten – das Einspielen der ESXi Konfiguration erfolgt manuell über das folgende vSphere CLI Kommando:

vicfg-cfgbackup –server <esx-host> -l <esx-host.tgz>

Fazit

Für die automatisierte Sicherung von ESXi Server-Konfigurationsdaten habe ich auf meiner Suche keine wirklich bessere Alternative zu ESXi Configuration Backup gefunden. Das Programm ist leicht verständlich, simpel, schnell eingerichtet und funktional – dafür ein Daumen hoch von mir.  Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.

Das Chromium Projekt hat für den beliebten (und von mir persönlich bevorzugten) Browser Google Chrome / Chromium die folgenden Gruppenrichtlinienvorlagen veröffentlicht. Damit ist eine zentrale Verwaltung und Steuerung des Browsers für Administratoren in Windows-Umgebungen möglich.

Die Vorlagen sind als ADM-Datei (Windows Server 2003) oder als neuere ADMX/ADML-Dateien (Windows Server 2008) verfügbar. Dabei werden selbige außer in Deutsch und Englisch noch in 50 weiteren Sprachen angeboten.

Alle Einstellungsmöglichkeiten werden in einer separaten – für alle Sprachen verfügbaren – Hilfedatei detailliert beschrieben. In meinen Augen eine beispielhafte perfekte Umsetzung, die so leider nicht einmal ansatzweise vom Hersteller Microsoft für seine Office 2010 Produkte in diesem Umfang angeboten wird.

Im Übrigen – und auch diese Information erhielt ich via RSS Feed von gruppenrichtlinien.de – empfiehlt das BSI (Bundesamt für Sicherheit in der Informationstechnik) den Einsatz von Google Chrome als sicheren Browser mit minimaler Angriffsfläche gegen Bedrohungen.

Laut Microsoft besteht hier kein Grund zur Sorge, das Verhalten ist normal, der Small Business Server funktioniert ohne Einschränkungen. Soweit so gut.

Problem

Leider führt das relativ häufige Auftreten des Fehlers und dessen Protokollierung dazu, dass die Benutzerdefinierte Ansicht Administrative Ereignisse nahezu unbrauchbar wird, da selbige eben keinen schnellen Überblick mehr zu Warnungen und Fehlern bietet. Die Konfiguration des Filters Administrative Ereignisse ist fest vorgegeben und lässt sich nicht manuell ändern.

Lösung

Abhilfe schafft hier nur die Abschaltung des Protokolls in der Ereignisanzeige über Anwendungs- und Dienstprotokolle, Microsoft, Windows, Kernel-EventTracing, Admin: Protokoll deaktivieren.

Im Anschluss werden keine Fehler – leider alle! – der Quelle Kernel-EventTracing mehr protokolliert, die Benutzerdefinierte Ansicht für Administrative Ereignisse ist so wieder nutzbar.

Fazit

Ein Problem und eine zugehörige Lösung nach dem Motto – nicht schön aber selten. Der beschriebene Weg ist sicher kein Non-Plus-Ultra, behebt aber recht schnell das beschriebene, lästige Verhalten. Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.

Für den Betrieb der einzelnen Microsoft Office Anwendungen sind – gerade auf einem Remotedesktop-Server – oftmals unterschiedliche Berechtigungen für verschiedene Benutzergruppen innerhalb einer Domäne nötig. Diese Einschränkung der möglichen Ausführung – bspw. von Microsoft Word (winword.exe)- nimmt der Administrator typischerweise in den Sicherheitseinstellungen auf Datei-Ebene (da alle Programm-Verknüpfungen letztendlich auf dieses eine Ziel verweisen) vor:

Im obigen Beispiel haben nur Mitglieder der eigens definierten Domänen-Gruppe der Microsoft Word Benutzer Zugriff (Lesen und Ausführen) auf Microsoft Word. Das SYSTEM sowie die Domänen-Administratoren haben in diesem Beispiel Vollzugriff. Diese Einstellungen funktionierten bisher reibungsfrei für alle Microsoft Anwendungen.

Problem

Die obigen Einstellungen wurden auch für Microsoft Excel (excel.exe) übernommen. Ein Benutzer – welcher zur Ausführung des Programmes berechtigt ist – erhält nun aber von Microsoft Outlook beim Öffnen einer Excel-Datei, welche als Anhang an einer E-Mail empfangen wurde, die folgende irreführende Fehlermeldung:

Nach der Bestätigung dieser Meldung informiert Outlook den Benutzer mit der folgenden Information:

Lösung

Bei der Suche nach der Behebung des Problems verfolgte ich zunächst den Ansatz, dass möglicherweise die Sicherheitseinstellungen für die Vorschau innerhalb von Microsoft Outlook fehlerhaft seien. In den Gruppenrichtlinien für Office 2010 fand ich lediglich die Einstellung für die geschützte Ansicht für Anlagen (Benutzerkonfiguration, Administrative Vorlagen, Microsoft Outlook 2010, Sicherheit), welche dieses Verhalten aber nicht beeinflusst.

Allerdings fand ich bei der Suche im Internet den Hinweis, dass durch Setzen des folgenden Registry-Schlüssels, Microsoft Outlook zur Anzeige von Excel-Daten in der Vorschau bewegt werden kann:

HKCU\Software\Microsoft\Office\14.0\Outlook\Security
Name: Level1Remove, Typ: REG_SZ, Wertdaten: .xlsx

Leider führte auch diese Konfiguration nicht zum gewünschten Erfolg – die Fehlermeldung erschien erneut. Aus diesem Grund setzte ich meine Recherche fort und fand schließlich diese nutzbringende Information. Für die Datei excel.exe hatte ich folgende Sicherheitsberechtigungen gesetzt:

• Lokaler Account: SYSTEM, Berechtigung: Vollzugriff
• Domänen-Gruppe: Domänen-Admins, Berechtigung: Vollzugriff
• Domänen-Gruppe: Microsoft Excel Benutzer, Berechtigungen: Lesen, Ausführen

Genau diese Einstellungen scheinen aber für Microsoft Excel zu restriktiv zu sein. Hier müssen speziell die folgenden Einstellungen vorgenommen werden.

• Lokaler Account: SYSTEM, Berechtigung: Vollzugriff
• Lokale Gruppe: Administratoren, Berechtigung: Vollzugriff
• Lokale Gruppe: Benutzer, Berechtigung: Ordner auflisten / Daten lesen, Erweiterte Attribute lesen, Berechtigungen lesen
• Domänen-Gruppe: Microsoft Excel Benutzer, Berechtigung:  Ordner durchsuchen / Dateien ausführen, Ordner auflisten / Daten lesen, Attribute lesen, Erweiterte Attribute lesen, Berechtigungen lesen

Mit diesen Einstellungen funktionierte im Anschluss auch die Outlook-Vorschau einer in einer E-Mail angehängten Excel-Datei ohne Probleme.

Fazit

Erstaunlicherweise tritt das oben beschriebene Verhalten nur in Verbindung mit Microsoft Excel auf. Dabei ließen sich Dateien im Netzwerk problemlos öffnen und bearbeiten. Nur bei in E-Mails angehängten Excel-Dateien, die via Outlook-Vorschau angezeigt oder von dort geöffnet werden sollten, trat der dokumentierte Fehler auf. Andere Anhänge wie etwa Word oder PDF-Dokumente wurden immer ohne Fehler angezeigt.

Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.

Doch es gibt Abhilfe auf die ich durch den Artikel von Nils gestoßen bin: Das Programm DelProf2 von Helge Klein ist eine Eigenentwicklung und führt die Arbeit von Microsofts veralteter DelProf-Version fort. Das Kommandozeilen-Werkzeug kommt ohne grafische Oberfläche aus und löscht vollständig alle veralteten Benutzerprofile vom System.

Leider lässt sich das Programm nicht über die Gruppenrichtlinien-Einstellungen für die Skript-Ausführung beim Computer-Start aufrufen, Grund genug für mich ein kleines VBS-Skript delprof-system.vbs zu schreiben, welches diese Arbeit automatisiert erledigt:

...
strExec = "\\" & FQDN & "\Netlogon\Tools\DelProf2.exe"
strParam = " /u"
If objFSO.FileExists(strExec) Then
 Set oExec = WshShell.Exec(strExec & strParam)
 Do While Not oExec.StdOut.AtEndOfStream
 OutPut = Output & oExec.StdOut.Readline() & vbCr
 Loop
End If
..

Für eine erfolgreiche Ausführung des Skriptes ist zum Einen das Programm DelProf2 erforderlich, zum Anderen die folgende Ordnerstruktur in der NETLOGON-Freigabe der Domäne (oder die Änderung des Pfades in delprof-system.vbs in Zeile 12 ):

\\FQDN\Netlogon\Skripte\delprof-system.vbs
\\FQDN\Netlogon\Tools\delprof2.exe

Der Aufruf des Skriptes erfolgt über Gruppenrichtlinien im Teil der Computerkonfiguration für die betreffenden Terminalserver (Computerkonfiguration, Richtlinien, Windows-Einstellungen, Skripts (Start/Herunterfahren), Starten):

Wie im Bild zu erkennen, wird hier gleichzeitig ein weiteres Skript ausgeführt, welches ich bereits seit geraumer Zeit nutze, um den zentralen temporären Ordner eines Systems beim Start zu leeren (In meinem Fall C:\Temp).

Mit dieser Einstellung wird nun bei jedem Start auf dem betreffenden System(en) der Benutzerprofilordner

• %SystemDrive%\Users\ bei Windows Server 2008 R*
• %SystemDrive%\Dokumente und Einstellungen\ bei Windows Server 2003 R*

geleert und somit von “Rückständen” bereinigt – Systemorder wie All Users, Default bzw. Public bleiben selbstverständlich unangetastet. Wie bei allen meinen Skripten wird der Status der Ausführung (erfolgreich = Information, nicht erfolgreich = Fehler) der Skripte und – in diesem Fall – die Ausgabe von DelProf im Anwendungsereignisprotokoll dokumentiert.

Ich bin mit DelProf2 und dem Skript sehr zufrieden, das Konstrukt hat sich mittlerweile mehrfach bewährt. Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.

Das Problem wurde vom Internet Explorer 9 verursacht, dieses Verhalten wurde nun aber durch das Sicherheitsupdate für Microsoft Windows (KB2618444) beseitigt.

Die Meldung findet man auch im System-Ereignisprotokoll (Event ID 26, Application Popup):

Anwendungspopup: Tool zum Vorbereiten der Migration von Windows Small Business Server 2011 Standard: Um den Quellserver für die Migration vorbereiten zu können, müssen Sie Mitglied aller folgenden Sicherheitsgruppen sein: “Organisations-Admins”, “Schema-Admins” und “Domänen-Admins”. Weitere Informationen finden Sie in dem Artikel unter “http://go.microsoft.com/fwlink/?LinkId=190413″.

Problem

Das Tool selber startet nach dieser Meldung nicht. Der betroffene Benutzer ist aber Mitglied der drei aufgeführten Gruppen:

Leider findet man im Artikel von Microsoft, noch im Migrationsleitfaden für den Small Business Server 2011 einen entscheidenden Hinweis.

Lösung

Erst die Suche im Internet brachte die Lösung, den Artikel von Ronny Pot (Share iT).

Die primäre Gruppe des Benutzers darf nicht einer der oben aufgeführten, also den

• Organisations-Admins
• Schema-Admins
• Domänen-Admins

enstprechen. In meinem Fall fügte ich den Benutzer zur Gruppe der Domänen-Benutzer hinzu und legte diese als primäre Gruppe fest:

Danach startete das Migrationstool für den Small Business Server 2011 ohne Probleme:

Fazit

Dank der bereits vorliegenden Lösung für das Problem hielt sich der zeitliche Aufwand in Grenzen. Deshalb soll mein Beitrag hauptsächlich der internen Dokumentation und zur Hilfestellung für Leidensgenossen in deutscher Sprache dienen.

Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.