ukulele-7
Goto Top

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."
unbenannt
(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?

Content-Key: 6377048561

Url: https://administrator.de/contentid/6377048561

Printed on: April 26, 2024 at 18:04 o'clock

Member: ukulele-7
ukulele-7 Mar 15, 2023 at 09:38:30 (UTC)
Goto Top
PS: Der Restore war inklusive AD und ist natürlich in einem eigenen Subnetz ohne Kontakt zur Produktivumgebung.
Member: erikro
erikro Mar 15, 2023 at 09:50:49 (UTC)
Goto Top
Moin,

steht doch in der Fehlermeldung, warum es nicht geht. face-wink

https://learn.microsoft.com/de-de/exchange/troubleshoot/administration/e ...

hth
Erik
Member: ukulele-7
ukulele-7 Mar 15, 2023 at 11:28:52 (UTC)
Goto Top
Zitat von @erikro:

steht doch in der Fehlermeldung, warum es nicht geht. face-wink

https://learn.microsoft.com/de-de/exchange/troubleshoot/administration/e ...
Der Zusammenhang erschließt sich mir noch nicht face-smile

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.
Mitglied: 6247018886
6247018886 Mar 15, 2023 updated at 11:47:54 (UTC)
Goto Top
Member: ukulele-7
ukulele-7 Mar 15, 2023 updated at 13:04:25 (UTC)
Goto Top
Ich hab jetzt Windows 2022 nochmal auf den aktuellen Stand gebracht mit ein paar Updates aber das hat nichts geändert.

Unter C:\Users\administrator.DOMAIN\AppData\Roaming\Microsoft hat keinen Unterordner Exchange.

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
Ich habe die "Remote"-Connection vom exchangeneu selbst per Powershell probiert, ich bin durch die Teststellung etwas eingeschränkt.
Mitglied: 6247018886
6247018886 Mar 15, 2023 updated at 13:52:44 (UTC)
Goto Top
Dein Exchange ist neu aufgesetzt schon kaputt??
Member: ukulele-7
ukulele-7 Mar 15, 2023 at 13:59:07 (UTC)
Goto Top
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.
Mitglied: 6247018886
6247018886 Mar 15, 2023 updated at 14:05:31 (UTC)
Goto Top
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 face-smile.
Member: Dani
Dani Mar 15, 2023 at 19:37:23 (UTC)
Goto Top
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?


Gruß,
Dani
Member: ukulele-7
ukulele-7 Mar 16, 2023 at 09:41:44 (UTC)
Goto Top
Zitat von @Dani:

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?
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.

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.
Member: Dani
Dani Mar 16, 2023 at 11:26:53 (UTC)
Goto Top
Moin,
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
Member: ukulele-7
ukulele-7 Mar 16, 2023 at 12:35:46 (UTC)
Goto Top
Zitat von @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
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?

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.
Member: Dani
Dani Mar 16, 2023 at 14:11:56 (UTC)
Goto Top
Moin,
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. face-wink

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
Member: ukulele-7
ukulele-7 Mar 16, 2023 updated at 14:31:28 (UTC)
Goto Top
Zitat von @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 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.
* 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.
exchangeneu exchangealt heißen eigentlich anders und behalten im Lab ihre Namen. Die MX Adresse ist mail.domain.de und die wechselt auf den neuen Exchange. Zertifikate bleiben auch.

Die IPv4 eines Exchange sollte sich problemlos ändern lassen oder?
Bestimmt. Unsere Exchange Kollegen setzen bis dato den Exchange Server neu auf. face-wink
o o ok das mache ich halt nicht so oft face-smile

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.
Auch hier wird alles ein bisschen anders, aus einem großen Subnetz (inkl. Server) werden mehrere kleine. Die alten Server bleiben dabei wo sie sind, die Nachfolger stehen im jeweils passenden neuen Subnetz.

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.
Member: ukulele-7
ukulele-7 Mar 16, 2023 at 15:10:50 (UTC)
Goto Top
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.
Member: ukulele-7
Solution ukulele-7 Mar 24, 2023 updated at 09:10:36 (UTC)
Goto Top
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.