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

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.

VMware vCenter Server Appliance Upgrade 5.5 auf 6.0 schlägt fehl: File /usr/lib/vmidentity-firstboot.py (2119876)

Problem

Der Upgrade Assistent in Form des netten HTML-Setups is ausgefüllt, alle Eingaben sind validiert und das Setup legt los. Nach (gefühlten) 10 Minuten steht die Migration still und es erscheint diese unfreundliche Fehlermeldung:

Firstboot script execution error: 
Encountered an internal error. Traceback (most recent call last): File "/usr/lib/vmidentity-firstboot.py", line 202, in main vmidentityFB.boot()
File "/opt/vmware/lib64/vmidentity_firstboot_core.py", line 180, in boot self.dolmport()
File "/opt/vmware/lib64/vmidentity_firstboot_core.py", line 1369, in dolmport self.doLSImport()
File "/opt/vmware/lib64/vmidentity_firstboot_core.py", line 1411, in dolSImport returncode = self.runShellCommand(command, True)
File "/opt/vmware/lib64/vmidentity_firstboot_core.py", line 1515, in runShellCommand args = shlex.split(command)
File "/opt/vmware/lib/python2.7/shlex.py", line 279, in split return list(lex)
File "/opt/vmware/lib/python2.7/shlex.py", line 269, in next token = self.get_token()
File "/opt/vmware/lib/python2.7/shlex.py", line 96, in get_token raw = self.read_token()
File "/opt/vmware/lib/python2.7/shlex.py", line 172, in read_token raise ValueError, "No closing quotation" ValueError: No closing quotation 

This is an unrecoverable error, please retry install.
If you run into this error again, please collect a support bundle and open a support request.

Lösung

Das Kennwort für root und den SSO-Adminbenutzer dürfen keine Sonderzeichen enthalten (/\+()“ Leereichen und so weiter). Einfach eine neues Kennwort nur aus Buchstaben und Zahlen vergeben, schon läuft der Assistent *kopfschüttel*

Das gilt für den root und administrator@vsphere.local, wenn SSO nicht eingerichtet ist.

Update: vmware hat dieses Verhalten zwar nicht gefixt, aber Dokumentiert: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2119876

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 2013/2016 alle PST-Dateien aus einem Verzeichnis auf einmal importieren

Nach einer „kalten“ Migration, nach einem Desaster oder einer anderen PST-Export-Orgie liegen in einem Ordner oft viele wichtige PST-Dateien, deren Inhalt wieder den Weg in die Mailboxen der passenden Benutzer finden soll.

Die Waffe der Wahl dazu heisst „New-MailboxImportRequest„. Wenn das CMDlet noch nicht eingeschaltet ist ( … nicht gefunden …) oder für diesen Benutzer aus magischen RBAC-Gründen nicht zur Verfügung steht, hilft ein:

New-ManagementRoleAssignment -Name "Import Export PST" -SecurityGroup "Organization Management" -Role "Mailbox Import Export"

In der Active Directory-Gruppe „Organization Management“ ist der erste Domänen-Administrator (und der schlaue Zweit-Admin) selbstverständlich Mitglied. Wenn nicht, ändern und neu anmelden. Gruppenmitgliedschaften werden nur beim anmelden übergeben!

Alle PST-Dateien aus einem Verzeichnis in die selben Ordner importieren:

dir \\SERVER\FREIGABE\*.pst | %{ New-MailboxImportRequest -Mailbox $_.BaseName -FilePath $_.FullName -TargetRootFolder /}

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.