Windows 7 Update „Es wird nach Updates gesucht“ dauert ewig, wird nicht fertig

Problem

Seit eingier Zeit funktioniert das Windows Update unter Windows 7 nicht mehr richtig. Ob das ein „Schubser“ in richtung 10 sein soll? 🙂  Das Windows 7 Update steht ewig lange bei „Es wird nach Updates gesucht“ und wird nicht fertig, wenn es fertig wird, findet es manchmal keine Updates. Im %windir%\windowsupdate.log findet man nichtssagende Timeouts („timed out“ um genau zu sein) und sonst sehr wenig. Der Vorgang lässt sich nicht vernünftig anhalten und das Windows-Update-Repair-Tool-Fixit Ding (https://support.microsoft.com/de-de/kb/971058) hilft auch nicht weiter. Dabei wird zudem der Computer teilweise überlastet, indem CPU- und RAM-Ressourcen (durch svchost.exe) entsprechend beansprucht werden.

Lösung

Wenn man sich genau an diese Vorgehensweise hält, läuft danach in der Regel alles wieder richtig. Vorher noch das SP1 installieren (falls noch nicht geschehen), ohne SP1 geht gar nichts.

  1. Reboot. (Clean Boot)
  2. In der systemsteuerung unter Windows Update > Einstellungen ändern die Einstellung „Wichtige Updates“ auf „Nie nach Updates suchen (nicht empfohlen)“ ändern.
  3. Reboot.
  4. DIESE Updates in DIESER Reihenfolge installieren:
    1. Windows 7 64bit
      1. Sicherheitsupdate für Windows 7 für x64-basierte Systeme (KB3078601) vom 11.08.2015
      2. Sicherheitsupdate für Windows 7 für x64-basierte Systeme (KB3087039) vom 05.09.2015
      3. Sicherheitsupdate für Windows 7 für x64-basierte Systeme (KB3109094) vom 05.12.2015
      4. Sicherheitsupdate für Windows 7 für x64-basierte Systeme (KB3145739) vom 11.04.2016
      5. Sicherheitsupdate für Windows 7 für x64-basierte Systeme (KB3168965) vom 11.07.2016
      6. Sicherheitsupdate für Windows 7 für x64-basierte Systeme (KB3185911) vom 12.09.2016
    2. Windows 7 32bit
      1. Sicherheitsupdate für Windows 7 (KB3078601) vom 11.08.2015
      2. Sicherheitsupdate für Windows 7 (KB3087039) vom 05.09.2015
      3. Sicherheitsupdate für Windows 7 (KB3109094) vom 05.12.2015
      4. Sicherheitsupdate für Windows 7 (KB3145739) vom 11.04.2016
      5. Sicherheitsupdate für Windows 7 (KB3168965) vom 11.07.2016
      6. Sicherheitsupdate für Windows 7 (KB3185911) vom 12.09.2016
    3. Windows 8.1 / Server 2012 R2 64bit
      1. Sicherheitsupdate für Windows 8.1 / Server 2012 R2 für x64-basierte Systeme (KB3021910)
      2. Sicherheitsupdate für Windows 8.1 / Server 2012 R2 für x64-basierte Systeme (KB3173424)
      3. Sicherheitsupdate für Windows 8.1 / Server 2012 R2 für x64-basierte Systeme (KB3172614)
    4. Windows 8.1 / Server 2012 R2 32bit
      1. Sicherheitsupdate für Windows 8.1 / Server 2012 R2 (KB3021910)
      2. Sicherheitsupdate für Windows 8.1 / Server 2012 R2 (KB3173424)
      3. Sicherheitsupdate für Windows 8.1 / Server 2012 R2 (KB3172614)
  5. Reboot
  6. Die Einstellung „Wichtige Updates“ auf den ursprünglichen Wert zurücksetzen.
  7. Fertig

Ab hier eine neue Update-Suche starten. Es ist möglich, das das wieder eine ganze Weile dauert und Leistung frisst, aber diesmal wird der Update-Dienst ganz sicehr fertig und kann Updates wieder fehlerfrei installieren.

Thx an Alexander Schimpf: https://alexanderschimpf.de/windows-7-update-es-wird-nach-updates-gesucht
und Dalai: http://wu.krelay.de/

Windows 10 Anmeldung mit Fingerabdruck in Active-Directory Domäne via GPO erlauben

Problem

Windows 10 erlaubt im Prinzip die „komfortable Anmeldung“ mittels PIN und Fingerabdruck über den Live-Account („Microsoft-Account“). Standartmäßig ist das in der Domäne aber deaktiviert und nur die Anmeldung an lokalen Benutzerkonten erlaubt.

Das ist daran zu erkennen, das praktisch alle Optionen unter Einstellungen > Konten > Anmeldeoptionen ausgegraut sind.

Sollte das ebenfalls in der lokalen Anmeldung der Fall sein, ist zumeist der Treiber des Biometrie-Gerätes schuld: Aufgrund der hohen Sicherheitsanforderungen (und dem geldlichen Notleiden des Konzerns) müssen Treiber für die Biometrischen Geräte zur Anmeldung ausnahmslos zertifiziert sein. Eine Menge älterer Treiber (Synaptics, WD, Asus …) sind das nicht und müssen vorher aktualisiert werden.

Sollte das endlich alles klappen, kann man die Biometrische Anmeldung in der Domäne aktivieren.

Lösung

windows10-biometrie-erlauben

Fingerabdruck-Anmeldung und Biometrische Anmeldung via GPO (Gruppenrichtlinie) erlauben:

  1. Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten Biometrie > Verwendung von Biometrie zulassen
    1. aktivieren
  2. Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten Biometrie > Benutzeranmeldung mithilfe von Biometrie zulassen
    1. aktivieren
  3. Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten Biometrie > Bomänenbenutzeranmeldung mithilfe von Biometrie zulassen
    1. aktivieren

Fingerabdruck-Anmeldung via Live-ID (Die PIN ist eine Voraussetzung) mithilfe der GPO (Gruppenrichtlinie) erlauben:

  1. Computerkonfiguration > Richtlinien > Administrative Vorlagen > System > Anmelden > PIN-Anmeldung aktivieren

Wichtig: Bei der Anmeldung via PIN wird das Kennwort des Benutzers im Tresor („Anmeldeinformationsspeicher“) lesbar gespeichert. Mit „lesbar“ ist an dieser Stelle Mimikatz oder ähnliches gemeint.

Active Directory Zertifikatsdienste Webregistrierung Fehler 0x80070057 (WIN32: 87)

Problem

Wenn man versucht die Zertifizierungsstellen-Webregistrierung nach der Installation oder Migration (oder Wiederherstellung einer CA) zu installieren („Konfiguration abschliessen“), tritt dieser Fehler auf:

Certification Authority Web Enrollment: Konfiguration fehlgeschlagen
Active Directory Certificate Services-Setup ist fehlgeschlagen mit dem folgenden Fehler: Der Parameter ist falsch. 0x80070057 (WIN32: 87)

0x80070057-windows-ca-zertifizierungsstelleLösung

Mir sind bisher zwei Ursachen untergekommen, wahrscheinlicher ist die zweite.

Möglichkeit 1

Die Node zu den Public-Key Services im Active Directory existiert (noch) nicht oder der ausführende Benutzer hat keine Berechtigungen darin.

  1. ADSIEdit öffnen, Zum Konfigurationskontext verbinden
  2. Zu dieser Node navigieren: CN=Public Key Services, CN=Services, CN=Configuration, DC=DOMAIN,DC=TLD
  3. Wenn diese noch nicht existiert, anlegen.
  4. Wenn diese existiert, die Rechte auf den Schlüssel prüfen. Die Organisations-Admins sollten hier Vollzugriff haben (und der Account der das Setup abschliesst sollte dort Mitglied sein)

0x80070057-windows-ca-zertifizierungsstelle-ldap
Möglichkeit 2 (*wahrscheinlich*)

Das wahrscheinlichere Problem ist, dass der Wert des Schlüssels Setupstatus unter HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration falsche Daten enthält. Vermutlich steht hier der (HEX) Wert 6003 drin. Der Wert 6003 zeigt an, dass CA Webregistrierung bereits installiert ist. Der korrekte Wert für die Aktivierung lautet 6001 (not installed).

  1. In HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration den Wert Setupstatus von 6003 in 6001 ändern:
    certutil -setreg config \ Setupstatus 0x6001
  2. Den Abschluss von Setup erneut versuchen

Outlook 2016 gegen Exchange 2016 fragt immer wieder nach Kennwort („MAPI Virtual Directory Bug in Exchange 2016 CU2“)

Problem

Outlook 2016 verbindet sich nicht zu Exchange 2016. OWA geht. Die wichtigen URLs sind alle richtig konfiguriert:

Get-ClientAccessServer | fl autodiscover*
Get-ActiveSyncVirtualDirectory | fl *url*
Get-OutlookAnywhere | fl *hostname
Get-WebServicesVirtualDirectory | fl *url*
Get-OwaVirtualDirectory | fl *url*
Get-OabVirtualDirectory | fl *url*

Outlook 2013 funktioniert einwandfrei. Bei Outlook 2016 schlägt allerdings schon das hinzufügen eines Profils in der Systemsteuerung fehl – Man wird immer wieder nach Name und Kennwort gefragt.

Lösung

No+MAPI+AuthenticationExchange 2016 CU2 bringt einen (bisher ungefixten) ziemlich fiesen und schwer zu jagenden Bug mit. Wenn man im GUI (ECP) das virtuelle Verzeichnis „mapi“ (für die RPC/HTTP von Outlook 2016) bearbeitet, wird beim Speichern immer die IIS-Authentifizierung zurückgesetzt. Immer. Auf nichts. Leer. Egal ob man auf der Seite etwas macht oder nicht, egal was man macht.

Fix für alle mapi-Verzeichnisse

Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm,Negotiate,OAuth

Vielen Dank Microsoft für erfüllte neun (!) Stunden Fehlersuche mit viel Haare raufen. Vor allem vielen Dank für die absolute Abstinenz jeglicher Outlook-Discovery debugging-Werkzeuge (nein, dieser Server war nicht extern erreichbar).

Exchange 2016: „Setup encountered a problem while validating the state of Active Directory: Couldn’t find the Enterprise Organization container.“

Problem

Das Setup von Exchange 2013/2016 brit untätig mit dieser Fehlermeldung ab:

Setup encountered a problem while validating the state of Active Directory:
Couldn't find the Enterprise Organization container

Das Exchange Setup Logfile (C:\ExchangeSetupLogs\ExchangeSetup.log) liefert ähnlich genau Details:

[11/08/2016 05:36:10.0207] [1] Failed [Rule:AdInitErrorRule] [Message:Setup encountered a problem while validating the state of Active Directory: Couldn’t find the Enterprise Organization container. See the Exchange setup log for more information on this error.]
[11/08/2016 05:36:10.0223] [1] [RECOMENDED] Setup will prepare the organization for Exchange 2013 by using ‘Setup /PrepareAD’. No Exchange 2007 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2007 servers.
[11/08/2016 05:36:10.0223] [1] [RECOMENDED] Setup will prepare the organization for Exchange 2013 by using ‘Setup /PrepareAD’. No Exchange 2010 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2010 servers.
[11/08/2016 05:36:10.0223] [1] [REQUIRED] Setup encountered a problem while validating the state of Active Directory: Couldn’t find the Enterprise Organization container. See the Exchange setup log for more information on this error.
[11/08/2016 05:36:10.0223] [1] Help URL: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.AdInitErrorRule.aspx
[11/08/2016 05:36:10.0238] [1] Ending processing test-SetupPrerequisites

Lösung

In dieser Domäne wurde ein Exchange 2007 oder Exchange 2010 Server deinstalliert. Im letzten Schritt entfernt das Exchange Setup nämlich die „Erste Organisation“ aus dem ActiveDirectory, aber hinterlässt die Microsoft Exchange System Objects. Das verwirrt das 2013’er Setup. Vermutlich wurde dieser Fall bei Microsoft nicht getestet (wer will auch Exchange deinstallieren?).

Das Setup von Exchange 2007 (SP3+) oder Exchange 2010 einfach nochmal aufrufen:

C:\THINGS\ex2007> setup /preparead /on:"<ORGANISATIONSNAME>"

Die Installation ist nicht notwenig, nur das PrepareAD. Das Setup baut die entsprechenden Contain wieder ein und das Exchange 2013/2016 Setuo läuft problemlos durch.

Veeam Backup & Replication – Access Denied bei einigen Backup Copy Jobs

Problem:

In Veeam Backup & Replication (v9) schlagen manche Backup Copy Jobs fehl.
Situation:
Mehrere Backup Copy Jobs
Repository auf einem eigenständigen Repository-Server
Einer der Copy Jobs schlägt fehl mit „Access Denied“ – alle anderen funktionieren.
veeam_copy_access-denied

Lösung:

Die Anmeldung für den Veeam Backup Service erfolgt standardmäßig mit dem lokalen Systemkonto, ändert man die Einstellung z.B. auf ein Domänenkonto, welches Zugriff auf die Ziel-Repositories hat, funktionieren die fehlerhaften Copy Jobs nach neustart des Dienstes.
veeam_copy_service

  1. Continuous Copy Jobs auf Disabled stellen
  2. Beachten, dass keine weiteren Veeam Backup Jobs laufen
  3. Veeam Konsole schließen
  4. Anmeldedaten des Dienstes „Veeam Backup Service“ auf ein entsprechendes Domänenkonto ändern
  5. den Dienst neustarten
  6. Veeam Copy Jobs wieder aktivieren

Windows Update Fehler 80244007 (WSUS)

Problem:

WSUS Clients (in diesem Fall Windows Server 2012 R2) können nicht nach Updates suchen (Fehler 0x80244007).
Folgendes zeigt die WSUS-Verwaltungskonsole:
WSUS_Verbindungsfehler

Kopiert man den Fehler in die Zwischenablage, beinhaltet diese (in etwa) folgendes:

Die WSUS-Verwaltungskonsole konnte über die Remote-API keine Verbindung mit dem WSUS-Server herstellen. 

Stellen Sie sicher, dass der Update Services-Dienst, IIS und SQL auf dem Server ausgeführt werden. Starten Sie IIS, SQL und den Update Services-Dienst erneut, wenn das Problem weiterhin besteht.
An der WSUS-Verwaltungskonsole ist ein unerwarteter Fehler aufgetreten. Möglicherweise ist es ein vorübergehender Fehler.
Versuchen Sie, die Verwaltungskonsole erneut zu starten. Wenn der Fehler weiterhin besteht, entfernen Sie die gespeicherten Einstellungen für die Konsole, indem Sie die WSUS-Datei unter "%appdata%\Microsoft\MMC\" löschen.

System.IO.IOException -- Fehler bei Handshake wegen eines unerwarteten Paketformats.

Source: System
Stack Trace:
   bei System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
   bei System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   bei System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
   bei System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
   bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   bei System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
   bei System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
   bei System.Net.ConnectStream.WriteHeaders(Boolean async)
** this exception was nested inside of the following exception **

System.Net.WebException -- Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden..

Source: Microsoft.UpdateServices.Administration
Stack Trace:
   bei Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer(Object[] args)
   bei Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.GetUpdateServer(PersistedServerSettings settings)
   bei Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.ConnectToServer()
   bei Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.get_ServerTools()

Fügt man das WSUS-SnapIn manuell einer MMC hinzu und will sich mit dem Server verbinden erhält man folgende Meldung (wobei ‚SQUID‘ natürlich den jeweiligen Servernamen darstellt):
WSUS_SQLServer

Zu guter Letzt findet man folgenden Auszug in der Ereignisanzeige:

Fehler bei der Anmeldung für den Benutzer 'NT-AUTORITÄT\Netzwerkdienst'.Ursache: Fehler beim Öffnen der explizit angegebenen Datenbank 'SUSDB'. [CLIENT: ]

(Event-Quelle: MSSQL$MICROSOFT##WID; Event-ID: 18456)

Lösung:

Ursprung des Problems ist ein fehlerhaftes Windows Update auf dem WSUS Server (KB3148812).
Sollte dieses installiert sein (und die erforderlichen post-install Schritte noch nicht durchgeführt sein), ist die Empfehlung des WSUS-Teams (Blogbeitrag), das Update einfach wieder zu deinstallieren.

Anderenfalls kann das ersetzende Update KB3159706 die Ursache sein. Es wird als „The long-term fix for KB3148812 issues“ beschrieben, benötigt aber ebenfalls einige post-install Schritte um fehlerfrei zu funktionieren:

  1. das KB3159706 installieren (sofern noch nicht geschehen)
  2. eine Kommandozeile mit Admin-Rechten starten
  3. den Befehl „C:\Program Files\Update Services\Tools\wsusutil.exe“ postinstall /servicing ausführen
  4. daraufhin im Server-Manager das Feature „HTTP-Aktivierung“ hinzufügen, zu finden unter .NET-Framework 4.5-Funktionen -> WCF-Dienste -> HTTP-Aktivierung
    WSUS_feature_postinstall
  5. nun den WSUS-Dienst neu starten und schon können Clients wieder Updates suchen und das WSUS MMC-SnapIn funktioniert auch wieder

Netzlaufwerke von Gruppenrichtlinien werden nach Windows 10 Upgrade nicht mehr verbunden.

Problem:

Nach dem (erfolgreichen) Update von Windows 7 auf Windows 10 werden „plötzlich“ Netzlaufwerke nicht mehr eingebunden, welche per GPO verteilt werden.
In der Ereignisanzeige findet man i.d.R. folgenden Fehler:

Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\foo.bar\SysVol\foo.bar\Policies\{UID}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich. Die Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes Problem, das mindestens eine der folgenden Ursachen haben kann:
a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen Domänencontroller erstellte Datei hat nicht auf dem aktuellen Domänencontroller repliziert).
c) Der DFS-Client (Distributed File System) wurde deaktiviert.

Ursache ist in diesem Fall meist das UNC-Hardening, welches unter Windows 10 standardmäßig aktiviert ist.

Lösung:

Einfachste Lösung ist eine neue GPO anzulegen, welche das UNC-Hardening für die SYSVOL und ggfs. NETLOGON Freigabe wieder deaktiviert.
Dazu unter „Computerkonfiguration > Administrative Vorlagen > Netzwerk > Netzwerkanbieter “ die Richtlinie für Gehärtete UNC-Pfade aktivieren und folgende Einträge hinzufügen:

Wetname: \\*\SYSVOL
Wert: RequireMutualAuthentication=0, RequireIntegrity=0
(ggfs. für \\*\NETLOGON den selben Wert hinzufügen)
unc-hardening

Bei der nächsten Anwendung der Gruppenrichtlinien an den Clients (spätestens nach einem Neustart) wird dann auch die Netzlaufwerke-GPO wieder angewendet und somit die Netzlaufwerke wieder eingebunden.

Programme von Netzlaufwerken crashen nach Upgrade von Windows 7

Problem

Nach dem (erfolgreichen) Update von Windows 7 auf Windows 10 stürzen auf einigen Arbeitsstationen auf einmal Programme ab, die „jahrelang“ völlig stabil liefen. Betroffen sind Prgoramme, die von Netzlaufwerken gestartet werden oder von Netzlaufwerken und UNC-Pfaden DLLs (nach)laden. Betroffen sind Windows 8/8.1 und hauptsächlich Windows 10.

Lösung

Seit Windows 8 werden offene SMB-Sitzungen zu Netzlaufwerke und UNC-Pfaden nach einer gewisser Leerlaufzeit (standardmäßig 15 Minuten) getrennt (autodisconnect und keepconn) um den Fileserver zu entlasten. Bei „moderner“ Software und Programmen die alle benötigten Bestandteile nur einmal laden ist das kein Problem – schwierig wird es bei klassischen Programmen die davon ausgehen, das eine SMB-Sitzung „ewig“ offen bleibt.

Die entsprechenden Werte kann man per Registry (oder via GPO) anpassen:

HKLM\System\CurrentControlSet\services\LanmanWorkstation\Parameters

ein DWORD-Wert „KeepConn“ mit dem Wert „FFFF“ (HEX) Anlegen und zudem unter

HKLM\System\CurrentControlSet\services\LanmanServer\Parameters

ein DWORD „autodisconnect“ mit dem Wert „FFFFFFFF“ (HEX) Anlegen.

Ergänzend: Bei Netzlaufwerken, welche per GPO verteilt werden, kann auch das Ändern der Richtlinie von „Ersetzen“ auf „Aktualisieren“ helfen. Die Einstellung „Element entfernen, wenn es nicht mehr angewendet wird“ ist dann leider nicht mehr möglich, aber Windows behält dann über die Anwdung einer GPO hinweg die Laufwerksverbindung bei.