MHeiss2003

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!

Schönen guten Abend, meine Frage ist, wie würdet Ihr eine eigene Benutzer- oder Systemvariable in Windows mit dem Wert aus dem AD Benutzerobjekt im Feld "Initials" bestücken? Den Code zum Auslesen mit Powershell habe ich bereits, dieser lautet Get-ADUser "%username%" -Properties Initials Ziel ist es, bei der Anmeldung einem Benutzer einen bestimmten Ordner zuzuordnen, der sich mit dem Wert eben aus dem oben genannten Feld finden lässt. Danke Mario

Danke für Eure Informationen. Die Lösung war, das betroffene Postfach zu deaktivieren. Nach einer Wartezeit von 30 Minuten und der danach erfolgten Verbindung des Postfaches mit dem Benutzer, war das Archiv nicht mehr aktiv.

Die Datenträger sind sehr schnell, deshalb war das OK. Das Postfach wurde bereits bereinigt, mehr geht nicht. Bei der Business Lizenz sind 50GB onboarding als Limit möglich.

Sowohl als auch, ja! onPrem gibt es keine Moverequests. Das Archivpostfach hatte knapp 90 Gigabyte vor dem Versuch der Migration!

Hallo liebe community, ich habe einen Exchange 2019 onPrem und EXO im Hybrid Modus. Software ist aktuell. Bei einer Testverschiebung von onPrem nach EXO ist von 5 Postfächern eines nicht verschoben worden, da der Speicher des Archivpostfaches 69 Gigabyte groß ist. Diesen Fehler hatte ich zur Kenntnis genommen und bei den Details dieses Migrationsbatches eine Löschung desselbigen vorgenommen. Der Batch wurde dann abgeschlossen und ebenfalls nach Fertigstellung gelöscht. Nun habe ich das Archivpostfach über den onPrem als PST exportiert und wollte es im Postfach deaktivieren. Folgenden Hinweis erhalte ich, wenn ich das durchführen will: Das Postfach "NAME" hat den Verschiebungsstatus None und den Remotehostnamen "DOMAIN.onmicrosoft.com". Solange das Postfach verschoben wird, kann das Archiv nicht aktiviert/deaktiviert werden. Diese Hilfestellung hilft nicht weiter, da es keine Verschiebeanforderung gibt: Link zu Microsoft Learning Nun meine Frage an Euch: Wie kann ich den Verschiebungsstatus noch prüfen? Danke und Grüße Mario

Der Hinweis ist gut. In der XML Datei finde ich keinen Eintrag zu PublicFolderInformation. Das bedeutet dann, das dies ausgeschaltet sein muss, richtig? Danke für Deinen Hinweis in Bezug auf Autodiscover. Die Ursache war der fehlende Eintrag. Durch den Befehl Get-CASMailbox MAILBOXNAME | Format-List konnte ich feststellen, dass die Option PublicFolderClientAccess auf "$false" stand. Durch den Befehl Set-CASMailbox MAILBOXNAME -PublicFolderClientAccess $true habe ich die Anzeige wieder herstellen können.

Danke Evgenij für Deine Antwort. Der Test ergibt, dass der korrekte Autodiscover Server zurückgegeben wird. Sowohl extern wie intern der korrekte DNS-Name, der Richtung onPrem zeigt.

Hallo zusammen, das Hybrid Szenario besteht aus einem Exchange 2019 Server und einer "modernen" Hybrid Konfiguration. Die PublicFolders sind noch nicht migriert und eben auch noch nicht alle Benutzer. Die Konfiguration der PublicFolders habe ich nach diesem Microsoft Artikel vorgenommen: https://learn.microsoft.com/de-de/exchange/hybrid-deployment/set-up-modern-hybrid-public-folders Nun ist es leider so, dass manche Benutzer onPrem die PublicFolders onPrem nicht mehr sehen können. Migriere ich diese nach EXO, dann können Sie wieder zugreifen. Kontrolliert habe ich die Benutzer dahingehend, dass ich die Werte DefaultPublicFolderMailbox, EffectivePublicFolderMailbox, bei einem funktionierenden Benutzer ausgegeben habe. Die Ausgabe ist identisch mit den Werten eines Nutzers, der Zugriff auf die öffentlichen Ordner hat. Habt Ihr noch einen Tipp, wo der Fehler eventuell liegen könnte? Danke und Grüße Mario

Guten Abend Jan, danke für Deinen Gedankenanstoß. Bei VMware bin ich kompletter Laie! Bei der IP-Adresse handelt es sich tatsächlich um den Host. Der VMware Server ist gar nicht installiert in diesem Netzwerk. Mir war der Unterschied zwischen VMware Host und Server nicht bewusst. Meine Aufgabe ist es, von diesem Host vier virtuelle Maschinen nach Hyper-V 2022 zu konvertieren und den Host danach, auch wegen EOL VMware (danke für den Hinweis), abzuschalten. Würdest Du das über den SCVMM machen oder einen anderen Weg wählen? Gruß Mario

Schönen guten Abend liebe Mitstreiter, vielleicht hat jemand eine Idee. Über die einschlägigen Suchmaschinen habe ich nichts gefunden und in der Techcommunity von Microsoft bin ich auch nicht fündig geworden. Auf dem Blech ist VMware ESXI Version 6.5 Update 3 (Build 16576891) installiert. Es erscheint nach dem Hinzufügen im Verlauf immer folgender Fehler im SCVMM: "IP-Adresse" kann von Virtual Machine Manager nicht als Virtualisierungs-Manager hinzufügt werden, da "IP-Adresse" keine vCenter API ausführt. Empfohlene Aktion Verwenden Sie einen Server, auf dem die vCenter-API ausgeführt wird. Wie kann ich prüfen, ob die vCenter-Api vorhanden ist und ausgeführt wird? Danke und Grüße Mario

Ja liegt es. Danke, dann muss ich mir die E-Mail nochmals genauer ansehen. Eventuell ist doch am Empfänger oder Absender aus Outlook heraus irgendwie noch etwas veraltetes im Cache.

Benutzer von DomainB sendet über EX2019 onPrem an externen Empfänger.

Guten Abend liebe IT-Gemeinde, welchen Weg schlagt Ihr ein, wenn Ihr es ermöglichen wollt, vom EX2019 onPrem über die DomainB versandte E-Mails an einen Relayconnector auf eben diesem zu übergeben, wenn gleich der Connector von M365 E-Mails zu EXO installiert ist und brav die E-Mails transportiert? Aktuell ist es so, dass wenn ich E-Mails über die DomainB versende, ein NDR von EXO mit 554 5.4.0 zurückkommt. Die DomainB ist in EXO nicht eingerichtet, auf dem EX2019 allerdings Autoritativ. Danke und Grüße Mario

Hallo, ich habe einen Windows Server 2016 mit IIS und Webdav. Die Einrichtung habe ich gemäß der Anleitung bei Microsoft vorgenommen: https://learn.microsoft.com/de-de/iis/install/installing-publishing-technologies/installing-and-configuring-webdav-on-iis Nun zu meinem Problem: Die Nutzung des virtuellen Verzeichnisses, dessen physikalischer Pfad einen UNC Pfad auf die Freigabe eines Domänen Mitgliedservers enthält, ist nur solange möglich, bis ich die Pfadanmeldinformationen von "Bestimmter Benutzer" auf "Anwendungsbenutzer (Pass-Through-Authentifizierung)" ändere. Danach erhalte ich beim Zugriff über den Windows Client die Meldung: "Der eingegebene Ordner ist ungültig. Wählen Sie einen anderen Ordner". Ergänzt habe ich die Freigabe- und Sicherheitsberechtigungen des Shares auf dem Mitgliedsserver um den Eintrag SERVERNAME$ mit den Rechten Lesen, Ausführen, Ordnerinhalte anzeigen und Lesen. Der DefaultAppPool auf dem IIS läuft mit der Identität "LocalSystem". Sobald ich einen lokalen Pfad nutze, funktioniert der Zugriff auch mit "Anwendungsbenutzer (Pass-Through-Authentifizierung)". Habt Ihr eine Idee, was ich übersehe? Danke Mario

Hallo zusammen, folgende Meldung erhalte ich, wenn ich die Anmeldung aus einem der Office 365 Programme starte: Zurzeit kann keine Verbindung hergestellt werden. Überprüfen Sie bitte das Netzwerk, und versuchen es später erneut. Der Fehler tritt an zwei Servern auf. Den Support Assistenten habe ich laufen lassen, dieser findet keine Probleme. Die Firewall ausgeschaltet, den Content-Filter überprüft. Fehlerbehebung laut Microsoft durchgearbeitet. Alle Lösungen haben bisher nicht. Auch eine erneute Deinstallation und Installation inkl. dem jeweiligen Neustart, brachte keine Veränderung. Leider weiß ich nicht, wo ich noch nachsehen könnte. Habt Ihr eine Idee? Dank und Grüße Mario