WSUS und das Windows 10 Anniversary Update

Veröffentlicht am Veröffentlicht in Computer

Im Zusammenhang mit dem Anniversary Update 1607 und WSUS gab es gleich mehrere Probleme, die mich einige ganze Tage Fehlersuche gekostet haben:

Mit dem Anniversary Update 1607 hat Microsoft begonnen, die Updates an den WSUS verschlüsselt auszuliefern. Damit das funktioniert, muß der WSUS natürlich von dieser Verschlüsselung wissen. Dafür gab es mit KB3159706 ein Update für den WSUS. Dummerweise ist dieses WSUS-Update aber erst ein paar Tage nach der Veröffentlichung des Anniversary Updates erschienen. Wenn man jetzt in diesen paar Tagen das Anniversary Update im WSUS genehmigt und damit heruntergeladen hat, hatte man ein Problem:
Der ungepatchte WSUS hat das Anniversary Update verschlüsselt wie es war den Clients zur Verfügung gestellt. Diese habe das Update gesehen, heruntergeladen und versucht zu installieren. Diese Installation am Cient ist aber sofort mit dem Fehler 0xC1800118 abgebrochen. Microsoft hat mehrere Wochen (!) gebraucht um eine Lösung zu finden, wie man die WSUS-Datenbank wieder soweit bereinigen kann, das sich der jetzt gepatchte WSUS die Updates neu herunterlädt und dann sauber entschlüsselt. Die mit viel Handarbeit (PowerShell und SQL) verbundene Lösung wird in KB3194588 beschrieben.

Damit konnten Clients dann ohne Probleme das Anniversary Update 1607 installieren. Beim Versuch nachfolgende Einzelupdates zu installieren, bleibt Windows-Update aber bei „0% herunterladen“ hängen. Ein Blick in das (tiefrote) Ereignisprotokoll zeigt, dass jede Menge Dienste (darunter der „Intelligente Hintergrundübertragungsdienst“ und „Windows Update“) so oft unerwartet beendet wurden, dass sie auf manuellen Start umgestellt wurden und nicht liefen. Nach langem Suchen hat sich herausgestellt, dass man das jeweils aktuellste „Cumulative update for Windows 10 Version 1607“ (zur Zeit ist das KB3197356) mit dem Internet Explorer aus dem Microsoft Update Catalog herunterladen und manuell auf dem Client installieren muß. Nach dem obligatorischen Neustart fängt Windows Update sofort an ohne Probleme die fehlenden weiteren Updates vom WSUS zu laden und zu installieren. Die vorher unerwartet beendeten Dienste laufen jetzt normal.

„Authentifizierung auf Netzwerkebene“ Fehler trotz installierten Updates

Veröffentlicht am Veröffentlicht in Computer

Von einem sauber aktualisiertem Windows 7 Client soll per Remotedesktopverbindung auf einen Windows 2008 Server zugegriffen werden. Per Gruppenrichtlinie wird in der Domäne die Authentifizierung auf Netzwerkebene erzwungen. Trotz der installierten Updates klappt die Verbindung nicht und es wird die Fehlermeldung „Der Remotecomputer erfordert die Authentifizierung auf Netzwerkebene. Diese Funktion wird von Ihrem Computer nicht unterstützt. Wenden Sie sich an den Systemadministrator oder den technischen Support, wenn Sie Hilfe benötigen.“ angezeigt.

Der Menübefehl „Info“ (Rechtsklick auf die Titelzeile des Remotedesktopverbindungs-Fensters) zeigt aber korrekt sowohl „Authentifizierung auf Netzwerkebene wird unterstützt“ als auch „Das Remotedesktopprotokoll 8.1 wird unterstützt“ an.

Die einfache Lösung für dieses Problem habe ich in diesem Posting gefunden: Einfach die beiden versteckten Dateien „Default.rdp“ und „Default.bak“ in den „Dokumenten“ löschen (werden automatisch neu angelegt), danach klappt die Verbindung auf Anhieb!

Windows Updates auf Windows 7 ohne ewige Wartezeiten installieren

Veröffentlicht am Veröffentlicht in Computer

Seit vielen Monaten ist es kaum mehr möglich auf einem frisch installiertem Windows 7 die üblichen 100+ Windows Updates ohne ewige Wartezeiten (wenn überhaupt) zu installieren.

Ich habe es vor ein paar Tagen noch einmal probiert: Auf einem nagelneuem PC (SSD, VDSL-Anschluß) hat die Suche nach Windows Updates 14 Stunden gedauert. Nach Klick auf „Installieren“ wurde dann für weitere 12 Stunden „Installation wird vorbereitet“ angezeigt, worauf ich den Vorgang dann abgebrochen habe. Das ging immerhin ohne Probleme innerhalb weniger Sekunden.

Ich habe sehr viele Beiträge zu diesem Thema gefunden. Die Grundproblematik liegt wohl darin, dass der Windows Update Dienst selbst im Lauf der Zeit mehrfach aktualisiert wurde und die ursprüngliche Version – die auf einem neu installierten System vorhanden ist – nicht mehr funktioniert. Wie in Blogpostings wie diesem beschrieben wird, ändert sich das Problem mit dem Erscheinen neuer Updates immer wieder, aber im Moment läßt sich Windows Update durch die Installation vom „Juli 2016 Update Rollup (KB3172605)“ wieder reaktivieren. Dieses Update enthält wohl die aktuellste Fassung des Windows Update Dienstes. Bei mir war es nicht nötig, aber scheinbar meldet dieses Update bei der Installation häufig, dass es nicht für diesen PC geeignet wäre. In diesem Fall muß vorher KB3020369 installiert werden.

Um dieses (oder diese) Updates installieren zu können, muß man den passenden Standalone-Installer von der Microsoft-Website herunterladen, in der Systemsteuerung Windows Update auf „Nie nach Updates suchen (nicht empfohlen)“ umstellen und den PC neu starten. Dann den heruntergeladenen Updater laufen lassen, der ohne Probleme durchlaufen sollte. Dann den PC wieder neu starten und die Einstellung in der Systemsteuerung Windows Updates auf den ursprünglichen Wert zurückstellen. Es wird dann automatisch nach Windows Updates gesucht, was jetzt in normaler Zeit (in meinem Fall ca. 10 Minuten) funktionieren sollte.

Microsoft Updates unter Windows 7 aktivieren

Veröffentlicht am Veröffentlicht in Computer

Die Standardeinstellung für Windows Updates unter Windows 7 ist „Nur für Windows“. Um diese Einstellung auf „Für Windows und andere Produkte von Microsoft Update“ zu ändern, kann man in der Systemsteuerung Windows Update in der entsprechenden Zeile auf den Link „Weitere Informationen“ klicken, wodurch dann die Microsoft Updates Webseite geöffnet wird. Dort muß man dann einmalig der Änderung zustimmen und erhält ab diesem Zeitpunkt wie gewünscht zusätzliche Updates.

Auf einem neu installiertem PC habe ich zuerst die üblichen 100+ Windows Updates installiert und wollte anschließend auf Microsoft Update umstellen. Der oben beschriebene Link „Weitere Informationen“ hat hier aber nur auf eine Seite mit zwei Screenshots geführt, auf der beschrieben wird wie man unter Windows 7 die Systemsteuerung Windows Update öffnet. Nach einiger Recherche hat sich das als Problem des Internet Explorer 11 herausgestellt: Die Microsoft Update Website funktioniert im IE 11 nur, wenn man sie im Kompatibilitätsmodus aufruft!

Dazu wählt man im IE 11 im „Zahnrad-Menü“ den Befehl „Einstellungen der Kompatibilitätsansicht“ und fügt im folgenden Dialog microsoft.com zu der Liste hinzu. Nach Beenden und neu Starten des IE 11 funktioniert dann die Microsoft Update Website wie erwartet.

VMware vCenter Plug-Ins werden mit SSL/TLS-Fehler nicht geladen

Veröffentlicht am Veröffentlicht in Computer

Bei einem Kunden mit einer etwas älteren VMware Installation ist mir aufgefallen, dass im vSphere-Client der Reiter „Hardware Status“ fehlt, in dem u.a. der Zustand der Festplatten überprüft werden kann.

Das Problem hatte ich schon einmal, daher war mir die Lösung bekannt: Einfach im Menü „Plug-ins -> Manage Plug-ins…“ aufrufen und das nicht gestartete Plug-in mit der rechten Maustaste und „enable“ aktivieren. Dies wird z.B. in diesem Posting beschrieben.

Nur war das in diesem Fall leider nicht möglich. In dem Plug-ins Fenster wurde bei jedem deaktiviertem Plug-in ein Fehler „Could not create SSL/TLS secure channel“ angezeigt. Die Lösung habe ich in einem Posting im VMware-Forum gefunden: Das Microsoft Update KB3161639 (bzw. das Update Rollup KB3161608 in dem das problematische Update enthalten ist) verändert die Sicherheitseinstellungen von Windows so, dass der vCenter nicht mehr sauber funktioniert. In dem Posting wird empfohlen folgenden Registry-Key anzulegen, der die Systemsicherheit nicht so beeinträchtigt wie es die Deinstallation des Microsoft Updates tun würde.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\
  KeyExchangeAlgorithms\Diffie-Hellman]
"ClientMinKeyBitLength"=dword:00000200

Dies hat bei mir funktioniert, seit dieser Registry-Key existiert starten die vCenter Plug-ins wieder und der „Hardware Status“ Reiter wird daher auch wieder angezeigt.

Windows Server Backup und lokaler User auf NAS

Veröffentlicht am Veröffentlicht in Computer

Ich habe heute auf einem Windows Server 2008 R2 eine Sicherung mit der (als Feature nachzuinstallierenden) „Windows Server-Sicherung“ eingerichtet. Der lokale Server soll auf eine Freigabe auf einer NAS (Synology) gesichert werden.

Die NAS ist nicht Mitglied der Domäre, weshalb für den Zugriff auf die Freigabe die Zugangsdaten eines lokal auf der NAS eingerichteten Users erforderlich sind. Somit hat kein Domänenbenutzer Zugriff auf die Freigabe und ein evtl. Verschlüsselungstrojaner tut sich etwas schwerer auf die gesicherten Daten zuzugereifen.

Bei der Definition der Sicherung habe ich als Sicherungsziel den „Freigegebenen Remoteordner“ angegeben und den User in der Form „NAME_DER_NAS\Lokaler_Username“ angegeben. Dies führt beim Abschluß der Sicherungs-Definition zu einer (ziemlich unspezifischen) Fehlermeldung.

Der Grund für diesen Fehler liegt in der Tatsache, dass der in der Sicherung verwendete User Mitglied der lokalen Windows-Gruppe „Sicherungs-Operatoren“ sein muß, was der lokale NAS-User natürlich nicht ist.

Die (etwas unschöne) Lösung ist sowohl auf der NAS als auch auf dem Windows Server jeweils einen lokalen User mit exakt gleichem Namen und Kennwort anzulegen und den Windows User zum Mitglied der „Sicherungs-Operatoren“ zu machen. Bei der Definition der Sicherung muß man den User dann unbedingt in der kurzen Form „Lokaler_Username“ angeben. Damit findet Windows einen Sicherungs-Operator und die NAS hat die korrekten Zugriffsdaten.

Unsauber, aber funktioniert!

Lange Wartezeit bei erstem Logon nach Disk Cleanup

Veröffentlicht am Veröffentlicht in Computer

Auf einem Server 2008R2 ist im Lauf der Zeit die C:\ Partition ziemlich voll geworden. Da auf dem Server schon lange nichts mehr aktiv verändert wurde, hatte ich die Vermutung dass der Platz durch Temp-Dateien und alte Windows-Update-Dateien verbraucht wurde.

Daher habe ich den Disk Cleanup („Datenträgerbereinigung“) Assistenten über die C:\ Partition laufen lassen. Und zwar doppelt: Einmal die erste Stufe mit „Temporary files“ usw. und einmal (hinter dem Button „Clean up system files“) die zweite Stufe mit „Windows Update Cleanup“, „Service Pack Backup Files“ usw.. Diese zweite Bereinigung hat relativ lange gedauert, ist aber irgendwann normal fertig geworden und hat anschließend den üblichen Neustart angefordert. Bevor ich diesen durchgeführt habe ist mir noch aufgefallen, dass durch den Assistenten nicht allzuviel freier Festplattenplatz geschaffen wurde.

Nach der normalen Neustart-Wartezeit konnte ich den Server wieder anpingen und mich auch wieder mit den Shares verbinden. Bei der Anmeldung per RDP jedoch wurde dauerhaft „Please wait for the windows modules installer“ angezeigt. Etwas Recherche hat gezeigt, dass erst jetzt die alten Windows-Updates im WinSxS Ordner („Windows component store“) aufgeräumt wurden und dies durchaus ziemlich lange dauern kann.
Als ich nach ca. 2 Stunden die RDP-Anmeldung mal wieder überprüft habe, konnte ich mich endlich normal anmelden. Jetzt war auch deutlich mehr Platz auf der C:\ Partition frei.

Der Disk Cleanup Assistent wird auf neueren Server-Betriebssystemen übrigens nicht mehr automatisch mitinstalliert. Man kann ihn aber nachträglich über die Aktivierung des Features „Desktop Experience“ installieren. Leider werden dadurch auch eine ganze Reihe anderer Dinge installiert, die man auf einem Server nicht haben möchte wie z.B. der Windows Media Player!
Früher gab es noch Tricks manuell  an Disk Cleanup zu kommen ohne das ganze Desktop Experience Feature aktivieren zu müssen, aber seit Server 2012R2 ist dies nicht mehr möglich.

[Update] In einem Blog-Posting habe ich eine Möglichkeit gefunden, mit PowerShell und dem Tool „DISM“ den WinSxS-Ordner auch unter Windows Server 2012R2 zu optimieren.

Windows Server 2008R2 Installationsmedium mit USB 3.0 Treibern erstellen

Veröffentlicht am Veröffentlicht in Computer

Vor einiger Zeit mußte ich eine Windows Server 2008R2 Installation von einem älteren, unzuverläßig gewordenen DELL PowerEdge R210 auf einen neuen R230 umziehen. Da täglich ein Backup mit der „Windows Server-Sicherung“ auf eine NAS durchgeführt wird, war der Plan dieses Backup ein letztes Mal am alten Server zu aktualisieren, diesen dann herunterzufahren, den neuen Server von einer passenden Windows Server 2008R2 DVD zu booten und die Installation dann von diesem Backup wiederherzustellen.

Nach dem Start von der Windows Server 2008R2 DVD wird als erstes ein Bildschirm mit den Auswahlmöglichkeiten für Sprache, Tastatur/Währung und Tastaturlayout angezeigt. Nur funktionieren an dieser Stelle weder Maus noch Tastatur, ich hatte als keine Möglichkeit irgendetwas auszuwählen und die Installation fortzusetzen!

Etwas Recherche hat die Information geliefert, dass auf dem original Windows Server 2008R2 Installationsmedium nur Treiber für PS/2 und USB 2.0 vorhanden sind, nicht aber für USB 3.0. Am DELL PowerEdge R230 gibt es aber keine PS/2- oder USB 2.0 Ports und die vorhandenen USB 3.0 Ports sind beim R230 (im Gegensatz zu den höherwertigeren PowerEdge Modellen) auch nicht im BIOS auf USB 2.0 umstellbar.

Auf der DELL Website gibt es ein ausführliches Blog Posting das auf dieses Problem eingeht und erklärt, wie man sich ein Installationsmedium mit integrierten USB 3.0 Treibern erzeugen kann. Dazu braucht man viel Zeit, einen Windows-Rechner mit viel freiem Festplattenplatz, natürlich eine original Windows Server 2008R2 DVD, die Intel USB 3.0 Treiber von der DELL Support-Website und das passende Microsoft-Tool zum Erzeugen des neuen Installationsmediums.

Der ganze Vorgang wird in dem Blog-Posting ausführlich erklärt, nur finde ich den Text sehr unübersichtlich deshalb hier ein paar Hinweise:

  • Es werden dort drei alternative Methoden erklärt eine ISO-Datei mit den USB 3.0 Treibern zu erzeugen. Das ist nicht klar ersichtlich, man könnte meinen man muß die Seite von oben bis unten durcharbeiten.
    • Methode 1: Ein DELL-Tool, das man auf der Seite herunterladen kann
    • Methode 2: Power Shell
    • Methode 3: Klassische Eingabeaufforderung
  • Für die Methoden 2 und 3 muß man sich das passende Microsoft-Tool herunterladen. Wenn man auf einem Windows 7 Rechner arbeitet, benötigt man das „Windows Automated Installation Kit (WAIK)“, für Windows 8 und neuer benötigt man das „Windows Assessment and Deployment Kit (ADK)“
  • Ich habe die neue ISO-Datei auf einem Windows 7 Rechner mit der Methode 3 erzeugt. Dazu habe ich zuerst das WAIK installiert, die komplette DVD nach C:\temp\WindowsISO und die Intel USB 3.0 Treiber nach C:\temp\drivers kopiert und dann in einer administrativen Eingabeaufforderung folgende Befehle eingegeben, die teilweise erhebliche Laufzeiten haben:
    cd c:\temp
    Dism /Get-WimInfo /WimFile:C:\temp\WindowsISO\sources\boot.wim
    Dism /Get-WimInfo /WimFile:C:\temp\WindowsISO\sources\install.wim
    
    Dism /Mount-Wim /WimFile:C:\temp\WindowsISO\sources\boot.wim /Index:1
      /MountDir:C:\temp\wim
    Dism /Image:C:\temp\wim /Add-Driver /Driver:C:\temp\drivers /Recurse
    Dism /Unmount-Wim /Mount-Dir:C:\temp\wim /Commit
    
    Dism /Mount-Wim /WimFile:C:\temp\WindowsISO\sources\boot.wim /Index:2
      /MountDir:C:\temp\wim
    Dism /Image:C:\temp\wim /Add-Driver /Driver:C:\temp\drivers /Recurse
    Dism /Unmount-Wim /Mount-Dir:C:\temp\wim /Commit
    
    Dism /Mount-Wim /WimFile:C:\temp\WindowsISO\sources\install.wim /Index:1
      /MountDir:C:\temp\wim
    Dism /Image:C:\temp\wim /Add-Driver /Driver:C:\temp\drivers /Recurse
    Dism /Unmount-Wim /Mount-Dir:C:\temp\wim /Commit
    
    oscdimg –n –m –bC:\temp\WindowsISO\boot\etfsboot.com C:\temp\WindowsISO\
      C:\temp\mynew.iso
  • Von der so erzeugten mynew.iso habe ich dann mit UNetbootin einen startfähigen USB-Stick erzeugt, den neuen R230 davon hochgefahren und konnte dann endlich Maus und Tastatur verwenden um das Backup zurückzuspielen. Dies hat dann auch ohne Probleme funktioniert.

 

IMCEAEX Fehler bei internen Empfängern nach Umzug zu Office 365

Veröffentlicht am Veröffentlicht in Computer

Nach der Migration vom lokalem Exchange zu Office 365 via Export/Import bei einem Kunden sind hin und wieder beim Versenden NDR-Fehler mit dem Hinweis „Your email program is using outdated address information for the recipients“ aufgetreten. In der Erläuterung des Fehlers werden lange Links angezeigt, die mit „IMCEAEX“ beginnen.

Nach einiger Suche konnte ich das Problem eingrenzen: Der Fehler tritt nur bei internen Empfängern auf, und zwar nur dann, wenn man in einer alten E-Mail (also einer, die vor dem Umzug empfangen wurde) auf „Antworten“ klickt. Outlook hat sich bei internen Empfängern nicht die SMTP-Adresse, sondern die interne X500-Adresse gemerkt, die jetzt nach der Migration zu Office 365 natürlich nicht mehr funktioniert.

Das Problem wird in einem Microsoft KnowledgeBase-Artikel beschrieben. Als Lösung wird dort empfohlen, bei jedem Postfach in Office 365 eine zusätzliche X500-Adresse hinzuzufügen und es wird auch genau beschrieben wie diese aus der IMCEAEX-Fehlermeldung generiert werden kann.

Nur heißt es dort, dass die Adresse mit „X500:“ beginnen muß, was in der aktuellen Office 365 Version nicht korrekt ist. Dort wird (wie in diesem Posting beschrieben) der Adresstyp (eben X500) in einem getrennten Feld eingegeben, die eigentliche Adresse beginnt direkt mit „/o=…“.
In dem erwähnten Posting wird auch beschrieben, wie man diese X500-Adresse statt aus der IMCEAEX-Fehlermeldung alternativ für alle Postfächer mit PowerShell ermittelt.

Ich habe bei allen Postfächern bei diesem Kunden eine entsprechende X500-Adresse hinzugefügt. Seitdem ist der Fehler nicht wieder aufgetreten.

 

Windows 10: Zugriff auf administrative Freigaben wieder ermöglichen

Veröffentlicht am Veröffentlicht in Computer

Nachdem ein Kunde seinen PC (nicht Mitglied der Domäne) auf Windows 10 aktualisiert hatte, war es nicht mehr möglich über das LAN mit einem lokalen Adminstratorkonto auf dessen administrative Freigaben (in diesem Fall: \\IP-des-PCs\ADMIN$) zuzugreifen. Trotz Eingabe der korrekten Zugangsdaten wurde der Zugriff verweigert.

Etwas Recherche hat mich zu einem Forenthread gebracht, in dem die Lösung beschrieben wird: Zuerst mit RegEdit das folgende DWORD (32 Bit) mit dem Wert „1“ erzeugen:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\
   LocalAccountTokenFilterPolicy

und dann die Einstellungen der Firewall kontrollieren, da evtl. weitere (dynamische) Ports zugelassen werden müssen.

Nach diesen Änderungen war der Zugriff von einem Windows Server 2008 R2 aus wieder problemlos möglich.