Oli1990

Moin cj_berlin, der Befehl gibt mir in der Tat das gewünschte Ergebnis. Ob das auch mit dem Script funktioniert, weiß ich nicht. Das Script ist ein vorgefertiges Produkt von VMware für den Umzug von Persistent Clones zu Instantclones um die Daten der User zu sichern. Gibt es eine Möglichkeit diesen Befehl in eine Variable zu packen? Aktuell wird im Script folgendes aufgerufen $drives = Get-Volume Wenn ich den Befehl mit Diskpart und List Volume in diese Variable packen kann würde es vielleicht gehen. Aber da sind meine Fähigkeiten was Scripte angeht schon am Ende..

Guten Morgen, ich bin mit meinem Latein am Ende und hoffe hier auf Anregungen die mir etwas auf die Sprünge helfen. Folgendes Szenario spielt sich ab: Für ein Script benötige ich den Powershell Befehl "get-volume". An meinem Rechner (WIN10 Enterprise 22H1) habe ich ein korrektes Verhalten und bekomme den gewünschten Output. Dies funktioniert auch an X weiteren Rechnern problemfrei. Dann gibt es jedoch Rechner, die zeigen mir nach der Eingabe des Befehls einfach gar nichts an. Der Befehl wird ausgeführt und anschließend erhalte ich eine leere Zeile für eine neue Eingabe. Der Versuch den Output in eine Datei umzulenken ergibt ein Dokument ohne Inhalt. An den Rechnern bei denen dieses Verhalten auftritt kann ich jedoch jeden anderen beliebigen Powershell Befehl ausführen und erhalte einen Output auf der Shell. Bei dem Problem ist es egal ob ich die Powershell normal starte oder mit Administratorrechten. Melde ich mich mit dem lokalen Administrator an dem Rechner an, funktioniert der Befehl. Ich habe bereits folgendes versucht: Benutzer isoliert um alle Benutzer GPOs auszuschließen PC isoliert um alle PC GPOs auszuschließen Beides isoliert. Eine andere Version von Powershell verwendet. Die beschriebene Umgebung ist eine VDI Umgebung, somit handelt es sich in dem beschriebenen Szenario immer um VMs. Alle Rechner sind Mitglied einer Domäne. Das Problem konnte ich nicht nur an WIN10 VMs feststellen sondern auch auf Windows Servern 2022. Irgendwelche Ideen, was ich noch testen kann, um dieses Problem loszuwerden? Liebe Grüße Oliver

Alles gut. Nehme das nicht übel. Dennoch bin ich mit dem Begriff "vergurkt" nicht einverstanden :-D Die Umgebung ist frisch aufgesetzt. Aber wie gesagt, mit sehr streng gestrickten GPOs. Restriktiv ja, vergurkt nein. Ausnahmen kann man in den GPOs natürlich umsetzten solange sie dokumentiert und begründet werden. Wenn alles läuft, wird entweder schrittweise alles zurückgebaut um zu sehen wo es hängt oder dokumentiert was verändert wurde. Der Fehler während der Installation wurde bereits auch behoben. Die Gruppe "Exchange Server" die während der Installation angelegt wird benötigte auch noch Rechte die nicht automatisch gesetzt wurden. Den Fehler findet man vermehrt auch im Netz.

Ich habe die ganzen Einstellungen dokumentiert und werde sie nach der Installation Schritt für Schritt wieder rückgängig machen. Die meisten Rechte werden ja nur für die Installation benötigt. Ganz rund lief die Installation leider dennoch nicht. Bei Schritt 6 von 12 hat er jetzt einen neuen Fehler. D.h. erstmal wieder Fehlersuche.

Hallo Nils, leider handelt es sich um eine Produktivumgebung. Die GPOs die gesetzt wurden, sind identisch wie die bei einem Kunden um vergeichen zu können. Ich habe Testweise den Exchange schon per Sysprep zurückgesetzt und ihn nach dem Domainjoin in der OU Computers gelassen, damit keine GPOs auf ihn wirken. Folgende Berechtigungen wurden auf dem DC aber schon angepasst: Verwalten von Überwachungs- und Sicherheitsprotokollen Anmelden als Stapelverarbeitungsauftrag Als Dienst anmelden Einsetzen als Teil des Betriebsystems Das waren die Berechtigungen die ich im Netz gefunden habe, die der Exchange für die Installation benötigt. Die tagelange Suche hat endlich ein Ende. Hab es soeben ans Laufen bekommen. Ich bin nochmal die GPO mit den Richtlinien für Benutzer durchgegangen. Eine der Rechte hat es dann geregelt: Erstellen eines Tokenobjekts Übernehmen des Besitzes von Dateien und Objekten Sichern von Dateien und Verzeichnissen Danke für euern Input.

Hallo Norbert, Das hatte ich in der Tat noch nicht gemacht. Habe das jetzt nachgeholt. Aber das Problem bleibt weiterhin bestehen. Das PrepareAD läuft auf einen Fehler. @Nobbyaushb Quelle ist das ISO Exchange 2019 CU5. Wobei ich auch schon CU4 versucht habe, da es einen Microsoft Artikel in Verbindung mit CU5 und Problemen bei PrepareAD existiert. Aber der Fehler bleibt bei beiden ISOs der gleiche

Hallo Norbert, wir haben eine AD mit 2 Domänencontrollern. Diese sind alle im selben Netz, am selben Standort und können sich alle untereinader verständigen. Einzige Besonderheit, es handelt sich um eine Offline Umgebung. IP-Adressenbeipiel: DC1: 192.168.1.1 DC2: 192.168.1.2 Exchange: 192.168.1.3

Guten Tag zusammen, ich schlage mich jetzt schon seit mehreren Tagen mit einem Installationsproblem bei Exchange 2019 herum aber ich komme einfach nicht weiter. Ich habe bereits ein Beitrag in einem anderen Forum erstellt. Allerdings kommen wir dort nicht wirklich voran. Ich hoffe das ich hier auf Leute treffe, die noch einen Rat für mich übrig haben. Beitrag zum Problem mit Umgebungsbeschreibung, ErrorLogs, etc. Liebe Grüße Oliver