16
PowerShell mit Exchange 2019
Moin,
ich sehe den Wald nicht...
Wir haben hier einen Restore aus unserer Produktivumgebung (Exchange 2013 auf Windows 2012 R2) gemacht um ein Exchange Setup (Exchange 2019 auf Windows 2022) vorab zu testen. Soweit sieht das auch alles erstmal ganz gut aus, die Exchange Management Shell auf dem neu installierten Exchange möchte aber keine Cmdlets laden.
Windows 2022
Exchange 2019
https://exchangeneu.domain.de/ecp geht interessanter Weise nicht, tut aber eventuell nichts zur Sache, https://localhost/ecp auf exchangeneu.domain.de geht
DNS auf exchangeneu.domain.de geht
Windows-Anmeldung an exchangeneu als Domäne\Administrator
Exchange Management Shell auf exchangeneu = Verbunden mit exchangeneu.domain.de
whoami = Domäne\Administrator
Domäne\Administrator ist Mitglied von "Organization Management"
"Organization Management" wurde nicht verändert
Wenn ich jetzt in der Management Shell einen Befehl ausführen will wie z.B.:
Get-OwaVirtualDirectory
Get-EcpVirtualDirectory
Get-WebServicesVirtualDirectory
Get-ActiveSyncVirtualDirectory
Get-OabVirtualDirectory
Get-MapiVirtualDirectory
Get-OutlookAnywhere
Get-ClientAccessService
...kommt immer: "Die Benennung "[...]" wurde nicht als als Name eines cmdlets, [...] erkannt."
(ich fand den Tipp des Tages sehr passend)
Wie man sieht habe ich an ein Berechtigungsproblem gedacht, kann aber nicht erkennen wo es hier hakt. Auf dem alten Exchange 2013 läuft das alles in der Management Shell. Auch sehe ich im ECP alle Einstellungen von beiden Servern, So ziemlich jede Anleitung die ich für Exchange Migrationen gefunden habe gehen davon aus das ich diese cmdlets aufrufen kann, bin ich hier zu blöd?
ich sehe den Wald nicht...
Wir haben hier einen Restore aus unserer Produktivumgebung (Exchange 2013 auf Windows 2012 R2) gemacht um ein Exchange Setup (Exchange 2019 auf Windows 2022) vorab zu testen. Soweit sieht das auch alles erstmal ganz gut aus, die Exchange Management Shell auf dem neu installierten Exchange möchte aber keine Cmdlets laden.
Windows 2022
Exchange 2019
https://exchangeneu.domain.de/ecp geht interessanter Weise nicht, tut aber eventuell nichts zur Sache, https://localhost/ecp auf exchangeneu.domain.de geht
DNS auf exchangeneu.domain.de geht
Windows-Anmeldung an exchangeneu als Domäne\Administrator
Exchange Management Shell auf exchangeneu = Verbunden mit exchangeneu.domain.de
whoami = Domäne\Administrator
Domäne\Administrator ist Mitglied von "Organization Management"
"Organization Management" wurde nicht verändert
Wenn ich jetzt in der Management Shell einen Befehl ausführen will wie z.B.:
Get-OwaVirtualDirectory
Get-EcpVirtualDirectory
Get-WebServicesVirtualDirectory
Get-ActiveSyncVirtualDirectory
Get-OabVirtualDirectory
Get-MapiVirtualDirectory
Get-OutlookAnywhere
Get-ClientAccessService
...kommt immer: "Die Benennung "[...]" wurde nicht als als Name eines cmdlets, [...] erkannt."
Wie man sieht habe ich an ein Berechtigungsproblem gedacht, kann aber nicht erkennen wo es hier hakt. Auf dem alten Exchange 2013 läuft das alles in der Management Shell. Auch sehe ich im ECP alle Einstellungen von beiden Servern, So ziemlich jede Anleitung die ich für Exchange Migrationen gefunden habe gehen davon aus das ich diese cmdlets aufrufen kann, bin ich hier zu blöd?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6377048561
Url: https://administrator.de/contentid/6377048561
Ausgedruckt am: 18.11.2024 um 17:11 Uhr
16 Kommentare
Neuester Kommentar
PS: Der Restore war inklusive AD und ist natürlich in einem eigenen Subnetz ohne Kontakt zur Produktivumgebung.
Moin,
steht doch in der Fehlermeldung, warum es nicht geht.
https://learn.microsoft.com/de-de/exchange/troubleshoot/administration/e ...
hth
Erik
steht doch in der Fehlermeldung, warum es nicht geht.
https://learn.microsoft.com/de-de/exchange/troubleshoot/administration/e ...
hth
Erik
Zitat von @erikro:
steht doch in der Fehlermeldung, warum es nicht geht.
https://learn.microsoft.com/de-de/exchange/troubleshoot/administration/e ...
Der Zusammenhang erschließt sich mir noch nicht steht doch in der Fehlermeldung, warum es nicht geht.
https://learn.microsoft.com/de-de/exchange/troubleshoot/administration/e ...
Als Lösung wird hier auf KB3000850 verwiesen, das für Windows 2012 R2 geeignet ist. Auf dem exchangealt ist das schon drauf, der ist auf dem letzten Stand CU23 mit Patches. Auf exchangeneu mit Windows 2022 lässt sich das erwartungsgemäß nicht ausführen, "nicht geeignet". Ich wüsste auch nicht warum das Windows Patchlevel von exchangealt relevant sein sollte aber gut man weiß ja nie.
exchangeneu hat
Exchange Server - Standard 2019 MultiLanguage 64-Bit Win X21-88195.iso und
ExchangeServer2019-x64-CU12.ISO
installiert. Ich werde mal online nach Updates suchen aber das ist aufgrund der Trennung etwas frickelig.
Mal das hier probiert?
https://social.technet.microsoft.com/Forums/en-US/1ad99f0e-5230-43b2-ad2 ...
Cheers briggs
https://social.technet.microsoft.com/Forums/en-US/1ad99f0e-5230-43b2-ad2 ...
Cheers briggs
Ich hab jetzt Windows 2022 nochmal auf den aktuellen Stand gebracht mit ein paar Updates aber das hat nichts geändert.
Remote Power Shell connection habe ich auch probiert:
https://technet.microsoft.com/en-us/library/dd335083(v=exchg.150).aspx
Ich habe die "Remote"-Connection vom exchangeneu selbst per Powershell probiert, ich bin durch die Teststellung etwas eingeschränkt.
Zitat von @6247018886:
Mal das hier probiert?
https://social.technet.microsoft.com/Forums/en-US/1ad99f0e-5230-43b2-ad2 ...
Unter C:\Users\administrator.DOMAIN\AppData\Roaming\Microsoft hat keinen Unterordner Exchange.Mal das hier probiert?
https://social.technet.microsoft.com/Forums/en-US/1ad99f0e-5230-43b2-ad2 ...
Remote Power Shell connection habe ich auch probiert:
https://technet.microsoft.com/en-us/library/dd335083(v=exchg.150).aspx
New-PSSession : [exchangeneu.domain.de] Beim Verbinden mit dem Remoteserver "exchangeneu.domain.de" ist
folgender Fehler aufgetreten: Weitere Informationen finden Sie im Hilfethema "about_Remote_Troubleshooting".
In Zeile:1 Zeichen:12
+ $Session = New-PSSession -ConfigurationName Microsoft.Exchange -Conne ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gTransportException
+ FullyQualifiedErrorId : -2144108173,PSSessionOpenFailed
Dein Exchange ist neu aufgesetzt schon kaputt??
Aha und hast du noch eine Idee was?
- Postfachrolle angehakt
- Installation auf eigenem Laufwerk
- Schutz vor Schadsoftware = nein
Zertifikate haben wir nach dem Setup importiert, das war dann so das wesentliche.
- Postfachrolle angehakt
- Installation auf eigenem Laufwerk
- Schutz vor Schadsoftware = nein
Zertifikate haben wir nach dem Setup importiert, das war dann so das wesentliche.
https://www.frankysweb.de/installation-von-exchange-2019-cu12-auf-window ...
https://www.frankysweb.de/exchange-2019-umfangreiches-whitepaper-zu-zert ...
https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-auto ...
Der Reihe nach durchgehen.
Das sich die Webseite ja schon nicht mit dem richtigen Domainnamen aufrufen lässt zeugt a schon von einer fehlerhaften Einrichtung/Anpassung der Exchange URLs an die Umgebung. Wenn solche Grundlegenden Dinge schon nicht funktionieren dann wundern mich weitergehende Fehler in der Shell nicht wirklich, Kerberos lässt dich übrigens deswegen schön grüßen.
https://www.frankysweb.de/exchange-2019-umfangreiches-whitepaper-zu-zert ...
https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-auto ...
Der Reihe nach durchgehen.
Das sich die Webseite ja schon nicht mit dem richtigen Domainnamen aufrufen lässt zeugt a schon von einer fehlerhaften Einrichtung/Anpassung der Exchange URLs an die Umgebung. Wenn solche Grundlegenden Dinge schon nicht funktionieren dann wundern mich weitergehende Fehler in der Shell nicht wirklich, Kerberos lässt dich übrigens deswegen schön grüßen
.
Moin,
Gruß,
Dani
PS: Der Restore war inklusive AD und ist natürlich in einem eigenen Subnetz ohne Kontakt zur Produktivumgebung.
dann versteh ich den Fehler noch um so weniger. Das muss out-of-the-box sofort funktionieren. Sicher dass du nicht wesentliche Konfiguration geändert hast?Gruß,
Dani
Zitat von @Dani:
Moin,
Eventuell spielen hier Änderungen mit rein die in der Vergangenheit am exchangealt gemacht wurden, dort haben wir Zeitweise das Split-Permissions-Model gefahren. Das ganze ist aber komplex weil auch der Microsoft Support Hand angelegt hatte. Meine Hoffnung basiert darauf das der neue Exchange durch das Setup Rechtetechnisch wieder "normal" in der AD integriert ist.Moin,
PS: Der Restore war inklusive AD und ist natürlich in einem eigenen Subnetz ohne Kontakt zur Produktivumgebung.
dann versteh ich den Fehler noch um so weniger. Das muss out-of-the-box sofort funktionieren. Sicher dass du nicht wesentliche Konfiguration geändert hast?Aber: Die Management Shell auf exchangealt funktioniert problemlos. Wäre es ein Rechteproblem aufgrund von "Verbrechen" am alten Exchange würde ich hier auch Probleme erwarten.
Zurzeit versuchen wir in der Testumgebung es irgendwie zum laufen zu bringen, eventuell Testumgebung nochmal ganz neu machen.
Ich hätte auch kein Problem damit alles zu exportieren, den aktiven Exchange zu deinstallieren und dann das Setup für 2019 zu starten. Aber ich fürchte das ich mir dann viel Arbeit mache und am Ende bleibt die AD ja die gleiche.
Moin,
Configure Exchange Server for split permissions
Gruß,
Dani
Meine Hoffnung basiert darauf das der neue Exchange durch das Setup Rechtetechnisch wieder "normal" in der AD integriert ist.
das wird nicht passieren. Du kannst aber Active Directory split permissions jederzeit wieder deaktivieren:Configure Exchange Server for split permissions
Gruß,
Dani
Zitat von @Dani:
Configure Exchange Server for split permissions
Das habe ich auch schon überlegt, meinst du ich sollte das mit einem erneuten Setup-Lauf von Exchange 2013 auch exchangealt machen bevor ich Exchange 2019 installiere oder sollte das auch mit dem 2019 Setup gezielt möglich sein?Meine Hoffnung basiert darauf das der neue Exchange durch das Setup Rechtetechnisch wieder "normal" in der AD integriert ist.
das wird nicht passieren. Du kannst aber Active Directory split permissions jederzeit wieder deaktivieren:Configure Exchange Server for split permissions
Einen anderen Lösungsansatz gibt es auch noch bei uns:
Der Domain\Administrator ist lokal am exchangeneu sowie exchangealt angemeldet und hat auch das Exchange Setup ausgeführt. Aufgrund der Teststellung hatte der Anfangs keinen gültigen Profilpfad (der Pfad war in der Testumgebung ungültig). Als das Setup dann gelaufen ist hatten wir das aber auf eine andere Freigabe umgebogen. Nur da es unter C:\Users\administrator.DOMAIN\AppData\Roaming\Microsoft nicht die erwarten Unterordner gibt kann das auch daran liegen.
Wir werden diese Woche noch die Testumgebung aus der Datensicherung komplett neu klonen und die beiden Ansätze testen.
Die IPv4 eines Exchange sollte sich problemlos ändern lassen oder? Wir machen das ganze Spiel im Moment über zwei Subnetze, ich überlege den exchangeneu erst im alten Subnetz aufzusetzen und dann zu verschieben. DNS passe ich natürlich an.
Moin,
mir ist immer noch nicht klar, was du mit dem Test Setup vor hast. Möchtest du
Gruß,
Dani
mir ist immer noch nicht klar, was du mit dem Test Setup vor hast. Möchtest du
- nur das Upgrade auf Exchange Server 2019 testen
- das Active Directory split permissions und dann auf Exchange Server 2019 aktualisieren?
Das habe ich auch schon überlegt, meinst du ich sollte das mit einem erneuten Setup-Lauf von Exchange 2013 auch exchangealt machen bevor ich Exchange 2019 installiere oder sollte das auch mit dem 2019 Setup gezielt möglich sein?
Kann ich inhaltlich nicht bewerten. Ich würde zuerst Active Directory split permissions zurück bauen, Zeit verstreichen lassen, ob alles funktioniert. Wenn dem so ist, das Upgrade auf Exchange Server 2019 durchführen.Der Domain\Administrator ist lokal am exchangeneu sowie exchangealt angemeldet
Warum ändert ihr überhaupt im Lab den Namen? Ist für mich nicht nachvollziehbar. Das macht es doch nur komplizierter.Die IPv4 eines Exchange sollte sich problemlos ändern lassen oder?
Bestimmt. Unsere Exchange Kollegen setzen bis dato den Exchange Server neu auf. Wir machen das ganze Spiel im Moment über zwei Subnetze, ich überlege den exchangeneu erst im alten Subnetz aufzusetzen und dann zu verschieben. DNS passe ich natürlich an.
Auch hier kann ich nicht beurteilen, warum es zwei Subnetze sind was euere Gedanken dazu sind. Heutzutage beschäftigt man sich ja auch im LAN mit Mikrosegmentierung.Gruß,
Dani
Zitat von @Dani:
mir ist immer noch nicht klar, was du mit dem Test Setup vor hast. Möchtest du
Das Upgrade und die Migration der Postfächer testen und im Anschluss das Verhalten von Outlook 2013 mit Exchange 2019. Outlook soll erst ersetzt werden wenn dann die Terminal Server gewechselt werden, daher will ich sicher gehen das Outlook 2013 noch ein paar Wochen benutzbar ist.mir ist immer noch nicht klar, was du mit dem Test Setup vor hast. Möchtest du
- nur das Upgrade auf Exchange Server 2019 testen
* das Active Directory split permissions und dann auf Exchange Server 2019 aktualisieren?
Split Permissions soll sowieso komplett raus.Der Domain\Administrator ist lokal am exchangeneu sowie exchangealt angemeldet
Warum ändert ihr überhaupt im Lab den Namen? Ist für mich nicht nachvollziehbar. Das macht es doch nur komplizierter.Die IPv4 eines Exchange sollte sich problemlos ändern lassen oder?
Bestimmt. Unsere Exchange Kollegen setzen bis dato den Exchange Server neu auf. Wir machen das ganze Spiel im Moment über zwei Subnetze, ich überlege den exchangeneu erst im alten Subnetz aufzusetzen und dann zu verschieben. DNS passe ich natürlich an.
Auch hier kann ich nicht beurteilen, warum es zwei Subnetze sind was euere Gedanken dazu sind. Heutzutage beschäftigt man sich ja auch im LAN mit Mikrosegmentierung.Ich sehe dabei eigentlich das geringste Problem, die Firewall lässt für den Übergang alles zwischen den beiden Exchange Servern durch, ebenso Kommunikation mit dem DC. Client Kommunikation will ich auch testen.
Es geht jetzt übrigens mit einem anderen Benutzer der Domain-Admin ist und im Exchange entsprechend die Organization Management inne hat. Meldet sich dieser Benutzer lokal unter Windows am exchangeneu an und startet die Management Shell dann laden alle Module.
Ich tendiere zu Rechteproblem, das mit dem Profil kann ich noch nicht vollständig ausschließen. Aber wir machen den Test nochmal neu und deaktivieren zuerst Split Permissions.
Ich tendiere zu Rechteproblem, das mit dem Profil kann ich noch nicht vollständig ausschließen. Aber wir machen den Test nochmal neu und deaktivieren zuerst Split Permissions.
Da ich etwas Urlaub hatte hier etwas verspätet mein Eintrag.
Wir haben die Teststellung neu gemacht. Dann AD Split Permissions auf dem Exchange 2013 (exchangealt) rückgängig gemacht und dann exchangeneu aufgesetzt. (Nebenbei haben wir natürlich auch das Problem mit den Profilpfaden umgangen aber ich denke nicht, das dass eine Auswirkung gehabt hat.) Jetzt tritt das Problem mit der Management Shell nicht mehr auf, ich würde sagen das war die Lösung dieses Problems...
Danke für den Austausch. Auch wenn natürlich keiner Eingangs die Ursache kennen konnte hilft es auch wenn nicht sofort auf einen bekannten Fehler verwiesen wird und man dann seine Altlasten löst.
Wir haben die Teststellung neu gemacht. Dann AD Split Permissions auf dem Exchange 2013 (exchangealt) rückgängig gemacht und dann exchangeneu aufgesetzt. (Nebenbei haben wir natürlich auch das Problem mit den Profilpfaden umgangen aber ich denke nicht, das dass eine Auswirkung gehabt hat.) Jetzt tritt das Problem mit der Management Shell nicht mehr auf, ich würde sagen das war die Lösung dieses Problems...
Danke für den Austausch. Auch wenn natürlich keiner Eingangs die Ursache kennen konnte hilft es auch wenn nicht sofort auf einen bekannten Fehler verwiesen wird und man dann seine Altlasten löst.
