Tischzecke

SAN kostet nunmal eine Kleinigkeit. Dafür macht es recht wenige Probleme. Für weniger Speicher: Raidcontroller kaufen, Plattenturm drunter (notfalls IBM EXP710) und über SCSI anschliessen. Fertig. Das SAN mehr Performance haben soll, weil keine Dienste laufen, halte ich für ein Gerücht. Der Geschwindigkeitsvorteil mag wohl eher in der FCC-Technologie und der 2 bzw. ab demnächst 4GBit-Geschwindigkeit liegen. mfg TZ

Hallo, dann wird das doch locker. Alles in einem Raum (Auf Temperatur achten), verkabeln und evtl auch die DCs doppelt auslegen. .. Dann schön über die Maschinen verteilen. Fertig. mfg TZ

Hallo, wir haben zwei von den Dingern in den ersten beiden Räumen. Ursprünglich waren die so bemessen, dass eine ruhig ausfallen konnte. Das ist nun auch vorbei ;) Bei 25°C läuft alles noch einigermaßen, 28°C war auch schon drin... aber wehe es wird mehr. Das Argument mit dem Ausfall ist eines der Besten, die ich kenne... trotzdem zieht es nicht immer. Da bleibt dann nichts anderes als einfach vorher darauf hinzuweisen und zu warten, bis es knallt. mfg, TZ

Tag auch. Wenn das Profil trotz ntuser.dat (nicht ntuser.man) zurückgeschrieben und somit keine Änderungen übernommen werden, obwohl die Berechtigungen korrekt sind und es sonst auch immer funktioniert hat, habe ich noch einen Vorschlag. Das ist ein Problem, dass schon diverse Male bei uns aufgetreten ist. Ich behelfe mir da wie folgt: 1. Sicherung des Profiles auf dem Server (irgendwo hinkopieren) 2. Sicherung des Profiles auf dem Client (auch irgendwo hinkopieren) Entweder hat das Profil auf dem Client ne Macke oder das Profil auf dem Server. Ich lösche meistens zu erste das Profil auf dem Client und schaue nach, ob bei der nächsten Anmeldung dieses wieder geladen werden. Da dies im vorliegenden Fall bereits einmal nicht funktioniert hat, wäre dann Lösungsweg 2 an der Reihe. Profil und Ordner auf dem Server löschen und neu anlegen, Rechte setzen. Keine Sorge, ich weiss selbst wie sich das anhört, aber zumindest bei mir funktioniert dieser Weg, so dass das Profil anschliessend vom Client wieder zurückgeschrieben werden kann. Das gleich werde ich jetzt auch nocheinmal machen.....*Telefonschnapp* mfg,TZ

Nein. Eine nachteilige Beeinflussung durch und mit den Mitarbeitern ist ausgeschlossen. Die Anmeldung läuft auch tagsüber (jetzt) problemlos. Die Druckereinstellungen sind nach wie vor unverändert und bereiten keinerlei Probleme. Bei nicht vorhandenem Druckertreiber wird der Drucker nicht erstellt und ein entsprechender Eintrag tauchte (bis ich das abgeschaltet habe) im Eventlog auf. Eine Anmeldedauer von mind. 1 Minute ist dabei jedoch ebenfalls ungewöhnlich. mfg TZ

Guten Morgen, in den mitlerweile vergangenen Tagen konnte ich nie ein sauberes Log erstellen, da sich ständig jemand neu am System angemeldet hat. Daher bin ich heute morgen mal um 7:00 Uhr auf der Arbeit gewesen (nicht, dass hier jemand neidisch wird) und wollte das testen. Die Anmeldung klappte in einem Bruchteil einer Sekunde. Mein überraschtes Gesicht und meinen Ärger möge man sich vorstellen ;) Daher kann das Problem als gelöst betrachtet werden, auch wenn Ursache und Fehlerbehebung im unklaren bleiben. Um aber noch die gestellte Frage zu beantworten: Es wurde nichts am System verändert (vor vier Wochen), was für die Anmeldedauer in Frage (oder auch nicht in Frage) käme. mfg TZ

Hallo, folgendes Szenario: Die Anmeldung an einem Terminal-Server (Citrix MetaFrame XPe) - 8 sind es insgesamt - dauert über RDP mit einem Domänen-Konto zu lange. Angepeilte 66 Sekunden (Domänen-Login, ohne Roaming-Profile), werden von 2 Sekunden (lokale Anmeldung) glatt geschlagen. Vor noch knapp 4 Wochen waren beide Anmeldezeiten gleichwertig. Einschränkungen - Das Problem tritt nur bei einem Server auf - Es ist unerheblich, ob mit oder ohne Romain-Profile - Es ist unerheblich, ob mit oder ohne Login-Skript - Es ist unerheblich, ob bereits bekannte User oder neue - Es ist unerheblich, welcher Anwendergruppe der Benutzer angehört - Es ist unerheblich, ob Desktop-Freigabe(ICA/RDP) oder Anwendungsfreigabe(ICA) - DNS, DCHP, WINS: OK - Es ist unerheblich, aus welchen VLAN der Zugriff erfolgt (keine Firewall dazwischen) Was bisher geschah: 1. Event-Logs: Keine Einträge 2. FileMon: Keine Auffälligkeiten 3. Prozesse: Keine Auffälligkeiten 4. Netzwerklast: Keine Auffälligkeiten Gibt es hinsichtlich einer Lösung des Problems weitere Vorschläge, die wir untersuchen könnten? MfG, Tischzecke

Ja. Die IP stimmt soweit. Diese wird manuell eingetragen, weil DHCP aus Sicherheitsgründen in dem Netzwerksegment abgeschaltet wurde. Sonstige Kommunikation ist auch nicht beeinträchtigt. Keine Fehler bei der Verarbeitung. Einzig aufgefallen ist mir ein Eintrag kurz vor der Abmeldung und Neuanmeldung des Benutzers: Event Type: Error Event Source: Userenv Event Category: None Event ID: 1068 Date: 27.04.2006 Time: 10:15:16 User: SYSTEM Computer: XXX Description: Die Verarbeitung des Gruppenrichtlinienobjekts wurde abgebrochen, weil der Computer heruntergefahren wurde, oder der Benutzer sich abgemeldet hat. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Dies erfolgt aber knapp zwei Stunden nach der ersten Anmeldung. Die Verarbeitung dauert m.E. zu lange. Nein. Ich vermute es handelt sich um ein Xp-spezifisches Problem. Andere Systeme unter W2K haben mit der W2K-Domäne keine Probleme und behalten auch ihre Rechte dauerhaft. Mir fehlen entsprechende Referenzsysteme --- könnte ich eigentlich mal aufsetzen... Es ist bisher jedoch nicht gelungen den Fehler zu reproduzieren, da er sporadisch auftritt. mfg TZ

Hallo, ich habe folgendes Problem: Ein XP-Client bekommt in einer Windows 2000-Domäne über die ADS (Gruppenrichtlinie) lokale Administrator-Rechte zugewiesen. Ab und an kommt es vor, dass die Rechte nicht übernommen werden und der Benutzer auf dem Client nicht mehr die Rechte hat, die er benötigt. Nach der nächsten Neuanmeldung funktioniert wieder alles. Hat jemand diese Problem schon einmal gehabt oder kann sich jemand einen Lösungsweg denken? mfg, Tischzecke

Hallo allerseits, Der Testserver ist in der Zwischenzeit am Ende seines Testzyklus angekommen (SP4, R1). Ich habe den Zugriff von 10 Systemen aus sowohl mit FQDN als auch über den reinen Systemnamen versucht - beides funktionierte Einwandfrei. Nur nicht auf einem System. Hier bekomme ich weiterhin die Meldung, dass der Name nicht aufgelöst werden kann. Dies kann u.U. auch daran liegen, dass dort zur Zeit der Evt.-ID-Eintrag 5788 auftaucht. Zumindest sprechen 500 Clients und die restlichen MS-Server eine deutliche Sprache. Interessant war es in diesem Zusammenhang auch, dass die W2K-Clients keine Probleme mit dem Alias hatten, jedoch ein Großteil der MS-Server unter SP2 und SP3. Mal gucken, was daraus wird. mfg, Tischzecke

Hallo, da bin ich wieder. SP4 - keine Änderung. Es sah erst auf zwei Servern so aus, als würde der Aufruf sowohl über FQDN als auch nur mit dem Servernamen dauerhaft funktionieren, beim dritten Server, von dem aus der Zugriff erfolgen sollte, klappte dies jedoch ohne FQDN nicht. Nun bin ich am überlegen, ob ich noch das Rollout probieren sollte (auf nem Testserver), aber ich rechne nicht wirklich mit einer Lösung des Problems. mfg, Tischzecke

So, heute Nacht habe ich den Server mal neugestartet. Siehe da: In SP3 ist diese Funktion wohl nicht enthalten. Also muss ich dann wohl heute abend SP4 installieren und hoffen, dass es morgen besser funktioniert. stay tuned...

Hallo und Danke, das war genau der Artikel, in dem ich ohnehin schon am rumfuhrwerken war. Da bin ich ja schon auf der richtigen Spur. Die Angabe ist mir zur schwammig, ich kann nicht einfach auf dem System ein neues Servicepack auf Verdacht installieren, wenn es sich nicht doch vermeiden lässt.Ist bekannt, ob es mit SP3 bereits funktioniert? mfg, Tischzecke

Hallo, ich habe hier ein Problem, dessen Ursprung ich noch nicht eindeutig identifizieren konnte. Folgendes: Auf einen FileServer (W2kServer SP3) wurde ein DNS-Alias in einer Domäne gelegt. Dieser wird nun von einigen Servern (eigentlich sind es wohl alle w2k-Server) nicht bei einem UNC-Aufruf (SMB) gefunden. Der Fehler lässt sich leider nicht reproduzieren, so dass der Zugriff mal funktioniert und (was viel schlimmer ist) mal nicht. Ich persönliche Vermute eine Cache-Geschichte, weiss jedoch nicht, warum er wiederholt den Zugriff schafft und dann mal wieder nicht. Im Eventlog finden sich keinerlei Einträge (auf keinem der beteiligten Systeme). Hat jemand etwas in der Art bereits gehabt? Ein bereits geführter Thread brachte hier leider kein Ergebis (Problem wurde zwar gelöst, Autor meldete sich jedoch leider nicht). mfg, Tischzecke