Servergespeicherte Profile

Guten Morgen,
ich habe Probleme mit Servergespeicherten Profilen beim UCS 3.1 PAE. Im Prinzip kann man sagen geht, geht nicht, geht, geht nicht …
Das Konto (Konto.jpg) ist mit dem Verweis auf die Server-Freigabe angelegt. Bei der Erstanmeldung gab es keine Probleme. Auf dem Server wurde unter /home alle Verzeichnisse angelegt. Nachdem ich den Client neu gestartet hatte bekamm ich einen Fehlerhinweis (Error-Log.jpg). Ich habe daraufhin die Default-Rechte geändert und Domain Admins auch Leserechte auf das User-Verzeichnis gegeben. Danach hatte ich Ruhe. Nun kommt der Fehler immer. Ich habe keine Ahnung warum!

Noch eine Frage: Wie Sie im Konto sehen habe ich auch ein Logon-Skript angelegt. Das wird von Windows 7 schlicht ignoriert. In keinem Log finde ich einen Hinweis für den Grund. Wenn ich das Skript manuell ausführe ist alles Ok.

Bitte um Hilfe!



Hallo,
ich glaube es ist ein BUG im UCS. Zunächst war das Verhalten nich reproduzirbar, nun schon. Ich beschreibe mal genauer was ich getan habe.

  1. Auf einem Server (sjg001) UCS 3.1 PAE installiert. Domain: j-graband.de
  2. Über UMC User (domadmin) angelegegt. Gruppe: Domain Admins, Profile-Path: \sjg001%username%\windows-profiles
  3. Ich habe einen Client (wjg006) mit Windows 7 Pro, der in Arbeitsgruppe (ARBEITSGRUPPE) an einem Windows Home Server hängt.
  4. Beitritt von wjg006 zur Domäne j-graband.de
  5. Anmelden mit J-GRABAND\domadmin
  6. ALLES IST GUT
  7. Abmelden von domadnin
  8. Auf sjg001 kontrolliert, ob alle Dateien richtig angelegt wurden. Das war der Fall.
  9. Anmelden an wjg006 mit WJG006\sysadmin (Administrator)
  10. Kontrollieren, ob Profile auch hier vorhanden ist. OK!
  11. Kontrollieren, ob der Eintrag in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList richtig ist. OK!
  12. Abmelden von sysadmin
  13. Anmelden von J-GRABAND\domadmin
  14. FEHLER! Profile kann nicht …
  15. Feierabend! Alle Rechner runter fahren inkl. Server.
  16. Nächster Tag
  17. Server hochfahren
  18. wjg006 hochfahren
  19. Als J-GRABAND\domadmin anmelden.
  20. ALLES IST GUT! ???
  21. Abmelden und als WJG006\sysadmin anmelden.
  22. Kontrolle, ob Datum von NTUSER.DAT aktuell ist. OK!
  23. Kontrollieren, ob der Eintrag in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList richtig ist. OK!
  24. Kontrolle, ob Datum von NTUSER.DAT sich geändert hat. OK!
  25. wjg006 runtergefahren
  26. wjg006 hochfahren
  27. Anmelden als J-GRABAND\domadmin
  28. FEHLER!
  29. Alle Rechner runterfahren
  30. Gleiches Spiel! Erste Anmeldung OK! Danach Fehler!
  31. log.smbd angeschaut. Da steht das Problem!

Ich bin leider kein Programmierer, der das alles versteht oder gar lösen kann. Habe den Auszug von Heute angehängt.

Bitte um Hilfe!
log.2.smbd.txt (21.2 KB)

Nub, ich scheine der Einzige zu sein, der dieses Problem hat(te). Da ich keine Lösung habe, habe ich den Server platt gemacht und nehm orginal Debian.
Gruß aus dem Norden
Jürgen Graband

Hallo,

schade, dass Sie derartige Verhaltensweisen feststellen mussten - tatsächlich ist uns dieses Problem bisher nicht bekannt.
Könnten Sie uns zu diesem System eventuell noch spezifische Informationen zukommen lassen? Ich nehme an, Sie haben das System mit Samba 4 installiert?

Auch wenn ich nicht davon ausgehe - haben Sie noch Zugriff auf die Daten des Systems? So wäre es beispielsweise gut, wenn wir den generierten Core-Dump näher analysieren könnten um so die Ursache des Verhalten ermitteln zu können.

Mit freundlichen Grüßen,
Tim Petersen

Lieber Herr Petersen,
leider habe ich keine Dumps mehr. Nur das, was ich Ihnen schon geschickt hatte. Wie gesagt, platt gemacht. Schade finde ich es auch, weil ich Systeme out of the box liebe. However, was ich noch selber analysiert hatte war folgendes:

  1. Wenn ich auf dem Client das Profile und den Eintrag in der Registry Profile.list gelöscht habe, konnte ich mich mit dem Account ganz normal anmelden. Das Profile wurde dann vom Server gezogen.
  2. Bei der Abmeldung wurden dan das Profile auf dem Server aktualisiert.
  3. Bei der nächsten Anmeldung kam der Fehler wieder.
  4. Wenn ich aber einige Zeit bis zur nächsten Anmeldung verstreichen ließ, gab es keine Fehler.
  5. Ich habe dann in allen (wirklich allen) Logs nach einem verdächtigen Prozess ausschau gehalten, der das Profile blockiert. Leider fand ich nichts. Spannend fand ich das auch desshalb, wei ich nichts von der Univention Synchronisation gefunden habe (vielleicht hab ich das Prinzip nicht verstanden oder es läuft ohne Log-Einträge, was nicht schön wäre). Das da etwas lufen muss habe ich daran gesehen, dass ich den Profile-Path per GPO geändert habe, was der Server sehr wohl mitbekommen hat.

Noch einige Beobachtungen:

  1. Wie schon gesagt ignorierte Windows Login-Scripts, die auf dem Server lagen. Aber, wenn ich beim User direkt ein Home-Verzeichnis mit einem anderen Laufwerk als das von Univention voreingestellt I: angab, wurde das Home-Verzeichnis auf dem Client unter Z: eingebunden. Damit nicht genug!
  2. Ich habe noch andere Clients mit Windows 7 in der Arbeitsgruppe “ARBEITSGRUPPE” laufen. Wenn ich nun auf dem UCS ein Account angelegt habe, der auch in der Arbeitsgruppe besteht, so hat Windows bei der Anmeldung am Profile-Path rumgemeckert und hat den Pfad in der Registry geändert. Das hatte bei der nächsten Anmeldung zur Folge, dass das Profile des Users neu unter Benutzername.Domain angelgt wurde. Wohl gemerkt, der Client war nicht in der Domain j-graband.de beigetreten. Da ich noch ne allte Kiste mit dem Windows 2003 Server am Laufen habe, habe ich das gleich mal versucht nachzuvollziehen. Da macht Windows keine Fehler. Der Verlangt gleich ein Login mit einem Popub, wo man Domain\Benutzername zur Autentifizierung angeben muss.
  3. Noch irrer ist das Verhalten mit der GPO. Das wird auch von dem NICHT beigetretenem Client vom UCS-Domain-Controler gezogen. Und der mountet das Home-Verzeichnis prombt unter Z mit vollem Zugriff. Das ist irre und nicht tollerierbar. Ohne Zugang zur Domäne, aber gleichem User-Name und Password.

Ich weiß nicht, ob es nun an den Anpassungen von Univention, an Samba 4 oder an Windows selbst liegt. Da ich Zeit habe und gern spiele, habe ich beschlossen eine reine Debian und Samba 4 Installation aufzusetzen. Mal sehen, was die tut. Wenn Sie wollen halte ich Sie auf dem Laufenden. Dazu sollten Sie mir eine Mail schreiben, weil ich nicht das Forum dazu benutzen will. Auch kann es etwas dauern, weii ich sicher “rumfrickeln” muss.

Gruß aus dem Norden

Für alle die es interessiert: Das Problem mit Servergespeicherten Profilen ist beim Samba-Team bekannt. GugstDuhier: lists.samba.org/archive/samba-te … 85154.html
Dort wird fast genau meine Umgebung beschrieben, die dieses Problem verursachen kann (Laptop über Wifi am Server nach Domain-Wechsel). Leider habe ich keine Lösung gefunfen. Ich glaube nicht, dass ich anfange mit valgrind mein System zu debuggen :wink: Werde aber noch den Versuch machen das Laptop ans LAN zu hängen, die Domain-Registrierung zu erneuern und vor der nächsten Anmeldung das Profile zu löschen. Mal sehen, ob das etwas bringt.

Gruß von einem im Ruhestand befindlichem Maintenance Manager

Letzter Status zu diesem Theard: OHNE WLAN KEINE PROBLEME!
Wenn ich WLAN, nachdem ich einige Tests gemacht habe, wieder einschalte, geht das alte Spiel von Neuem los.
Kurzbeschreibung der Infrastruktur:

Router: AVM 7390
Server: HP ProLiant N40L mit GBit LAN an Router
Client: Samsung Laptop mit WLAN 54 Mbit an Router (Problem)
mit 100 Mbit an Router (OK)

Fazit: Warnung vor WLAN! Und: Es lieg NICHT an Univention, es liegt an Linux/Samba! Mit einer alten 2003 Möhre gibt es keinen Ärger.

@Univention: Ich hätte - in meiner aktiven Zeit - ein Hinweis an meine Kunden gegeben.

Es ist der gleiche Router und somit das gleiche Netzwerk?

Mastodon