deubi

poledit...? Hat wer an der Policy gebastelt? oder Schau mal, ob jemand in den Profilen (c:\winnt\profiles...) die Struktur manipuliert hat, so dass "all users" die "administrative tools" nicht mehr hat.

Datensicherung mittels der "konventionellen" Mittlen wie DLT-Tapes ist empfehlenswert, sofern Ihr nicht über ein Sicherungsstorage à la EMC verfügt sogar unerlässlich. AD hat ein eigenes Sicherungs"prozedere" für die AD-Datenbank. Zu Scripting findest Du massenhaft hilfreiche Ressourcen unter http://www.microsoft.com/technet/treeview/default.asp?url=/technet/scriptcenter/default.asp

). Zu dem, was Du umsetzen willst/sollst, gehört das Auditing sicher mit dazu, und die Sicherung der entsprechenden Logs, falls dies bei Euch so hohe Priorität hat. Mittles Kommandozeilen-Tools wie ldifde und csvde lassen sich User in AD im- und/oder exportieren, schau Dir mal die entsprechenden Optionen an (cmd-line, ldifde /? ). So kannst Du den "Userbestand" mittels CSVDE exceltauglich exportieren (erzeugt eine csv-Datei). Ein Stück weit ist Dir damit sicher geholfen. Was die Rechte und Einschränkungen betrifft, die sind ja nicht (nur) in AD festgehalten, sondern NTFS-seitig durch die Berechtigungen. Leider kann ich Dir in diesem Gebiet hinsichtlich "Reporterstellung" keinen weiteren Tipp geben, ich kenn da leider nichts (das heisst nicht, dass es das nicht gibt ;) ). Mittels Scripting lässt sich selbtsverständlich alles auslesen und -werten. Ist aber sehr aufwändig, wenn Du sowas von Null auf erstellen musst. Ähh ja... NT4.0... da war ich wohl zu schnell, sorry. Nutz doch mal die Boardsuche, Du findest sicher noch was. Ich weiss z.B. nicht sicher, wie weit ein Tool wie Sysoft Sandra hier helfen würde.

Auf welche konkreten Prüfungen? Ich habe gute Erfahrungen gemacht mit den "CrashTest"-Büchern vom Mitp-Verlag, mit Ausnahme dessen zur 216er. Dort empfehle ich nach wie vor das dicke grüne von M$ in der 2. Auflage. Versuch mal, die Fragen selber zu analysieren: welche der Angaben und Daten in der Frage brauchst Du wirklich? Du wirst feststellen, dass Du regelrecht überflutet wirst mit nutzlosen Angaben. Wenn Du Dich drauf konzentrierst rauszufinden, was wesentlich ist, ist die richtige Antwort bereits sehr viel näher.

Ach, gerne geschehen! Setzt Du den W2K-DHCP-Server ein? Schau Dir mal an, was für'n DNS-Server der "mitgibt", vermutlich einen falschen. Daher haben die Clients keine DC's finden können.

Hast Du den Rechner mal mit AD-Aware (http://www.lavasoft.de) gescannt? Wenn nicht, mach ma...

Kannst Du nähere Angaben machen zur DNS-Konfiguration, sowohl client- als auch serverseitig?

Glückwunsch, Stevie, weiter zum MCSE!

Glückwunsch! Weiter so.

Ein einfacher Grund könnte darin bestehen, dass das Benutzerkonto, mit dem Du arbeitest, kein administrationsrecht besitzt. Um auf Dein Problem angemessen eingehen zu können, brauchen wir schon mehr Angaben: Benutzer, installierte SP's, Netzwerk (Domäne, Workgroup), etc...

Schau mal auf dem Server die Eventlogs an, da wirds wohl schon länger/öfters Hinweise auf den kommenden "Verfall" des TerminalServerZugriffs gegeben haben. Ich geh jetzt mal davon aus, dass das bei W2K3 ähnlich ist wie W2Ksrv (bitte korrigiert mich andernfalls). Wenn TerminalService im UserMode installiert ist, müssen entsprechende CAL's (CLient Access Licenses) installiert sein, entweder lokal auf diesem oder auf einem zentralen "Lizenzserver" der Organisation. Wenn diese Lizenzen nicht existieren, verfällt der Zugriff via Terminal Service 30(?) Tage nach der Installation... Bei der ANzahl Tage bin ich mir aber echt nicht mehr sicher. Lösung: -entweder den TerminalServer im Administrative Mode betreiben -oder die CALS auftreiben und eingeben.

Was ist genau die Absicht dieses Tools? "NUR" Protokollierung? Wieso benutzt Du nicht die Überwachung - Stichwort Audit - der entsprechenden Events, und speicherst die Eventlogs? Die Eventlogs lassen sich auch recht einfach auswerten.

das geht oft wesentlich schneller, als lange nach Fehlern zu suchen ;)

Verstehe ich das richtig: drei verschiedene Rams parallel? Ich hatte mit solchen Versuchen in der Vergangeneit öfters seltsame Resultate - etwa solche, wie Du sie jetzt erlebst. Es ist empfehlenswert, identische Teile einzusetzen. Und setzt das Bios auf die Defaulteinstellungen zurück. Der Übertaktungsversuch kann durchaus an Deinem Problem mit schuldig sein. Teste die Rams mal einzeln durch, ich schliesse mich Günter an.

Hardyman, das kennen wohl die meisten von uns :D Urlaub könnten wir wohl alle brauchen Mit welcher Lektüre hast Du Dich denn worauf vorbereitet? Du wirst mit der Boardsuche zu den meisten Themen viele nützliche Hinweise finden, welche Literatur Du zu welcher Prüfung verwenden solltest.

Na ja, zurück zu den Ursprüngen des Threads. Wenn Du versuchst, ab CD zu booten, was geschieht genau, wo bleibt der Rechner hängen? Kriegst Du Fehlermeldungen? Welche? Hast Du den Ontrack-Kram entfernen können? Ich hatte früher mit diesem Kram schlechte Erfahrungen gemacht... Falls Du die Möglichkeit hast, nimm die XP-InstallationsCD und erstell an einem andern Rechner den Installationsdiskettensatz. Varnik hatte geschrieben, wie's funktioniert. Allerdings brauchst Du dazu nicht DOS zu booten, Du kannst ein CMD-Windows öffnen und das ganze da drin tun. Prinzipiell sollten die Bootdisketten aber unnötig sein, da die Installation/Bootvorgang direkt ab CD laufen müsste. Hast Du den Datenträger überprüft, ggf. an einem andern Rechner (z.B. paar Verzeichnisse ins Temp rüberkopiert...)?

Nun, was mic da schreibt, kann man nicht allgemein so stehen lassen. Zum Lohnniveau: Unsere Löhne hier sind zwar klar höher, aber die Lebenshaltungskosten genauso. Miete, Lebensmittel, Strom, Wasser, etc. Zu den Jobs selber: seht mal auf http://www.nexus.ch an, wie's aussieht mit IT-Stellen in der Region. Ein klarer Indikator: 241 Stellen sind geboten, 531 Stellen werden gesucht. Zum Teil findet Ihr hier auch Salärangaben in sFr. Ich kenne Mic's Vorgeschichte und Verhandlungstaktiken nicht, aber ich würde behaupten, für jemanden ohne Fachhochschulabschluss (bitte korrigier mich, falls ich falsch liege) verdient er für hiesige Verhältnisse überdurchschnittlich gut. Übrigens, Mic, die UBS hat vor kurzer Zeit offiziell einen Stellenabbau im IT-Bereich angekündigt... Viele der Stellen, die immer wieder in den Stelleninseraten zu finden sind, unterliegen einer hohen Fluktuation. Ich will ja gar nicht wissen, was dort für Verhältnisse herrschen, dass die Leute gleich wieder kündigen... :shock:

dann würde ich das Problem primär woanders suchen... Booten ab CD: hast Du die von Dir benutzten Datenträger geprüft, ob die auch wirklich funktionieren?

sieht das BIOS die Platte?

der Onlinedoku entnommen: sp_password Adds or changes a password for a Microsoft® SQL Server™ login. Syntax sp_password [ [ @old = ] 'old_password' , ] { [ @new =] 'new_password' } [ , [ @loginame = ] 'login' ] Arguments [@old =] 'old_password' Is the old password. old_password is sysname, with a default of NULL. [@new =] 'new_password' Is the new password. new_password is sysname, with no default. old_password must be specified if named parameters are not used. [@loginame =] 'login' Is the name of the login affected by the password change. login is sysname, with a default of NULL. login must already exist and can only be specified by a member of the sysadmin fixed server role. Return Code Values 0 (success) or 1 (failure) Remarks SQL Server passwords can contain from 1 to 128 characters, including any letters, symbols, and numbers. The new password is updated and stored in an encrypted form so that no user, not even system administrators, can view the password. When members of the sysadmin or securityadmin fixed server role reset their own password using sp_password with all three arguments, the audit record will reflect that they are changing someone else's password. sp_password cannot be used with Microsoft Windows NT® security accounts. Users connecting to SQL Server through their Windows NT network account are authenticated by Windows NT; therefore their passwords can be changed only in Windows NT. sp_password cannot be executed within a user-defined transaction. Permissions Execute permissions default to the public role for a user changing the password for his or her own login. Only members of the sysadmin role can change the password for another user's login. Examples A. Change the password of a login without the former password This example changes the password for the login Victoria to ok. EXEC sp_password NULL, 'ok', 'Victoria' B. Change a password This example changes the password for the login Victoria from ok to coffee. EXEC sp_password 'ok', 'coffee'

na ja, in OSQL/ISQL ist TSQL angesagt, nicht scripting... wie gesagt, ich musses selber erst mal ausgraben, wie das läuft. Wenn Du erst mal raushast, wie, kannst Du das Ganze als Script "verpacken"... Die SQL-Online-Dokumentation mit einer verhältnismässig ausführlichen TSQL-Referenz kann man übrigens bei M$ herunterladen... Aber ich nehme an, die hast Du ohnehin?

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/scriptcenter/default.asp über WSH auf WMI lässt sich weit mehr ausrichten als bloss Daten abzufragen.. ;)

oder auch hier: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/scriptcenter/default.asp Du findest hier viele gut brauchbare und leicht anzupassende Samplescripts.

öhm ja,... :D :D :D Schlafmangel? Kann verheernde Auswirkungen haben! Ich schreib jetzt trotzdem mal.. "Profile" in AD Users& Computers... bloss so als Stichwort oder Gedächtnisstütze... :cool:

Ich schätze, der User, mit dem Du für diesen Screenshot eingeloggt war, ist NICHT lokaler Administrator. Ich weiss nicht, was Du genau tun oder fragen willst. Aber ich schätze, wenn Du's unter einem administrativen Useraccount tust, ist die Chance, dass es funktioniert, vermutlich höher...?