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