IThome

Genau, sonst raten wir nur noch ... :)

Ich denke, er meint, der User ist nicht deaktiviert (was man an dem roten Symbol sofort sehen kann) . Wenn er gesperrt ist, sieht man das nicht gleich. Ist auch nur zur Sicherheit gewesen, Windows meldet sowas nicht einfach so ...

Hast Du in den Eigenschaften des Benutzerkontos unter Konto geschaut, ob da "Konto ist gesperrt" angehakt ist ?

Öhm, übertragen ? Einfach nur replizieren lassen ... Oder was meinst Du ?

Am Server mit FSMGMT.MSC - Geöffnete Dateien ... Vom Client aus (entsprechende Gruppenzugehörigkeit vorausgesetzt) mit einer benutzerdefinierten MMC-Konsole oder wie am Server direkt mit einer RDP-Sitzung ...

Na dann schauen wir mal ... :) , Du hast dieses GPO auf die Notebooks angewendet ?

Versuch es mal mit dem Benutzerrecht "Laden und Entfernen von Gerätetreibern" ... Im Assistenten ist diese Möglichkeit allerdings ausgegraut ...

Hm, ich wüsste jetzt nicht, wie das ohne Zugehörigkeit zu einer bestimmten Gruppe möglich sein soll, ausser vielleicht, ihnen das Laden und Entfernen von Gerätetreibern zu erlauben

Meinst Du Computerkonfiguration - Windowseinstellungen - Sicherheitseinstellungen - Lokale Richtlinien - Sicherheitsoptionen - "Geräte: Anwendern das Installieren von Druckertreibern erlauben" ? Da geht es aber nicht um lokale Drucker ...

Hui, 10 Stunden, das mach mal beim Kunden ... :D

Sieht gut aus ...

Gehen wir mal davon aus, dass es für diese Clients eine eigene Zone gibt (sie würden sich sonst nicht registrieren, zumindest nicht im WLAN). Ist ein Client im WLAN, registriert er sich in der Zone INTERN.PELLETSWORLD.COM. Ich gehe auch davon aus, dass dieser Client den Verbindungssuffix dieses Netzwerkes vom dortigen DHCP-Server übermittelt bekommt. Fragt jetzt einer der LAN-Clients diesen WLAN-Client nur mit dem Hostnamen an, wird an diesen Namen der oder die Suffixe des LAN-Clients angehängt und an den DNS-Server übermittelt. Dieser schaut in die entsprechende Zone (INTERN.FIRMA.LOCAL) und findet ihn dort nicht (er ist in der anderen Zone registriert). Wird allerdings ein FQDN des WLAN-Clients angegeben, wird kein Suffix vom LAN-Client angehängt, der DNS-Server sucht in der richtigen Zone und der Name kann aufgelöst werden. Wechselt der WLAN-Client jetzt in das LAN, bezieht über DHCP dort den LAN-Verbindungssuffix und ist in seiner Konfiguration der Haken gesetzt, dass er auch Verbindungssuffixe registriert, dann wird sein Name in der LAN-Zone (durch den Verbindungssuffix) und in der WLAN-Zone (durch den primären Suffix) registriert. Wird jetzt von einem LAN-Client dieser Name nur durch Angabe des Hostnamens aufgelöst, wird wieder der Suffix des LAN-Clients angehängt. Der DNS-Server sucht in der Zone der LAN-Clients und da der WLAN-Client sich dort durch den Verbindungssuffix registrieren konnte, kann er aufgelöst werden. Versucht das Gleiche jetzt ein anderer WLAN-Client, der sich zur Zeit im LAN aufhält, auch nur mit dem Hostnamen aufzulösen, dann hängt er zuerst seinen primären Suffix an den Namen. Der DNS-Server schaut also in die WLAN-Zone und findet dort den WLAN-Host, allerdings mit einer Adresse aus dem LAN. Und wenn das jetzt auch wieder falsch ist, dann gehe ich ins Bett :D

Ich frage mich, wie die WLAN-Clients sich am DNS registrieren. Existiert für diese Clients eine eigene Forward Lookupzone ?

Ähm, ich hatte das, glaube ich, falsch verstanden :rolleyes: . Das interne Netzwerk befindet sich hinter den IPCOPs, das WLAN befindet sich vor den IPCOPS, richtig ? Wenn ja, worauf sollen die WLAN-Clients zugreifen ?

Was bekommst Du als Antwort, wenn Du NSLOOKUP <Hostname Client im WLAN> durchführst ? Was bekommst Du als Antwort, wenn NSLOOKUP <FQDN Client WLAN> durchführst ? Auch wenn NSLOOKUP-Abfragen nicht im DNS-Cache gespeichert werden, lösche den Cache vor dem Test mit IPCONFIG /FLUSHDNS. Poste auch mal IPCONFIG /ALL eines LAN-Clients und eines WLAN-Clients. Werden die WLAN-Clients mal im LAN und mal im WAN betrieben ? existieren 2 Reverse Loookup-Zonen ? Existieren für Hosts mehrere Host-Einträge mit unterschiedlichen IP-Adressen (also für HOSTX ein Eintrag mit der Adresse aus dem LAN und HOSTX mit der Adresse aus dem WLAN) ?

Deswegen sage ich ja, erst die Empfängerrichtlinie, dann der POP-Connector ... Die Richtlinie muss erstmal angewendet werden ...

Was machen die IPCOPS, werden die nur von innen angesprochen ? Oder schicken die auch nach innen ?

Nur mit Routen kommste dann ja nicht weit, da der innere Router per Default nichts nach innen lässt. Inwiefern verbinden sich die Geräte, die sich in dem Zwischennetz verbinden, in das innere LAN ? Ich benutze sowas auch, der äussere Router ist der Zugangsrouter, der innere (meistens eine Firebox) übernimmt den VPN-Server. Der äussere Router hat die externe Schnittstelle der Firebox entweder als DMZ-Host eingetragen oder er macht eine gezielte Portweiterleitung. Geht es nur um einen weiteren Schutz, müssen keine Routen erzeugt werden, entsprechende Default Gateway Einträge reichen (die Clients die innere Schnittstelle der Firebox, die Firebox die innere Schnittstelle des Zugangsrouters) ...

Die machen beide NAT gell ?

Konfiguriere die Empfängerrichtlinie wie beschrieben, entferne die alten POP-Einträge. Warte, bis die User die richtigen Adressen zugewiesen bekommen haben und konfiguriere dann die POP-Einträge neu. Du kannst für die Konfiguration des Exchange für eingehende und ausgehende Mails auch den Internet Mail-Assistenten im Exchange System Manager machen lassen ...

Hinter der Fritzbox mit einer anderen Range ? Als Trenner zum eigentlichen LAN ?

Entferne die Einträge im POP-Connector und erstelle sie neu ...

Nein, Option 001 steht nicht zur Verfügung (in den DHCP-Standardoptionen) ...

Und vergiss nicht bei der Prüfung etwas anzuklicken ... ;) :D Spass beiseite, viel Erfolg am Montag ... :)

Schau mal hier ... : www.SBSPraxis.de, Konfigurieren der Empfängerrichtlinie für den SBS 2003 Exchange Server :