MHeiss2003

Die Zeitachse zwischen kurz- und langfristig in diesem Projekt sind nur mehrere Stunden!

Guten Morgen Jan, danke für Dein aufmerksames Code-Auge! Es sind insgesamt 10 Gigabyte an Daten vorhanden. Diese sollen per "Drag-and-Drop" migriert werden, wenn die Öffentlichen Ordner auch in der Cloud liegen, wie es bereits bei allen Postfächern ist. Wir werden von den PFs kurzfristig weggehen. Grüße Mario

Guten Abend, gemäß der Anleitung von MS zur Migration von Öffentlichen Ordnern Migrieren von öffentlichen Exchange Server-Ordnern zu Exchange Online mithilfe einer Batchmigration, bin ich bei Schritt 4 angelangt und erhalte in der Powershell Online einen Fehler nach folgenden Eingaben: $mappings = Import-Csv map.csv $primaryMailboxName = ($mappings | Where-Object FolderPath -eq "\" ).TargetMailbox; New-Mailbox -HoldForMigration:$true -PublicFolder -IsExcludedFromServingHierarchy:$false $primaryMailboxName ($mappings | Where-Object TargetMailbox -ne $primaryMailboxName).TargetMailbox | Sort-Object -unique | ForEach-Object { New-Mailbox -PublicFolder -IsExcludedFromServingHierarchy:$false $_ } Der Fehler sieht so aus: New-Mailbox: A positional parameter cannot be found that accepts argument 'Mailbox2'. In der map.csv sieht es wie folgt aus: "TargetMailbox","FolderPath" "Mailbox1","\" "Mailbox2","\NON_IPM_SUBTREE" Hängt das eventuell mit dem Subordner NON_IPM_SUBTREE zusammen? Habt Ihr eine Idee, was ich übersehe? Danke und Grüße Mario

Ich habe keine Custom Connectoren im Einsatz, ist alles Standard Einrichtung Exchange. Die entscheidende Frage wird sein, auf wann ich zurückgehen muss, wenn es ein Security Thema ist. Irgendwie werde ich den Verdacht nicht los, dass es hier einen Zusammenhang zu dem heutigen weltweiten IT Problem gibt.

Nein. Ja, EdgeTransport.

Und zwar so was von... Alles drauf was das MS Herz begehrt.

1. MSExchangeTransport, 1018, SmtpReceive: The address is already in use. Binding: 0.0.0.0:2525. 2. MSExchangeTransport, 1019, SmtpReceive: Failed to start listening (Error: 10048). Binding: 0.0.0.0:2525. 3. MSExchangeTransport, 1036, SmtpReceive: Inbound direct trust authentication failed for certificate %1. The source IP address of the server that tried to authenticate to Microsoft Exchange is [%2]. Make sure EdgeSync is running properly 4. MSExchangeTransport, 26015, TransportService: EdgeTransport requested that the MSExchangeTransport process terminate with an unhandled exception due to TCP/IP-Socketfehler. Der Dienst wird beendet.. Call stack: bei System.Environment.GetStackTrace(Exception e, Boolean needFileInfo) bei System.Environment.get_StackTrace() bei Microsoft.Exchange.Transport.Main.Program.StopService(String reason, Boolean canRetry, Boolean retryAlways, Boolean failServiceWithException) bei Microsoft.Exchange.Transport.Components.StopService(String reason, Boolean canRetry, Boolean retryAlways, Boolean failServiceWithException) bei Microsoft.Exchange.Protocols.Smtp.Receive.SmtpInComponent.OnTcpListenerFailure(Boolean addressAlreadyInUseFailure) bei Microsoft.Exchange.ProcessManager.TcpListener.StartListening(Boolean invokeDelegateOnFailure) bei Microsoft.Exchange.Protocols.Smtp.Receive.Legacy.SmtpInServer.Initialize(HandleFailure failureDelegate, HandleConnection connectionHandler) bei Microsoft.Exchange.Protocols.Smtp.Receive.SmtpInComponent.Start(Boolean initiallyPaused, ServiceState targetRunningState) bei Microsoft.Exchange.Transport.Common.CompositeTransportComponent.Start(Boolean initiallyPaused, ServiceState targetRunningState) bei Microsoft.Exchange.Transport.Common.CompositeTransportComponent.Start(Boolean initiallyPaused, ServiceState targetRunningState) bei Microsoft.Exchange.Transport.Components.Activate() 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.Transport.Components.ProtectedActivate() bei Microsoft.Exchange.Transport.Components.Start(StopServiceHandler stopServiceHandler, Boolean passiveRole, Boolean serviceControlled, Boolean selfListening, Boolean paused) bei Microsoft.Exchange.Transport.Main.Program.Run(String[] args) bei Microsoft.Exchange.Transport.Main.Program.Main(String[] args)

Ja, hatte ich auch schon vor dem Post hier gemacht. Alles grün, bis auf den Transportdienst, der eben nicht gestartet war. Habe gerade nochmals das aktuelle Skript laufen lassen, alles grün!

Ich glaube, das verheißt nichts Gutes aus dem Eventlog, seit gestern Abend 20:00 Uhr, da fing es an. Request URL: https://OEFFENTLICHEIPVOMKUNDEN:443/ecp/what.js Request path: /ecp/what.js User host address: 194.165.17.21 User: Is authenticated: False Authentication Type:

Hier steht: ::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255 Es gibt keine Bindung zu Port 2525, wobei ich den IIS Workerprozess vorher beendet habe, damit ich den Transportdienst wieder starten konnte.

SMTP Dienst läuft nicht. Wie kann ich das im IIS prüfen?

Es steht alles auf dynamisch, IPv6 und DNS, IPv4 und DNS ist statisch.

Guten Morgen zusammen, ich habe einen Exchange 2016, bei dem der Transportservice nicht mehr startet, auch nach mehreren Neustarts des Servers nicht. Nun habe ich folgenden Artikel herangezogen: Microsoft Transport Service stoppt Nur ist laut Fehlerlog der Port nicht 25, der das starten verhindert, sondern 2525. Jetzt habe ich mich über netstat -ano | findstr :2525 auf die Suche gemacht, welche Prozesse den Port nutzen. Was ich gefunden habe, lässt mich stauen, es wird ein Prozess erkannt, der die Datei w3wp.exe nutzt. Dies stammt wohl aus dem Umfeld des IIS. Normalerweise sollten auf den Port 2525 beim Exchange hören: EdgeTransport.exe, MSExchangeFrontEndTransportexe. Nun meine Frage an Euch. Wie kann ich herausfinden, was genau hier auf den Port 2525 hört und vor allem, wie kann ich es entfernen? Danke und Grüße Mario

Danke.

Der Exchange Server wurde auf dem Server auf eine separate virtuelle HDD mit dem Laufwerkbuchstaben D:\ installiert. Wenn ich das Skript vom Laufwerk C:\ aus laufen lasse, funktioniert es. Es scheint wohl mit den Berechtigungen zu tun zu haben. Diese VM wurde von VMware auf HyperV umgezogen, indem die HDDs konvertiert wurden. Wahrscheinlich hängt es damit zusammen. Habt Ihr eine Idee, was ich prüfen kann?

Hab jetzt mal das Benutzerprofil vom Server gelöscht und mich neu angemeldet. Weder der Benutzer, mit dem ich gelöscht habe, noch der gelöschte und dann neu angelegte Benutzer bringen die Lösung. Interessant ist, dass der neu angelegt Benutzer diesen Fehler beim ersten Aufruf des Skripts bekommt: Fehler beim Lesen oder Schreiben der Verlaufsdatei "C:\Users\BENUTZER\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt": Der Prozess kann nicht auf die Datei "C:\Users\adminst\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt" zugreifen, da sie von einem anderen Prozess verwendet wird. Ja ganz sicher. Wenn ich die Datei ConsoleHost_history.txt und auch alle anderen Dateien aus dem Ordner, in dem healthchecker.ps1 liegt, startet das Skript und ich erhalte diesen Fehler: Exchange Health Checker version 24.06.24.2018 Failed to Health Checker against SV-EXCHANGE Es wird nur die ConsoleHost_history.txt neu angelegt, ansonsten keine weiteren TXT Dateien im Ordner der Skriptdatei.

Ja, Rechtsklick als Administrator habe ich gemacht.

Hallo zusammen, ich habe hier einen Exchange 2019 Server auf Windows Server 2019 aktuell gepatched. Leider funktioniert das healthchecker.ps1 Skript nicht mehr. Getestet habe ich die Version aus dem April und die aktuelle. Folgende Fehler finden sich im Debug Log: 1. Ausnahme beim Aufrufen von "FindOne" mit 0 Argument(en): "Ein solches Objekt ist auf dem Server nicht vorhanden. 2. Error Origin Info: EXSERVER.DOMAIN Get-DynamicDistributionGroup : Der Vorgang konnte nicht ausgeführt werden, weil das Objekt 'PublicFolderMailboxes*' nicht auf 'DOMAINCONTROLLER.DOMAIN' gefunden wurde. 3. Out-File : Der Prozess kann nicht auf die Datei "D:\HealthChecker-Debug_20240713150934.txt" zugreifen, da sie von einem anderen Prozess verwendet wird. 4. Get-NetRoute : Durch "CIM-Abfrage für Instanzen der Klasse "ROOT/StandardCimv2/MSFT_NetRoute" auf dem CIM-Server "": SELECT * FROM MSFT_NetRoute WHERE ((DestinationPrefix LIKE '::/0')) AND ((InterfaceAlias LIKE 'Ethernet'))" wurden keine übereinstimmenden MSFT_NetRoute-Objekte gefunden. Überprüfen Sie die Abfrageparameter, und wiederholen Sie den Vorgang. 5. Invoke-CimMethod : Ungültiger Namespace 6. Get-ItemProperty : Der Pfad "HKLM:\Software\Microsoft\Updates\UpdateExeVolatile\" kann nicht gefunden werden, da er nicht vorhanden ist. 7. Out-File : Der Prozess kann nicht auf die Datei "D:\HealthChecker-Debug_20240713150934.txt" zugreifen, da sie von einem anderen Prozess verwendet wird. Der letzte Fehler wiederholt sich noch 4 mal. Ein Get-Serverhealth zeigt unhealthy bei folgenden Namen an: 1. NotApplicable HealthManagerWorkItemQuarantaineMonitor Monitoring 2. NotApplicable NetworkAdapterRssMonitor Network 3. NotApplicable RestDeepTestMonitor MSExchangeRestApp... Rest.Protocol Virencheck habe ich gemacht, der Server scheint sauber zu sein, es laufen auch keine auffälligen Dienste. Bisher hat der Server auch keine Einschränkungen in der Verwendung. Wo sollte ich Eurer Meinung nach ansetzen, um das healthchecker.ps1 Skript wieder zum laufen zu bekommen? Grüße Mario

Hallo, ich habe diese Meldung jeweils mit Fehler 0xC0000035 nicht nur für die Sitzung "RemoteCommandExecutionLog", sondern noch für weitere Sitzungen: "FastDocTracingSession" und "QueryRequestLog". Hast Du mal versucht healthchecker.ps1 auf Deinem Exchange laufen zu lassen? Dies hatte ich versucht, allerdings erhalte ich hier mehrere Fehler. Hierzu mache ich noch einen separates Thema auf. Grüße Mario

Was bitte schön ist Cloud?! Was bitte bedeutet SE? Es steht noch kein Szenario fest, sehr wahrscheinlich aber ein Upgrade onPrem. Ist ja noch Zeit bis 14.10.2025!

Ich habe gerade mal zwei weitere Exchange 2016 geprüft, bei denen steht "Bypass". Auf zwei Exchange 2019, die ich mir ebenfalls angesehen habe, steht "RemoteSigned". Beides funktioniert, RemoteSigned habe ich gesetzt.

Guten Morgen Evgenij, vielen Dank für Deine Anmerkung. Das Ergebnis ist eindeutig: LocalMachine = AllSigned LocalMachine sollte auf Bypass stehen, richtig? Zwei Kommandos und einen Neustart der Verwaltungsshell später, siehe da, die Shell verarbeitet wieder die Exchange Befehle. Vielen Dank. Hier noch die Lösung, die ich in einer administrativen Verwaltungsshell Sitzung ausgeführt habe. Die zweite Zeile prüft, ob die Änderung geschrieben wurde. Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope LocalMachine Get-ExecutionPolicy -List

Vielen Dank für die Tipps Norbert. Remote von einem anderen Server funktioniert die Verwaltungsshell fehlerfrei. Einen anderen Benutzer habe ich noch nicht getestet. Meinst Du, dass das Löschen des Benutzerprofils eine Option sein könnte? Nun habe ich die Anmeldung eines zweiten Benutzers durchgeführt. der noch die am Server angemeldet war und die gleichen Rechte hat,, wie der betroffene Benutzer. Hier erhalte ich beim ersten Start der Verwaltungsshell folgende Frage zu den Skripten "RemoteExchange.ps1", "CommonConnectFunctions.ps1", "Microsoft.Forefront.Management.Powershell.types.ps1xml": "Möchten Sie die Software dieses nicht vertrauenswürdigen Herausgebers ausführen?" Selbst wenn ich alle drei mit [A] Immer ausführen beantworte, erhalte ich keinen Zugriff auf Exchange Verwaltungsshell Befehle.

Guten Abend zusammen, ich habe einen Software seitig aktuellen Exchange Server 2016, bei dem die Exchange-Verwaltungsshell zwar startet, aber keine Befehle mehr vorhanden sind. Im Internet habe ich Berechtigungsprobleme als Ursache finden können oder aber ein Verzeichnisproblem unter %appdata%\Microsoft\Exchange\RemotePowershell\SERVERNAME.DOMAINNAME. Das Verzeichnis hatte ich einmal gelöscht. Nach einem Neustart der Verwaltungsshell wird dieses zwar erstellt, aber es fehlen die drei Dateien, die darin liegen sollten. Die Ereignisanzeige gibt nicht viel her. Ein Get-HealthReport läuft leider nicht und der Start des Skriptes HealthChecker.ps1 führt zur folgenden Ausgabe: WARNUNG: "Export-Module" für die aktuelle Sitzung kann nicht mithilfe von "Import-PSSession" generiert werden. AUSFÜHRLICH: Verbunden mit SERVER.DOMAIN. WARNUNG: Something went wrong while loading the Exchange Management Shell WARNUNG: Failed to load Exchange Shell... stopping script Habt Ihr eine Idee, wie eine Lösung aussehen könnte, dass ich die Befehle in der Exchange Verwaltungsshell wieder nutzen kann? Grüße Mario

Wir pflegen dieses Feld mit bis zu 5 Stellen, jeweils die ersten beiden Buchstaben des Vor- und Nachnames in Großbuchstaben. Vielen Dank an dieser Stelle für Eure Anregungen!