KB3046017 konnte nicht installiert werden "Path not found"

Auf einem Windows Server 2012 R2 Terminalserver konnte das KB3046017 nicht installiert werden.

Fehlerbeschreibung:

Installation Failure: Windows failed to install the following update with error 0x80070003: Security Update for Windows (KB3046017).

Hinter der Fehlernummer steckt "Path not found". Mit Procmon kam ich nicht weiter, da dort zu viel geloggt wurde.

Ein "SFC /Scannow" fand korrupte Dateien und reparierte sie:

2015-10-27 10:42:26, Info                  CSI    00000970 [SR] Verify complete

2015-10-27 10:42:26, Info                  CSI    00000971 [SR] Repairing 8 components

2015-10-27 10:42:26, Info                  CSI    00000972 [SR] Beginning Verify and Repair transaction

2015-10-27 10:42:27, Info                  CSI    00000973 [SR] Repairing corrupted file [ml:520{260},l:154{77}]"\??\d:\Users\Default\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch"\[l:36{18}]"Server Manager.lnk" from store

2015-10-27 10:42:27, Info                  CSI    00000974 [SR] Repairing corrupted file [ml:520{260},l:154{77}]"\??\d:\Users\Default\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch"\[l:34{17}]"Control Panel.lnk" from store

usw.

Es stellte sich heraus, dass die Umstellung des Profilpfades für neue Profile von c:\ nach d:\ zu dem Problem führte. Direkt nach dem Durchlauf von "sfc /scannow" konnte das Update installiert werden.

schannel Fehler durch fehlerhaften Java LDAPS Sync

Domaincontroller und Eventlogs...

Plötzlich tauchten auf einem Domaincontroller im System Eventlog etliche Schannel Errors auf.

Error 17.09.2015 09:04:15 Schannel 36887 None

A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 46.

Die Detailansicht gibt dann zusätzlich noch die Process- und Thread-ID aus. Anhand derer kann man mit dem Task Manager den Prozess ermitteln. In dem Fall war es lsass.exe. Also die Authentifizierungsschnittstelle des DC.

Laut http://blogs.msdn.com/b/kaushal/archive/2012/10/06/ssl-tls-alert-protocol-amp-the-alert-codes.aspx handelt es sich dabei um ein "Certificate unknown" Fehler.

Man würde erwarten, dass Windows auch das Quellsystem benennt, welches diesen Fehler erzeugt. Dem ist aber nicht so. Mehr als die oben beschriebenen Infos bekommt man nicht.

Wenn man nach "schannel log level" und ähnlichem googelt kommt man immer wieder auf den Punkt, dass man das Log Level im Eventlog erhöhen. Siehe https://support.microsoft.com/en-us/kb/260729. Allerdings bringt einen das hier nicht weiter, da die Fehlermeldung nicht detaillierter wird, sondern nur zusätzlich Warnungen und ggf. erfolgreiche TLS Handshakes gemeldet werden. Weiterhin kein Hinweis auf das Quellsystem.

Also Sysinternals procmon gestartet. Den Filter auf "Process Name" contains "lsass" und "Operation" auf "TCP Accept" gesetzt und gewartet.

Anhand des Logs und der zugehörigen Eventlog Einträge konnte ich das Quellsystem dann mühelos ermitteln.

Es handelte sich um Atlassian Confluence und ich hatte Tage zuvor ein Upgrade durchgeführt und bei diesem den Import des Root CA Zertifikates der Enterprise CA vergessen. Dadurch hat Confluence die ganze Zeit erfolglos versucht die Accounts abzugleichen.

Der Import erfolgt übrigens per keytool:

"c:\Program Files\Atlassian\Confluence\jre\bin\keytool.exe" -importcert -alias "RootCA_xxx Root CA"  -keystore "c:\Program Files\Atlassian\Confluence\jre\lib\security\cacerts" -file "\\server\RootCA_xxx Root CA.crt"

Dort dann "changeit" als Passwort und am Ende noch mal "yes" um das als Trusted zu markieren. Das muss man dann bei jedem Upgrade wiederholen.

Das Confluence selbst nutzt bei uns eine .pfx Datei um selbst per SSL erreichbar zu sein. Das merkt man dann eher wenn das nicht mehr funktioniert...

Aufgefallen war das erst nicht, da die Anmeldung selbst per ADFS Plugin erfolgt und es sich auch noch um das Testsystem handelt.

Wieder was gelernt...

Update:

Am Ende war es garnicht die cacerts sondern eine Änderung in der Java Runtime welche jetzt bei Confluence 5.8.10 mitgeliefert wird. Zum Glück viel mir dieser Bug schon bei Stash auf da ich dort schon die aktuellste Runtime nutzte.

https://jira.atlassian.com/browse/CONF-34975

Als Workarounf hilft hier "-Djdk.tls.trustNameService=true" als Java Startup Option dem Service hinzuzufügen.

Die Config für den Service ruft man folgendermaßen auf (der Name des Service kann sich unterscheiden und muss aus dem Serviceeintrag in services.msc ermittelt werden):

"c:\Program Files\Atlassian\Confluence\bin\tomcat8w.exe" //ES//Confluence060114171110

HP SSM und fehlende Silent Installation von Intel Treibern

Wir nutzen HP SSM zur Nachinstallation von gerätespezifischen Treibern für unsere HP Elitebooks.
Nachdem eine neue Generation (850 G2) bestellt wurde, kam es bei der unbeaufsichtigten Installation zu Meldungen.

"Intel Multiple Package Installation Tool" meldete, dass es den jeweiligen Treiber erfolgreich installiert hat.

Betroffen waren die SP:

sp69959.exe "Intel 7260_3160 Wireless LAN Driver"
sp69976.exe "Intel Bluetooth driver"

Nach einiger Analyse stellte sich durch die Nutzung von Sysinternals "Process Explorer" heraus, dass beim Kommandozeilenaufruf, welcher an den Installer übergeben wurde, der letzte Buchstaben verloren geht.

Betroffen war die Version 3.2.2.1 unter Windows 8.1. Eine älter Version 3.0.6.1 zeigte das Verhalten nicht.

Workaround 1: Ältere SSM Version nutzen

Workaround 2: Die jeweilige .cva anpassen:

Den Eintrage:

SilentInstall="InstMultiPkg.exe" /silent

durch

SilentInstall="InstMultiPkg.exe /silent"

ersetzen.

Interessanterweise wird das dann nicht so aufgerufen sondern am Ende kommt beim Installer die Kommandozeile an:

"InstMultiPkg.exe" /silent

Aber wenigstens fehlt dann das "t" am Ende nicht mehr.

Schön dass solche Hersteller noch Aufwand in die QA stecken...

LDAPS Anmeldeprobleme nach Upgrade JRE auf 1.8u51

Beim Upgrade einer Atlassian Stash Testumgebung auf 3.11.1 habe ich gleichzeitig die benötigte JRE von 1.8u25 auf 1.8u51 aktualisiert.

Stash ist mit Active-Directory Anbindung auf SSL eingerichtet. Damit prüft das darunter liegende Java die Zertifikate der Domain Controller. Hierzu wurde das Root CA Zertifikat der Enterprise-PKI in den cacerts Store der JRE importiert.

Das funktionierte bei 1.8u25 problemlos.

Jetzt kam aber folgende Fehlermeldung:

"The remote authentication server is not available. Please try again later."

Logmeldung:

Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address 192.168.0.1 found

Nach https://www.java.com/de/download/faq/release_changes.xml wurde ein Reverselookup bei der Zertifikatsprüfung entfernt. 

In Stash selbst ist der Hostname und keine IP konfiguriert.

Trotzdem scheint es bei der Übergabe des Hostnamens auf die weiter unten liegenden Module zwischendurch eine Namensauflösung zu geben. Damit scheint die Funktion, die am Ende prüft ob der Hostname mit dem Zertifikat übereinstimmt, diesen Hostnamen nicht zu haben und bis u51 einen Backresolve im DNS zu machen.

Mit "-Djdk.tls.trustNameService=true" kann man das Verhalten vor u51 wiederhestellen. Damit geht dann die Anmeldung.

Sauber erscheint mir das Vorgehen trotzdem nicht. Muss wohl jemand mal die Funktionen in der Kette überarbeiten.

Centralized Logging Service Agent Error while moving cache files to network share.

Am Tag zuvor per Skype Logging Tool kurzzeitig das "AlwaysOn" Szenario gestartet.

Am nächsten Tag noch:

24.06.2015 07:05:55

Error

33020

Centralized Logging Service Agent Error while moving cache files to network share. Path: C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\Tracing\CLS_WPP_06-22-2015-10-50-43.cache Exception(s): NetworkCacheDirForAgent not set in Cls Configuration. Use Set-CsClsConfiguration to set it Cause: Examine exception details to determine cause. Resolution: Examine exception details to determine resolution.

LS Centralized Logging Agent

Wiederholt sich alle 5 Minuten.

Entweder man stellt dann einen entsprechenden Netzwerkordner zur Verfügung in dem der Agent die Dateien archivieren kann, oder man löscht manuell die Dateien, wenn man sie nicht mehr braucht.

Skype for Business Suche von Skype IDs schlägt fehl

Nach Upgrade und Einrichtung der Skype ID Suche funktioniert diese trotzdem nicht.

Vorgegangen nach:

http://lyncinsider.com/skype-for-business/how-to-re-enable-skype-directory-search-in-the-skype-for-business-client/
bzw.
http://lyncinsider.com/skype-for-business/how-to-re-enable-skype-directory-search-in-the-skype-for-business-client/

Im SfB Client steht dann einfach nur Fehler bei der Suche.

Englisch: "An error occured during the search. Pleasy try again, and contact your support team if the problem continues."

Im Eventlog des Frontend und Edge wurde ich fündig:

Edge:

22.06.2015 14:11:16 Error 4106 The server selected for next hop could not be reached, or did not reply. A server selected as a proxy target for HTTP traffic could not be reached or did not reply: skypegraph.skype.com. Performance Counter Instance: Failure occurrences: 5, since 21.06.2015 19:36:50. Failure Details: WebException: Unable to connect to the remote server Cause: The remote server may be experiencing problems or the network is not available between these servers. Resolution: Examine the event logs on the indicated server to determine the cause of the problem. LS Web Components Server

Frontend:

22.06.2015 14:29:56 Error 62044 Skype search request failed. Exception information : Skype search service failed with response code: 503 response body: . Exception type: Exception Additional Data: Source: Microsoft.LiveServer.DLExpansion Stack Trace: at Microsoft.LiveServer.DLExpansion.Service.EndSearchSkypeDirectory(IAsyncResult asyncResult) Data: 0 key/value pairs Inner Exception: . Cause: A configuration or network connectivity issue might be causing failure to access the Skype search service. Resolution: Check the Skype search proxy and network configuration. LS Address Book and Distribution List Expansion Web Service

Es stellte sich heraus, dass der Edge Server eine https Verbindung zu "skypegraph.skype.com" herstellen wollte. Dies verhinderte die externe Firewall jedoch. Nach Freischaltung ging es dann sofort.

Lync 2013 nach Skype for Business Upgrade und die 32GB Speicherplatz

Skype for Business prüft ja beim Setup ob es 32GB freien Speicherplatz findet.
Normalerweise sind unsere HyperV-VMs mit "fixed disks" ausgestattet und haben nicht unnötig freien Speicherplatz.

Idee war also eine temporäre dynamische VHDX zu erstellen und diese als zusätzliches Laufwerk einzubinden.

Das klappt soweit ganz gut, allerdings schafft der Installer dann das Replicaverzeichnis auf dieses zusätzliche Laufwerk. Eigentlich wollte ich dies wieder löschen.

Über http://ucken.blogspot.de/2012/04/resetting-lync-cms-replication.html habe ich dann die entsprechende Lösung gefunden. Es ist aber wichtig, vorher zu prüfen ob es das Share "xds-replica" noch gibt (Computer Management) und dieses ggf. zu löschen. Dann legt das "Repair" auch das Share wieder korrekt an.

WICHTIG! Das nächste Skype for Business Update (siehe http://tomtalks.uk/2015/06/skype-for-business-server-cumulative-update-1-june-2015-6-0-9319-45/) prüft intern beim Installieren eines der Updates (genauer beim Ausführen eines "Install-CsDatabase"-Cmdlets auch den freien Speicher und scheitert dann auch mit einer kryptischen Fehlernummer, die man dann erst durch mehrere Logs verfolgen muss bis man auf die genaue Fehlermeldung stößt.

Also darauf achten, bei den Servern die eine eigene Datenbank haben (Frontend, ggf. Chat) für 32GB freien Festplatten-Speicher sorgen.

Upgrade Skype for Business Reports

Das Inplace Upgrade einer Lync 2013 Umgebung nach Skype for Business ist relativ gut dokumentiert.
Dabei wird beschrieben, dass die Monitoring Datenbank automatisch aktualisiert werden kann.

Allerdings scheinen die Reports im Reportserver nicht automatisch auf den neusten Stand gebracht zu werden, es steht weiterhin "Lync Server 2013" da:

Das Upgrade ist allerdings auch recht simpel. Man geht genauso vor wie beim Deployment in Lync 2013.

Man startet den SfB Wizard, wählt "Deploy Monitoring Reports":

Im Wizard dann die gleichen Einstellungen vornehmen wie vorher bei Lync. Die Reports werden dann aktualisiert.

Unter https://technet.microsoft.com/en-us/library/jj204989.aspx finden sich auch Informationen zu neuen / überarbeiteten Reports.