Gulp

Weil dein Macro vielleicht mit anderen Rechten läuft? (Kristallkugel polier) Grüsse Gulp

Doch kann sein ... ist ja auch so. Shutdown hat auch ein grafisches UI mit shutdown.exe /i kannst Du Zeiten und andere Sachen eingeben. Alternativ gibbet auch psshutdown von sysinternals. Hier Grüsse Gulp

Dat is Standard bei XP unn hat nix zu sagen! Grüsse Gulp

So ungefähr hab ich es mal aufgefasst. Grüsse Gulp

Da hilft die SHUTDOWN.EXE ..... Grüsse Gulp

Also ich kenne keinen, der mit einem Haken auf dem Server erledigt wäre. Wenn die Switche verschiedene physikalische Subnetze beheimaten, kann man auch die Subnetze trennen. (Stichpunkt VLAN) Oder wenn DHCP verwendet wird verschiedene Subnetze etablieren. Hat aber jemand Zugriff auf seine IP-Einstellungen, Kenntnis der Server-IP und einen gültigen Domain-User ist's vorbei mit der Zugriffssperre. Ausserdem ist der Aufwand für die oben genannten Möglichkeiten extrem. Grüsse Gulp

Wieso MAC Adressen manuell sperren? Der Switch kennt doch alle im Netz verwendeten MAC Adressen, es werden nur dem Switch unbekannt Adressen (also neue) gesperrt, weil die nicht in seiner Liste stehen. Da musst Du nur noch die rausfiltern, die Du sperren willst, das ist weit weniger Aufwand. Ich habe eine solche Umstellung auch schon in Firmen mit über 1000 Switches und 300+ Server gesehen. Ging in ca. einer Woche reibungslos durch. Wenn man die richtigen Switche (zB Cisco) verwendet, geht das auch automatisiert bzw mit wenig Interaktion. Grüsse Gulp

Die Default Domain Policy geht normalerweise auf alle OU's durch, wenn sie nicht geblockt wird. Wie wäre ein Block aller GPO's auf eine neue OU, in Du zB Dein Laptop vorher reinschiebst. .... und dann gucken was passiert. Grüsse Gulp

Das geht so einfach eben nur in einer Domäne .... Grüsse Gulp

Das würde ich über portbasierte MAC Identifizierung/Authentifizierung auf den Switches lösen. Eine andere Lösung wird schwierig .... Grüsse Gulp

Ja, das sollte funktionieren. Grüsse Gulp

Es muss ja was mit der Domäne zu tun haben, wenn es nur dann passiert, wenn Du die Kisten in die Domäne hängst. Verhält sich das SP2 denn "normal" ohne den Domänenbeitritt? Dann bleibt "nur" die Variante, dass in Deinem ADS irgendwas quer konfiguriert ist. Grüsse Gulp

RealVNC Google ist Dein Freund! Grüsse Gulp

Da sind folgende Dateien betroffen: NTLDR (NT Boot Loader) NTDETECT.COM BOOT.INI bootfont.bin autoexec.bat cmldr config.sys io.sys msdos.sys möglicherweise auch: hiberfil.sys (RAM Abbild für den Ruhrzustand) pagefile.sys (Auslagerungsdatei) Die beiden letzteren werden normalerweise auch beim Systemstart automatisch angelegt. Die system.ini und win.ini liegen bei XP nicht standardmässig auf C:\ . Mit einer Reparaturinstallation (von XP-CD booten, bei der ersten Abfrage auf Installieren anschliessend bei "Soll das gefundene .... repariert werden?" mir "r" reparieren lassen) solltest Du auf der sicheren Seite sein. Grüsse Gulp

Sehr seltsam, vor allem weil ich SP2 in Domänenumgebungen bisher ohne solchen "Schnickschnack" nutze. Schon mal versucht die Berechtigungen auf die Setup Default zurückzusetzen? Grüsse Gulp

Haha, ja dann .... Hast Du Deinen Domänenbenutzer auch in die Gruppe der lokalen Admins gesteckt? Denn bedenke Du meldest Dich, auch wenn der Domänenbenutzer gleich lautet/heisst wie der lokale Benutzer eben nicht mit beiden an, da sie unterschiedliche SID's aufweisen. Mit dem lokalen Admin sollte es jedoch funktionieren. Es sei denn Du verwendest eine GPO die genau das einschränkt. Grüsse Gulp

Tja, das wird der freundliche Admin der Domäne wohl per GPO so eingestellt haben (is ja auch kein Problem). Entweder lässt Du Dir vom Admin lokale Adminrechte verpassen oder lässt es so wie es ist. Grüsse Gulp

Kann ein Problem werden, da XP (wie alle NT basierten OS) seine Startdateien auf die erste verfügbare Partition, in Deinem Fall C:\ schreibt. Dies sollte man aber mit einer Reparaturinstallation oder auch mit etwas Handarbeit über die Reparaturkonsole wieder hinbiegen können. Ich bevorzuge die Installation meines Primärbetrienssystems auf C:\ das erspart den meisten Ärger. Grüsse Gulp

Ja, da dämmert es mir ..... Zu NT Zeiten (da hab ich mich das letzte Mal mit dem Thema beschäftigt, da hatte man auch noch Zeit für sowas) hat der Novell Client eine NWGINA.DLL installiert, die die MSGINA.DLL umbenannt hat und anschliessend wurde die NWGINA.DLL zur MSGINA.DLL. (Gab da mal ein Problem mit der vom Novell Client mitgelieferten GINA, die beim Anmeldeversuch immer in einem BSOD endete, man musste nur die originale GINA von MS wiederherstellen und schon gings wieder, was hätte ich da gerne die Reparaturconsole gehabt!) Grüsse Gulp

Ist jetzt ne gute Frage Edgar, da aber zB der Novell Client ebenfalls die msgina.dll ändert/tauscht (auch DriveCrypt macht das) und ich irgendwo mal gelesen habe (wenn ich das jetzt noch finden würde), dass diese DLL genau dafür gedacht ist, so vermute ich mal, dass es da wohl kein grosses Problem auf der rechtlichen Seite gibt. Kann natürlich sein, dass mit dem Herumspielen an der msgina.dll, die ja im Original von Microsoft ist, dies wieder zu einem rechtlichen Problem wird. Grüsse Gulp

Das ändert aber nix am Ablauf des Passwortes für's Computerkonto. Dir bleiben da nicht viele Alternativen ..... Grüsse Gulp

Na fein, sieht ja dann plausibel aus. Grüsse Gulp

Read The F*ucking Manual (RTFM) ..... sach ich auch immer .... Grüsse Gulp

Ich weiss schon was ein Backup Domain Controller ist .... ich weiss auch, dass es sich hier um NT handelt ..... ich weiss auch, dass es für meine Kunden bisher immer teurer war a: mich oder meine Kollegen am kompletten Wochenende zu bezahlen oder b: x Arbeitstage auf seine Dokumente/Daten vom Server zu verzichten als einen kleinen Standard-PC mit NT Server als Backup Domain Controller laufen zu lassen. Natürlich ist das worst case, aber glaube mir ich habe einige 5 Workstation Netzwerke mit einem BDC verkauft, obwohl das natürlich heftig diskutiert wurde. Grüsse Gulp

Wenn Du die Hardware wechselst kommst Du auch mit BackupExec und NT in Schwulitäten. Es hängt eben davon ab, wie Du wiederherstellen kannst. Hast Du IDR geht's einfacher, ist erstmal ein "neuer" DC aufgesetzt wird es in jedem Fall schwer die alte Domäne zu restaurieren. Daher war es immer geschickt (unter NT) einen BDC zu betreiben. Da sich die Kosten für die Hardware bei NT relativ im Rahmen halten lassen, will ich (für NT) Deine Aussage "ein BDC ist übertrieben" doch in Frage stellen, denn es kostet meistens mehr die alte Struktur ohne BDC wiederherzustellen. Für 2000 und 2003 ist es tatsächlich nicht mehr unbedingt notwendig, wenn auch deutlich einfacher, da diese beiden System ein nachträgliches Erstellen der Domäne zulassen. Bei NT wirst Du schoin bei der Grundinstallation gefragt, ob der Server ein DC werden soll. Nachträglich läuft da nichts mehr, denn das ist für NT auch nicht vorgesehen. Grüsse Gulp