Servergespeichertes Profil

german

#1

An unserer Schule wurde ein neuer Server mit UCS in Betrieb genommen.
ca. 40 Clients (Win 7) mit ca. 180 Benutzern wurden eingerichtet. Da die Benutzer in der Regel Schüler sind, sollten die Benutzerprofile einmal eingerichtet werden und dann nicht mehr veränderbar sein.
Wie könnte man das umsetzen? Z. Zt. werden die Profile “servergespeichert”!


#2

Hallo,

ich habs nicht selbst probiert, aber unter dem Stichwort “mandatory user profile” findet man im Netz diverse Hinweise.
Zum Beispiel Creating a Mandatory User Profile oder Unveränderliche Windows-Konten nutzen.
Im Kontext sinnvoll ist ggf. auch 11.3.6. Verwendung temporärer Benutzerprofil-Kopien.

Viele Grüße,
Dirk Ahrnke


#3

Hallo:)
wenn du auf Linux seite in das Homeverzeichnis gehst des Schülers, gibt es eine Datei namens " NTUSER.DAT" nenne diese in “NTUSER.MAN” um , nach einem relog wird alles zurückgesetzt


#4

Wir haben nun ca. 20 Windows 7 Clients mit 180 Usern, die sich am UCS anmelden. Dabei wird pro User ein Homelaufwerk erstellt, das in WIN7 angezeigt wird. Weiters existiert ein Anmeldescript, das an den Clients 2 zusätzliche Netzlaufwerke erstellen soll. (ServerNetlogonStart.cmd als Anmeldescript bei jedem User eingetragen)
Leider passiert es immer wieder, dass Clients nur mit einem temporären Profil angemeldet werden. Auch das Script funktioniert nur fallweise - ansonsten muss das Script manuell gestartet werden vom Client aus.
Das ist nicht zielführend.

Woran könnte es liegen, dass
a) die Anmeldung oft nur mit einem temporären Profil erfolgt
b) das Script nicht ausgeführt wird, d.h. die Netzlaufwerke nicht angezeigt werden sondern nur das Home-Verzeichnis

Zusätzlich läuft auf den Clients noch HDGuard.


#5

Schwierig zu sagen.
Wenn die Anmeldung nur mi einem lokalen Profil erfolgt, dann haben diese Clients keine Verbindung zum Server gehabt oder die Verbindung ist während der Übertragung abgebrochen (das Profil konnte nicht übertragen werden). Ggf. liegt es an Dateien und Elementen im Profilordner selbst. Das Netzwerk und Netzwerkelemente wie Firewalls, etc. können ebenfalls Einfluss nehmen. DNS Konfiguration des Servers und der Clients, die eingesetzten Versionen und mindestens das Windows Eventlog müssen dann ebenfalls geprüft werden.

Das das Script nicht ausgeführt wird hat vermutlich den gleichen Grund wie das lokale Profil.


#6

Scheinbar ist das Problem gelöst - aber noch eine andere Frage:
Woran liegt es, dass die Anmeldedauer der Windows Clients doch geraume Zeit in Anspruch nimmt?

Liegt das eher an den Clients oder ist der Server “zu schwach”?

Auch die Abmeldung dauert gefühlt sehr lange, vor allem wenn man den normalen Windows-Start bzw. Shutdown mit einer SSD kennt. (Die Clients haben eine SSD als Systemplatte)

Wie könnte man das verkürzen?


#7

Das hängt meine Meinung nach von den Clients und der Profilgröße ab. Wenn bei jeder An und Abmeldung Gigabytes an Daten über das Netzwerk geschaufelt werden müssen, kann das beides verzögern. Der Server hat an sich bei der Anmeldung nicht zu viel zu tun ich sehe die meiste Last eher bei den Clients. Testweise könnte man einen Test Client in die Domäne bringen aber ohne servergespeichertem Profil und dann das An und Abmelden messen.


#8

Wie könnte man die Profilgröße reduzieren?


#9

Indem die im Profil liegenden Daten auf ein Minimum reduziert werden? Das kommt darauf an was übertragen wird - die Menge muss man dann versuchen zu reduzieren. Ich würde aber vorher den beschriebenen Test mit einem Client ohne servergespeichertem Profil machen um zu sehen ob das wirklich daran liegt.


#10

Habe jetzt mal die Profilgrößen ausgelesen - daran sollte es wirklich nicht liegen - sind alle zwischen 500 Kb und 1,5 Mb


#11

Habe noch etwas vergessen zu sagen: die Clients haben fixe IP Adressen, die in Windows eingetragen sind. Ev. hängt es damit zusammen, weil im samba-log oft von “unknown lease” die Rede ist - und das betrifft eben diese fixen IP Adressen


#12

Okay, das lässt sich alles testen. Ein Client mit lokalem Profil und DHCP Adresse gegen einen Client mit server Profil und fester Adresse, wer gewinnt? Wenn beide gleich schnell sind, wird die Anmeldung eher am Server hängen oder halt am Netzwerk allgemein. Andernfalls weiss man auf diese Weise auch Bescheid. Ggf. könnte man auch den Test verändern um eine ideale Kombination herauszufinden.


#13

Leider lässt sich keine einheitliche Verhaltensweise bei der Anmeldung der WIN7 Clients bestimmen.
Der lokale Test-User braucht zur Anmeldung ca. 30 Sekunden. Der servergespeicherte User hat einmal ca. 40 Sekunden gebraucht, kurz darauf derselbe User an einem anderen PC über 3 Minuten. Aber wenig später nach einem Neustart auch wieder nur 30 Sekunden.
Irgendwie kann ich die Anmeldedauer von Fall zu Fall absolut nicht nachvollziehen.
Besonderes schlimm ist es, wenn sich 2 Klassen in den EDV Räumen gleichzeitig anmelden. (ca. 30 Clients)
Dann kann es bei einzelnen Usern bis zu 5 Minuten dauern - und das ist sehr lästig.


#14

Haben Sie schon das Netzwerk (oder Switches, etc.) als bremsenden Faktor ausgeschlossen? Sie können noch allgemein die Last auf dem Server messen wenn sich 2 Räume gleichzeitig anmelden. Das sollte dann genug Datenpunkte ergeben um zu sehen ob das Problem eher beim Server oder zwischen Server und Client liegt.


#15

Also der “normale” Traffic, sprich Internet, Dateitransfer etc. funktioniert m.E. völlg normal. Wie kann ich die Last am Server messen? Gibt es Methoden, die Switches etc. zu messen?


#16

Problem: Die Anmeldung von Clients dauert lange

Wer ist (grob) beteiligt?

  • Server
  • Clients
  • Netzwerk

Was sind die Faktoren und wie kann man das überprüfen?

  • Server
    -> Netzwerkeinstellungen (Geschwindigkeitsdrosslung?)
    -> CPU/Ram (Auslastung überprüfen durch: UMC: “Statistiken”, Konsole: “# top” oder “# iotp”)
    -> Harddisks (Auslastung müsste auch über die Statistiken zu sehen sein)
  • Clients
    -> Profilgröße
    -> Netzwerkkarten Einstellungen
    -> Betriebssystem
  • Netzwerk
    -> Prüfung der eingesetzten Hardware (Typ, mögliche Geschwindigkeiten, etc.)
    -> Kabelverbindungen i.o.?

Was bedeuten die Daten?
Wenn am Server bei mehreren gleichzeitigen Verbindungen sich “nichts regt” würde ich zunächst nicht von einem Geschwindigkeits oder Ressourcen Problem des Servers ausgehen. Da die Tests ein sehr breites Spektrum aufweisen und mind. einmal durch Aktionen am Client (Neustart) stark verbessert wurden, würde ich die Ursachensuche bei den Clients oder dem Netzwerk weiterführen. Beim Netzwerk macht es ggf. Sinn mit einem Netzwerktester mal die Geschwindigkeit an sich zu testen - das ist vermutlich etwas Aufwand müsste man sehen ob das sinnvoll ist. Bei den Clients (zumindest Windows) gibt es mit sicherheit Tools die die Geschwindigkeit und den Datendurchsatz messen können.


#17


Die Spitzen zeigen die Benutzung der EDV Räume genau an - denke aber nicht, dass das schwerwiegende Überlastungen sind.


#18

Ein kleiner AUsschnitt aus dem samba log-file

[2017/01/29 06:26:52.726848, 0, pid=17316] …/lib/util/util_runcmd.c:316(samba_runcmd_io_handler)
/usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is unacceptable
[2017/01/29 06:26:52.764549, 0, pid=17316] …/lib/util/util_runcmd.c:316(samba_runcmd_io_handler)
/usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is unacceptable
[2017/01/29 06:26:52.802344, 0, pid=17316] …/lib/util/util_runcmd.c:316(samba_runcmd_io_handler)
/usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is unacceptable
[2017/01/29 06:26:52.840525, 0, pid=17316] …/lib/util/util_runcmd.c:316(samba_runcmd_io_handler)
/usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is unacceptable
[2017/01/29 06:26:52.878785, 0, pid=17316] …/lib/util/util_runcmd.c:316(samba_runcmd_io_handler)
/usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is unacceptable
[2017/01/29 06:26:52.916682, 0, pid=17316] …/lib/util/util_runcmd.c:316(samba_runcmd_io_handler)
/usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is unacceptable
[2017/01/29 06:26:52.955012, 0, pid=17316] …/lib/util/util_runcmd.c:316(samba_runcmd_io_handler)
/usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is unacceptable
[2017/01/29 06:26:52.995031, 0, pid=17316] …/lib/util/util_runcmd.c:316(samba_runcmd_io_handler)
/usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is unacceptable
[2017/01/29 06:26:53.056718, 0, pid=17316] …/source4/dsdb/dns/dns_update.c:290(dnsupdate_nameupdate_done)
…/source4/dsdb/dns/dns_update.c:290: Failed DNS update - with error code 8
[2017/01/29 06:36:53.021074, 0, pid=17316] …/lib/util/util_runcmd.c:316(samba_runcmd_io_handler)
/usr/sbin/samba_dnsupdate: dns_tkey_negotiategss: TKEY is unacceptable
[2017/01/29 06:36:53.059289, 0, pid=17316] …/lib/util/util_runcmd.c:316(samba


#19

korreliert die Meldung aus dem Samba-Log mit den Spitzen oder tritt das generell auf? Können Sie das DNS-Backend auf LDAP umstellen um zu sehen ob sich das Verhalten ändert?

[code]# ucr set dns/backend=‘ldap’

service bind9 restart[/code]


#20

Tritt generell auf - genau alle 10 Minuten - 9 Einträge