Microsoft hat heute neue Updates für Exchange Server 2016 und 2019 veröffentlicht. Bei dem jetzt veröffentlichten CU21 für Exchange 2016 handelt es sich um das letzte CU, welches noch für Exchange 2016 erscheint. Ab jetzt wird es nur noch Sicherheitsupdates für Exchange 2016 geben.
Hier geht es direkt zum Download der CUs:
Das CU10 für Exchange 2019 lässt sich nun auch direkt von Microsoft runterladen, ohne dass ein VLSC Zugang, Action Pack oder Visual Studio Abo benötigt wird. Bisher war dies nicht möglich, aber scheinbar hat Microsoft hier seine Strategie überdacht und bietet den Download nun direkt an.
Details zu den behoben Problemen gibt es unter den folgenden Links (möglicherweise noch nicht direkt verfügbar):
- Exchange Server 2019 Cumulative Update 10 (KB5003612)
- Exchange Server 2016 Cumulative Update 21 (KB5003611)
Die CUs enthalten alle zuvor veröffentlichen Sicherheitsupdates.
Mit den Juni CUs für Exchange bekommen beide Versionen ein neues Feature. Das Windows Antimalware Scan Interface (AMSI) integriert sich nun auch in Exchange Server. AMSI ist auf Windows Server 2016 und 2019 verfügbar. Sollte Exchange 2016 noch auf Server 2012R2 installiert sein, lässt sich die AMSI Integration nicht nutzen.
Die AMSI Integration ermöglicht es, dass AMSI kompatible Software, die HTTP-Verbindungen zu Exchange Servern auf schadhaften Traffic untersuchen und blockieren können. Die AMSI-Integration in Exchange Server funktioniert mit jeder AMSI-fähigen Antiviren-/Antimalware-Lösung. Sollte keine AMSI kompatible Antimalwaresoftware auf dem Exchange Server installiert sein, übernimmt Microsoft Defender Antivirus (MDAV) das Scannen des Traffics. MDAV ist bereits in Windows Server 2016 und Server 2019 vorinstalliert. wird aber deaktiviert, sobald eine andere Antivirus Lösung installiert wird. Hier sollte geprüft werden, ob die eingesetzte Antivirensoftware AMSI kompatibel ist, damit das neue Feature genutzt werden kann. Wichtig: Bei der AMSI Integration handelt es sich nicht um eine Integration in einen Virenscanner im klassischen Sinn. AMSI ermöglicht es den HTTP Verkehr eines Exchange Servers zu untersuchen, also Protokolle wie MAPIoverHTTP, ActiveSync, EWS und OWA. Hier werden also nicht Mails auf Viren, Malware oder SPAM untersucht, sondern die Verbindungen der Clients zum Exchange Server.
Die Exchange AMSI Integration dürfte eine Reaktion auf die HAFNIUM Schwachstelle Anfang des Jahres sein, denn ein entsprechendes Signaturupdate hätte schnell die Auswirkungen abmildern können.
Moin,
ich bekomme einen Abbruch der Installation mit folgender Fehlermeldung
[08.13.2021 20:54:13.0336] [2] Ending processing new-PowerShellVirtualDirectory
[08.13.2021 20:54:13.0337] [1] The following 1 error(s) occurred during task execution:
[08.13.2021 20:54:13.0337] [1] 0. ErrorRecord: Das virtuelle Verzeichnis ‚PowerShell‘ ist bereits unter ‚xxx.xxx.de/Exchange Back End‘ vorhanden.
Parametername: VirtualDirectoryName
[08.13.2021 20:54:13.0337] [1] 0. ErrorRecord: System.ArgumentException: Das virtuelle Verzeichnis ‚PowerShell‘ ist bereits unter ‚xxx.xxx.de/Exchange Back End‘ vorhanden.
Parametername: VirtualDirectoryName
bei Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
bei Microsoft.Exchange.Management.SystemConfigurationTasks.NewExchangeVirtualDirectory`1.InternalValidate()
bei Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)
[08.13.2021 20:54:13.0340] [1] [ERROR] The following error was generated when „$error.Clear();
$feVdirName = „PowerShell (Default Web Site)“;
$beVdirName = „PowerShell (Exchange Back End)“;
$vdirName = „PowerShell“;
$InternalPowerShellUrl=“http://“ + $RoleFqdnOrName + „/powershell“;
$vdir = get-PowerShellVirtualDirectory -ShowMailboxVirtualDirectories -server $RoleFqdnOrName -DomainController $RoleDomainController | where { $_.Name -eq $beVdirName };
if ($vdir -eq $null)
{
new-PowerShellVirtualDirectory $vdirName -Role Mailbox -DomainController $RoleDomainController -BasicAuthentication:$false -WindowsAuthentication:$true -RequireSSL:$true -WebSiteName „Exchange Back End“ -Path ($RoleInstallPath + „ClientAccess\PowerShell-Proxy“);
}
else
{
update-PowerShellVirtualDirectoryVersion -DomainController $RoleDomainController;
}
$vdir2 = get-PowerShellVirtualDirectory -ShowMailboxVirtualDirectories -server $RoleFqdnOrName -DomainController $RoleDomainController | where { $_.Name -eq $feVdirName };
if ($vdir2 -eq $null)
{
new-PowerShellVirtualDirectory $vdirName -Role Mailbox -InternalUrl $InternalPowerShellUrl -DomainController $RoleDomainController -BasicAuthentication:$false -WindowsAuthentication:$false -RequireSSL:$false -WebSiteName „Default Web Site“ -AppPoolId „MSExchangePowerShellFrontEndAppPool“;
}
else
{
update-PowerShellVirtualDirectoryVersion -DomainController $RoleDomainController;
}
“ was run: „System.ArgumentException: Das virtuelle Verzeichnis ‚PowerShell‘ ist bereits unter ‚xxx.xxx.de/Exchange Back End‘ vorhanden.
Parametername: VirtualDirectoryName
bei Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
bei Microsoft.Exchange.Management.SystemConfigurationTasks.NewExchangeVirtualDirectory`1.InternalValidate()
bei Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)“.
[08.13.2021 20:54:13.0340] [1] [ERROR] Das virtuelle Verzeichnis ‚PowerShell‘ ist bereits unter ‚xxx.xxx.de/Exchange Back End‘ vorhanden.
Parametername: VirtualDirectoryName
[08.13.2021 20:54:13.0341] [1] [ERROR-REFERENCE] Id=PowerShellComponent___0933481a46d24e77abfdf174e8240b80 Component=EXCHANGE14:\Current\Release\Shared\Datacenter\Setup
[08.13.2021 20:54:13.0341] [1] Setup is stopping now because of one or more critical errors.
[08.13.2021 20:54:13.0341] [1] Finished executing component tasks.
[08.13.2021 20:54:13.0375] [1] Ending processing Install-BridgeheadRole
[08.13.2021 20:54:38.0022] [0] CurrentResult setupbase.maincore:396: 0
[08.13.2021 20:54:38.0023] [0] End of Setup
ich hab bereits versucht die Powershell im IlS zu Löschen das hat mir keine abhilfe gebracht, hat da jemand eine Idee?
Hallo zusammen,
ich möchte gerne unsere beiden DAG Server Exchange 2019/ Server 2019 auf das CU 10 bringen. Dieses CU beinhaltet ja auch eine Schemaänderung.
Jetzt mal in die offene Welt gefragt, wie installiert ihr ein CU?
Ich habe bislang die iso bereitgestellt, dann per doppelklick die setup ausgeführt. (Auch schon mal mit Schema) Bislang lief es immer ohne Probleme durch oder empfehlt ihr die Eingabeaufforderung mit admin rechten wie folgt
E:\Setup.exe /IAcceptExchangeServerLicenseTerms /Mode:Upgrade /DomainController:dc01.contoso.com
??
Sicherheitsupdates wie immer mit cmd und admin
Konnte das das Security Update für Exchange Server 2016 CU20 (KB5004779) auf einem einzelnen Exchange-Server einspielen. Jedoch leider nicht CU21, weder mit KB5004779 noch ohne. Die Installation von CU21 bricht jeweils bei Schritt 16 von 18 mit folgender Meldung ab:
Der folgende Fehler wurde generiert, als „$error.Clear();
Install-ExchangeCertificate -services „IIS, POP, IMAP“ -DomainController $RoleDomainController
if ($RoleIsDatacenter -ne $true -And $RoleIsPartnerHosted -ne $true)
{
Install-AuthCertificate -DomainController $RoleDomainController
}
“ ausgeführt wurde: „Microsoft.Exchange.Management.SystemConfigurationTasks.AddAccessRuleCryptographicException: Aufgrund einer Kryptografieausnahme konnte konnte kein Netzwerkdienstzugriff auf das Zertifikat mit dem Fingerabdruck BA9E98E9E395A7914DA49C7E376969F3197B21BD erteilt werden. —> System.Security.Cryptography.CryptographicException: Zugriff verweigert
bei Microsoft.Exchange.Security.Cryptography.X509Certificates.TlsCertificateInfo.CAPIAddAccessRule(X509Certificate2 certificate, AccessRule rule)
bei Microsoft.Exchange.Security.Cryptography.X509Certificates.TlsCertificateInfo.AddAccessRule(X509Certificate2 certificate, AccessRule rule)
bei Microsoft.Exchange.Management.SystemConfigurationTasks.ManageExchangeCertificate.EnableForServices(X509Certificate2 cert, AllowedServices services, String websiteName, Boolean requireSsl, ITopologyConfigurationSession dataSession, Server server, List`1 warningList, Boolean allowConfirmation, Boolean forceNetworkService)
— Ende der internen Ausnahmestapelüberwachung —
bei Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
bei Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
bei Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.EnableForServices(X509Certificate2 cert, AllowedServices services)
bei Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.InternalProcessRecord()
bei Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)“.
Kannst Du mit New-ExchangeCertificate ein neues Zerifikat erzeugen?
Kannst Du die fehlenden Rechte manuell zuweisen:
Zertifikate -> Rechte Maustaste auf das „BA9E98E9E395A7914DA49C7E376969F3197B21BD“
Alle Aufgaben -> Private Schlüssel verwalten
Netzwerkdienst hinzufügen -> „lesen“ Rechte hinzufügen
Ja ich konnte ein neues, selbst signiertes Zertifikat in der Exchange Management Shell mittels des Kommandos „New-ExchangeCertificate“ erstellen. Und ich konnte auch die Rechte für dieses Zertifikat einsehen in der certlm.msc bzw. in „Benutzerzertifkate verwalten“ und dort durch rechten Mausklick auf das Zertifikat und Wahl von „Alle Aufgaben \ Private Schlüssel verwalten“.
Ich habe dieses selbst signierte Zertifikat allerdings nicht das aktuelle Zertifikat ersetzen lassen, da ich Let’s encrypt Zertifikate mittels WIN-ACME nutze wie hier beschrieben auf https://www.frankysweb.de/exchange-certificate-assistant-keine-neue-version-aber-eine-bessere-alternative-win-acme/ .
Das in der Fehlermeldung aufgeführte Zertifikat habe ich gar nicht mehr gefunden. Allerdings hatte ich zwischenzeitlich 2 uralte, nicht mehr genutzte Zertifikate gelöscht gehabt.
Dank Änderung der Zugriffsrechte für das Let’s Encrypt Zertifikat, dass ich Leserechte für „Netzwerkdienst“ ergänzt habe, konnten Exchange Server 2016 CU21 und KB5004779 erfolgreich installiert werden. Danke an Ralf für seinen wertvollen Tip!
Habe gestern das Security Update For Exchange Server 2016 CU20 (KB5004779) eingespielt und nun komme ich nicht mehr auf das ECP.
erhalte diesen Fehler:
Serverfehler in der Anwendung /owa.
ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length<1
hat da jemand eine Idee was hier passiert ist?
Adrian, Dein oAuth Zertifikat fehlt oder ist abgelaufen. Schau mal hier in der „Workaround“ Sektion: https://support.microsoft.com/en-us/topic/you-can-t-access-owa-or-ecp-after-you-install-exchange-server-2016-cu6-88b3fe67-5f97-a8a2-8ed8-70034ff15761
Ralf
Sali Ralf
Danke das habe ich auch schon probiert.
Musste Wohl einfach mal so ca. 4h warten dann ging es wieder.
Neues Sicherheitsupdate ist raus https://support.microsoft.com/de-de/topic/hinweise-zum-sicherheitsupdate-f%C3%BCr-microsoft-exchange-server-2019-2016-und-2013-13-april-2021-kb5001779-8e08f3b3-fc7b-466c-bbb7-5d5aa16ef064
Downloadsymbol Download Security Update For Exchange Server 2019 Kumulatives Update 9 (KB5001779)
Downloadsymbol Download Security Update For Exchange Server 2019 Kumulatives Update 8 (KB5001779)
Downloadsymbol Download Security Update For Exchange Server 2016 Kumulatives Update 20 (KB5001779)
Downloadsymbol Download Security Update For Exchange Server 2016 Kumulatives Update 19 (KB5001779)
Downloadsymbol Download Security Update For Exchange Server 2013 Kumulatives Update 23 (KB5001779)
Sorry falscher Link, bitte löschen!
Wir betreiben unsere Exchangeserver 2016 (DAG) auf Server 2012R2.
„AMSI Integration“ gem. obigen Beschrieb nicht möglich. Ist dies korrekt? Was passiert dann mit diesem neuem Modul? Wird es nicht aktiviert, gibt es Issues/Fehler/…?
Hat jemand das CU21 auf einer solchen Konstellation schon installiert?
Update von DAG Exchange 2016 von CU20 auf CU21 ohne Probleme.
Frage mich auch was Microsoft für Schema Änderungen im Update gesteckt hat.
Die eine Änderung ist hier dokumentiert:
https://docs.microsoft.com/en-us/Exchange/plan-and-deploy/active-directory/ad-schema-changes?view=exchserver-2016#exchange-2016-cu21-active-directory-schema-changes
Sorry, war mein Kollege, das Spielkind
Moinsen,
alles kaputt mussten unseren 2007er Exchange wieder hochfahren.
Der läuft wie am ersten Tag
Hat jemand eine Idee /Ahnung was MS mit „sehr großen Anhängen“ meint?
https://support.microsoft.com/de-de/topic/fehler-e-mail-kann-nicht-gesendet-werden-ihr-postfach-ist-voll-wenn-sie-iphone-mail-verwenden-um-sehr-gro%C3%9Fe-anlagen-zu-senden-kb5004622-eb95555f-80fd-47b4-bc6f-5c2c4fc4fea0
Irgendwie scheint das Problem aus KB5004622 auch mit CU22 noch nicht gelöst worden zu sein.
Ich habe auch schon diverse Grenzwerte im IIS angehoben, aber leider ohne Erfolg.
Kennt jemand einen sinnvollen Workaround oder eine andere vertretbare Alternative neben ActiveSync, um ein iPad oder iPhone auf Postfächer eines Exchenge 2016 CU22 onPrem loszulassen?
Irgendjemand eine Ahnung was mit KB5004623 passiert ist?
Es stand für ~1 Stunde direkt nach dem Release des CU bei den Fixes dabei und es war sogar ein Link zu einem CVE vorhanden(der aber nicht funktioniert hat). Mittlerweile ist allerdings sogar die KB5004623 seite komplett gelöscht worden.
Die Relevanten AD Schema Änderungen sind allerdings offenbar noch im CU vorhanden.
Google Cache link:
https://webcache.googleusercontent.com/search?q=cache:h5eg71PU66EJ:https://support.microsoft.com/en-us/topic/elevation-of-privilege-vulnerability-in-active-directory-because-of-msexchstoragegroup-schema-class-kb5004623-ae4dc955-ba80-4f5e-89a7-5005f80327b5+&cd=1&hl=de&ct=clnk&gl=de&client=firefox-b-e
Update Exchange 2016 CU19 -> CU21 lief problemlos durch \o/
Nach dem update wollte allerdings ein sendeconnector nicht mehr so wirklich tun was er sollte, ein deaktivieren und wieder aktivieren des Connectors hat das problem dann gelöst ;)
Ansonsten bisher keine weiteren Auffälligkeiten.
Update von CU20 auf das CU21 lief ohne Probleme auf beide Server des DAG-Verbundes durch.
Jedoch kommt es nun im Zusammenhang mit der Sophos Server Protektion (genauer Sophos AMSI Protection) zu erheblichen Problemen mit der Verbindung zu Outlook. Diese ist bei allen Clients nun brechend langsam. Mails Empfangen/Versenden dauert mehrere Minuten und bei manchen Kollegen geht Outlook schon gar nicht mehr auf. OWA, ActiveSync ist davon nicht betroffen.
Das temporäre deaktivieren dieses Moduls bringt hier Abhilfe. Ticket bei Sophos ist derzeit noch offen.
Danke erstmal das du ein Ticket bei Sophos aufgemacht hast. Somit muss ich das nicht machen :)
Gibt es schon eine Antwort auf das Ticket von Sophos?
Upgrade einer DAG 2016 von CU20 auf CU21 hat leider einen Node komplett gecrasht, Restore notwendig, trotz aller üblichen Vorab-Maßnahmen. Setup ist abgestürzt und der MSX ist auf dem Knoten nur noch halb drauf.
Upgrade auf einer Ex2019 DAG von CU9 auf CU10 problemlos durchgelaufen.
Vorsichtshalber vor dem Setup noch auf den Nodes einen Reboot durchgeführt.
Ex2016 CU20 auf CU21 lief problemlos durch. Der Exchange hat im Anschluss ganz schön gerödelt. Erst lief der. NET Optimizer an und dann ratterte bei den IIS Workern noch was durch. Ein Neustart hat aber wieder alles beruhigt.
EX 16 CU 21 lässt sich nun auch direkt so herunterladen :-)
War das mal anders? ;)
Ex 19 ist das. Ex 16 ging schon immer.
Also Ex 19 CU 10
„ob das daranliegt?“
Nein. :)
Hallo
diese Vorbereitung „Setup.EXE /PrepareAD /IAcceptExchangeServerLicenseTerms“ für das eigentliche Setup habe ich nie gemacht, ich habe aber immer alle CUs nathlos installiert und keines ausgelassen, ob das daranliegt?
Also, die Installation des CU21 auf Exchange 2016 mit Server 2016 lief problemlos duch.
EAC kann man sich einloggen, keine Probleme erkennbar, E-Mails senden und empfangen funktioniert auch.
Die Fehler in der Ereignissanzeige sind aber nicht verschwunden, aber die gibts schon seit 2017.
Nabend,
derzeit scheitere ich schon an den Vorbereitung für das eigentliche Setup:
Schema wurde erfolgreich von CU19 auf CU21 aktualisiert
Setup.EXE /PrepareAD /IAcceptExchangeServerLicenseTerms bricht immer wieder ab:
per GUI im Schritt 1 von 18:
Fehler:
Der folgende Fehler wurde generiert, als „$error.Clear();
$createTenantRoot = ($RoleIsDatacenter -or $RoleIsPartnerHosted);
$createMsoSyncRoot = $RoleIsDatacenter;
#$RoleDatacenterIsManagementForest is set only in Datacenter deployment; interpret its absense as $false
[bool]$isManagementForest = ($RoleDatacenterIsManagementForest -eq $true);
if ($RolePrepareAllDomains)
{
initialize-DomainPermissions -AllDomains:$true -CreateTenantRoot:$createTenantRoot -CreateMsoSyncRoot:$createMsoSyncRoot -IsManagementForest:$isManagementForest;
}
elseif ($RoleDomain -ne $null)
{
initialize-DomainPermissions -Domain $RoleDomain -CreateTenantRoot:$createTenantRoot -CreateMsoSyncRoot:$createMsoSyncRoot -IsManagementForest:$isManagementForest;
}
else
{
initialize-DomainPermissions -CreateTenantRoot:$createTenantRoot -CreateMsoSyncRoot:$createMsoSyncRoot -IsManagementForest:$isManagementForest;
}
“ ausgeführt wurde: „System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
bei Microsoft.Exchange.Management.Tasks.SetupTaskBase.LogReadObject(ADRawEntry obj)
bei Microsoft.Exchange.Management.Tasks.InitializeDomainPermissions.InternalProcessRecord()
bei Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)
bei Microsoft.Exchange.Configuration.Tasks.Task.ProcessTaskStage(TaskStage taskStage, Action initFunc, Action mainFunc, Action completeFunc)
bei Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord()
bei System.Management.Automation.CommandProcessor.ProcessRecord()“.
Da ich bisher das CU20 nicht installiert hatte habe ich selbstredend versucht die Vorbereitungen für das CU20 vorzunehmen, dies funktioniert einwandfrei.
Derzeit weiß ich nicht wo ich ansetzen kann. Berechtigungen sind fast ausgeschlossen (Upgrade von CU19 auf CU20 hat soeben funktioniert)
Hat Jemand eine Idee?
Danke & Gruß
Mario
Hallo Mario,
habe den gleichen Fehler bei einem Exchange 2019 CU 9. Upgrade schlägt auf die CU 10 mit dem gleichen Fehler fehl.
Hier die Kreuzverlinkung:
Gruß
Tobi
Nabend,
bisher habe ich keine Lösung gefunden.
Zwischenzeitlich habe ich versucht Exchange 2019 mittels CU10 auf einer neuen VM zu installieren, aber auch hier gibt es entsprechende Fehler wenn es um PrepareAD geht.
Bei Microsoft (https://techcommunity.microsoft.com/t5/exchange-team-blog/released-june-2021-quarterly-exchange-updates/ba-p/2459826) finden sich weitere Einträge zum von mir geschildertehn Problem.
Ich warte mal eine gute Woche ab, wenn es dann immer noch keine Lösung gibt werde ich ein Ticket bei Microsoft eröffnen. Das letzte Ticket ist > 15 Jahre her und handelte sich um MS-MAIL auf Novellservern :-)
Leider bei uns das selbe Problem, aber beim Update von CU20 auf CU21 …
Hi Mario, und hast schon eine Lösung gefunden?
Hi Stefan,
würde mich auch interessieren. Bin seit Tagen dran am System aber kommen nicht weiter. Frank ist auch dabei im Administrator Forum.
Hallo Zusammen,
wurde das Problem gelöst?
Gruß
Markus
Bei mir ist das Update von 2019 CU9 auf CU10 auch nicht möglich. Obwohl der User in der Gruppe Schema- und Organisationsadmins ist, schlägt die Vorbereitung des Setups mit der Meldung fehl: „Das Active Directory-Schema ist nicht aktuell, und dieses Benutzerkonto ist kein Mitglied der Gruppe ‚Schema-Admins‘ und/oder ‚Organisations-Admins‘.“
Ich komme als gar nicht bis zur Installation. Und ja, das Setup wurde mit erhöhten Rechten in der PowerShell ausgeführt.
Bitte Schema Erweiterung immer per CMD Admin Mode und nie per Powershell.
natürlich kann das Schema auch mittels einer mit Adminstrationsrechten gestarteten powershell erweitert werden.
Das Problem mit dem Upgrade auf CU10/CU21 ist ein anderes und wird seitens Exchange Team/Microsoft noch untersucht.
Weitere Leidensgenossen finden sich unter https://techcommunity.microsoft.com/t5/exchange-team-blog/released-june-2021-quarterly-exchange-updates/ba-p/2459826
Hi Mario,
der Fehler allein bzw. der Call-Stack genügen leider nicht. Was steht denn unmittelbar in der Zeile darüber?
Das hier: Used domain controller NTVMDC05.kba.de to read object CN=AdminSDHolder,CN=System,DC=contoso,DC=com.
?
Wenn ja führe bitte mal das aus (mit angepasstem DC=:
C:\>dsquery * -filter „(&(objectCategory=*)(distinguishedName=CN=AdminSDHolder,CN=System,DC=contoso,DC=com)(!(msExchCU=*))(objectCategory=container)(|(&(msExchVersion<=1125899906842624)(!(msExchVersion=1125899906842624)))(!(msExchVersion=*))))"
Was ist das Resultat? Etwa so: "CN=AdminSDHolder,CN=System,DC=contoso,DC=com"
Wenn das für den Admin klappt, kannst Du das selbe Mal als LocalSystem auf dem Exchange Server ausführen? Dazu brauchst Du psexec von Sysinternals und startest es per: psexec -s -i cmd.exe
Ralf
Hallo Ralf,
ich sehe derzeit nicht was Du wissen möchtest.
dsquery zeigt jeweils CN=AdminSDHolder,CN….. an, als Admin wie auch als System.
Die Verbindung zu einem der AD Controller besteht und wird nicht angemeckert.
Es besteht kein Handlingsfehler und es gibt auch keine Berechtigungsprobleme…
[07.06.2021 12:53:17.0508] [2] Used domain controller AD-1.intern.de to read object DC=intern,DC=de.
[07.06.2021 12:53:17.0560] [2] Used domain controller AD-1.intern.de to read object CN=AdminSDHolder,CN=System,DC=intern,DC=de.
[07.06.2021 12:53:17.0571] [2] [ERROR] Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
[07.06.2021 12:53:17.0572] [2] [WARNING] An unexpected error has occurred and a Watson dump is being generated: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
[07.06.2021 12:53:17.0829] [1] The following 1 error(s) occurred during task execution:
[07.06.2021 12:53:17.0829] [1] 0. ErrorRecord: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
[07.06.2021 12:53:17.0829] [1] 0. ErrorRecord: System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
bei Microsoft.Exchange.Management.Tasks.SetupTaskBase.LogReadObject(ADRawEntry obj)
bei Microsoft.Exchange.Management.Tasks.InitializeDomainPermissions.InternalProcessRecord()
bei Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)
bei Microsoft.Exchange.Configuration.Tasks.Task.ProcessTaskStage(TaskStage taskStage, Action initFunc, Action mainFunc, Action completeFunc)
bei Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord()
bei System.Management.Automation.CommandProcessor.ProcessRecord()
[07.06.2021 12:53:17.0831] [1] [ERROR] The following error was generated when „$error.Clear();
$createTenantRoot = ($RoleIsDatacenter -or $RoleIsPartnerHosted);
$createMsoSyncRoot = $RoleIsDatacenter;
#$RoleDatacenterIsManagementForest is set only in Datacenter deployment; interpret its absense as $false
[bool]$isManagementForest = ($RoleDatacenterIsManagementForest -eq $true);
if ($RolePrepareAllDomains)
{
initialize-DomainPermissions -AllDomains:$true -CreateTenantRoot:$createTenantRoot -CreateMsoSyncRoot:$createMsoSyncRoot -IsManagementForest:$isManagementForest;
}
elseif ($RoleDomain -ne $null)
{
initialize-DomainPermissions -Domain $RoleDomain -CreateTenantRoot:$createTenantRoot -CreateMsoSyncRoot:$createMsoSyncRoot -IsManagementForest:$isManagementForest;
}
else
{
initialize-DomainPermissions -CreateTenantRoot:$createTenantRoot -CreateMsoSyncRoot:$createMsoSyncRoot -IsManagementForest:$isManagementForest;
}
“ was run: „System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
Gruß
Mario
Mario, es hilft nicht wenn Du den selben CallStack wieder und wieder reinkopierst. Befindet sich der AdminSDHolder Container im AD auch an der Stelle: CN=AdminSDHolder,CN=…..
Kannst Du mal einen LDAP Dump mit ldp.exe davon machen. Hatte gestern einen identischen Fall, da hat der Admin den Container CN=Computers umbenannt und eine OU=Computers erzeugt.