IThome

Zentrales Profil heisst Default User im NETLOGON, welches dann beim Abmelden als servergespeichertes Profil irgendwohin übertragen wird ? Oder meinst Du mit dem zentralen Profil das servergespeicherte Profil an sich ?

Entferne mal die Richtlinie, dass die zwischengespeicherten Profile gelöscht werden, melde Dich mit einem Benutzer an (besser 2 mal die An- und Abmeldung durchführen, um sicherzustellen, dass die lokalen Profile nicht gelöscht werden), lösche den Inhalt des Serverprofils und lass es wieder zurückschreiben. Wie hast Du bei dem Serverumzug die Profile übertragen ?

Entweder mit Filtern auf dem Router oder Du stellst die Windows-Firewall mit geeigneten Ausnahmen entsprechend ein ...

Domänencomputer kannst Du nehmen, wenn Du Software via Verteilungsrichtlinie vor der Anmeldung installierst. Wenn aber ein Benutzer die Software installiert, dann muss auch ein Benutzer oder eine Benutzergruppe berechtigt werden. Die Gruppe "Jeder" reicht da nicht aus, zumindest nicht, wenn das Gastkonto nicht aktiv ist (es ist per Default nicht aktiv und das sollte auch so bleiben). Ist das Kennwort des lokalen Administrators gleich dem Kennwort eines Administrators der Domäne (Benutzername natürlich auch), dann kommt keine Passwortabfrage. Ich denke allerdings nicht, dass das gewünscht ist ...

Aber nur, wenn die jetzige Adressierung 192.168.0.0/24 ist ...

Du kannst sie nicht finden oder sie ist nicht eingestellt ?

Das ICS ist nicht wirklich konfigurierbar im Gegensatz zum RRAS ... vorgegebene Adressbereiche (die festen internen Adressen müssen alle angepasst werden), NAT nur sehr eingeschränkt einstellbar, keine Konsole. Der einzige Vorteil ist der, dass es einfach mit einem Klick zu konfigurieren ist (viel mehr kann man ja auch nicht machen). Wozu ICS, wenn ein vollständig konfigurierbarer Router verfügbar ist ...

Doch nicht auf einem Server und schon gar nicht auf einem DC ... Wenn schon auf dem Server, dann mit RRAS als NAT-Router inklusiv Firewall ...

Lösche mal das Computerobjekt auf dem DC, lade Dir NEWSID runter, führe es auf dem PC aus und joine erneut ... Wenn das nicht klappt, dann installiere ihn neu ...

Was meinst Du damit ? Ich sprach nicht von DHCP, sondern von einer statischen Range des RRAS. Passiert das eigentlich erst, seit der Computer WLAN benutzt oder ist es mit einem kabelgebundenem LAN noch nie probiert worden (was ich persönlich als erstes testen würde) ?

Hm, ich habe mal einen Drucker konfigurieren müssen (ein Canon war das glaube ich), der hat sich ebenso verhalten. In der Konfiguration dieses Druckers konnte man Filter setzen, welche IP zugreifen darf. Demzufolge müsste dann ja ein Client, der temporär die Adresse des Servers bekommt, der den Drucker nicht erreicht, die gleichen Probleme haben. Und der Server müsste dann mit einer jetzt funktionierenden Adresse den Drucker erreichen können ...

Wenn dort "Zielhost nicht erreichbar" steht, dann wird keine Route zum Ziel gefunden (kein Default Gateway z.B.). Gibt es wenigstens eine Default Route, dann kommt sowas wie "Zeitüberschreitung der Anforderung". Schau Dir mal die Routingtabelle des fehlerhaften Clients an. Ich gehe auch von einem eingesetzten Proxy auf den betroffenen Clients aus, die so kein Default Gateway benötigen ...

Eingeschränkte Gruppen sind immer ersetzend ... Du kannst Mitgliedschaften auch via Script und dem NET-Befehl einstellen ...

Hm, "testwiki", "testwiki2", was denn nun ? (&(objectCategory=user)(memberOf=CN=testwiki2,OU=test,DC=xxxxx,DC=local)) oder (&(objectCategory=user)(memberOf=CN=testwiki,OU=test,DC=xxxxx,DC=local))

Aha, "Magic Number" (habe ich vorher noch nie gehört, aber jetzt nachgelesen :D). Hm, wenn der Client sich im Netz des DHCP-Servers befindet, was interessiert das den Relay Agent, der ja eigentlich auf dem anderen Interface konfiguriert ist ...

Das sollte doch eigentlich CN=Users heissen, wenn sich die Gruppe testwiki in diesem Container befindet. Wo befindet sich die Gruppe ?

Sind die Uhrzeiten synchron ? Gibst Du den gesamten DNS-Domänennamen und nicht nur den NetBIOS-Domänennamen beim Joinen an ? Existiert schon ein Computerobjekt mit dem Namen des neuen Clients ? Ist der Rechner geklont worden ?

Du hast BROWMON auf dem nicht funktionierenden Server durchgeführt ? Du kannst den Stack mal zurücksetzen mit NETSH INT IP RESET C:\RESETLOG.TXT NETSH WINSOCK RESET CATALOG Danach Server neu starten und die IP-Adresse neu konfigurieren. Was ergibt BROWMON denn auf einem funktionierenden Rechner ?

Wenn er sich nur an einem Rechner anmelden soll und an keinem anderen, dann mit Limitlogin z.B. Limiting a user's concurrent connections in Windows Server 2003, Windows 2000, and Windows NT 4.0 Hier im Board findet Du auch einiges zu diesem Thema. Welchen Grund hat es, dass ein User sich nur einmal anmelden darf ?

Ist auf dem DC NetBIOS über TCP/IP aktiv ? Läuft dort der Computerbrowserdienst ? Eigentlich gewinnt ein Server eine Wahl zum Masterbrowser und nicht das Clientbetriebssystem. Hast Du eigentlich mehrere Subnetze ? Ich denke nicht, dass WINS der Auslöser ist, denn die Computer bauen untereinander noch nicht mal eine Browsing-Struktur auf ...

In der Terminaldienstekonfiguration muss der entsprechende Benutzer im RDP-TCP Objekt berechtigt werden, wenn der Server sich im Remoteverwaltungsmodus befindet. Dieser Modus ist allerdings, wie der Name schon sagt, für die Verwaltung gedacht und nichts für einen User ...

Wie nur einmal , insgesamt nur einmal irgendwo oder nur an einem Rechner und nicht gleichzeitig an einem anderen ?

Also ist das Notebook mit der 99er Adresse in dem physikalischen Netzwerk, in dem es KEINEN DHCP-Server gibt, aber einen Cisco Router, der als Relay Agent mit der Adresse des DHCP-Servers konfiguriert ist ?

Wer ist denn der Hauptsuchdienstcomputer ?

Der lokale DHCP-Server meldet sich und merkt, dass er die Range nicht hat und verweigert. Solch einen Vorgang (Rechner war woanders und hat dort seine IP bekommen) solltest Du mal sniffen, dann sollte das Verhalten klar werden. Das scheint ja nur zu passieren, wenn jemand extern an einem anderen DHCP-Server angeschlossen war und der Client intern versucht, die fremde Adresse zu erneuern ...