Diesen Monat stopf Microsoft so einige Sicherheitslücken in seinen Betriebssystemen und Anwendungen. Zwölf Sicherheitsupdates, sieben kritische und fünf als wichtig eingestufte, werden am nächsten Dienstag über die automatischen Updates ausgeliefert.

In den bisher veröffentlichten Informationen zu den Updates zeigt sich, dass eine breite Palette von Microsoft-Produkten betroffen ist:

• Windows in allen aktuellen Versionen
• Internet Explorer 6 und 7
• Windows Media Player 11
• Outlook Express 5.5 und 6
• Windows Messenger 4.7 und 5.1
• Access bis 2007
• Excel einschließlich 2007
• PowerPoint einschließlich 2007
• Word bis 2007

Spielen Sie daher die Updates zeitnah auf Ihren Rechnern im Netzwerk ein. 

Voraussichtlich erscheinen die Updates am 12.08. gegen Abend. Damit Ihnen die neuen Updates direkt angezeigt werden, geben Sie in der Kommandozeile den Befehl  wuauclt /detectnow ein. Der Dienst für die automatischen Updates auf Ihrem Rechner prüft dann umgehend, ob neue Updates vorliegen.

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.

Das Service Pack 3 für Windows XP  wird ab heute über die automatischen Updates verteilt.

Mittlerweile hat Microsoft zwar die meisten Probleme hiermit behoben, jedoch berichten einzelne Leser immer noch, dass sie das Service Pack aufgrund von Problemen wieder deinstalliert haben.

Mit dem Service Pack Blocker Tool Kit verhindern Sie die Installation des Service Packs sowohl in Domänenumgebungen, als auch auf Ihrem einzelnen Rechner, auch ohne Windows Server Update Services (WSUS) oder andere Zusatzsoftware.

Falls Sie Service Pack 3 einsetzen, beachten Sie auch die Änderungen bei der Nutzung des Remote Desktop-Clients, zu dem unsere Redaktion immer noch vereinzelt Rückfragen bekommt.

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”.

Bereits im letzten Beitrag habe ich die Frage vieler Leser aufgegriffen, wie sie auch nach der Installation des aktuellen Remote Desktop Clients (z.B. mit Service Pack 3 für Windows XP) eine Konsolensitzung per Remote Desktop Protokoll (RDP) zu ihrem Windows Server 2003 aufbauen können. Microsoft hat den Schalter hierfür in der Version 6.1 des Remote Desktop Clients von “/console” schlichtweg in “/admin” umbenannt. Dabei wurden dem Schalter allerdings neue Funktionen für den Windows Server 2008 hinzugefügt, die gar nicht mit der Konsolensitzung zusammenhängen.

Im Windows-Admin-Blog 4sysops sehen Sie, dass das Verwirrspiel um mstsc /console und mstsc /admin weit über die Namensänderung hinaus geht. Denn während der Schalter “/admin” nun auf Ihrem Windows Server 2003 eine Konsolensitzung öffnet, ist das Verhalten bei einer Verbindung zu einem Windows Server 2008 gänzlich anders. Hier ist es Ihnen nicht mehr möglich, sich mit der sogenannten 0-Sitzung (der Konsolensitzung) des Servers zu verbinden.

Im Windows Server 2003 war dies noch als zusätzliche dritte Sitzung möglich, neben den beiden normalen Sitzungen (mit den zwei enthaltenen Zugriffslizenzen). Beim Server 2008 ist dies nicht mehr der Fall, wodurch Sie nur noch die zwei enthaltenen Zugriffslizenzen nutzen können. Eine Ausnahme hat Microsoft als Überbleibsel des “/console”-Schalters jedoch belassen: Haben Sie für Ihren Windows Server 2008 die Rolle “Terminaldienste” aktiviert, verschlingt Ihre Sitzung, die Sie mit dem Schalter “/admin” öffnen, keine Zugriffslizenz.

Der Schalter “/admin” deaktiviert beim Zugriff auf Ihren Windows Server 2008 nun lediglich Funktionen, die bei administrativen Arbeiten nicht benötigt werden. Hierunter fällt beispielsweise das neue EasyPrint, das die Druckernutzung bei der Arbeit in Terminal Server-Sitzungen für Ihre Mitarbeiter erheblich vereinfacht. 

Eine detaillierte Beschreibung zu der Änderung im RDP erhalten Sie auch direkt bei Microsoft. Warum Microsoft den Schalter “/admin” bei Verbindungen zum Windows Server 2003 für die Konsolensitzung missbraucht und nicht den Schalter “/console” hierfür belassen hat, bleibt aber auch in Microsofts Beschreibung ungeklärt.

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\.