Microsoft hat heute neue Sicherheitsupdates für Exchange Server 2013, 2016 und 2019 veröffentlicht. Die Sicherheitsupdates bringen auch ein neues Sicherheitsfeature mit, welches aktuell noch manuell eingeschaltet werden muss:
Hier geht es direkt zu den Download der Sicherheitsupdates:
Die Sicherheitsupdates beheben die folgenden als wichtig eingestuften Sicherheistlücken:
- CVE-2023-21764 – Microsoft Exchange Server Elevation of Privilege Vulnerability
- CVE-2023-21763 – Microsoft Exchange Server Elevation of Privilege Vulnerability
- CVE-2023-21745 – Microsoft Exchange Server Spoofing Vulnerability
- CVE-2023-21762 – Microsoft Exchange Server Spoofing Vulnerability
- CVE-2023-21761 – Microsoft Exchange Server Information Disclosure Vulnerability
Neues Sicherheitsfeature: Certificate Signing of PowerShell Serialization Payload
Um Exchange-Server vor Angriffen auf serialisierte Daten zu schützen, wurde in den SUs vom Januar 2023 die zertifikatsbasierte Signierung von PowerShell Serialization Payloads hinzugefügt. In der ersten Phase des Rollouts muss dieses neue Feature aufgrund von Feature-Abhängigkeiten manuell von einem Administrator aktiviert werden. Wichtig für das neue Feature „PowerShell Serialization Payload Signing“ ist, dass das Zertifikat „Microsoft Exchange Server Auth Certificate“ gültig ist. Die Gültigkeit dieses Zertifikats sollte vor der Installation des SUs geprüft werden. Hier gibt es einen Artikel, wie das Zertifikat im Fehlerfall neu erstellt werden kann:
Mit dem folgenden Befehl lässt sich prüfen ob das Zertifikat noch gültig ist:
(Get-AuthConfig).CurrentCertificateThumbprint | Get-ExchangeCertificate | Format-List Subject, Thumbprint, NotAfter, NotBefore
Um PowerShell Serialization Payload Signing auf Exchange 2016 / 2019 Servern zu aktivieren, können die folgenden Befehle verwendet werden:
New-SettingOverride -Name "EnableSigningVerification" -Component Data -Section EnableSerializationDataSigning -Parameters @("Enabled=true") -Reason "Enabling Signing Verification"
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name W3SVC, WAS -Force
Achtung: Im letzten Schritt wird der IIS neu gestartet, Clients verlieren also kurz die Verbindung.
Hier gibt es weitere Informationen zu PowerShell Serialization Payload Signing:
Die Sicherheitsupdates sollte wie immer zeitnah eingespielt werden. Das Script „Apply-ExchangeHealthChecker-Recommendations“, welches die Exchange Health Checker Empfehlungen automatisch umsetzen kann, werde ich jetzt gleich anpassen, sodass auch die PowerShell Serialization Payload Signing aktiviert wird:
Bei mir ist es seit dem Update komplett verwurstet. Irgendwie habe ich es scheinbar verpasst in der Gruppenrichtlinie einzustellen, dass Windows die CU nicht über Windows Update installiert. Seit dem findet auch Recovery den ganzen Exchange 2016 in der Domäne nicht wieder.
Installer:
Microsoft Exchange Server 2016, kumulatives Update, unbeaufsichtigte Installation 23
Sprachen
Verwaltungstools
Postfachrolle: Clientzugriffs-Front-End-Dienst
Postfachrolle: Front-End-Transport-Dienst
Der Server wurde nicht in Active Directory gefunden. Der Server muss für eine Wiederherstellung in Active Directory
vorhanden sein.
Die folgenden Serverrollen sind bereits installiert: BridgeheadRole, ClientAccessRole, MailboxRole,
UnifiedMessagingRole, FrontendTransportRole, AdminToolsRole, CafeRole.
Die Datei exchangeserver.msi ist in dem angegebenen Verzeichnis D:\Exchange Server\bin nicht vorhanden.
Setup von Exchange Server wurde nicht abgeschlossen. Weitere Details finden Sie im Protokoll ‚ExchangeSetup.log‘ im
Ordner ‚:\ExchangeSetupLogs‘.
Da tauchen dann so Fehler auf wie:
[02.12.2023 13:27:32.0398] [0] [ERROR] Setup encountered a problem while validating the state of Active Directory: Der Active Directory-Server ist nicht verfügbar. Fehlermeldung: Active Directory-Antwort: Der LDAP-Server ist nicht verfügbar. See the Exchange setup log for more information on this error.
[02.12.2023 13:27:32.0477] [0] [ERROR] Active Directory server is not available. Error message: Active Directory-Antwort: Der LDAP-Server ist nicht verfügbar.
[02.12.2023 13:27:32.0478] [0] [ERROR] Der LDAP-Server ist nicht verfügbar.
Ich habe echt keine Ahnung wie ich den DC überreden soll, traue mich aber auch nicht die vorhanden Einträge zu löschen.
Also bei mir werden nach er Installation des SU auf Ex 2016 auf Windows Server 2012R2 die Dienste nicht gestartet (obwohl alle auf automatisch stehen).
Manueller Neustart der Dienste funktioniert; leider müssen nach einem Serverneustart die Dienste dann immer wieder manuell neu gestartet werden. Die Exchange Funktionalität ist aber nach diesem manuellen Neustart der Dienste vollständig gegeben.
Hat irgendjemand es hinbekommen, dass die Dienste wieder vollautomatisch von selbst starten nach einem Serverneustart?
MS sucks. Mann muss echt schon bei jedem Update zittern, was dann nicht alles wieder auf uns an Fehlersuche und Troubleshooting auf uns Admins zukommt ;)
https://support.microsoft.com/en-us/topic/some-exchange-services-do-not-start-automatically-after-installing-january-2023-security-update-2abd76a6-9dea-46a6-8d75-af12c0ad6e76
Ich habe seit dem Januar SU auf einem Ex2016/WinSrv2016DC einige MSExchange Common (Fehler ID 4999) im Ereignislog:
Watson report about to be sent for process id: 9836, with parameters: E12IIS, c-RTL-AMD64, 15.01.2507.017, w3wp#MSExchangeServicesAppPool, M.Exchange.Services, M.E.S.C.T.ServiceResult`1.ProcessServiceResults, System.ArgumentNullException, feb4-dumptidset, 15.01.2507.017.
ErrorReportingEnabled: False
So wirklich werde ich aus der Meldung nicht schlau, kann aber nachvollziehen das es direkt am Tag nach der Installation losging, vorher war der Fehler nicht vorhanden. Es gibt auch keine technischen Probleme, der Fehler wird 7-8x pro Tag protokolliert zu immer anderen Zeiten.
Hat jemand eine Idee woran das liegen könnte?
Das neue Sicherheitsfeature ist noch nicht aktiviert. Healtchecker hat nichts auszusetzen, außer eben das neue, inaktive Feature.
Ich habe hier genau das selbe, kommt 4 mal am Tag
Guten Morgen,
ich habe seit dem Update Probleme mit der Authentifizierung.
denke es betrifft auch meinen DC , denn ich kann nicht mehr über Outlook Anywehre darauf zugreifen. ich werde immer wieder nach dem passwort gefragt und egal was ich eingebe (dom\user oder user@dom) ich werde immer wieder nach dem Passwort gefragt.
Komme ich nicht mehr weiter…. Outlook geht nichts mehr , aber Iphones und OWA ohne Probleme…
LG
Hallo,
etliche Ex 2016er auf Win 2016 klappten ohne Probleme (Elevated Shell). Ein 2013er auf 2012R2 auch.
Bei zwei Ex 2013 auf 2016 Server dagegen war kein einziger Exchange-Dienst nach dem Update gestartet. Man hat den Eindruck der Support für 2013 IST schon vorbei…
Für Exchange 2013 funktioniert das obige Skript nicht, hier dies durchführen:
For servers running Exchange Server 2013
If you have servers that are running Microsoft Exchange Server 2013 in your environment, you must configure a registry key on each server. Specify the following settings.
Registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics
Value: EnableSerializationDataSigning
Type: String
Data: 1
To create the registry value on an Exchange Server 2013-based server, run the following cmdlet:
New-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics -Name „EnableSerializationDataSigning“ -Value 1 -Type String
To apply the new settings, restart the World Wide Web Publishing service and the Windows Process Activation Service (WAS). To do this, run the following cmdlet:
Restart-Service -Name W3SVC, WAS -Force
Achtung!
Laut Microsoft wird derzeit die Aktivierung auf Exchange Server 2013 NICHT empfohlen.
Siehe Link bei:
Hier gibt es weitere Informationen zu PowerShell Serialization Payload Signing:
PowerShell Serialization Payload Signing
DAG, 2x Exchange auf Windows Server 2019 ohne Probleme heute Abend installiert.
Das neue Feature gucke ich mir nochmal genauer an, wird schätze ich mal mit dem neuen CU Standard werden
Schönen Abend noch
scheinbar mehren sich die Probleme durch das Update: siehe Borncity exchange Januar 2023 Patchday
(LINK wird leider durch SPAM Schutz verhindert)
Dass ich es mal unbewusst in Günters Blog schaffe… ;)
Die Exchange Toolbox funktioniert devinitiv nach aktivieren von Certificate Signing nicht mehr alles andere funktioniert.
Gibt es dazu schon eine Lösung?
FX:{714FA079-DC14-470f-851C-B7EAAA4177C1}
Deserialization fails: System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. —> System.InvalidOperationException: The process ‚mmc‘ (PID = 21204) has been initialized as Unknown Multiple instance type un-expectedly.
Reasons of this exception: 1. For any product executables, which will be shipped out of box, they should never use AD driver functionality without initializing its performance counter instance since we can NOT show a intuitive Perf Counter instance name here.
2. We don’t need the validation for test assembly because we don’t care for its performance counter naming; however, we definitely want to make sure it is under our control, so that we don’t miss any out of box product DLLs/EXEs.
What to do to avoid this exception: For any newly added Exchange test executables which utilize AD perf, please add the executable name of the process into exclusion list in Microsoft.Exchange.Data.Directory.Globals.CheckExchangeTestExecutables.
bei Microsoft.Exchange.Data.Directory.Globals.InitializePerfCounterInstance(String applicationName, Boolean hasMultiInstance, Action`1 logStage)
bei Microsoft.Exchange.Data.Directory.Globals.InitializeUnknownPerfCounterInstance()
bei Microsoft.Exchange.Data.Directory.ADProviderPerf.AddDCInstance(String serverName)
bei Microsoft.Exchange.Data.Directory.LdapConnectionPool.CreateOneTimeConnection(NetworkCredential networkCredential, ADServerInfo serverInfo, LocatorFlags connectionFlags)
bei Microsoft.Exchange.Data.Directory.LdapTopologyProvider.GetDirectoryServer(String partitionFqdn, ADRole role)
bei Microsoft.Exchange.Data.Directory.LdapTopologyProvider.InternalGetServersForRole(String partitionFqdn, IList`1 currentlyUsedServers, ADServerRole role, Int32 serversRequested, Boolean forestWideAffinityRequested)
bei Microsoft.Exchange.Data.Directory.LdapTopologyProvider.GetConfigDCInfo(String partitionFqdn, Boolean throwOnFailure)
bei Microsoft.Exchange.Data.Directory.TopologyProvider.PopulateConfigNamingContexts(String partitionFqdn)
bei Microsoft.Exchange.Data.Directory.TopologyProvider.GetConfigurationNamingContext(String partitionFqdn)
bei Microsoft.Exchange.Data.Directory.SystemConfiguration.ADSystemConfigurationSession.GetRootOrgContainer(String partitionFqdn, String domainController, NetworkCredential credential)
bei Microsoft.Exchange.Data.Directory.SystemConfiguration.ADSystemConfigurationSession.GetRootOrgContainerId(String partitionFqdn, String domainController, NetworkCredential credential)
bei Microsoft.Exchange.Data.Directory.SystemConfiguration.ADConfigurationSession.GetOrgContainerId(String callerFilePath, Int32 callerFileLine, String memberName)
bei Microsoft.Exchange.Security.OAuth.KernelModeConfigurationReader.c__DisplayClass7_1.b__0()
bei Microsoft.Exchange.Data.Directory.ADNotificationAdapter.RunADOperation(ADOperation adOperation, Int32 retryCount)
bei Microsoft.Exchange.Data.Directory.ADNotificationAdapter.TryRunADOperation(ADOperation adOperation, Int32 retryCount)
bei Microsoft.Exchange.Security.OAuth.KernelModeConfigurationReader.LoadConfiguration(Boolean loadOnlineCertificates)
bei Microsoft.Exchange.Security.OAuth.Common.ConfigProviderBase.ManualLoadIfNecessary()
bei Microsoft.Exchange.Security.OAuth.Common.ConfigProviderBase.get_Configuration()
bei Microsoft.Exchange.Security.Authentication.Utility.GetCertificates()
bei Microsoft.Exchange.Security.Authentication.Utility.SafeGetCertificates()
— Ende der internen Ausnahmestapelüberwachung —
bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
bei System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
bei System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
bei Microsoft.Exchange.Data.Common.CertificateDataHelper.GetProtectionCertificates()
bei Microsoft.Exchange.Data.Common.HmacCryptoProvider.GetHmacProvider(X509Certificate2[] x509Certificate2s)
bei Microsoft.Exchange.Data.Common.HmacCryptoProvider.VerifyMessage(X509Certificate2[] x509Certificate2s, Byte[] hmac, Byte[] message)
bei Microsoft.Exchange.Data.SerializationTypeConverter.VerifySerializationDataAndGetOriginalSerializationData(Byte[] serializationData)
bei Microsoft.Exchange.Data.SerializationTypeConverter.DeserializeObject(Object sourceValue, Type destinationType)
Gibt es für die fehlerhafte Exchange Toolbox unter Exchange 2019 bereits eine Lösung?
Ohne die Aktivierung von Certificate Signing unter Exchange2016 + 2019 funktioniert alles normal.
Falls ja, wär davon sicher hier oder im Blog bereits zu lesen, meinst du nicht? ;)
Da hast Du recht. Habe natürlich im Hintergrund auch bereits recherchiert und konnte nichts finden. Dacht ich frage nochmal in die Runde :))
Ist auch nicht sooo dringend, funktioniert ja ansonsten alles, mir fehlt nur die Queue live Ansicht die über PowerShell
nicht so toll ist.
Bräuchte auch hier bitte eine Lösung, gleiches Problem.
Man findet nichts im Netz. Restart vom Microsoft Exchannge Unified Messaging Srv + -„- Call Router Service bringt garnichts
was auch auffällt ist das in der EMS erst nach dem zweiten mal starten Zertifikate angezeigt werden.
So ein Mist
Wo bin da denn bitte ich falsch abgebogen? Der Service hat doch garnichts damit zu tun :(
Naja, auf jeden Fall gibts keine Lösungen zu finden via Web. BItte um Hilfe falls wer einen Fix hat.
DANKE
Gestern Abend auf 2016 mit CU23 und 2012R2 installiert.
Nach Neustart haben folgende Dienste nicht automatisch gestartet:
Microsoft Exchange-Konformitätsprüfung,
Microsoft Exchange-Antispamupdate,
Microsoft Exchange DAG-Verwaltung,
Microsoft Exchange EdgeSync,
Microsoft Exchange IMAP4,
Microsoft Exchange-IMAP4-Back-End,
Microsoft Exchange-Notfallschutzdienst,
Microsoft Exchange POP3,
Microsoft Exchange-POP3-Back-End,
Microsoft Exchange-RPC-Clientzugriffsdienst,
Microsoft Exchange-Diensthost,
Microsoft Exchange-Einschränkungen,
Microsoft Exchange Unified Messaging,
Microsoft Exchange Unified Messaging-Anrufrouter
Nach manuellem Dienststart soweit alles OK.
Certificate Signing noch nicht aktiviert. Schaue ich mir die Tage an…
Known issues with this release
If Exchange Server 2016 is installed on Windows Server 2012 R2, after installation of the January 2023 SU, the AD Topology service might not start automatically, causing services that depend on it to not start automatically either. To work around this problem, start Exchange services manually. We are investigating this further.
Ich habe ein Server 2012 auf dem Exchange 2013 läuft. Sowohl nach dem Windows Update als auch nach dem Exchange Update startet der Arbeitsstationsdienst nicht mehr, was zur Folge hat dass sämtliche Weitere Dienste (u.a. Exchange) nicht mehr starten:
Der Dienst „Arbeitsstationsdienst“ auf „Lokaler Computer“ konnte nicht gestartet werden.
Fehler 2: Das System kann die angegebene Datei nicht finden.
Warnung: Hat unsere EXCH 2019 CU12 als Baustelle hinterlassen… WTF !
Alle Exchange Dienste deaktiviert Fehlermeldung: … Update … ended prematurely.
Dienste manuell wieder aktiviert, Update wird als installiert anzeigt, nach dem 2 Anlauf.
Wieder alle Dienste manuell aktiviert.
Ich bin wirklich begeistert von zuverlässigen Sicherheits Updates von Microsoft, tolle Qualität in den letzten Jahren…
Hast du das Ding händisch installiert, oder per Windows Update?
Richtig. Das selbe bei meinem 2016 mit CU 23. Update erfolgreich installiert. Reboot, danach HTTP 500 Fehler. Musste alle Dienste manuell starten. Geht nun zum Glück wieder!
Update per Windows Update installiert! Bisher immer problemlos geklappt!!!!
Selbst schuld, wer immer noch per Windows Update die Sicherheitsupdates für exchange installiert. Das ist seit Jahren bekannt, dass es immer mal wieder zu Problemen führen kann.
Das mit dem service ist sogar jetzt auf der Seite bei ms als known Problem beschrieben.
Ähnlich hier mit Exch 2016/CU23:
Nach dem Neustart hat es ewig gedauert, bis die Dienste neu gestartet wurden.
In den ersten 15 Minuten ist nichts passiert, dann startete der erste Exchange-Dienst.
Nach 45 Minuten waren 6 Dienste immer noch nicht gestartet, da hatte ich die Nase voll und habe die restlichen Dienste manuell gestartet.
Der Exchange läuft einwandfrei, Healt Checker zeigt auch überall grün.
Die PowerShell Serialization Payload Signing habe ich allerdings noch nicht aktiviert.
kann’s echt nicht sein… gleiche bei mir…
Im Zweifel hilft ein zweiter reboot. Wer wartet denn 45 min auf den Dienststart?
auch ein zweiter Reboot hatte bei mir nicht geholfen.
Moin,
wir haben es gestern Abend auf einem Windows Server 2016 mit Exchange 2016 CU23 über Windows Update eingespielt.
Lief problemlos durch und nach dem Neustart sind auch alle Dienste ordnungsgemäß gestartet.
Ja, manche stehen eben drauf, es darüber zu installieren und sich bei Problemen dann darüber aufzuregen. ;) es gibt oft genug Probleme mit nicht startenden Diensten usw. Als das man das nutzen sollte. Und ja es tritt nicht immer und bei jedem auf. Das Risiko ist aber manuell definitiv geringer.
Nichts für ungut, aber wir haben damit bislang nie Probleme gehabt, daher gibt es auch nichts, worüber man sich aufregen könnte :-)
In der Vergangenheit bestand das Problem mit deaktiverten Diensten ja eher dann, wenn man das Update NICHT über Windows Update eingespielt hat, sondern über die Shell, bei der dann gerne vergessen wurde, sie als „Administrator“ auszuführen.
Die Installation erfolgt bei uns aber auch trotz Nutzung von Windows Update nur auf Anforderung und keinesfalls automatisch über einen definierten Zeitplan oder ähnliches.
Ja, bis man eben doch Probleme hat. Sei froh, wenns dich bisher nicht getroffen hat, und denk dran, wenns schief geht. ;)
Nach der Aktivierung von PowerShell Serialization Payload Signing lässt sich bei meinem EX19 in der Exchange Toolbox der „Queue Viewer“ nicht mehr starten. Auf verschiedenen Servern reproduzierbar.
Kann das jemand mal bitte testen und berichten?
Ja, kann ich bestätigen. Bei Exchange 2016 bin ich noch nicht soweit, aber die beiden 2019er zeigen genau diesen Fehler und zeigen im Healthchecker auch nicht die Aktivierung an.
Danke für die Rückmeldung!
Ja tritt bei Exchange 2016 ebenfalls auf. Im Script (HTML Report) ist es aber mehrfach zu sehen. ;)
Also, ich habe das mal umgesetzt…
New-SettingOverride -Name „EnableSigningVerification“ -Component Data -Section EnableSerializationDataSigning -Parameters @(„Enabled=true“) -Reason „Enabling Signing Verification“
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name W3SVC, WAS -Force
in einer Elevated Exchange PowerShell.
Interessanterweise kann ich nun (nach der Umsetzung) Get-ExchangeCertificate normal (non-elevated shell) nicht mehr ausführen, da kommt ein Empty-Result zurück:
Thumbprint Services Subject
———- ——– ——-
ABER: Get-ExchangeCertificate läuft anscheinend dann nur noch in einer elevated Exchange PowerShell, da kommen dann die normalen Ergebnisse.
Habe mal mit einer anderen Exchange Domain getestet (noch nicht mit dem neuesten SU versehen), mit ’normaler‘ Exchange PowerShell (nicht elevated), da funktioniert der Get-ExchangeCertificate Befehl weiterhin mit Ergebnissen.
Ist das so beabsichtigt, oder habe ich was falsch gemacht ??
When the ability to sign serialization data is enabled, an expired auth certificate prevents the Get-ExchangeCertificate cmdlet from returning certificate details.
There is NO expired certificate! Tested on 3 different servers, everywhere the same. Only an elevated PowerShell returns the Certs. after applying the PowerShell signing. One of the three servers had been installed 14 days(!!) ago, so there is nothing which could be expired! Lukas Sassl (of MS) mentioned the same as you, but that’s not the problem. Just start an Exchange PowerShell (not elevated) and try yourself the Get-ExchangeCertificate command. You’ll see an empty output. If you are using an elevated Exchange PowerShell the output will be correct! If an expired certificated would cause this, then you won’t see any result even in an elevated shell.
EX 19 CU 12 und Januar SU installiert.
Habe PowerShell Serialization Payload Signing aktiviert. Im Exchange Health Checker wird die Funktion aber nicht angezeigt.
Die Zeile fehlt dort. Bei einem EX 16 wird die Zeile als Grün aktiviert angezeigt.
Noch jemand die Erfahrung oder kann das mal testen?
Bei 2019 wird nix angezeigt. 2016 konnte ich noch nicht testen.
OK dann scheint das noch ein Fehler vom HealthChecker zu sein.
Ist jetzt mit der aktuellsten Skriptversion behoben.
Bzgl. IISReset.
Auf https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/SerializedDataSigningCheck/ wird gesagt
„Exchange 2016/2019: It’s sufficient to restart the services on the server where the change was made.“
Heißt das, dass es für die Anwender doch nicht zu einem Ausfall kommt, weil der IIS nur auf dem letzten Exchange neugestartet wird, welcher sich sowieso noch im Wartungsmodus befindet?
Alle anderen Server haben das Update bereits installiert und bekommen das Sicherheitsfeature durch die Aktivierung automatisch ohne Dienst-Neustart?
Ich antworte mir mal selbst…
Vermutlich wird die Aktivierung von einem Exchange im Wartungsmodus gar nicht funktionieren, da die Shell nicht (oder nicht vollständig) zur Verfügung stellt.
Ich werde es nicht testen und einfach eine kurze Unterbrechung ankündigen.
Hallo,
Danke für die Info – kann die PowerShell Serialization Payload Signing auch problemlos wieder deaktiviert werden?
Welche Nebenwirkungen kann das neue Feature verursachen?
Was muß getestet werden, wenn man das Feature einschaltet?
Ohne es getestet zu haben, da noch nicht aktiviert:
Remove-SettingOverride -Identity „EnableSigningVerification“
Wir nutzen in unseren Infrastrukturen selbstgebaute Commandlets, welche per PS-Modul bereitgestellt werden. Hier haben wir nach Aktivierung von CSPSP massive probleme, wenn diese nicht durch Exchange-Org-Admins, sondern von Exchange-Recipient-Admins aufgerufen werden. Gleiches ist, wenn ich als Org-Admin eine non-elevated PS Session starte.
Ich hab daraufhin CSPSP wie folgt deaktiviert:
New-SettingOverride -Name „EnableSigningVerification“ | Remove-SettingOverride
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name W3SVC,WAS -Force
Danach funktioniert alles wieder wie vorher.
Sorry, Cut-And-Paste-Fehler ;)
Erste Zeile muss natürlich lauten:
Get-SettingOverride -Name „EnableSigningVerification“ | Remove-SettingOverride
Boah, es wird Zeit für’s Wochenende ;) … das hier sollte jetzt passen :) …
Get-SettingOverride -Identity „EnableSigningVerification“ | Remove-SettingOverride
Lief problemlos auf Exchange 2016 CU23 durch. HealthChecker zeigt in der aktuellen Version alles grün.
Certificate Signing nicht aktiviert. Ich warte da noch ab.
Gruß
Vielen Dank erst einmal für die schnelle Aktualisierung. Es scheint sich wohl der Fehlerteufel eingeschlichen zu haben:
.\Apply-ExchangeHealthChecker-Recommendations.ps1
In C:\Scripte\Apply-ExchangeHealthChecker-Recommendations.ps1:48 Zeichen:43
+ [string]$SetExchangeExtendedProtection
+ ~
„)“ fehlt in Funktionsparameterliste.
In C:\Scripte\Apply-ExchangeHealthChecker-Recommendations.ps1:55 Zeichen:1
+ )
+ ~
Unerwartetes Token „)“ in Ausdruck oder Anweisung.
+ CategoryInfo : ParserError: (:) [], ParseException
+ FullyQualifiedErrorId : MissingEndParenthesisInFunctionParameterList
Hi,
dürfte jetzt behoben sein. Bitte einmal testen.
Beste Grüße, Frank
Certificate Signing schon jemand aktiviert nach den Updates?
Besonders in einer DAG?
Grüße
Ja. Sowohl bei 2019 als auch 2016. die dag stört das nicht. ;) der queueviewer geht dann nicht mehr (hat aber nix mit der dag zu tun).
Installation auf Ex2016 CU23 verlief problemlos, allerdings scheint es ein Problem beim Healthchecker zu geben. Da werden alle in dem SU behobenen CVE Einträge trotzdem rot angemeckert. Vielleicht liegts am fehlenden Certificate Signing das ich noch nicht aktiviert habe.
MS hat eben den HealthChecker aktualisiert
.\HealthChecker.ps1
Exchange Health Checker version 23.01.10.2035
Damit sind die Tests dann i.O.
VG
René
Wir sind inzwischen bei 23.01.11.1522
Kein Kommentar zu Microsoft, dass nur noch CU 23 für Exchange 2016 unterstützt wird…. Da hieß immer, dass die letzten beiden CU‘s unterstützt werden…. Jemand schon getestet ?
Im Blog schreibt Nino Bilic:
„That is correct. It is over a year now (about 15 months) that CU22 has been released and it is not a supported CU anymore for Exchange Server 2016. As we said on this blog few times over last few months, from November 2022 on, only CU23 is supported for Exchange Server 2016. Please upgrade.“
es hieß immer, dass die letzten beiden CU’s Updates erhalten. Das ist nun nicht mehr so
Das stimmt. Ist auch für mich neu!
Nein, das ist nicht korrekt. Im Mainstream Support sind es die letzten beiden CUs (und da ist Exchange 2016 jetzt schon länger raus). Kann man hier nachlesen:
https://techcommunity.microsoft.com/t5/exchange-team-blog/servicing-exchange-server/ba-p/3676996
Extended Support:
· To get support (and SUs), customers must run the current CU – either Exchange Server 2016 CU23 or Exchange Server 2013 CU23.
@NorbertFe: Danke, du hast vollkommen Recht!