ugg.li Schnelle Hilfe für schnelle Admins – Seite 104 – Nicht immer schön, aber effektiv. Schnelle Hilfe für schnelle Admins.

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

Veröffentlicht am September 28, 2016 von weed — Keine Kommentare ↓

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.

Reboot. (Clean Boot)
In der systemsteuerung unter Windows Update > Einstellungen ändern die Einstellung „Wichtige Updates“ auf „Nie nach Updates suchen (nicht empfohlen)“ ändern.
Reboot.
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
4. Windows 8.1 / Server 2012 R2 32bit
Reboot
Die Einstellung „Wichtige Updates“ auf den ursprünglichen Wert zurücksetzen.
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

Veröffentlicht am September 28, 2016 von weed — 21 Kommentare ↓

Problem

Windows 10 erlaubt im Prinzip die „komfortable Anmeldung“ mittels PIN und Fingerabdruck über den Live-Account („Microsoft-Account“). Standardmäß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

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

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

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

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)

Veröffentlicht am September 7, 2016 von weed — 1 Kommentar ↓

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 [email protected], 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)

Veröffentlicht am September 1, 2016 von weed — 6 Kommentare ↓

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)

Lö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.

ADSIEdit öffnen, Zum Konfigurationskontext verbinden
Zu dieser Node navigieren: CN=Public Key Services, CN=Services, CN=Configuration, DC=DOMAIN,DC=TLD
Wenn diese noch nicht existiert, anlegen.
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)

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

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

Made some Changelog

Veröffentlicht am August 31, 2016 von weed — Keine Kommentare ↓