Exchange 2016 CU2 Fehler HMACProvider.GetCertificates:protectionCertificates.Length

[roccomarcy 20]

ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length<1 / frische Installation

 

 

Moin,

 

bekomme o.g. Fehlermeldung bei einem frisch installierten Exchange 2016 CU22 auf Windows Server 2016.

Habe bereits das System durchgestartet, ein neues Zertifikat wie im Internet beschrieben erstellt und eine Stunde abgewartet. Allerdings keine Veränderung - auch nach einem iisreset nichts.

 

 

Das Zertifikat ist dem SMTP zugeordnet. Mein öffentliches Zertifikat, welches den internen/externen URLs entspricht, ist IMAP + POP + IIS zugeordnet. Spricht da was gegen?

[testperson 1.676]

Hi,

 

vor 13 Minuten schrieb roccomarcy:

und eine Stunde abgewartet

 

so b***d es klingt, warte mal 2 bis 2,5 Stunden.

 

Gruß

Jan

[NorbertFe 2.034]

Einfach warten. Der authconfig hast du das Zertifikat auch zugewiesen?

[roccomarcy 20]

Ja, ich habe das Skript von Frank angewendet. Dort wird dem ja ein Zertifikat zugewiesen. Dann muss ich wohl abwarten - ist ja "zum Glück" nicht weiter tragisch,

da der 2016 noch nicht in Betrieb ist und einen Ex2010 ablösen soll.

 

[roccomarcy 20]

Guten Morgen,

 

das Problem hat sich über Nacht "aufgelöst".

Scheint, wie von euch gesagt, einfach mit abwarten zu lösen sein.

 

Versteh allerdings nicht, wie Microsoft sowas passieren kann. Ich meine im Netz gelesen zu haben, dass das mit dem CU21 gekommen ist und ich habe ja direkt CU22 installiert.

Nunja, habt ein schönes Wochenende!

[NorbertFe 2.034]

Das passiert, wenn man das auth Zertifikat vorher schon immer ignoriert hat. ;) wenn man das alte aber noch nicht ablaufen lassen hat, und es auch nicht gleich aus der konfig löscht, dann passiert da gar nix. ;)

[mwiederkehr 373]

Ein Grund, weshalb mir bei der Installation von CUs jeweils etwas unwohl ist. In fast jedem CU steckt irgendwo eine Überraschung, bei der man dann froh ist, dank Internet hoffentlich eine Lösung zu finden. So etwas könnte der Installer abfangen und auch gleich beheben, wenn er schon eine Stunde lang PowerShell-Scripts ausführt.

 

Die Wartezeit liegt daran, dass die als Lösung gezeigten Scripts das neue Zertifikat gültig ab "Get-Date" erstellen und das liegt bei uns in der Sommerzeit zwei Stunden in der Zukunft. Mit (Get-Date).AddDays(-1) wäre das neue Zertifikat sofort gültig.

[NorbertFe 2.034]

Man könnte natürlich vor der Installation auch mal die Eventlogs durchflöhen und darauf achten, dass nicht fehlende oder abgelaufene Zertifikate angemeckert werden. Ja die CUs sind manchmal ungünstig, aber am Ende ist das auch echt kein Grund für schlaflose Nächte. Die hatte ich nur im März als man nicht schnell genug war. ;)