aba

Befindet sich der Server in einer W2k-Domäne? Wenn ja, ist das der erste Exchange2000 in der Domäne? Falls ja, mit welchem Benutzer startest Du die Installation? Der Benutzer, der die erste Installation von Exchange2000 in einer Gesamtstruktur erstellt, muß Mitglied der Schema-Admins sein.

20 Verbindungen? Waren das nicht mal nur 10 gleichzeitige Verbindung bei der NT4.0 Workstation?

Abhängig von der Anzahl der Drucker und Druckjobs wäre evtl. auch die Druckjobgröße zu beachten (z.B. Konstruktionsdaten im TIFF-Format sind u.U. recht groß).

@günterf: Ich bin ja schon mal schwer beruhigt, dass es nicht mit einem simplen "da mußt Du doch nur den Haken bei der Option xyz setzen" funktioniert :) Sonst hätte ich mich schon etwas über mich geärgert. Vielen Dank für Deine Mühe!!!!

Stammdomäne mit einer untergeordneten Domäne. Eine 2. Subdomäne soll im Laufe des Jahres noch unter die Stammdomäne "gehängt" werden. Bisher nur ein Standort .... dabei sollte es eigentlich laut aktueller Planung auch bleiben.

Tja, das habe ich mich auch gefragt. Problem ist: 7/24 Betrieb des kompletten LANs, da ist wenig Zeit für downtimes bzw. für Experimente in Richtung "Was passiert, wenn wir es mal anders versuchen?" :) Bisher ist nur die Beauftragung für die Migration der Domäne von NT4.0 auf W2k3 erteilt worden (inkl. einiger "Randarbeiten") erfolgt. Über "den Rest" müssen wir noch reden. Das Admin-Team ist, nun ja, ich nenne es mal "kreativ" ... ;) Manchmal kann man sich die Dinge eben nicht aussuchen :p

Jepp. Selbst die lokalen Richtlinien für die Server gleichen Typs sind nicht identisch :( Und das wird wohl auch erst mal so bleiben müssen, da mir niemand auf Anhieb sagen kann, warum da so viel individuell rumgebastelt wurde :(

Alle Benutzerberechtigungen, die per lokaler Sicherheitsrichtlinie definiert sind, (Lokale Anmeldung: Administratoren, Benutzer, Hauptbenutzer, Backup Operatoren) werden von der Einstellung der GPO (Lokale Anmeldung: SQL-Operatoren) überschrieben (also dann auch nicht mehr vorhanden). Wenn die Server alle die Standard-Konfiguration hätten, wäre das ja nicht schlimm, das hätte ich noch irgendwie "gedengelt" bekommen. Aber da ist recht viel individuell von Hand an den lokalen Sicherheitsrichtlinien auf den einzelnen Servern rumgefummelt worden.

Jetzt kommen wir der Sache näher: Default Domain Policy regelt nur die Kontenrichtline MemberServer Policy hat nur die Einstellung "Loopbackverarbeitungsmodus" aktiviert / Ersetzen SQLServerPolicy enthält nur die Einstellung für die Benutzerrechte. Berechtigung für die GPO ist default, also Authenticated User lesen/ GPO anwenden. Innerhalb der OU befindet sich nur ein Schwung SQL-Server.

Sorry ... da habe ich dann wohl Deine Frage falsch verstanden. Ich würde es mir nicht anmaßen, Dich zu belehren !!!! Ich hoffe, dass ich sie jetzt richtig verstanden habe!?!?!?! Die jeweiligen GPOs sind mit der dazugehörigen OUs verknüpft, in denen sich die Computerobjekte befinden: Domain (Domain Default Policy) MemberServer (MemberServer Policy) SQLServers (SQLServer Policy) <- hier z.B. FileServer (FileServerPolicy <- hier z.B. Sollte das jetzt wieder eine falsche Interpretation Deiner Frage von mir sein, .... schubs mich bitte mal von der Leitung auf der ich stehe und red Klartext.

Computerkonfiguration -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Zuweisen von Benutzerrechten Und da dann z.B. "Lokal anmelden", "Herunterfahren des System", ...

Es geht um folgendes Problem, vor dem ich stehe: Netzwerk beim Kunden: W2k3-Domäne + ca. 120 MemberServer unter W2k und W2k3 (SQL-, Oracle-, Exchange-, File-, Print-Server). Für eine dezentrale Administration sollen die einzelnen MemberServer-Gruppen von unterschiedlichen Administratoren verwaltet werden (z.B. die SQL-Server von den SQL-Operatoren). Für jede Server-Gruppe wurden OUs erstellt, die Server ihren Aufgaben entsprechend in die OUs verschoben (W2k & W2k3 gemischt). Für jede Server-Gruppe wurden globale Gruppen in der Domäne erstellt, in die denen die jeweiligen Administratoren Mitglied sind (z.B. SQL-Operators, PrintServer-Operators, ....). Per GPO wollte ich dann den jeweiligen Gruppen die erforderlichen Benutzerrechte erteilen (z.B. Lokale Anmeldung, Herunterfahren des Systems, ....). Da bin ich auf folgendes Problem gestossen: Werden die Benutzerrechte per GPO erteilt, werden alle lokal erteilten Benutzer überschrieben. Leider sind die Server bei unserem Kunden alles andere als einheitlich konfiguriert, d.h. es wurden zusätzliche individuell Benutzerrechte über die jeweiligen lokalen Sicherheitsrichtlinen erteilt (natürlich undokumentiert ;) ). Nu steh ich da und grüble, wie ich aus dieser Nummer raus komme Durch die gemischte Umgebung (W2k & W2k3) scheidet die Lösung über die eingeschränkten Gruppen aus, da bei den beiden Betriebssystemen unterschiedliche Benutzer das Recht zur lokalen Anmeldung haben (z.B. IUSR.... unter W2k). Bisher ist meine einzige Idee: Startskript per GPO einbauen, in dem per NTRIGHTS die jeweiligen Benutzerrechte erteilt werden. Dabei werden die Benutzerrechte den vorhanden Einträgen hinzugefügt. Das entspräche eigentlich dem geforderten Ziel, sieht in meinen Augen allerdings "unelegant" aus. Hat hier vielleicht jemand eine bessere Idee? Vielen Dank für's Grübeln schon mal im Voraus.

Welches OS?

Mit Produkten wie "VMWare" oder "Virtuell PC" auf der Maschine funktioniert es. Ohne zusätzliche Software, die "virtuelle" PCs simuliert, klappt es nicht.

Es geht doch nichts über ein "anständiges" EDV-Admin-Frühstück -> Kippe und ein Becher schwarzer, starker Kaffee :) Und frühstücken könnte ich den ganzen Tag :D

Eine Möglichkeit wäre imho: Sichern des DCs (Systemstatusdateien) mit dem internen Backup-Programm in eine Datei ins Dateisystem. Diese Datei per Script auf den "Arcserve-Backup-Server" kopieren (in eine Freigabe) und dort einfach "wegsichern.

Ich glaube es geht bei der Frage eher darum, was man als Speicherort für die Datenbank und das Protokoll bzw. Pfad zum SYSVOL-Ordner beim Installieren eines DCs (mit dcpromo.exe)angibt. Falls ich da mit meiner Vermutung richtig liege, MS empfielt auf jeden Fall, die DB und das Protokoll auf getrennte, physikalische Festplatten anzulegen. Wenn 3 physikalische Datenträger im Server zur Verfügung stehen würden, dann würde ich das System auf dem ersten, die DB auf dem 2. und das Protokoll auf den 3. Datenträger installieren. Bei 2 physikalischen Platten System und DB auf einen Datenträger, das Protokoll auf den 2. Datenträger. Das Verzeichnis SYSVOL ist imho nicht so kritisch, dass kann man imho auf der Systemplatte im Standardpfad anlegen lassen.

Wenn er noch 10 freie Adressen im Pool findet .... sonst gibt er sich auch mit weniger zufrieden. :cool:

Net send ist eine NetBIOS-Applikation. Dafür muß die Namensauflösung für NetBIOS funktionieren -> in einem Subnetz ohne WINS-Server klappt das per Broadcast. In 2 Subnetzen durch einen Router getrennt, müßte imho ein WINS-Server im Netz stehen, der die NetBIOS-Namen auflösen kann. Zur Event ID 13508 spukt die Knowledge Base von MS folgendes aus: http://support.microsoft.com/default.aspx?scid=kb;en-us;285923 NtFrs 13508 Description: The File Replication Service is having trouble enabling replication from (computername) to (computername) for c:\winnt\sysvol\domain; retrying. To resolve this issue, synchronize the computers with the domain controller clock time. Das sieht dann nach einem "Zeit-Problem" zwischen den beiden DCs aus.

Ich schätze mal, die CMD liegt im falschen Ordner ... der komplette Pfad wäre recht hilfreich. Ich gehe mal davon aus, dass du das Script mal mit nem Doppelklick gestartet und getestet hast.

Winsock-Proxy ist für SSH (Port 22) konfiguriert? Winsock-Proxy-Client oder der MS ISA-Client ist auf dem Arbeitsplatzrechner installiert? Falls es dann immer noch nicht funktioniert: Wspcfg.ini ist im Ordner von Putty und hat die passenden Einträge?

Ohne ICMP ist imho nichts mit 'nem erfolgreichen Ping. Wenn der Port 22 (ausgehend) freigeschaltet ist, würde ich sagen, es müßte mit einem SSH-Connect funktionieren.

Müßte doch einfach mit einem Anmeldeskript gehen. Oder habe ich da was falsch verstanden?

Von der WS in die GPO's der OU "Domain Controllers" geschaut? Evtl. hilft es da, die Einstellungen für "Lokale Anmeldung erlauben" und "Lokale Anmeldung verweigern" zu überprüfen, bzw. zu ändern.

zu 2. Wenn Deine Netzwerkkarte nur für die Verbindung zum TDSL-Modem genutzt wird, kannst Du auch die Bindung des TCP/IP-Protokolls zur NIC wegnehmen (Haken vor "Internetprotokoll (TCP/IP)" entfernen). Für die Kommunikation zwischen NIC und T-DSL-Modem reicht das "T-DSL-Protocol (T-Online)" vollkommen aus.