MHeiss2003

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

Guten Morgen Jan, generell gebe ich Dir recht, was den Stressfaktor angeht. Nachdem ich selber als Händler, sowohl beratend als auch verkaufend, tätig bin, schockieren mich solche Praktiken. Das schadet der Branche, in der ich tätig bin, und macht auch den Wettbewerb schwieriger. Ganz zu schweigen von der Möglichkeit, sich durch die Anwendung solcher Praktiken auf Kosten anderer zu bereichern. Gruß Mario

Danke Franz für Deine Ausführungen. Es handelt sich auf jeden Fall um gebrauchte Lizenzen aus einem EA. Es liegt ein Transfer Dokument von "einem großen Händler aus dem Kreis Stormarn in Schleswig Holstein" auf den IT-Dienstleister vor. Dann existieren Rechnungen und Lieferscheine an den Endkunden von diesem Dienstleister. Weiterhin liegen geschwärzte Dokumente des Ersterwerbs vor, die dem "großen Händler" vorliegen und ausgehändigt wurden. Ein Transfer Dokument auf den Endkunden existiert nicht. Laut Aussage des "großen Händler" ist dieses Dokument nicht notwendig. Hat der Kunde Deiner Meinung nach Lizenzen oder nicht?

Das habe ich schon sehr intensiv getan! Der Kunde hat diese Lizenzen für ca. 15.000 EUR gekauft. Nun ist er natürlich verunsichert. Danke, das ist eine gute Idee.

Schönen guten Morgen, Kann mir jemand sagen, ob und wie es möglich ist, eine entsprechende Prüfung bei Microsoft zu veranlassen, wenn ich der Meinung bin, dass die Lizenzierung eines Kunden nicht auditsicher ist. Hintergrund meiner Frage ist, dass ich einen Kunden habe, der außer Rechnungen keinerlei Lizenzdokumente von Microsoft nachweisen kann. Die Dokumente, die er erhalten hat, zeigen einen Lizenznehmer, der nicht der Kunde ist, sondern ein Dienstleister. Der Dienstleister legt ein Dokument vor, das seine Beschaffung bei wiederum einem Händler für wiedervermarktete Lizenzen belegen soll. Grüße Mario Heiß

Ich danke Euch allen für Eure Meinung. Danke Norbert für den Tipp in Bezug auf die Vergangenheitsbewältigung!

Also, wenn ich CN=schema-root oder auch CN=OAB Version 4 lese...

Hallo zusammen, ich arbeite gerade diesen Artikel durch: Konfigurieren öffentlicher Exchange Server-Ordner für eine Hybridbereitstellung Das Skript Sync-ModernMailPublicFolders.ps1, wie in Schritt zwei beschrieben, habe ich laufen lassen. In der Datei "MailPublicFolderOrphans.txt" werden mir insgesamt 14 Ordner aufgelistet, die als "orphaned" ausgegeben werden. Nun frage ich mich, ob ich diese einfach löschen sollte, wie empfohlen. Es befinden sich doch einige Ordner darunter, bei denen ich mir nicht sicher bin, ob das ratsam wäre. Hier die Liste: CN=Default,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=exchangeV1,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=globalevents,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=internal,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=microsoft,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=OWAScratchPad{BFFDCA85-D484-47CC-B1B2-FBABA618B009},CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=StoreEvents{BFFDCA85-D484-47CC-B1B2-FBABA618B009},CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=schema-root,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=OAB Version 2,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=OAB Version 3a,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=OAB Version 4,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=Offlineadressbuch - \/o\=COMTOSO\/cn\=addrlists\/cn\=oabs\/cn\=Standard-Of,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=Offlineadressbuch - first administrative group,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local CN=Schedule\+ Zeitplaninformationen - first administrative group,CN=Microsoft Exchange System Objects,DC=COMTOSO,DC=local OnPremise ist installiert ein Exchange Server 2019, der bereits zwei Migrationen erfahren hatte. Die erste von Version 2010 auf 2013, die zweite von 2013 auf 2019. Danke vorab für Eure Meinungen. Grüße aus dem bewölkten Frankenland. Mario

Mit dem Tool Fiddler konnte ich herausfinden, dass beim Start von Outlook ein Server "mail.[domainname].de" kontaktiert wurde, den es aber gar nicht mehr gibt. Es kam somit zu einem Timeout. Zu allem Übel war dieser auch noch auf dem verwendeten DNS-Server eingetragen. Den Eintrag habe ich gelöscht und nun startet Outlook 2019 wieder normal. Vielleicht kann mich doch noch jemand aufklären, wie es zu diesem Aufruf kommt?