Bezpečnostní aktualizace pro Exchange Server 2013 CU23 (KB5004778) a jak na její následky.

Bezpečnostní aktualizace pro Exchange Server 2013 CU23 (KB5004778) a jak na její následky.

Ti, co spravují Exchange server 2013, tak už určitě aplikovali novou bezpečnostní záplatu KB5004778. Jaké však bylo překvapení když po restartu služeb a nebo i celého serveru nebylo možné použít webové konsole ECP a OWA.

Instalace aktualizace je dostupná pomocí Windows Update nebo je možné si ji stáhnout jako samostatnou aktualizaci.

V našem případě použijeme samostatně spustitelnou aktualizaci. Po stažení a spuštění aktualizace. Projdeme si klasického průvodce instalací.

Odsouhlasíme licenční podmínky a pokračujeme dále.

Poté se spustí instalace

Pokud nejsou dostupné všechny soubory, které se mají aktualizovat, tak lze pokračovat tlačítkem Ignore.

Instalace aktualizace se dokončí.

Aktualizaci dokončíme tlačítkem Finish.

Protože nebylo možné nahradit všechny soubory během instalace, tak je zapotřebí restartovat celý server.

Na první pohled to vypadá, že je ECP k dispozici a tak se pokusíme přihlásit do administrace.

Při přihlášení nás ovšem čeká velmi nemilé překvapení. Z této chybové hlášky nebudete moc rozumní.

Server Error in ‚/owa‘ Application.

ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length<1

Jak vyřešit tento problém?

Spustíme si Exchange Management Shell (PowerShell pro Exchange Server)

  1. vložíme následující kód, kterým si vygenerujeme nový Microsoft Exchange Server Auth Certificate. Parametr -DomainName „TreyResearch.net“ nahradíme doménou, kde je instalován náš Exchange server.
New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "cn=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -DomainName "TreyResearch.net"

2. Nyní si zkopírujeme Thumbprint, který vložíme do dalšího příkazu.

Set-AuthConfig -NewCertificateThumbprint 089E8FCA04E42854B580DA0E12FDFBBECCB64E59 -NewCertificateEffectiveDate (Get-Date)
Set-AuthConfig -PublishCertificate
Set-AuthConfig -ClearPreviousCertificate

3. Jako poslední krok provedeme restart obou aplikačních poolů.

Restart-WebAppPool MSExchangeOWAAppPool
Restart-WebAppPool MSExchangeECPAppPool

Zde je přehledná ukázka všech příkazů krok za krokem.

V případě, že se bude stále zobrazovat chyba (viz výše), tak je zapotřebí chvilku počkat, než se změny projeví. Tato doba je závislá na velikosti a složitosti infrastruktury. Může trvat třeba i několik hodin.

Nyní je již možné se opět přihlásit do ECP i OWA.

V rámci Administrace Exchanage Serveru ještě provedeme malý úklid. Smažeme starý autentizační certifikát již nemá smysl dále udržovat na serveru.

Protože se oba certifikáty jmenují stejně, tak vybereme jeden z nich a podíváme se na detaily. Tam je možné si zobrazit Thumbprint certifikátu.

Poté stačí pouze vybrat ikonu Delete a potvrdit zprávu tlačítkem ok.

Nyní máme opět aktualizovaný plně funkční Exchnage Server.

Aktualizace proběhne správně i když provedete nejprve vygenerování nového certifikátu a poté spustíte instalaci bezpečnostní aktualizace.

Postupoval lze i v obráceném sledu, což znamená nejprve vytvořit nový authentizační certifikát a poté aplikovat bezpečnostní záplatu.

1 comment so far

Petr Karafiát Posted on11:44 - 4. 11. 2021

„V případě, že se bude stále zobrazovat chyba (viz výše), tak je zapotřebí chvilku počkat, než se změny projeví. Tato doba je závislá na velikosti a složitosti infrastruktury. Může trvat třeba i několik hodin.“ – je upřesním, že to trvání je dáno tím, že certifikát se generuje v jiném časovém pásmu a tím pádem v našem časovém pásmu musíme počkat, až je platný. IISko s ním pracuje ihned, nemá na to vliv žádná velikost infrastruktury.