testperson

Wie lange hast du denn gewartet? Das muss sich ja auch erstmal replizieren. Exchange cached ja auch hier und da einiges etwas länger. Problem solved. Ich würde die Exchange Installation immer mit auf die System Disk legen. Da es in der PowerShell ohne Probleme funktioniert, gehe ich nicht von Performance Problemen im Bereich Disk / RAM / CPU auf dem Exchange aus.

Moin, evtl. einen Case bei Microsoft aufmachen? Gruß Jan

Das klingt ja glatt so, als sollte da minimales Budget sein, um den Mangel an Hauptspeicher zu beseitigen. Wie viel RAM ist denn vorhanden? Ein Domain Controller, Windows 10 und Router/Firewall VM sollte man in einer Testplattform doch schon mit 8 GB RAM zum Laufen bekommen.

Was hast du denn da überhaupt vor? Ist das ein Lab / eine Spielwiese? Oder soll das tatsächlich produktiv laufen? Falls Lab: Was möchtest du dir ansehen / lernen?

Hi, das klingt nach einer Spielwiese / einer Lab-Umgebung. Da wäre mein Rat: Vorne anfangen und diesmal von Anfang an richtig beginnen. Der Hyper-V Host ist ausschließlich Hyper-V Host. Dort wird nichts weiter installiert neben der Hyper-V Rolle. Ggfs. ein Monitoring Agent, Backup Software (Agent) und evtl. noch ein AV Client. DNS und DHCP gehören dann in eine gesonderte VM auf dem Host oder auf eine/n Hardware Router / Firewall. Remotedesktopdienste gehören dann in weitere VMs auf dem Host. (Im Lab dann ggfs. auch alle RDS Rollen auf eine VM.) Die Win 10 VM ist dann weiterhin eine eigen VM auf dem Host. Das wichtigste: Der Hyper-V Host stellt nur die Hyper-V Rolle bereit. Gruß Jan

Hi, hast du einen Windows Server 2016 mit aktivierter Hyper-V Rolle und Probleme mit einem virtualisierten Windows 10? Oder hast du Probleme mit einem virtualisiertem Windows Server 2016 unter einem Windows 10 mit aktiviertem Hyper-V? Wo sind DNS, DHCP, Routing und RAS sowie die Remotedesktopdienste installiert? Gruß Jan

Hi, hast du noch weitere Beispiele, wo es lange/länger dauert? Gibt es Auffälligkeiten in der Ereignisanzeige? Sind alle Domain Controller erreichbar? Gibt es evtl. DC Leichen? Passen die AD Sites und Services? Namensauflösung ist in Ordnung? Wenn du die Stellvertretung / andere langsame Dinge in der PowerShell machst, ist es ebenfalls langsam? Die meisten Exchange PowerShell Befehle kennen den Parameter "-DomainController". Damit könntest du mal prüfen, ob es aus/in Richtung AD klemmt. Gruß Jan

Hi, schau mal hier: https://www.mcseboard.de/topic/221573-microsoft-365-anmeldung-powershell/?do=findComment&comment=1433223 HTH Jan

Hi, ich würde an dieser Stelle nicht viel Zeit in die Suche nach einer Lösung stecken sondern den Windows Server 2008 ASAP in Rente schicken und die Update Services auf einem neuen Server mit supportetem OS in Betrieb nehmen. Gruß Jan

Die einzige nicht nach zugreifenden Endgeräten lizenzierte Option wären - die scheinbar nicht gewünschten - Office Produkte aus den M365 Plänen, die Apps for Business (mit Shared Activation Right) oder Apps for Enterprise beinhalten. (So gesehen wäre auch noch das SPLA Programm mit einer userbezogenen Lizenzierung von Office möglich.)

Zur Sicherheit: Du hast das per GPO gemacht und auch eine Office Version, welche die Policies anwendet / anwenden kann? Oder hast du es am Client direkt in HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover geschrieben?

Hi das klingt nach "ExcludeExplicitO365Endpoint": Unexpected Autodiscover behavior if settings under the \Autodiscover key - Outlook | Microsoft Docs Je nach eingesetztem Office kannst du das per GPO (GPS: Disable AutoDiscover (gpsearch.azurewebsites.net)) lösen oder es muss "so" in den User-Zweig der Registry rein. Gruß Jan

Hi, Office 2019 und Office (2021) LTSC. Siehe auch: RE2OqRI (microsoft.com) Beachten sollte man ggfs. das Support Ende von 2025 für Office 2019 bzw. 2026 für Office LTSC auf Server 2019 und 2022. Gruß Jan

Hi, um die Aussagen - insbesondere die von @mwiederkehr - zu untermauern: Schau dir mal das Extended Support Date vom SQL 2012 an (sofern du kein ESU erworben hat). Damit ist am 12.07.2022 Schluss. In meinen Augen wäre das ein weiterer, triftiger Grund neue Server aufzusetzen und die Applikation(en) (sauber) zu migrieren. Gruß Jan

Hi, warum nicht das ExchangeonlineManagement Modul nehmen? Install-Module ExchangeOnlineManagement Import-Module ExchangeOnlineManagement Connect-ExchangeOnline ... Disconnect-ExchangeOnline Gruß Jan

Hi, um wie viele User bzw. Postfächer geht es denn hier? Evtl. wäre es hier deutlich schneller und einfacher den Weg über einen PST Ex- und Import zu gehen. Ist nicht der schönste Weg, dürfte aber vom benötigten Know-How deutlich einfacher sein. Gruß Jan

Hi, das einfachste dürfte sein - sofern die (unbekannte) Anwendung das unterstützt - dir Zertifikate von einer öffentlichen CA zu besorgen und Split DNS einzurichten. Gruß Jan

Hi, hier wäre der Code bzw. die "Send-MailMessage" Zeile interessant. Ich vermute, du landest (per Default) auf Port 25 und nicht auf dem Client SMTP Port 587. Gruß Jan

OT: 25 Jahre MP3-Player WinAmp: Der Lama-Hintern kriegt Haue | heise online

Hi, noch ein Schuss ins Blaue: Ist auf den Hyper-V Hosts (oder ggfs. dem Storage) eine 3rd Party Antivirus oder Security Software installiert? Falls ja, sind dort alle benötigten Ausnahmen für Hyper-V / Failover Cluster gesetzt? Hast du mal versucht die Dateien an einen anderen Ort zu kopieren, ob die wirklich "lesbar" sind? Das Storage (welches?) untendrunter hat auch keine Probleme? Je nachdem wo du das höchste Supportlevel hast / überall (Server Hersteller, Storage Hersteller, Microsoft), einen Case aufmachen? Gruß Jan

Ich bin bei sowas immer gutgläubig und gehe davon aus, dass die dort liegenden Dateien automatisch generiert werden. Wenn da jemand händisch rumfriemelt, kann er die Datei auch gleich selber per Mail versenden.

Hi, in diesem Fall solltest du gar nicht erst mit VBS starten und stattdessen mit PowerShell loslegen. Da wäre dein gesuchter Part: Get-ChildItem -Path "C:\Protokolle\Statistik" ` -Filter "*.txt" | Sort-Object LastWriteTime | Select-Object -Last 1 Gruß Jan

Das wurde scheinbar leicht missverständlich ausgedrückt. Wobei ich gestern in der Tabelle bzw. im Blog auch genau das gelesen habe.. Dem fehlenden Exchange 2016 CU23 Support für 2022er DCs haben wir dann wohl die neue, kostenlose Exchange 2019 Hybrid Lizenz zu verdanken. (Released: 2022 H1 Cumulative Updates for Exchange Server - Microsoft Tech Community)

An dieser Stelle habe ich eigentlich immer "deutlich sicherere" Umgebungen gesehen, wo sich "nur" um eine Domain gekümmert wurde und die Hosts bzw. das Cluster in der gleichen Domäne waren. In den anderen Fällen waren es i.d.R. zwei "Weiter-Weiter-Fertig-stellen-Domänen" mit teils den gleichen privilegierten Accounts und Passwörtern. In der Theorie braucht es für ein (Hyper-V) Cluster keine Domäne mehr. Habe ich aber in der Praxis noch nicht gesehen. Och, da gab es auch interessante Dinge, die per SSH im ESX installiert wurden. Generell würde ich auch den standalone Hyper-V Host in die Domäne aufnehmen.

Ich war so forsch und habe das Textfile mit dem Code überflogen: ... [string]$EWSURL = "https://outlook.office365.com/EWS/Exchange.asmx" ... Evtl. ist auch Power Automate noch ein alternativer Ansatz für das (noch) unbekannte Problem. ;)