Servergespeichertes Profil - .ost-Fehler
Hallo zusammen,
ich stehe vor einem Problem, welches sich nur durch viel Aufwand lösen lässt. Daher die Frage, ob jemand einen charmanteren Weg hat.
Hard- und Software
Server: 2 Stück (Hyper-V 2012R2 - Fujitsu)
Server OS: Windows Server 2012R2 (VM)
Client OS: Windows 7
Outlook Version: 2016
Outlook Art: Office365
User: 16 Stück
Laptops: 8 Stück (Fujtisu schlag mich tot)
Desktops: 8 Stück (Fujitsu schlag mich tot)
Folgende Situation
Wir haben den Kunden E-Mail technisch von OnPremise nach Cloud mirgiert, zusätzlich wurden noch die Server auf eine neue OnPremise Platform migriert. Jeder User hat außerdem einen neuen Client erhalten. Die lokale Domäne ist erstmal erhalten geblieben (Kundenwunsch). Später bat der Kunde dann doch um eine neue lokale Domäne. Im Zuge dessen wurden alle Benutzernamen 1zu1 neu angelegt und was noch alles dazu gehört, inklusive Servergespeicherten Profilen.
Folgendes Problem ist nun aufgetreten
Nun ist uns aufgefallen, dass wenn sich ein User an einem anderen Client erstmalig anmeldet, Outlook beim starten einen Fehler ausgibt. Der Fehler besagt, dass die Outlook-Datendatei nicht konfiguriert werden kann. Nach der Verifizierung des Problems kam heraus, dass dies an dem wechseln der Domäne liegen muss.
Grund dafür ist, dass der User Mustermann bereits auf der Festplatte des Clients vorhanden war. Da der "neue" User Mustermann in der neuen Domäne ebenfalls so heißt, legt Windows einen Ordner mit dem Namen "Mustermann.Domäne" an. Hier wird dann Outlook konfiguriert, samt den .ost-Dateieinstellungen. Meldet der User sich aber nun an einem Rechner an, an dem er zuvor noch nicht angemeldet war, wird der Ordner "Mustermann" angelegt. Outlook versucht jedoch, warum auch immer, die Ost in "Mustermann.Domäne" anzulegen. Laut Recherche stehen diese Settings in der ntuser.dat.
Wir konnten das Problem lediglich dadurch beheben, dass alle vorhandenen Benutzerordner gelöscht werden müssen, die ntuser.dat gelöscht werden muss, und erst dann funktioniert eine übergreifende Anmeldung an anderen Clients wieder.
Gibt es eine Charmantere Lösung, dieses Problem zu umgehen? Ich habe leider bis jetzt nur die Probleme im Internet gefunden, nicht aber eine schönere Lösung, als das händische löschen.
Gibt es keine Möglichkeit, Outlook per GPO dazu zu zwingen, am Ort X eine neue .ost-Datei zu erzeugen?
Ich hoffe ich habe mich verständlich genug ausgedrückt.
Vielen Dank im Voraus
ich stehe vor einem Problem, welches sich nur durch viel Aufwand lösen lässt. Daher die Frage, ob jemand einen charmanteren Weg hat.
Hard- und Software
Server: 2 Stück (Hyper-V 2012R2 - Fujitsu)
Server OS: Windows Server 2012R2 (VM)
Client OS: Windows 7
Outlook Version: 2016
Outlook Art: Office365
User: 16 Stück
Laptops: 8 Stück (Fujtisu schlag mich tot)
Desktops: 8 Stück (Fujitsu schlag mich tot)
Folgende Situation
Wir haben den Kunden E-Mail technisch von OnPremise nach Cloud mirgiert, zusätzlich wurden noch die Server auf eine neue OnPremise Platform migriert. Jeder User hat außerdem einen neuen Client erhalten. Die lokale Domäne ist erstmal erhalten geblieben (Kundenwunsch). Später bat der Kunde dann doch um eine neue lokale Domäne. Im Zuge dessen wurden alle Benutzernamen 1zu1 neu angelegt und was noch alles dazu gehört, inklusive Servergespeicherten Profilen.
Folgendes Problem ist nun aufgetreten
Nun ist uns aufgefallen, dass wenn sich ein User an einem anderen Client erstmalig anmeldet, Outlook beim starten einen Fehler ausgibt. Der Fehler besagt, dass die Outlook-Datendatei nicht konfiguriert werden kann. Nach der Verifizierung des Problems kam heraus, dass dies an dem wechseln der Domäne liegen muss.
Grund dafür ist, dass der User Mustermann bereits auf der Festplatte des Clients vorhanden war. Da der "neue" User Mustermann in der neuen Domäne ebenfalls so heißt, legt Windows einen Ordner mit dem Namen "Mustermann.Domäne" an. Hier wird dann Outlook konfiguriert, samt den .ost-Dateieinstellungen. Meldet der User sich aber nun an einem Rechner an, an dem er zuvor noch nicht angemeldet war, wird der Ordner "Mustermann" angelegt. Outlook versucht jedoch, warum auch immer, die Ost in "Mustermann.Domäne" anzulegen. Laut Recherche stehen diese Settings in der ntuser.dat.
Wir konnten das Problem lediglich dadurch beheben, dass alle vorhandenen Benutzerordner gelöscht werden müssen, die ntuser.dat gelöscht werden muss, und erst dann funktioniert eine übergreifende Anmeldung an anderen Clients wieder.
Gibt es eine Charmantere Lösung, dieses Problem zu umgehen? Ich habe leider bis jetzt nur die Probleme im Internet gefunden, nicht aber eine schönere Lösung, als das händische löschen.
Gibt es keine Möglichkeit, Outlook per GPO dazu zu zwingen, am Ort X eine neue .ost-Datei zu erzeugen?
Ich hoffe ich habe mich verständlich genug ausgedrückt.
Vielen Dank im Voraus
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 323621
Url: https://administrator.de/forum/servergespeichertes-profil-ost-fehler-323621.html
Ausgedruckt am: 22.12.2024 um 12:12 Uhr
4 Kommentare
Neuester Kommentar
Hallo,
Gruß,
Peter
Zitat von @Holle1991:
Gibt es eine Charmantere Lösung, dieses Problem zu umgehen? Ich habe leider bis jetzt nur die Probleme im Internet gefunden, nicht aber eine schönere Lösung, als das händische löschen.
Outlook Profil in der Registrierung löschen (NTUser.dat)Gibt es eine Charmantere Lösung, dieses Problem zu umgehen? Ich habe leider bis jetzt nur die Probleme im Internet gefunden, nicht aber eine schönere Lösung, als das händische löschen.
Gruß,
Peter
Hallo,
Gruß,
Peter
Zitat von @Holle1991:
Genau das haben wir schon gemacht bei einem User. Jedoch müssten wir so händisch an jeden Client, deswegen die Frage nach einer Lösung per GPO.
Eine Batch oder Powershelldatei erstellen welches das Postfach identifiziert und danach in der Registrierung löscht. Neustarten und neues Outlook Konto anlegen (GPO?) und gut ist. Ohne Aufwand eurerseits wirds aber nichts.Genau das haben wir schon gemacht bei einem User. Jedoch müssten wir so händisch an jeden Client, deswegen die Frage nach einer Lösung per GPO.
Gruß,
Peter