Annette

Aaaaahhhhhh, wenn ich nur nicht (dunkel)blond wär' :D :D

Der Fön hatte gar nicht gelogen (Otto), die Rechner mit dem Bindestrich waren hinter einer Firewall :o

:rolleyes:

das funst dann nicht mit dem Adminpack von der W2k CD, muss ich den von Server2003 nehmen

Yep .... :)

Buenas Noches Hombres :)

Habe da ein kleines Problem. Ich bin gerade dabei, das VBS-Script vom MS-Scripting Center zum Ändern lokaler Kennwörter auf MemberComputern in einer AD-Domäne für meine Zwecke anzupassen. Das läuft soweit auch :cool:

Nun gibt es aber Computer mit einem Bindestrich im Namen, z.B.

WS-001

oder ähnlich. Dabei meldet dann WSH den Fehler:

Skript: Skriptnamen

Zeile: 14

Zeile: 1

Fehler: Der Netzwerkpfad wurde nicht gefunden

Code: 80070035

Quelle: (null)

Bei den Rechnern ohne Bidnestrich im Namen klappt es

So sieht der relevante Part des Skripts aus:

strComputer = "test-w2kprof"

Set objUser = GetObject("WinNT://" & strComputer & "/Administrator, user")

objUser.SetPassword "P@ssw0rd>"

objUser.SetInfo

Ich bin nicht die Helding des Skriptierens, wer weiss, wie man die Zeile korrigieren muss , natürlich ohne die Rechner umzubenennen.

Eine stateful Firewall, und ich kenne eigentlich keine halbwegs aktuelle, die es nicht wäre, öffnet die eingehenden Ports auf nach aussen gesendete Abfragen automatisch, weil sie sozusagen drauf wartet.

Ein Browser ist so konfiguriert, dass er als Zielport 80 wählt, oder eben einen anderen angegebenen, hier 9090. Als Absenderport wählt er irgendeinen auf dem Client freien Port > 1023, auf den er die Antwortpakete vom HTTP-Server will. Eine stateful Firewall, leitet (bei entsprechender Rule für 9090 in dem Fall!!!) das Paket weiter und wartet auf die eingehende Antwort auf dem Port aussen, den der Client als Absendeport angegeben hat. Dieser wird dann nur für das eingehende Paket und die anderen, die da noch folgen, solange die TCP-Verbindung nicht wieder abgebaut ist (F-Flag gesetzt und bestätigt), dynamisch geöffnet.

Also: keine spezielle eingehende Rule nötig ;)

Ja, das Boardleben ist hart am 01. April.... :D :D :D

Microsoft hat gestern bekanntgegeben, aufgrund der wachsenden Anforderungen im Security Bereich in der Industrie müssen alle MCSE unter NT 4.0 und 2000 bis spätestens zum 31.12.2004 das Upgrade auf den MCSE 2003 durchgeführt haben, da sie sonst den Zertifizierungsstatus verlieren. Upgrades mit 70-292 und 70-296 sind nach dem 31.12.2004 nicht mehr möglich, es müssen dann die Einzelprüfungen abgelegt werden, und es muss dan mind. eine Security Prüfung von 2003 darunter sein :(

Näheres auf der MS-Cert Hompage.

Annette

Hm, was für eine Fehlermeldung kommt denn da genau?

Und schau doch mal in der Computerverwaltung in die Datenträgerverwaltung. Da sollten eigentlich zwei Disks auftauchen und eine ist die Nummer 0, die andere sollte 1 haben. Ich nehme an, du weisst, welche welche ist, von der Größe her oder Hersteller oder so.

Nun solltest du ncoh in der boot.ini auf C: nachschauen, was da unter Default = drin steht. Kannst ja auch mal den Inhalt und das mit den Disks hier posten, wenn du dir nicht sicher bist

Gruß

Aber du siehst die Verzeichnisse im DFS, wenn du dich mit dem Client connectest?

Original geschrieben von kuerbis

ein beispiel: du hast bereits 100 clientrechner die dú in einen neu aufgesetzten domain controller haengen willst. das heisst jeden einzelnen rechner darfst du da manuell reinhaengen. dauert tierisch lange vorallem wenn die rechner überall verteilt sind.

die arbeit ist zwar nicht schwierig aber immens zeitaufwendig vorallem wenn du von 1000 clients strichst. wenn du 50 am tag schaffst bist du sehr gut ;P

Deshalb macht man das auch nicht so, dafür gibt es Tools, z.B. "netdom.exe /join", mit ein paar Zeilen Skript braucht man nicht mal eine Stunde für 1000 Clients ;)

Mir fällt da derzeit nur ein Szenario ein, in dem der "illegale" Adressbereich für eine Zone auf einem internen DNS-Server eingetragen ist und zufällig das Zielnetz im Internet die gleiche Netzwerkadresse hat. Dann wird der interne DNS-Server die DNS-Anfrage zwar weiterleiten, bekommt aber von einem externen DNS-Server eine IP-Adresse als Zieladresse, die für eine Zone des internen Netzes gilt. Diese Adresse wird falsch geroutet, und die Anfrage schlägt fehl.

Genau da liegt der Hund begraben, aber nur da. Es gibt sonst weder Sicherheitsbedenken oder andere "Unannehmlichkeiten". Beim Einsatz von VPN und Adressvergabe per DHCP durch den RAS-Server kann es natürlich weitere Verbindungsschwierigkeiten geben. Aber ansonsten....

Hallo speedbil,

Wie ich gemerkt habe, spielt es keine Rolle, wo der ordner $oem$ liegt, ob inerhalb des I386 Ordner, oder auf gleicher Ebene.

leider stimmt da was noch nicht bei dir, ich weiß aber nicht was. Es ist definitiv so, wie grizzly999 es sagte, mit der Anordnung des $OEM$ Ordners, auch Microsoft lässt da keinen Zweifel aufkommen (wenngleich auch in der KB irgendwo diesbezüglich einTypo drin ist). Außerdem musstest du ja auch erst alles löschen und neu machen, dass sich da überhaupt was tat, auch das ist ungewöhnlich. Also irgenwo steckt noch der Wurm drin, aber einer, mit dem du vermutlich erst mal leben kannst ;)

Die gekürzten Dateinamen kannst du mit der Datei $$rename.txt umbenennen. Die Datei muss ins $OEM$\$$ Verzeichnis. Siehe auch hier: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/deployguide/acicb_ui_wbgu.asp

Der Befehl, wobei hinter dem lpt1 noch der Doppelpunkt fehlt, mappt nur das "Netzlaufwerk" auf den LPT-Port 1, aber keinen Drucker. Wenn du im Anmeldeskript einen Drucker mappen willst, brauchst du einen anderen Befehl. Die Boardsuche gibt da Aufschluss, z.B. hier http://www.mcseboard.de/showthread.php?s=&threadid=10244

Wenn du ein Backup von C: hast, mit Sicherung der Registry, die immer mit extra Häkchen zu machen war, oder Notfalldiskette, dann kannst du doch den DC wieder herstellen

Nein, ADMT migriert keine lokalen Benutzerprofile, verständlicherweise. Ein Domänenbenutzer kann sich auf hunderten Rechnern angemeldet haben. Man stelle sich eine Domäne mit 20.000 Usern und 20.000 Clientcopmutern vor. ADMT kann nicht alle Rechner der Domäne durchsuchen und dort alle lokalen Profile von allen Domänenbenutzern migrieren.

Es gibt frei herunterzuladende Resource Kit Tools, aber das moveuser gehört leider nicht dazu: http://www.microsoft.com/windows2000/techinfo/reskit/tools/default.asp

Die Server wurden am Hauptstandort installiert und dann zu den Standorten gebracht.

Sind die neuen Serverobjekte an allen Standorten in AD -Standort-und-Dienste in die richtigen Standorte verschoben worden, sofern sie nicht schon drin waren?

DNS-Auflösung der Servernamen funktionieren, auch wenn die DNS-Zonen teilweise unterschiedliche Inhalte haben

Also damit solltest du anfangen. Die sollten überall schon aktuelle Infos enthalten und nich überall unterschiedlich sein. Zur Not die DNS-Struktur bei "Wenig-Betrieb" löschen und neu hochziehen.

Dann Replikation anstoßen. Aus Fehler Kontrollieren

Ja, so gut die grünen MOT von MSPress sind, so schlecht sind teils die giftgrünen Prüfungsvorbereitungsbücher von MSPress. Es haben alle diese Bücher fehler drin, und ich kenne die aktuellen nicht, aber bei den etwas älteren war die Fehlerkorrektur bald so dick wie das halbe Buch (naja, übertieben, aber es waren heftig viele)

Völk oder Föckeler sind da die bessere Wahl

Ja: entweder man benutzt das ADMT, um Benutzer in die neue Domäne zu kopieren, dabei können servergespeicherte Profile mit kopiert weren (keine lokalen Profile), oder aus dem W2k Resource Kit hinterher das Tool moveuser.exe einsetzen

Wenn man das original lokale Admin-Kennwort kennt UND die XP CD hat, schon. Ansonsten nur Möglicheiten, die hier im Board nicht unterstützt werden

Es gibt schon einen Unterschied. Mit der Startdiskette starte ich den Installationsvorgang, anstelle des CD-Boots zur Installation.

Mit der Bootdiskette starte ich das/ein Betriebssystem

Wenn man im Anmeldebilschrim auf Opionen klickt, muss man ein drittes Eingabefeld bekommen. Dort kann man statt der Domäne den lokalen Computernamen angeben und sich als lokaler Admin anmelden, vorausgesetzt man kennt dessen Kennwort

Die lokalen Richtlinien auf dem XP selber anpassen, mit gpedit.msc

Windows 2000 hat die Richtlinie nicht, man könnte sie dazu basteln, aber für einen Rechner doch lieber lokal schnell einrichten

Also, ich habe das jetzt mal geprüft, mit einem XP SP1 in einer W2k Domain. Wie erwartet, die GPO sind alle XP-like vorhanden, ist ja auch logisch, sind ja die XP adm-Files drauf. Das spielt es keine Rolle, ob der DC W2k oder W2k3 ist.

Nur so zur SIcherheit: das war auch bestimmt ein Screenshot von nem XP, nicht von einem W2k, um arme unbescholtene Ladies zu testen ;) :D

Geht denn ein ping auf den Computernamen, also wenn der Zielrechner (den, den du runterfahren willst) PC001 hieße:

ping PC001

Wenn ja, dann sollte es so gehen:

shutdown \\PC001 -r -m

Was für ein OS hat der Client?

Na, das sieht aber seltsam aus, da steht was komplett anderes drin als bei mir. Unter unterhalb von System fehlen 7 GPO-Ordner. Sieht genauso aus wie bei 2000. Kann mir allerdings nicht vorstellen, dass das von der W2k Domaäne kommt. Ich checke das mal.

Hi magicx,

Okay, machen wir dich den Mitschülern eins voraus ;)

Das geht nicht mit Gruppenrichtlinien, oder zumindest nur sehr indirekt. Es gibt Tools, die das können, z.B. Profilemaker (Löhnsoft) oder Newprof von Microsoft. Die können das über ein Anmeldeskript machen, welches man wiederum in einer Gruppenrichtlinie. Aber direkt in der GPO :suspect: Das sollen sie dir zeigen, würde mich auch interessieren.