Sunny61

Wir haben Konica Minolta und SafeQ6 als Zentrale für die Konfiguration.

Na klar, das sollte jetzt nicht das Problem sein. ;)

Wie Norbert schrub, entweder DC umbenennen oder Drucker löschen und neu anlegen. Oder Du legst dir einen Printserver als A-Record an, dann brauchst Du zukünftig an der Stelle nur die IP im DNS austauschen. Bei uns gibt es für 99% der User nur einen Drucker: \\PS\FollowMe Damit erschlägt man schon sehr viel.

2010 ist ja auch schon bald (Oktober 2020) aus dem extended Support, man sollte es eigentlich nicht mehr einsetzen. ;)

Ging das bei 2010 schon mit einem eigenen Update Server im LAN? https://www.dertechblog.de/2018/01/office-365-oder-2016-click-to-run-clients-update-mittels-netzwerkpfad/comment-page-1/

WSUS einrichten, konfigurieren und patchen. Am Anfang kann das etwas dauern, aber später ist es dann fast keine Arbeit mehr pro Monat. Schon sind alle Systeme aktuell.

Dann stimmt wohl mehr nicht. Autodiscover ist vermutlich nicht korrekt und vieles andere liegt wohl auch im Argen. BTW: Von Exchange 2010 kommt ihr nicht direkt zu Exchange 2019, da muss es eine Exchange Version als Zwischenschritt geben, AFAIK.

Du hast die Lösung selbst jetzt geschrieben. Der Automatismus birgt Risiken, auch wenn es lästig ist, manuell einbinden ohne Automapping auf dem Exchange ist IMO hier der beste Weg. Der Automatismus funktioniert so lange bis er nicht mehr funktioniert.

Hast Du auf einem der Rechner schon zum Test ein neues *Benutzer*profil angelegt? Wie sind die zweiten Postfächer eingebunden? Manuell oder Automatisch?

Kommt der Fehler auf jedem Client, egal welcher Benutzer angemeldet ist? Oder nur bei bestimmten Benutzern? Welche exakte Outlook Build ist im Einsatz?

Nimm den Haken raus bei erhöhten Rechten in der Aufgabe. Funktioniert es dann?

Die Aufgabe wird gestartet, vermutlich wird auch dein Script gestartet, nur eben nicht weiter. Hast Du im Script jetzt die Erstellung einer Logdatei an erster Stelle stehen? Falls ja, die Logdatei wird nicht erstellt? Und zum Testen nimmt man wirklich gleich den User her, der es später ausführen soll. So viel rechte wie nötig, so wenig wie möglich.

Oversized. War doch zu erwarten, oder nicht? Lass in dem Script eine Logdatei mitlaufen, schreib jede Zeile Code in die Logdatei, bevor und nachdem sie ausgeführt wurde. Dann siehst Du recht schnell wo es hakt.

System ist das Computerkonto, hat das Computerkonto, oder auch die Authentifizierten Benutzer, oder eine passende Gruppe mit dem Computerkonto als Mitglied, die passenden Zugriffsrechte?

Wie genau sieht denn der Inhalt des Scriptes aus? Evtl. liegt dort der Hund begraben.

Fast ist nicht identisch. Es wurde ja schon mal nach BIOS Version und Aktualität gefragt, hast Du das schon manuell geprüft? Firmware der Platten? Kabel im Server schon mal getauscht?

Ein SET auf Commandline zeigt dir schon mal ein bisschen was. Ein WHOAMI bringt noch ein paar weitere Informationen zu Tage. Kann auch mit Parametern aufgerufen werden: https://docs.microsoft.com/de-de/windows-server/administration/windows-commands/whoami

Happy Birthday! :)

Sind denn die verwendeten Treiber aktuell?

Ich bin mir nicht sicher, aber schau doch mal nach ob der W7 Telemetrie Dienst, falls W7 einen hat, laufen kann oder ob er deaktiviert ist. Wie sieht die HOSTS Datei aus? Sind irgendwelche Einträge in Sachen MSFT vorhanden? Falls ja, leeren und nochmal probieren.

Existiert das Problem bei allen Benutzern auf allen Clients?

Das funktioniert aber nicht. Auf dem Client wird der Registryeintrag auch nicht erstellt / gesetzt. Das ist ein Usereintrag, hast Du auch diesen Teil im Userteil des GPO untergebracht?

Ich habe keine Abfrage gepostet, ich habe nur Tipps gegeben in welche Richtung man hätte suchen können. Aber es ist ja jetzt alles erledigt.

Diesen Artikel meint Norbert: https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/

Du darfst sie gerne hier posten, Danke.