|
Verfasst am: 13. 01. 2008 [14:19]
|
|
rb
IT-Regionalbetreuer
Themenersteller
Dabei seit: 18.09.2007
Beiträge: 47
|
Keine Anmeldung möglich!!
Nach dem Clonen der Clients im EDV Raum lassen sich an immer mehr PC immer mehr Schüler nicht mehr anmelden (hängt beim Laden der Benutzerprofile). Wechselt der Schüler an einen anderen PC, kann er sich dort Problemlos anmelden.
Ein möglicher Grund (vermutlich einer von vielen): Beim Umstellen von man auf dat waren noch lokale Profile von diesen Usern vorhanden (auf man gesetzt - auf dem Server jedoch auf dat). Beim An- bzw. Abmelden kommt es zu einer Vermischung dieser beiden Profilvarianten, wodurch dann Probleme auftauchen. Also: Bei der Umstellung auf dat (auf dem Server) immer darauf achten, dass keine lokalen Profile dieses Users vorhanden sind.
|
|
Verfasst am: 17. 09. 2009 [22:47]
|
|
psph
IT PSPH
Dabei seit: 15.02.2008
Beiträge: 23
|
Ich denke ich habe auch dieses Problem 
Wie kann ich solche lokalen Profile löschen?
Ausprobiert habe ich delprof.exe und rmdir.
Beide schaffen es nicht alle ntuser.dat oder .man des lokalen Profils zu löschen 
lg
Stephan
|
|
Verfasst am: 17. 09. 2009 [23:23]
|
|
psph
IT PSPH
Dabei seit: 15.02.2008
Beiträge: 23
|
Habe jetzt gerade noch folgendes ausprobiert:
Servergespeichertes Profil von VS1 auf .dat gestellt und auf einem frischen Clone das erste Mal angemeldet. Das Profil wird auf den Client kopiert. Beim Abmelden wird die ntuser.dat auf den Server zurückgeschrieben. Jetzt ändere ich von dat auf .man und melde mich wieder an und ab und bekommen die ntuser.dat vom Client in mein Profil auf dem Server zurückgeschrieben.  Jetzt habe ich auf dem Server in dem Profil eine ntuser.man und eine ntuser.dat
Das kann ja wohl nicht Sinn und Zweck sein ...
Wer kann helfen?  Was mache ich falsch?
[Dieser Beitrag wurde 1mal bearbeitet, zuletzt am 17.09.2009 um 23:24.]
|
|
Verfasst am: 27. 09. 2009 [16:44]
|
|
hsal
Harald oder Kuno
Dabei seit: 01.01.1970
Beiträge: 25
|
Ich habe mir inzwischen angewöhnt, die lokalen Kopien der Profile immer zu löschen, wenn ich was am Profil ändere (eben das Hängenbleibens wegen).
Vorgangsweise:
Client: Neustart, als Administrator anmelden, Benutzerprofil löschen, Neustart (sicher ist sicher)
Server: .man -> .dat
Client: Anmelden als User, Änderungen vornehmen, Neustart, als Administrator anmelden, lokales Profil löschen, Neustart (sicher ist sicher)
Server: .dat -> .man
geht.
alternativ - nachdem ich ab und zu zu faul bin, mich als Administrator lokal anzumelden - kann man auch als Domänenadmin (wenn man schon mal am Server sitzt) das Profil auf dem lokalen Rechner löschen: \\RECHNERNAME\C$\Dokumente und Einstellungen\
die Neustarts sind notwendig, weil das System sonst beim Benutzerprofil - auch wenn der User nicht angemeldet ist - einige Dateien blockiert und diese nicht löschen lässt.
den sicher ist sicher bräuchte es eigentlich nicht (hat auch schon ohne funktioniert), aber ich traue Windows nicht immer 
Viel Erfolg!
Kuno Sandholzer
|
|
Verfasst am: 26. 10. 2009 [10:45]
|
|
koebd
Dietmar Köb
Dabei seit: 11.01.2008
Beiträge: 16
|
Das Hängenbleiben beim Login kann auch eine ganz andere (viel tiefergehende und nur schwer zu lösende) Ursache haben:
Besonders wenn das nach dem Clonen passiert (also beim ersten Anmelden an dem jeweiligen PC) und nur bei einzelnen PCs - bei anderen gehts. Der Client bleibt hängen beim Punkt "Benutzereinstellungen werden übernommen ..". Die Kiste ist zwar nicht vollständig abgestürzt (eingefroren), denn der blaue Balken ist immer noch in "Bewegung", aber es geht auch nach 3 h nichts weiter und der PC ist auch über das Netzwerk nicht mehr erreichbar.
Sollte dieses Erscheinungsbild auftreten so ist die sehr wahrscheinliche Ursache das Problem mit den „SIDs“. Im Dömänennetz muss jeder PC eine eindeutige SID haben. Da wir mit Images arbeiten muss diese Anpassung/Änderung anschließend an das Cloning, nachträglich am Client passieren. Das hat bis zur Version WinXP-SP1 das Symantectool "Ghost-Walker" (in der Ghost-Console integriert) zuverlässig gemacht. Seit WinXP-SP2 macht es dieses Tool aber eben nicht mehr zuverlässig (= offizielle Auskunft von Symantec), d.h. die einzig wirklich zuverlässige Alternative ist die Verwendung von Sysprep-Images (auch das wird vom Symantec-Support offiziell bestätigt)!!
Um also solche und in weiterer Folge auch andere Probleme von vornherein ausschließen zu können, gibt es als einzige Empfehlung: "Finger weg von "Ghost-Walker"! Statt dessen "gesysprepte"-Images verwenden (und das ausgehend von einem "sauberen" Musterimage - will heißen: einmal "Ghost-Walker" verwendet = Image ist vergurkt!).
lG
Dietmar
|
|
Verfasst am: 31. 10. 2009 [21:34]
|
|
psph
IT PSPH
Dabei seit: 15.02.2008
Beiträge: 23
|
Wenn der GhostWalker nicht korrekt funktioniert, warum ist er dann immer noch in der neuesten Solution Suite enthalten Was meint denn dazu der offizelle Symantec Support ?!? Wer kann da mal eine Anfrage dazu stellen??? Als ich selber mal über die Schule mit dem Symantec-Support telefonierte, wurde meine Anfrage schlichtweg abgelehnt, da unsere Schule kein Supportvertrag hat 
Im Handbuch der Solution Suite 2.5 steht so weit ich weiß nichts, dass GhostWalker nicht korrekt funktionieren soll. Wenn das tatsächlich so ist, ist das ja eine bodenlose Frechheit von Symantec
Das mit dem Syspreb-Dings ist ja auch eine einzige Tüftlerei, wenn man nicht einfach ein Image von den RBs verwenden kann, so wie ich, weil ich leider andere Maschinen und vorallem noch sehr alte Rechner neben den neuen im Einsatz habe. Da nehmen alleine die Tests mit den Syspreb-Images einen unzumutbaren Zeitaufwand ein.
Wann gedenkt Symantec ihren GhostWalker weiter zu entwickeln, damit das auch mit WinXP SP3 und natürlich auch mit Windows7 ordentlich funktioniert?!?!?
lg
Stephan
[Dieser Beitrag wurde 1mal bearbeitet, zuletzt am 01.11.2009 um 08:15.]
|
