Microsoft hat das Power Pack 1 für den Home Server nun endlich auch für die deutschsprachige Version veröffentlicht.

Damit soll dem Datenverlust auf dem Home Server ein Ende bereitet werden. Bereits Ende Juli war das Power Pack in der englischen Version erschienen.

Auch die passende Dokumentation steht nun auf Deutsch zur Verfügung. Bisher sind keine Probleme bekannt, die Sie an der Insatallation des Power Packs hindern sollten. Sie können es daher ruhigen Gewissens auf Ihrem Server einspielen :-)

Benutzer des Windows Home Servers warten seit Monaten auf die Behebung eines essentiellen Fehlers, durch den unter bestimmten Umständen Daten auf Ihrem Server beschädigt werden.

Ungewöhnlich lange hat es nun gedauert, bis das Problem endgültig behoben wurde. Microsoft hat das Power Pack 1 mittlerweile veröffentlicht und behebt damit den Fehler. Darüber hinaus erweitern Sie mit dem Update auch die Funktionen des Home Servers um die folgenden Features:

• Unterstützung von Windows Vista-Computern mit 64 Bit
• Datensicherung von freigegebenen Ordnern
• Verbesserungen beim Remotezugriff
• Effizienterer Energieverbrauch
• Verbesserte Leistung

Bisher steht das neue Power Pack nur für englischsprachige Systeme zur Verfügung. Als deutschsprachiger Anwender müssen Sie sich noch bis zum August gedulden. Bis dahin sind allerdings die ersten Erfahrungen mit möglichen Problemen im Zusammenhang mit dem Power Pack 1 bereits von den englischsprachigen Benutzern gesammelt. Sie können das Power Pack somit kurz nach dem Erscheinen ohne große Bauchschmerzen einspielen.

Die Entwickler von Microsoft haben nun endlich das Problem beseitigen können, das auf einigen WSUS-Servern für einen Stopp der Update-Auslieferung an Clients mit installiertem Office 2003 sorgte.

Mit einem Update, das Sie bei Microsoft manuell herunterladen können, wird das Problem nun endgültig behoben.

Sie konnten bereits über die Sperrung des Updates, das den Fehler hervorgerufen hatte, Abhilfe schaffen und so die restlichen Updates installieren lassen. Diese kurzfristige Lösung sollten Sie nun aber wieder beseitigen und die Sperrung aufheben. Installieren Sie jedoch zuvor das oben erwähnte Update von Microsoft.

Laut Microsoft müssen Sie das Update auf einem Windows Server 2008 manuell mit der rechten Maustaste und der Option “Als Administrator ausführen…” unter Admin-Rechten starten, um es erfolgreich zu installieren.

Microsoft hat mittlerweile offiziell bestätigt, dass seit dem Erscheinen der aktuellen Juni-Updates ein bisher noch ungelöstes Problem mit den Windows Server Update Services (WSUS) besteht.

Aufgetreten ist der Fehler bisher bei WSUS 3.0 und WSUS 3.0 mit Service Pack 1, jeweils in Kombination mit Microsoft Office 2003 auf den Client-Systemen. Auf den Clients wird die Installation mit der folgenden Fehlermeldung im Installationslog abgebrochen:

PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://<WSUS Server>/ClientWebService/client.asmx

PT WARNING: SyncUpdates failure, error = 0×8024400E, soap client error = 7, soap error code = 400, HTTP status code = 200

PT WARNING: SOAP Fault: 0×000190

Microsofts erste Untersuchungen haben ergeben, dass eine Erneuerung des Service Pack 1 für Office 2003 die Probleme verursacht. Damit Sie Ihre Clients mit den aktuellen Updates versorgen können, müssen Sie auf Ihrem WSUS Server das entsprechende Update ablehnen. Damit Sie das richtige Update erwischen, prüfen Sie vor dem Ablehnen, ob das gefundene Update mit Service Pack 1 für Office 2003 in den Eigenschaften die folgende Update-ID besitzt:
D359F493-0AAD-43FA-AF5C-6763326CD98F.

Nach dem Ablehnen des Updates für alle Client-Systeme geben Sie in der Kommandozeile Ihrer Clients den Befehl “wuauclt /detectnow” ein, durch den die Clients auf Ihrem WSUS Server nach neuen Updates suchen. Ob Sie das Problem erfolgreich lösen konnten, sehen Sie in den Logdateien. Die Client-Logdatei “WindowsUpdate.log” finden sie direkt im Windows-Verzeichnis des Clients. Die entsprechende Fehlerprotokollierung für Ihren Server finden Sie in der Datei “SoftwareDistribution.log” im WSUS-Installationsverzeichnis unterhalb des Ordners “Log Files”.

Nach der Installation des aktuellen Remote Desktop Clients klagen unsere Leser häufig darüber, dass sie nicht mehr die Möglichkeit haben, über den Schalter “/console” die Konsolensitzung eines Rechners zu öffnen.

In den bisherigen Versionen des Remote Desktop Clients diente der Schalter “/console” dazu, sich mit der Konsolensitzung des entfernten Rechners zu verbinden, anstatt eine weitere Sitzung zu öffnen.

Die allgemeine Verwirrung ist kein Wunder, denn Microsoft hat einfach den Namen des Parameters geändert, jedoch die Hilfedateien nicht entsprechend aktualisiert. Über die Taste [F1] suchen Sie vergeblich nach Hilfe. Die veralteten Informationen nennen Ihnen weiterhin den Schalter “/console” für das Öffnen einer Konsolensitzung.

Microsoft hat den Schalter „/console“ bei der neuen Version des Remote Desktop Clients umbenannt. Sie müssen nun den Parameter „/admin“ nutzen. Der neue Client (aktuelle Version ist 6.1) ist in Windows Vista und ins Service Pack 3 von Windows XP integriert. Sie können Ihn aber ebenso separat über Microsofts Download-Portal herunterladen.

Übrigens: Mit “Start” -> “Ausführen” -> “mstsc /?” bekommen Sie die möglichen Parameter angezeigt. Diese Auflistung kommt direkt aus dem Programm und ist unabhängig von den Informationen in der Hilfe. Hier finden Sie auch den richtigen Schalter für die Konsolensitzung.

Gestern hat ein Leser mir über ein seltsames Phänomen berichtet: In seinem Unternehmen zeigen manchmal auf einigen Clientrechnern Verknüpfungen plötzlich aus ungeklärten Gründen auf eine andere Version der Datei auf einem Server liegenden Zieldatei der Verknüpfung. Die Benutzer hatten das Ziel der Verknüpfung jedoch angeblich nicht manuell geändert.

Das Problem lag hierbei darin, dass Windows automatisch versucht, das Ziel zu einer Verknüpfung zu finden, wenn die Datei nicht zur Verfügung steht. Hier gilt wirklich der altbekannte Spruch: “It’s not a bug, it’s a feature”. Das Verhalten ist vollkommen beabsichtigt. Die Verknüpfungen sollen damit automatisch repariert werden, wenn die Zieldatei verschoben wurde.

Bedacht ist bei dieser Funktion jedoch nicht, dass auch vollkommen identische Dateien nicht unbedingt die gleiche Bedeutung haben müssen. Als ich selber vor knapp über einem Jahr mit Problem konfrontiert war, öffnte sich auf einigen Clients in einem Unternehmen eines Tages die Testumgebung des ERP-Systems (Enterprise Resource Planning) anstelle des Produktivsystems. Die Datei zum Starten der Testumgebung war in diesem Fall 1 zu 1 identisch mit der Startdatei für das Produktivsystem. Allerdings teilte dem Programm eine Konfigurationsdatei im Installationsverzeichnis die Datenquelle (entweder Test- oder Produktivdatenbank) mit. 

Das Problem tritt entweder auf, wenn die Zieldatei einer Verknüpfung kurzzeitig nicht erreichbar ist (z.B. bei einer Netzwerkunterbrechung, wenn die Zieldatei auf einem Server liegt), oder wenn die Zieldatei der Verknüpfung verschoben oder gelöscht wurde.

Selbstverständlich können Sie die automatische Suche nach dem Verknüpfungsziel unter Windows deaktivieren. Hierzu nutzen Sie in der Registrierung den Schlüssel “HKEY_CURRENT_USER\Software\Microsoft\Windows\ CurrentVersion\Policies\Explorer\”, unter dem Sie einen DWORD-Wert namens “NoResolveSearch” erstellen. Geben Sie diesem anschließend den Wert “1″.

Der große Haken daran: Die Einstellung muss für jeden Benutzer auf jedem Rechner vorgenommen werden, auf dem er arbeitet. Sie sollten den Eintrag also entweder durch ein Script oder mit einer selbsterstellten administrativen Vorlage über die Gruppenrichtlinien setzen.

Sicherlich kennen Sie bereits einige der zahlreichen Tools von Sysinternals, das mittlerweile zu Microsoft gehört. Aber kennen Sie auch Sysinternals Live? Das neue Projekt, das sich noch in der Beta-Phase befindet, ist unter http://live.sysinternals.com/ für Sie erreichbar.

Was zunächst nur wie eine chaotische Auflistung der Tools von Sysinternals wirkt, ist für Sie als Administrator auf den zweiten Blick eine absolut nützliche Arbeitshilfe. Da die Tools keine Installation benötigen, können Sie auf jedem beliebigen PC mit Internetanbindung sofort die aktuelle Version der Programme verwenden.

Noch hilfreicher als der Zugriff über den Browser erweist sich die Möglichkeit, dass Sie sich unter “Start” -> “Ausführen” per \\live.sysinternals.com\tools\ das Verzeichnis anzeigen lassen und z.B. per \\live.sysinternals.com\tools\procexp.exe direkt den Process Explorer starten können. Beim ersten Aufruf müssen Sie sich hier aber leider ein Wenig gedulden.

In der Eingabeaufforderung ist es Ihnen zudem möglich, das Verzeichnis mit den Tools von Sysinternals zu mappe, z.B. als Laufwerk “S:”: net use S: \\live.sysinternals.com\tools\.

Wenn Sie auf Ihrem Vista-Client Fehlermeldungen oder Einstellungen dokumentieren wollen, nutzen Sie hierfür am besten das integrierte Snipping Tool. Sie finden es im Startmenü unter “Start” -> “Alle Programme” -> “Zubehör” -> “Snipping Tool”.

Falls es auf Ihrem System noch nicht installiert ist, fügen Sie es über “Systemsteuerung” -> “Programme und Funktionen” ->  “Windows-Funktionen ein- oder ausschalten” hinzu, indem Sie “Optionale Tablet PC-Komponenten” aktivieren.

Beim Programmstart graut sich Ihr gesamte Bildschirm aus. Über den Pfeil neben dem “Neu”-Button wählen Sie aus, ob Sie den Auswahlbereich mit einem Rechteck, frei Hand oder direkt ein komplettes Fenster markieren wollen.

Unter “Extras” finden Sie nach dem Erstellen eines Screenshots Stiftwerkzeuge und einen Textmarker, mit denen Sie Markierungen im Screenshot vornehmen.

Das Tool speichert Ihre Screenshots auf Wunsch in den Formaten PNG, GIF, JPEG oder HTML.

Leider steht das Programm beim Windows Server 2008 nicht zur Verfügung. 

“Event-ID 16644: The maximum domain account identifier value has been reached. No further account-identifier pools can be allocated to domain controllers in this domain.”

Wahrscheinlich haben Sie diese Meldung bisher noch nicht gesehen. Das Limit der SIDs (Security Identifier) in einer Domäne kann aber ebenso erreicht werden, wie andere Grenzen.

Microsoft schlägt in diesem Fall übrigens als Workaround vor, eine zusätzliche Domäne zu erstellen und eine Vertrauensstellung zwischen den Domänen einzurichten, damit Sie einen neuen SID-Pool zur Verfügung haben.

Sicherlich profitieren Sie davon, wenn dies nicht ad hoc und auf die Schnelle geschehen muss, sondern rechtzeitig von Ihnen eingeplant und vorbereitet werden kann.

Microsoft hat deshalb diese Beschränkungen des Active Directory nun veröffentlicht. Auch wenn die Grenzen natürlich so hoch gesteckt sind, dass sie nicht so schnell erreicht werden, sollten Sie als Administrator sie zumindest kennen.

Im Folgenden finden Sie eine Übersicht der Limits des Active Directory:

• SIDs: Eine Domäne kann ca. eine Milliarde SIDs erzeugen
• Gruppenmitgliedschaften: Maximal kann ein Objekt in 1.015 Gruppen Mitglied sein
• FQDN-Namen: Der vollständige FQDN (Fully Qualified Domain Name) in der Domäne darf 64 Zeichen nicht überschreiten
• Dateinamen: Dateinamen inklusive Pfad dürfen maximal 260 Zeichen lang sein
• Organisationseinheit: Der Name einer OU (Organizational Unit) kann maximal eine Länge von 64 Zeichen haben
• Gruppenrichtlinien: Es können maximal 999 Gruppenrichtlinien auf ein Benutzer- bzw. Computerkonto angewendet werden
• LDAP-Operationen: Die empfohlene maximale Anzahl liegt bei 5.000 Operationen pro LDAP-Transaktion
• Domains: Maximal dürfen 800 Domains in einem Forest sein, wenn die Gesamtstruktur-Funktionsebene allerdings auf Windows Server 2003 eingestellt ist, sind 1.200 Domains möglich.
• Domänencontroller: Empfohlen wird, die Anzahl von 1.200 Domänencontrollern pro Domäne nicht zu überschreiten. Nutzen Sie Active Directory integrierte DNS-Zonen, müssen Sie bereits ab 800 Domänencontrollern Besonderheiten beachten.

Besonders die Begrenzung des Fully Qualified Domain Name auf 64 Zeichen sollten Sie beachten, wenn Sie Ihre Domain einrichten. Wählen Sie hier keinen zu langen Namen, damit Sie später bei der Benennung von Objekten in der Domäne keine böse Überraschung erleben.

Falsche DLL-Versionen (Dynamic Link Library) oder Fehlermeldungen, die auf irgendwelche unbekannten DLL-Dateien verweisen, sind im Admin-Alltag leider keine Seltenheit. Sicherlich hatten Sie auch schon Probleme mit einer falschen DLL-Version oder brauchten Details zu einer bestimmten DLL-Datei. Wenn ich Informationen über DLLs suche, dann verwende ich die Online-Datenbank von Microsoft.

Während in Deutsch bisher nur Daten für eine enge Auswahl an Produkten zur Verfügung stehen, bringt ein Wechsel zu englischsprachigen Variante eine große Menge an Informationen zutage.

Hier finden Sie nicht nur Informationen darüber, welche DLL-Dateien in welcher Version vorhanden sein sollten. Sie suchen hier auch gezielt nach der Beschreibung zu einer bestimmten DLL-Datei, wenn diese einen Fehler verursacht.

Schade nur, dass die Informationssammlung anscheinend mit der technischen Entwicklung nicht Schritt halten kann: Die aktuellsten Dateiversionen für den Windows Server 2003 betreffen das SP1.

Trotzdem konnte ich Freitagnachmittag einem Leser damit zur Lösung eines Problems verhelfen und wollte es mir nicht nehmen lassen, diesen Tipp auch hier zu veröffentlichen.