andrew

von einem anderen Forum (Informatikboard.ch): ----------------------------------------------- ich befürchte, dass Du wohl recht hast. Wenn man eine IPSec VPN Richtlinie erstellt, sollte man eben das local Subnetz und das remote Subnetz angeben können, weil man genau wie Du schreibst, definieren muss, welches lokale Netz soll mit welchem remote Netz "verbunden" werden. Genau das geht bei mir nicht, sprich, die Zywall 2 speichert einfach die Angaben beim Punkt "Remote Adress" nicht, egal, ob ich hier eine Singel Adresse eingebe, eine Subnetz Adresse aus welchen privaten Bereich auch immer, einen Range angebe, diese Zywall 2, welche ich da besitze, speichert genau diese Information NICHT !!! Naja, jetzt weiss ich auch, warum diese und auch ein andere Zyxel Gerät meines letzten Arbeitgebers mir diese zwei Teile quasi "geschenkt" haben. Der Grund ist wohl einfach: Die waren irgendwo vor Ort bei einem Kunden im Einsatz und hatten dann plötzlich einen Schuss, voilà ...das würde auch diese Problematik bei der Einrichtung des VPN Tunnels auf dieser Zywall 2 sprechen .. Naja....Dann löse ich halt das Problem auf eine andere Art und Weise... Bin mir noch am Überlegen, ob ich es mit Routing und RAS versuchen soll (Wählen bei bedarf >> VPN Verbindung von A nach B), oder ob ich mir vorab eine Zywall 2 bei Zyxel bestellen soll (Wäre eine Menge Geld, Minimum 250.-) oder was ich auch machen könnte ist, die Zywall 2 durch eine zweite Linux Firewall ersetzen (Endian, ist gratis)...dazu bräuchte ich aber einen alten PC, den hätte ich auch, benutze ich aber für andere Zwecke ..sprich, habe einen PC zu wenig ;( ... Naja, für Routing und RAS bräuhte ich auch noch was, nämlich Minimum eine zweite Netzwerkkarte, ansonsten haben die Routing und RAS Server nichts zu routen (von wo nach wo auch, wenn nur ein Netzwerk Interface :-)) Ist wohl die billigste Variante, mal gucken hehe ... Danke erst einmal, aber ist so, wie ich es vermutet habe, die Zywall 2 hat wohl einen Schuss!! --------------------------------------------------------------------

So: Initiere ich den Tunnel von der Linux Seite her, sage, bau den Tunnel auf, gelang mir dies auch, nur kann ich zurzeit folgende IPs NICHT anpingen: > GW Interface, also die interne LAN Adresse der Zywall 2, diese ist immer noch 192.168.5.1 > auch den Server 2003 dahinter ist nicht pingbar, der hat nämlich die IP 192.168.5.5 Merkwürdiges Phänomen: > am ersten Tag, als ich diese Idee hatte, nahm ich meine Zywall 2 Appliances und dachte, gut, resete doch mal zuerst diese Zywall 2. Das tat ich auch und richtete genau so wie oben sowohl die VPN Einstellungen auf der Zywall 2 ein wie auch die VPN Einstellungen gemäss obiger Darstellung auf der Linux Firewall. Das Interessante, ich konnte den Tunnel wie gewünscht aufbauen Und: > ich konnte die Zywall 2 internet GW Adresse 192.168.5.1 pingen > ich konnte ebenfalls die IP Adresse des 2003 Servers hintendran pingen, 192.168.5.5 Als ich dann aber merkte, dass ich von der DMZ aus, also von der IP 192.168.5.5 zwar jede erdenkliche IP pingen konnte (die IP jedes Routers), jedoch keine einzige IP des LANs (die beiden DCs im LAN konnte ich beispeilsweise nicht pingen), dachte ich mir, gut, ich spiele da ein wenig mit Routen herum, erstellte auf der Linux Routen ..jedoch ging dann plötzlich noch weniger ... Tja, dann dekativierte ich zuerst die erstellten Routen auf der Linux Firewall wieder und schlussendlich habe ich diese gelöscht. Tja, nun bin ich nicht einmal mehr in der Lage, vom grünen Netz, also vom LAN her die beiden IPs > 192.168.5.1 (ist die interne IP der Zywall 2) > noch die IP des Servers, welcher ebenfalls physisch an den LAN Schnittstellen der Zywall 2 angeschlossen ist, pingen Langer Rede kurzer Sinn: > ich konnte anfangs, nachdem ich die Zywall 2 resetet habe, die oben genannten VPN Einstellungen vornehmen und voilà, ich konnte vom LAN aus (192.168.3.0) auch die IPs > 192.168.5.1 > 192.168.5.5 pingen Jetz, nachdem ich die Zywall 2 schon hundert mal resetet habe, funktioniert die plötzlich nicht mehr, sprich, der Tunnel steht zwar, das ist aber auch gleich alles. Soweit ich es beurteilen kann, fliesst kein Datenverkehr durch den VPN Tunnel, wieso nicht? Die Verschlüsselungen habe ich schon fast alle durchgetestet, also anstatt 3DES AES (habe herausgefunden, dass die Zywall 2 "nur" die AES 128 Bit Verschlüsselung untersützt, bei AES 256 Bit baut Sie keinen Tunnel auf), habe die IKE Integrität und die ESP Integrität (Verschlüsselungs Algorithymus) geändert und konnte zwar je nach je auch einen Tunnel aufbauen, aber eben, die IPs hinter der Zywall 2 erreiche ich ping mässig nicht mehr.... Hat die Zywall 2 einen Schuss? Habe ich was falsches konfiguriert? Noch was zur Zywall2: Das komische ist, wenn ich das Remote Netz angeben will, egal, ob ich hier im Pull Down Menu sage, Subnetz, Range oder Singel Adress, egal, in welchem privaten Adressbereich sich hier die ANgaben auch immer befinden mögen, die Zywall 2 speichert genau diesen Eintrag nie ab .... Gehe ich auf Apply (übernehmen im Menü, dann ein zweites mal auf apply, sehe ich in der VPN Übersicht zwar die erstellte VPN Regel, aber bei Remote Netzwerk steht dann immer : N/A) Tja, nichts destotrotz kann ich trotz diesem "Bug" jeweils einen VPN Tunnel aufbauen, aber eben, die IPS hinten dran, hinter der Zywall 2 respktive, wenn ich von der DMZ aus die IPS im LAN pingen will, geht da nix ... wo Fehler? *pfffffffffffffff* chappe ah, bei der Kälte ... Danke für die zahlreichen Infos von euch, komme nicht weiter ... -------------------------------------------------------------------------------- Grüsse Andrew - MCP 70- 210 & 70- 620 - man kann nicht alles Wissen, aber wenn man weiss wo nachschauen, ist die Lösung nicht mehr weit

Nun zur Linux VPN KOnfiguration: -------------------------------------- LInux VPN Konfiguration: > Netzwerkonfig: lokales Subnetz: 192.168.3.0 mit Subnetzmaske 255.255.255.0 eingestellt > lokale ID = 192.168.4.1 (habe dieses Interface gewählt, weil ich dachte, ich müsses dieses angeben) > Gegenstelle/ Host IP: 192.168.4.254 > Subnetz der Gegenstelle: 192.168.5.0 > entfernte ID: 192.168.4.254 > Pre Shared Key = Gugus123$ ---------------- Phase 1 ---------------- > IKE Tunnel Settings (Phase 1): > IKE Verschlüsselung 3DES > IKE Integrität (SHA oder MD5 auswählbar, hier MD5 angegeben) > IKE Lebensdauer = 1 Stunde) > IKE Gruppen Typ = DH Gruppe 2 (1024 Bit) Tiefer geht nicht, die Endian Linux Firewall beginnt hier, ab DH Gruppe 2 und geht bis DH Gruppe 18 (8192 Bit Verschlüsselung) Bringt mir aber wenig, da der andere VPN Gateway, in meinem Fall die Zywall 2 nur DH 1 und DH 2 Gruppe unterstützt --------------- Phase 2 --------------- > IPSec Settings (Phase2) > ESP Verschlüsselung: Encryption Algorithm = 3DES > Authentication Algorithm = SHA1 (ESP Integrität, hier ist SHA1 und MD5 auswählbar, ich habe SHA1 ausgewählt) > ESP Schlüssel Lebensdauer:8 Stunden > Perfect Forward Secrey (PFS) = Yes (bei der Linux Firewall kann man hier nur sagen, yes oder no, mehr nicht)

Grundgedanke: Möchte meinen oder meine Server, welche ich in der DMZ habe, via VPN Tunnel mit dem LAN auf sichere Art und Weise kommunizieren lassen! Wie sieht mein Netz aus (vom Internet aus Richtung DMZ sehend) ----------------------------------- - Internet - dahinter eine Fritz Box mit DSL verbunden, macht auch WLAN. Fritz Box ist als Router konfiguriert. Konfig: > WAN = öffentliche IP von Provider > LAN = 192.168.2.254 ----------------------------------- - dahinter eine Linux Firewall mit drei eingebauten Netzwerkkarten Konfig: > WAN Schnittstelle: (rot) = 192.168.2.1 (ist also physisch mit der LAN Schnittstelle der Fritzbox verbunden >> 192.168.2.254) > LAN Interface: 192.168.3.1 (grün) (im 192.168.3.0 /24 Netz stehen zwei DCs mit Windows Server 2003 und ein Client mit Windows 7 --> Domäne) > DMZ Interface: 192.168.4.1 (orange) Da steht zurzeit ein Server (Arbeitsgruppe) mit VM Server installiert ----------------------------------- -dahinter habe ich eine Zywall 2 (eine alte, nicht mehr supportete Zywall 2, ich weiss) im Einsatz. Dachte, anstatt, dass die da auf meinem Tisch verstaubt, benutze ich diese und richte einen VPN Tunnen auf, einen VPN Tunnel zwischen DMZ (die DMZ wäre dann hinter der Zywall 2) und und LAN. Dies wäre zumindest das Ziel, weil ich möchte ja vom LAN aus die Netzwerkgeräte von der DMZ erreichen können respektive umgekehrt. von LAN > DMZ wäre eine Kommunikation mit den Netzwerkgeräten in der DMZ möglich, da die Linux Firewall per default dies so zulässt (jeden Datenverkehr, von any to DMZ) Umgekehrt verständlicherweise nicht, da es ja nicht der Sinn der Sache wäre, von der DMZ jegliche Kommunikation einfach mit dem LAN zuzulassen. Soweit kann ich noch alles nachvollziehen .. -------------------------------------------------------- - hinter der Linux Firwall befindet sich also neu auch die Zywall 2 Firewall. Konfig: > WAN Schnittstelle = 192.168.4.254 > 192.168.4.1 (ist physisch mit einem Netzwerkabel mit dem DMZ Interface 192.168.4.1 der Linux Firewall verbunden) > LAN Schnittstelle der Zywall 2: 192.168.5.1 (DMZ Netz ist also 192.168.5.0 /24) VPN Konfiguration der Zywall 2: > Netzwerkonfig: Local Network = Subnetz der DMZ gewählt, 192.168.5.0 mit Subnetzmaske 255.255.255.0 eingestellt > Remotekonfig: Remote Network = Subnetz des grünen LANs gewählt, also 192.168.3.0 und Subnetzmaske 255.255.255.0 (also habe hier Subnetz eingestellt, im Pulldown Menü) (weil ich ja möchte, dass ich von der DMZ mich mit dem LAN kommunizieren kann) ---------------- Phase 1 ---------------- > IKE Tunnel Settings (Phase 1): > Negotiation Mode = Main Mode > Encryption Algorithm = 3DES Authentication Algorithm = MD5 > Key Group = DH2 > SA Life Time = 28800 (Seconds) > Pre Shared Key = Gugus123$ --------------- Phase 2 --------------- > IPSec Settings (Phase2) > Encapsulation Mode = Tunnel Mode > IPSec Protocol ) = ESP > Encryption Algorithm = 3DES > Authentication Algorithm = SHA1 > SA Live time = 28800 (Seconds) bei Dieser Einstellung bin ich mir auswendig aus dem Kopf nicht mehr sicher, ob hier 28800 steht) Perfect Forward Secrey (PFS) = Yes (glaube da kann ich zwei auswählen, SHA1 und SHA2, habe hier meines Wissens SHA2) So das wars mal, betreffend Zywall 2

Den Server habe ich erst gestern am Abend ans Netz gehängt und heute Morgen bereits wieder vom firmen LAN getrennt (der war nun eine Nacht IP technisch im gleichen Subnetzt wie unsesr internes LAN --> Server --> Clienets) Nun, die Probleme mit dem Outlook Archiv, die Probleme mit dem Telefonbuchzugriff --> auf Server ist eine Telefonbuchfreigabe, ungefähr so sieht dann die Verknüpfung der Benutzer aus: \\ServerXY\Freigabename\exeDatei_Programm_Telefonbuch Auf dem Server wurde ursprünglich eine Serverinstalltion des Telefonbuch Programms vorgenommen, am Schluss hat man sich an einen Client gesessen, auf den Share des Server zugegriffen und eine exe Datei ausgeührt, welche machte, dass am Schluss auf dem Client eine Verknüpfung war, mit einem UNC Pfad, welcher ungefähr so aufgebaut ist, wie ich es oben schilderte Mein Chef hat mir soeben gesagt, dass bei Ihm der Zugriff auf das Archiv File (archiv.pst, liegt in seinem Home Laufwerk) wieder verwehrt bleibe. Das Telefonbuch konnte ich heute ohne Probleme starten (die Verknüpfung auf meinem Notebook) mal schauen, wie lang es sich starten lässt, hatte ja gestern Abend alle Switches kurz stromlos gemacht, ob es was gebracht hat, wissen wir bald :-)

hello together Frage: Habe einen Server 2008 frisch aufgesetzt und IP technisch ins gleiche Subnetzt gesetzt wie unsere Server (firmen Server, produktiv) und logischerweise ist er nun auch im gleichen LAN wie die Clients aller Mitarbeiter Habe aber den Server absichtlich noch nicht in die Firmen Domäne genommen. Meiner Ansicht nacht stellt mein Vorgehen oder meine Tätigkeit keine Probleme für irgend etwas dar, seht Ihr das auch so? solange ich kein DHCP Dienst wissend aktivieren werde oder aktiviert hätte, welcher natürlich dadurch Probleme verursachen könnte, gibt es keine Erklärung, warum man dies nicht tun sollte oder darf oder? Oder habe ich da irgendwie, irgendwo eine Wissenslücke? Mir wurde in der Firma intern, ja wie soll ich sagen, ja schon fast gedroht im Sinne von: Wehe, Du hast den SBS 2008 Server in unse Firmennetz gebracht, dies würde dann all die Probleme erklären Probleme? komme ich gleich darauf zurück ... 1. Ich habe keinen SBS 2008 Server installiert, sondern einen Windows Server 2008 Standard Edition. 2. Ich habe diesen nun in der Arbeitsgruppe und noch nicht in die Domäne aufgenommen (integriert) 3. Solange ich keinen DHCP Dienst auf diesem Server aktiviere, gibt es meiner Meinung nach auch keine Probleme, sieht das Jemand hier im Forum anders als ich? Ich wüsste nicht, welche Funktion, welche Rolle eines frisch aufgesetzen 2008 Servers da nun ein Problem im Netz hervorrufen sollte? öööööhhhhhhhh.....am Kopf kratz ...eeeehhhhh....böööö... Probleme? Unser Server spuckt in der letzten Zeit ziemlich deftig. Dieser ist ein Windows Server 2003, hat folgende Rollen: (weiss nicht alle auswendig, aber bei folgenden bin ich mir sicher) - Exchange (ist bei allen Outlooks als Exchange Server hinterlegt) - DC - DNS - und - und (der oder die DHCP Funktion wird meines Wissens von einem anderen Server ausgeführt) Programmtechnisch ist auf diesem unter anderem T***tel, T***route (ist ein schweizer Telefonbuch, T***route ist ein CH Routenplaner) Dieses ist als Serverinstallation auf diesem Server eingerichtet, alle Clients habe eine T***tel Verknüpfung, welche \\Serverxy\T***\T***tel.exe (ungefähr so) aussieht. Seit kurzem haben wir das Problem, dass manche Leute das T***tel gar nicht starten können, manche können, sind dann in der Lage, ein paar Minuten lang Adressen darin zu suchen und ggf. in eine Textverarbeitungsprogramm (in einen Brief, beispielsweise) zu kopieren und ja ...bei machen gehts, bei machen nicht oder nur kurze Zeit .. bei denen wo es nicht geht, kommt dann eine Meldung im Stiele von: Fehlermdlung (der UNC Pfad) erscheint und ja.... die Share und NTFS Berechtigungen auf dem T***tel Share habe ich schon überprüft, die Benutzer habe alle Vollzugriff (oder zumindest Schreibrechte) Wir haben auch das Probleme, dass beispielsweise viele Leute im Outlook sich ein Archiv eingerichtet haben (also eine weitere .pst Datei im Outlook eingebunden haben) und die alten Mails dort hinein verschieben. Diese .pst Datei liegt dann in deren Homeverzeichnis. Nun passiert es fast jeden Tag, oft fast zur gleichen Zeit, dass Unterbrüche statt finden, das heisst, die Leute können im Outlook nicht mehr auf das Archiv File zugreifen, trennen Sie dieses Archiv File und wollen es im Outlook neu einbinden, so geht dies nicht (Fehlermeldung) Jemand eine Idee, was da herumgeistert, welches Biest sich da auf unserem Server (Netzwerk) rumgeistert? ;) Und nun zum Schluss die Argumentation von meiner Firma (vom IT Kollege). Wehe, du hast den SBS Server 2008 schon in unser Netz genommen. Siehe oben meine Argumentation (Punkt 1. und 2.) Daaaanke vielmal

Also, den genauen Typen des Routers kann ich bereits angeben: Typ = Zyxel Prestige P-660 Router

Hello together Ich habe folgendes Ziel: möchte eine VPN Verbindung in mein Firmennetzwerk aufbauen Welche Art von VPN möchte ich hierzu verwenden? ein VPN Site to Site (Einwahl von meiner Linux Firewall, indem Sie mit der WAN Schnittstelle als PPPoE sich einwählt und die iPSEC Verbindung mit der Firmenfirewall umsetzt) Leider schaffe ich dies zur Zeit nicht, weiss nicht, was ich wo falsch mache und brauche daher die HIlfe von euch lieben Informatik Menschen :-) Soweit ich informiert bin, müsste für mein Vorhaben folgende Schritte ausreichen, damit ich dieses Szenario umsetzen könne: > DSL Gerät nicht als Router fungieren lassen, sondern als Bridge. > das Gerät hinter dem DSL Gerät sollte sich via PPPoE einwählen (Benutzername und Passwort habe ich hinterlegt) Und: schlussendlich, wenn dieses Gerät erfolgreich die öffentliche IP Adresse von 1und1 erhalten hat, sich erfolgreich mit iPSEC mit unserer Firmenfirewall verbinden > wenn ich keine fixe IP Adresse vom Provider zugeteilt erhalte, so müsse ich dies mit DYN DNS lösen Mein Arbeitskolleg hat mir dabei auch geholfen, einen Account für mich angelegt, diese Angaben besitze ich auch) 1. Mein DSL Gerät war original von 1und1 eine Fritzbox FON WLAN Diese habe ich abgebaut!! Direkt mit dem DSL Kabel ist nun eine Zyxel Box, glaube, eine 660 (weiss es nicht auswendig) Auf jeden Fall unterstützt diese Box via Interface beim Punkt WAN die Möglichkeit, von Routing auf Bridge umzuschalten. Was meiner Meinung nach für mein Vorhagen auch essentiell wichtig ist, oder? Was mir aber nicht klar ist, ist folgendes: Schalte ich die obgenannte Funktion für das WAN Interface um, also von Routing auf Bridge ...so müsste doch meiner Meinung nach die Box eben im besagten Bridge Modus sein, richtig? Was mir aber nicht klar ist, wenn ich Zyxel GUI (bin via IE mit der Zyxel Box verbunden) auf den Punkt NAT gehe, hier NAT danach immer noch aktiviert ist ?? ...höööö ? Warum bin ich darüber so erstaunt? Weil meiner Ansicht nach NAT ebenfalls eine Routing Art ist, oder nicht? Folgedessen müsste ich doch NAT auch deaktivieren, damit meine Zyxel Prestige BOX auch wirklich nun im sogenannten Bridge Modus ist oder sehe ich da was falsch? Egal, habe beides funktioniert, also > WAN Interface auf Bridge > NAT deaktiviert (und einmal nicht deaktiviert) Auf beide Arten bekam ich es nicht hin, dass meine Linux Firewall (das WAN Interface, das rote, ist physisch mit einem LAN Port des Zyxel Prestige Gerätes verbunden) sich erfolgreich via PPPoE mit meinem Internet Provider 1und1 verbinden kann, also von diesem die nötigen Netzwerkangaben wie öffentliche Adresse, GW, Subnetzmaske, DNS Server erhält !!! Auf der Firwall steht immer: connecting ...ich kann manuell versuchen, die Verbindung aufzubauen, jedoch bringe ich meine Linux Firewall nie dazu, dass diese sich eben via PPPoE einwählt Wo liegt der Hund begraben?

NorbertFe, Danke für die Lösung via Gruppenrichtlinien :-) Punkt 1 reichte, das hast Du richtig vermutet hehe .. (da ich auf den Clients und dem Member Server nichts verändert hatte) Als ich Punkt 1 erledigt hatte, hatte ich zwar immer noch den in meinem schon geschilderten Fehler (in der Ereignisanzeige --> Service Control Manager, Ereigniskennung 7003: Text: Der Dienst "Windows-Zeitgeber" ist von folgendem, nicht vorhandenem Dienst abhängig: srv01.electro.local) Als ich auf dem PDC Emulator dann ein zweites mal ein gpupdate /force absetzte und feststellte, dass die Registry Einträge danach nicht geändert wurden, dachte ich zuerst, was soll jetzt das? änderte diesen manuell ab (den Eintrag NTP Server -> Verwies immer noch auf c:\Timeservers\Timeservers.txt) durch swisstime.ethz.ch, 0x1 der Start des Dienstes Windows- Zeitgeber schlug dann immer noch fehl .. Die Lösung war dann ein Neustart :-) Also, für alle nochmals zusammengefasst: Zeitsynchronisation in einer Domäne mit einem NTP Server, Kurzaleitung: 1. Den Link von NorbertFe (danke nochmals an Dich) Gruppenrichtlinien - Übersicht, FAQ und Tutorials befolgen !! Bemerkung dazu: Falls Ihr wie ich "nur" auf dem PDC Emulator Änderungen vorgenommen hat (ggf. auch in der Registry), müsste wie bei mir der Punkt 1 ausreichen !! 2. nachdem Ihr auf dem PDC Emulator via gpupdate /force immer noch alte Registry Einträge vorfinden solltet, bitte den PDC Emulator Server neu booten 3. Sicherstellen, dass auch in der Firewall (extern) der Port 123, Protokoll UDP von innen gegen aussen geöffnet ist Bemerkung dazu: Falls dies in Ihrem Netz erlaubt ist und aus sicherheitstechnischer Hinsicht erlaubt ist :-) 4. Nun sollten auch alle Clients und Member Server (falls vorhanden) sich automatisch die Zeit vom PDC Emulator abholen *smile*

wie ich dazu komme, die NTP Server in eine Textdatei zu schreiben? Von einem, meiner ehemaligen MCSE 2003 Lehrer :-) Kennst Du diese Möglichkeit denn nicht? Wenn ich diesen Kontext lese, habe ich leicht, nur gaaanz leicht das Gefühl, dass Du mir was unterstellen willst von wegen: rumbasteln ... Du hast offensichtlich meinen Beitrag gelesen, dann wirst Du wohl auch urteilen können, ob ich gebastelt habe oder nicht...wenn dieses Vorgehen von mir in Deinen Augen als bastel betitelt wird? halloooooo? :cry: Kann ich was dafür, wenn Microsoft ein System entwickelt hat, welches schnmell aus den "Fugen gerät", sei es, weil irgendwelche Updates ein Problem verursachen, sei es, weil irgenwelche installierte Software nicht der besste Freund von Windows sein möchte? Was weiss ich .. Wie heikel Windows ist, muss ich Dir wohl nicht klar machen .. Danke, dass Du am Schluss doch noch hilfsbereit warst und nicht nur "Vorwürfe" machst, sondern auch mal ein wenig konstruktive Lösungen anbietest, sehr schön, dafür danke ich Dir schon jetzt, obwohl ich Dir/ euch noch nicht sagen kann, obs via Gruppenrichtlinien gelöst werden kann ... Bin aber sehr zuversichtlich, wie so oft im Leben und werde Dir/ Euch selbverständlich schon bald wieder ein Feedback abliefern ....Vielleicht sogar heute noch :-) ...bis später und danke vorerst mal

hello together Einleitung: habe wieder einmal ein Problem, welches ich durch googeln, durch Foren lesen, einfach mit Hilfe keiner Quelle lösen konnte ....Ihr seit nun meine letzte Hoffnung :-) Was will ich erreichen? Einen Zeitserver einrichten, welcher als Zeitquelle für alle Clients und Server in meinem 2003 Netzwerk dienen soll!! Was habe ich bis jetzt alles gemacht? > Mit dem Befehl -> dsquery server -hasfsmo pdc (via Dos Konsole) ausfindig gemacht, welches mein aktueller PDC Emulator ist (eine der FSMO Rollen) > Auf diesem Server (folgend srv01.electro.local genannt) folgendes gemacht: - auf dem Laufwerk C:\ einen Ordner mit dem Namen Timeservers erstellt - in diesem Ordner einen Textdatei mit dem Namen Timeservers.txt erstellt - darin (auf jeweils einer Zeile) folgende Einträge gemacht: Swisstime.ethz.ch time-a.timefreq.bldrdoc.gov - auf srv01.electro.local (müsste gemäss Befehl dsquery server -hasfsmo pdc der PDC Emulator sein) folgenden Befehl ausgeführt (im DOS Fenster): w32tm /config /syncfromflags:manual /manualpeerlist:c:\Timeservers\Timeservers.txt (Meldung: successfully) - den Zeitserver mit folgendem Befehl registriert: w32tm /register - danach wurde der Dienst Windows-Zeitgeber erstellt (meine Server und Clients sind alle auf deutsch) - der erstellte Dienst via Registry kontrolliert --> der Eintrag ntpserver lautet: C:\Timeservers\timeservers.txt - auf der Windows Firewall (ist eine Linux Firewall), eine Portweiterleitung gemacht (also von aussen gegen innen): Protokoll UDP, Port 123 nach srv01.electro.local - auf meinem Windows 7 Gerät im Dos Fenster folgenden Befehl ausgeführt: w32tm /monitor /domain:electro.local Damit kontrollierte ich, ob und welcher Zeitserver läuft/ Fehler anzeigt Genau, Fehler ..dieses Wort ist in meinem Wortschatz sehr unbeliebt :-D Bekam folgenden Fehler, nachdem ich diesen Befehl ausgeführt hatte: ------------------------------------------- C:\Users\aegertera>w32tm /monitor /domain:electro.local srv01.electro.local *** PDC ***[192.168.1.10:123]: ICMP: 0ms Verzögerung NTP: Fehler WSAECONNRESET - Keine Server am NTP-Port in Wartestellung srv02.electro.local *** PDC ***[192.168.1.11:123]: ICMP: 0ms Verzögerung NTP: -65.2853750s Offset von srv01.electro.local RefID: (nicht angegeben / nicht synchronisiert) [0x00000000] Stratum: 0 [Warnung] Die Reversenamenauflösung ist die beste Möglichkeit. Sie ist ggf. nicht korrekt, da sich das Ref-ID-Feld in Zeitpaketen im Bereich von NTP-Implementierungen unterscheidet und ggf. keine IP-Adressen verwendet. -------------------------------------------------------------- Daraufhin habe ich festgestellt, dass der neu erstellte Dienst (Windows- Zeitgeber) auf srv01.electro.local gar nicht gestartet war. Ooook, dachte ich mir und versuchte diesen zu starten, jedoch erhielt ich folgenden Fehler (Dienst ist auf automatisch): Systemfehler 1075 aufgetreten Dann führte ich folgenen Befehl aus (in der Verzweiflung): w32tm /resync /rediscover Meldung: Neusynchronisierungsbefehl wird gesendet an local computer ... Folgender Fehler ist aufgetreten: Der RPC Server ist nicht verfügbar. (0x800706BA) Danach habe ich die Ereignisanzeige (das "Logbuch" des Servers) geöffnet und stellte unter dem Punkt Anwendung folgenden Fehler fest: Quelle = Service Control Manager; Ereignis = 7003 Die darin beschriebene Fehlermeldung ist: Der Dienst "Windows- Zeitgeber" ist von folgendem, nicht vorhandenem Dienst abhängig: srv01.electro.local Interpretiere ich diesen Satz richtig, bedeutet dies, dass es einen Dienst geben sollte, der den Namen srv01.electro.local trägt ??? hääääää....so nennt sich mein PDC Emulator (auch Domain Controller, habe davon zwei Stück) Was soll denn das?? bin ich nun irgendwie ****, habe ich Schnee auf der Leitung (schneien tut es ja noch nicht) Genau dies verstehe ich nicht, da bin ich mit meinem Latein am Ende !!

ach soo, sehr interessant !! Danke für das Feedback, werde ich mir merken ;)

Hallo Sunny61 eeh, mich würde jetzt trotzdem noch interessieren, wie Du auf die Kombination von Nvidia und Teamviewer kommst --> Probleme mit servergespeicherten Profilen, danke für das Feedback :-) cheers Andrew

Was hat dies mit Servergespeicherten Profil und deren "NICHT funktionieren" zu tun? Halloooo, reden wir aneinander vorbei? es sieht ganz danach aus :-D .... Ich rede von Servergespeicherten Profilen, konkret: Von einem Windows 7 servergespeicherten Profil, welches auf einem Windows 2003 Server abgelegt werden sollte und genau dieser Schritt geschah nicht !!! Mit msconfig hat dies nicht wirklich was zu tun. Es hat damit zu tun, dass ab Windows Vista die servergespeicherten Profile neu mit der Endung .v2 gespeichert werden. konkret sieht das so aus: \\ServerXY\Sharename\gugusanmeldename.v2 Ich hatte wie früher immer direkt beim User in den Eigenschaften, im Reiter Profil den obigen UNC Pfad eingegeben, bekam auch keinen Fehler. Darum ging ich davon aus, dass alles funktionieren wird. Doch bei der Anmeldung mit der Windows 7 Maschine, also beim Domänenanmeldeversuch merkte ich, dass es sehr lange ging, bis das Profil geladen werden konnte und danach erschien die Meldung: das servergespeicherte Profil konnte nich geladen werden, Sie wurden mit einem temporären Profil angemeldet. Da kam ich dann auf die Idee, den Profilordner manuell zu erfassen, das heisst: \\ServerXY\Profiles$ <<< hier, in diesem Share habe ich den Profilordner manuell erstellt, mit den entsprechenden Rechten versehen (User Vollzugriff) und entsprechend gespeichert, also zum Beispiel meiera.v2 das sah dann so aus: \\ServerXY\Profiles$\meiera.v2 Erst als ich den Profilordner manuell erstellt hatte, konnte ich mich mit dem Windows 7 Gerät an der Domäne anmelden, ohne das eine Fehlermeldung erschien !! So, Problem gelöst :-)

wurde da nun eine Lösung gefunden???? Habe soeben das gleiche Problem!!

Hello together So, habe das Problemm, dass ich das RSAT 64 Bit Programm --> amd64fre_GRMRSATX_MSU und auch nicht das x86 Programm x86fre_GRMRSAT_MSU installieren konnte, obwohl: - mein Windows 7 zuvor via Netzwerkboot freisch installiert worden war - danach einige Updates von Windows installiert worden waren - und einige Anwendungen drauf waren (Adobe Acrobat Reader) Danach installierte ich mein Windows7 nochmals, erneut via Netzwerkboot (beim Starten des PCs F12 drücken, sofern man wie ich einen WDS Server zuvor erfolgreich installiert hat) den PC mit Windows 7 installierte, ging es dann. Hatte als erstes mal die Windows Update Konfiguration bei Fertigstellung der Windows 7 Installation (am Schluss) so eingestellt, dass keine Updates automatisch installiert werden. Ich wusste nicht, ob dies der mögliche Grund für das eewige Scheitern der RSAT Installation auf einem Windows 7 Enterprise 64 Bit System war? Auf jeden Fall habe ich so die RSAT Installation hingekriegt. Das erste mal brach er mir wieder mit der Fehlermeldung ab, dass das Update für den PC (KB958830) nicht installiert wurde. Nach dem zweiten mal hat es dann wie soeben erwähnt funktioniert und ich konnte auch soeben erfolreich diverse Optionen des RSAT Tools erfolgreich ankreuzen (diese Windows Funktionen wurden dann entsprechend installiert, also die RSAT Funktionen) Für die, die es nicht wissen oder gerade diesen Artikel lesen und denken, hey, wie gehts weiter, nachdem man das RSAT Tool erfolgreich auf einem Windows 7 Gerät installiert hat, hier der Weg, damit man schlussendlich via Windows 7 Gerät die Gruppenrichtlinien von Server 2003/ 2008 editieren kann, das AD verwalten etc. - RSAT Tool von Microsoft Download Seite downloaden (schauen, ob für X86 oder 64 Bit Windows PC) - danch unter: Systemsteuerung\ Programme und Funktionen\ Windows Funktionen aktivieren oder deaktivieren\ --> so, hier erscheint nun neu der Punkt: Remoteserver- Verwaltungstools !!!! Hier die gewünschten Optionen auswählen und fertig, die entsprechenden, angekreuzten RSAT Optionen werden installiert und sind darauf hin unter Windows 7 Knopf, dann Verwaltung (aber man muss zu diesem Zeitpunkt, also wenn man angmeldet ist, über erhöhte Reche verfügen (admin Rechte), damit dieser Menüpunkt angezeigt wird und man schlussendlich die ausgewählten RSAT Tools auch anwählen und starten kann. Das klappt bei mir wunderbar, jedoch habe ich ein neues, altbekanntes Problem. Das Problem nennt sich: Servergespeicherte Profile von Windows 7 werden bei der Anmeldung nicht geladen. Dieses Problem kannte ich schon mit Windows Vista, jedoch war ich dort der Meinung, das Problem gelöst zu haben, indem ich die CSEs (Client Side Extensions) zuvor auf dem Windows Vista Client installiert hatte. Erst danach funktionierte meiner Meinung nach das laden der servergespeicherten Profile in einem Windows 2003 Netzwerk. Aber jetzt mit Widows 7 kriege ich das nicht hin!!! Man findet irgendwie auch nichts schlaues, wenn man danach googelt. Sind nun die CSE bei Windows 7 schon integriert? Wenn dies so sei sollte, warum werden dann die servergespeicherten Profile trotzdem nicht geladen? Danke für euere zahlreichen Tipps !!

so, hier sind mal die Fehlermeldungen :) diese Fehlermeldung erschien, als ich mit meinem Windows 7 Client auf diesen UNC Pfad Zugriff und versuchte, mit Administratoren Rechten das RSAT zu installieren (aus der Ereignisanzeige kopiert) Das Windows-Update konnte aufgrund eines Fehlers nicht installiert werden: 2149842967 "" (Befehlszeile: ""C:\Windows\system32\wusa.exe" "\\srv01\install$\install\special\RSAT\x86fre_GRMRSAT_MSU.msu" ") Diese Fehlermeldung erschien, als ich auf manuelle Art und Weise versuchte, das RSAT Tool zu installieren: Das Windows-Update "Update für Windows (KB958830)" konnte aufgrund eines Fehlers nicht installiert werden: 2147942413 "Die Daten sind unzulässig." (Befehlszeile: ""C:\Windows\system32\wusa.exe" "C:\temp\amd64fre_GRMRSATX_MSU.msu" ") Danke für eure Anregungen, habe immer noch keine Lösung gefunden, auf meinem Windows 7 Enterprise PC das RSAT Programm zu installieren!! P.S. Sunny61, der von Dir vorgeschlagene Ort unter Systemsteuerung\Programme und Funktionen\Windows Funktionen aktivieren oder deaktivieren, hier gibts den Punkt Remoteserververwqaltungstools gar nicht!!! der erscheint meiner nach erst, sobald ich eben RSAT installiert habe, kann ich aber nicht, warum auch immer!! Sonst noch eine Idee?

hello together Frage, hat mir Jemand einen guten Tipp, auf welche weise ich das RSAT Programm installieren könnte? Auf folgende Arten habe ich es versucht, leider scheiterte am Schluss der Installationsvorgang mit einem Fehler (inkompatible Dateien oder ähnlich) Möchte das RSAT Tool auf einem Windows 7 Enterprise, 64 Bit installieren, versucht habe ich dies wie schon erwähnt via folgende Möglichkeiten: > RSAT 64 Bit download gemacht, Link war: Downloaddetails: Remoteserver-Verwaltungstools für Windows 7 > RSAT 64 Bit lies sich nicht installieren > RSAT 32 Bit lies sich nicht installieren, am Schluss der Installation des KB 85XY (weiss es nicht mehr auswendig) > das manuelle entpackens der msu Datei und das anschliessende ausführen der cab Datei brach ebenfalls mit einem Fehler ab. Kurz, ich konnte das RSAT Paket von obiger Quelle auf keine "Geis Art" installieren, warum den nicht? oder wie kriege ich das hin, möchte noch erwähnen, dass ich den PC mit Windows 7 Enterprise (RSAT läuft unter Enterprise, Ultimate und glaube ich noch einer Version) via Netzwerkboot frisch installiert habe Und: ich habe kein anderes Remote Verwaltungstool auf dem Windows 7 Gerät installiert (unter Programme via Systemsteuerung ist nur die Adobe Acrobat Reader) Software installiert (aufgeführt) Danke für die Hinweise

so, habe herausgefunden, woran es lag :-) Problem war, ich hatte stets mit der Netzwerkaufzeichnung begonnen (auf dem DC mit dem Netzwerkmonitor), wenn auf dem Mitgliedsserver bereits die Anmeldemaske erschien. Wann passiert aber genau der Authentifizierungsprozess eines Mitgliedssrvers (oder eines Clients) an einer Domäne? Der erste Schritt des Authentifizierungsprozesses ist folgender: > während der zu authentifizierende Mitgliedsserver (oder der Windows 7 Client) bootet, fragt dieser während des Bootvorgangs via DNS Dienst den LDAP Dienst des DCs ab: --> Hier, im Netzwerkmonitor sieht das so aus: Qry Resp. for _ldap._tcp.Standardname-des-ersten-Standorts._sites.dc._msdcs……………………………………. > Man muss also, wenn mau beispielsweise wie ich auf dem DC den Netzwerkmonitor am Laufen hat, die Aufzeichnung starten > in einem zweiten Schritt muss man den PC oder Server neu booten, da wie oben gerade erwähnt, der Domänencontroller schon während des Bootvorgangs abgefragt wird :-)

Hallo OlC Welchen Client soll ich neu starten? Du schreibst weiter: "Starte den Client einmal neu und ziehe den Trace dabei auf Deinem Test DC / primary DNS des Clients" Das heisst konkret was? Ich soll den Netzwerkverkehr mit dem Netzwerkmonitor auf dem DC aufzeichnen oder? Habe ich ja vorher schon gemacht (habe auch schon den DC und den Mitgliedsserver neu gestartet und das ganze Spiel von neuem getestet, kein Erfolg) Ich habe einen > Windows Server 2003 als DC (auf diesem läuft der Netzwerkmonitor) > Windows Server 2003 als Mitgliedsserver Sorry, erkläre mir einfach Schritt für Schritt, was ich Deiner Meinung nach machen soll (ungefähr in etwa wie folgt) Punkt 1: ..... Punkt 2: ...... Punkt 3: .... thanks ;)

Hallo Jungs Möchte gerne im Zusammenhang mit der Prüfung 70- 291 (Bin gerade am Teil "Verwalten der Netzwerksicherheit" --> Kerberos Tickets und so) folgendes nachvollziehen: Was geschieht, wenn sich ein Client oder ein Mitgliedsserver an einer Domäne anmeldet, welche Einträge auf dem DC werden abgefragt etc. Frage (Problem) sehe im Netzwerkmonitor keine DNS Abfrage für den LDAP Dienst Da müsste ich ja ein Zeile finden: Protokoll = DNS Qry Resp. for _ldap._tcp.Standardname-des-ersten-Standorts._sites.dc._msdcs...... Bemerkung dazu: Aber eben, wenn ich auf dem Mitgliedsserver den DNS Cache mit ipconfig / flushdns lösche, mich danach abmelde, mich mit dem Administrator am Mitgliedsserver wieder an der Domäne anmelde, sehe ich auf dem DC (auf welchem der Netzwerkmonitor läuft) trotzdem keine DNS Abfrage für den LDAP Dienst Bemerkung zu meiner Testumgebung: Interessanter Weise habe ich dieses Phänomen, wenn ich  Einen Server, welcher in der Arbeitsgruppe habe, frisch via dcpromo zum DC heraufstufe  Danach einen ebenfalls frischen Server als Mitglied dieser Domäne mache  Und mich schlussendlich an diesem Mitgliedsserver an der Domäne anmelde (mit dem Administrator) (den DNS Cache habe ich manuell schon gelöscht) Die Maschinen hatte ich im VMware installiert Und: beide Server, egal, ob es der Server ist, welchen ich zum DC machte oder ob es der Server ist, welchen ich nachträglich als Memberserver der Domäne einrichtete, beide Server waren zu diesem Zeitpunkt frisch aufgesetzt. Das heisst, ich hatte beide Server via SnapShot auf diesem Stand gesetzt und genau die Schritte durchgeführt, welche ich oben erwähnt habe.. Rein aus dieser Sicht kann es NICHT daran liegen, dass meine Umgebung verbastelt wäre oder ist .und genau das macht mich sehr nachdenklich?! :confused:

Nachtrag: Wenn ich nun effektiv auf dem Windows 7 PC überprüfe, oder eine oder beide der vorgenommen Einstellungen (Gruppenrichtlinie via RSAT) gegriffen habe, so stelle ich fest, jaaaa :-) rufe ich die Systemeigenschaften auf und dort Windows Update, so sehe ich unter anderem die grau hinterlegten Felder respektive die genaue Uhrzeit, um welche nach Updates gesucht werden sollen --> da stellte ich in den Gruppenrichtlinien fest, dass am Abend um 23:00 Uhr der Client den WSUS Server kontaktieren soll ... Aber eben, diesen muss ich zuerst noch korrekt konfigurieren ... Also, diese hat gegriffen, so wie es aussieht ... die RDP Richtlinie, welche auf dem Windows 7 PC bewirken soll, dass in den Systemeigenschaften unter Remotedsktop oder wie das heisst (aus dem Kopf auswendig gesagt), dass dort die entsprechende Funktion aktiviert ist, aber ich kann als normaler Benutzer diese Optionen ändern, das wiederum irritiert mich ... Es ist zur Zeit folgende Option aktiv: Systemeigenschaften, Ritter Remote: - Verbindungen von Computern zulassen, auf denen eine beliebige Version von Remotedesktop ausgeführt wird auswählen kann man nicht (da inaktiv): - Keine Verbindung mit diesem Computer zulassen und folgende Option kann ich als normaler Benutzer ebenfalls jetzt, aktuell nach wie vor manuell ändern (oder eben diese Option aktivieren) - Verbindungen von Computern zulassen, auf denen eine beliebige Version von Remotedesktop mit Authentifizierung auf Netzwerkebene ausgeführt wird (höhere Sicherheit)

COMPUTEREINSTELLUNGEN ---------------------- CN=CHBISUW001,OU=Computer,OU=Biel,OU=Standorte,DC=bangkok,DC=intern Letzte Gruppenrichtlinienanwendung: 01.09.2009, um 22:28:34 Gruppenrichtlinieanwendung von: chbisus001.bangkok.intern Schwellenwert für langsame Verbindung:500 kbps Domänenname: BANGKOK Domänentyp: Windows 2000 Angewendete Gruppenrichtlinienobjekte -------------------------------------- erlaubt RDP Verbindungen auf den PC WSUS Updates ziehen Default Domain Policy Folgende herausgefilterte Gruppenrichtlinien werden nicht angewendet. ---------------------------------------------------------------------- Richtlinien der lokalen Gruppe Filterung: Nicht angewendet (Leer) Der Computer ist Mitglied der folgenden Sicherheitsgruppen ---------------------------------------------------------- Administratoren Jeder Benutzer NETZWERK Authentifizierte Benutzer Diese Organisation CHBISUW001$ Domänencomputer Systemverbindlichkeitsstufe BENUTZEREINSTELLUNGEN ---------------------- CN=Administrator,CN=Users,DC=bangkok,DC=intern Letzte Gruppenrichtlinienanwendung: 01.09.2009, um 14:01:45 Gruppenrichtlinieanwendung von: chbisus001.bangkok.intern Schwellenwert für langsame Verbindung:500 kbps Domänenname: BANGKOK Domänentyp: Windows 2000 Angewendete Gruppenrichtlinienobjekte -------------------------------------- Default Domain Policy Folgende herausgefilterte Gruppenrichtlinien werden nicht angewendet. ---------------------------------------------------------------------- Richtlinien der lokalen Gruppe Filterung: Nicht angewendet (Leer) Der Benutzer ist Mitglied der folgenden Sicherheitsgruppen ---------------------------------------------------------- Domänen-Benutzer Jeder Benutzer Administratoren INTERAKTIVE REMOTEANMELDUNG INTERAKTIV Authentifizierte Benutzer Diese Organisation LOKAL Schema-Admins Richtlinien-Ersteller-Besitzer Organisations-Admins Domänen-Admins Hohe Verbindlichkeitsstufe

habe nun etwas interessantes herausgefunden: hatte ja, weil ich merkte, dass die Richtlinien, welche ich auf dem Server 2003 vorgenommen hatte, nicht griffen. Daraufhin hatte ich RSAT heruntergeladen, unter Programme und Funktionen "Windows Funktionen aktivieren oder deinstallieren" (sinngemäss übersetzt) und hier die entsprechenden Hacken gesetzt (es gibt nach dem Download und der Installation des RSAT Paketes hier eine neue Rubrik oder neue Punkte --> Remotetools oder so, weis den Namen nicht mehr genau ... genau und via GPMC richtete ich sowohl neu die WSUS (Windows Update) Richtlinie ein wie auch die RDP Richtlinie ...soooo, nun das Resultat hier ... ja eben, was ich noch erwähnen wollte: Ich habe herausgefunden, dass wenn ich als normaler 08:15 Benutzer mich auf dem Windows 7 PC an der Domäne anmelde, das Dos starte und den Befehl gpresult /r ausführe, folgendes rauskommt: BENUTZEREINSTELLUNGEN ---------------------- CN=Testvorname Testnachname,OU=Benutzer,OU=Biel,OU=Standorte,DC=bangkok,DC=intern Letzte Gruppenrichtlinienanwendung: 01.09.2009, um 22:28:34 Gruppenrichtlinieanwendung von: chbisus001.bangkok.intern Schwellenwert für langsame Verbindung:500 kbps Domänenname: BANGKOK Domänentyp: Windows 2000 Angewendete Gruppenrichtlinienobjekte -------------------------------------- Default Domain Policy Folgende herausgefilterte Gruppenrichtlinien werden nicht angewendet. ---------------------------------------------------------------------- WSUS Updates ziehen Filterung: Nicht angewendet (Leer) Richtlinien der lokalen Gruppe Filterung: Nicht angewendet (Leer) Der Benutzer ist Mitglied der folgenden Sicherheitsgruppen ---------------------------------------------------------- Domänen-Benutzer Jeder Remotedesktopbenutzer Benutzer INTERAKTIV KONSOLENANMELDUNG Authentifizierte Benutzer Diese Organisation LOKAL Mittlere Verbindlichkeitsstufe Sooo, nun kommt nochmals das resultat von gpresult /r aber der Unterschied ist, dass ich das Dos Fenster als Administrator ausführe und folgendessen mit Admin Rechten Befehle ausführen kann, wie soeben erwähnt auch gpresult /r ergibt folgenden, relevanten Unterschied (und ich frage mich, warm ich als normaler Benutzer nicht die Berechtigung habe, eben zu sehen, was effektiv wird, denn das Resultat welches ihr gleich sehen werdet, hat meiner Meinung nach auch effektiv gegriffen

hello together Umgebung: > Habe zwei Server mit Windows 2003 R2 installiert > dann den einen mit dcpromo heraufgestuft > auf dem zweiten Server auch dcpromo ausgeführt (einen weiteren DC für eine bestehende Domäne) > auf beiden DNS installiert > im AD einen OU erstellt --> Name = Standorte > eine Unter OU von Standorte erstellt --> Name = Biel > und hier wieder unter OUs erstellt (Name = Computers, Name = Users etc.) soweit so gut ... > dann habe ich einen Client mit Windows 7 (Final Version) installiert > diesen in die Domäne aufgenommen danch Gruppenrichtlinien erstellt .... > auf der OU Computers habe ich via AD Verwaltung auf dem Server 2003 eine Richtlinie erstellt (unter Computerkonfiguration) --> RDP Verbindungen auf diese Maschine sind erlaubt (sinngemäss übersetzt) > danach habe ich das Computerkonto (Windows 7 Client) in die OU Computers verschoben gpupdate /force ausgeführt > auf dem Windows 7 Client ein gpupdate /force ausgeführt > gpresult /r ausgeführt und festgestellt: die Richtlinie ist bei folgendem Punkt aufgeführt: Angewendete Gruppenrichtlinienobjekte -------------------------------------- WSUS Updates ziehen Default Domain Policy Folgende herausgefilterte Gruppenrichtlinien werden nicht angewendet. ---------------------------------------------------------------------- erlaubt RDP Verbindungen auf den PC Filterung: Deaktiviert (Link) Richtlinien der lokalen Gruppe Filterung: Nicht angewendet (Leer) Wie Ihr sehen könnt, gibt es noch eine WSUS Richtlinie, welche ich auch erstellt habe, aaaaber diese habe ich nicht via Server 2003 via Users and Computers (AD Verwaltung) erstellt, sondern via Vista !!! weil ich merkte, das keine Richtlinie zog (WSUS Richtlinie und RDP Verbindungen zulassen --> auf dem Client), entschloss ich mich, als Test eine Gruppenrichtlinie mit dem Windows 7 Gerät zu erstellen. > Dies ist eben die WSUS Richtlinie und wie Ihr sehen könnt, greift diese .... > die Richtlinie, welche ich unter Server 2003 erstellt habe (remote Deskop erlauben --> auf Clients), greift nicht Frage: Wir könnt Ihr euch dieses Phänomen erklären? meine Behauptung: > das dsa.msc (Active Directory- Benutzer und Computer) ist mit Vista/ Windows 7 nicht kompatibel und darum greifen die Gruppenrichtlinien unter Windwos 7/ Vista nicht ... > Windows 7 und Vista verwenden neu admx Vorlagen und nicht wie Windows 2003 adm Vorlagen --> sind ja unter Windows 2003 unter %Systemroot%\inf gespeichert Könnte das der Grund sein? dass wenn ich unter Windows 2003 Gruppenrichtlinien erstelle, diese unter Vista/ Windows 7 nicht greifen???