IThome

Kleine Korrektur ... ;) Der Inhalt der HOSTS-Datei wird gelesen und in den Cache geschrieben. Editiere ich die HOSTS-Datei, wird der editierte Teil (nach dem Speichern) sofort in den Cache übertragen. Der Cache (also auch der gesamte Inhalt der HOSTS-Datei) wird VOR der Abfrage an einen DNS-Server gelesen und benutzt. Ist der Resolvercache allerdings abgeschaltet, wird auch die HOSTS-Datei bei der Namensauflösung gelesen. Sobald ich den Resolvercache wieder anschalte, wird die HOSTS-Datei wieder eingelesen und deren Inhalt in den Cache übertragen, so dass die HOSTS danach nicht mehr gelesen werden muss. In dem Zuge hat Norbert also recht, dass die HOSTS-Datei vor dem DNS-Server gelesen wird. Aber nur, wenn der Resolvercache abgeschaltet ist ... :)

Trotz Proxyausnahme für den WSUS-Server ?

Mach´s doch einfach mal ... IPCONFIG /FLUSHDNS leert den Cache und die HOSTS wird erneut eingelesen. IPCONFIG /DISPLAYDNS zeigt sofort wieder alle Einträge der HOSTS im Cache an ... ohne dass man eine Namensauflösung angeregt hätte ...

Changes in File Types and File Association Features in Windows 2000 and Windows Server 2003

Die maximale Farbtiefe kann man auch in der RDP-TCP Konfiguration des Remotedesktop-Hosts einstellen (Terminaldienstekonfiguration oder Konfiguration des Remotedesktop-Sitzungshosts) ...

Du erreichst auch den SBS nicht ? Poste mal bitte IPCONFIG /ALL eines verbundenen Clients und des Servers, wenn der Client verbunden ist ...

So mache ich das auch, BDC rein, BDC hochstufen, den Original PDC (jetzt ja BDC) abschalten, abwarten und hoffen, dass es klappt (in der Regel klappt´s) ... ;-) :D Auf jeden Fall daran denken, dass Windows 2003 AD primär auf DNS-Namensauflösung setzt und nicht mehr auf NetBIOS-Namensauflösung. Pass auf, dass Du Dir keine Single Label DNS Domain erzeugst (also DNS Domäne, die so heisst, wie die NetBIOS Domäne zuvor, ohne .local, .intern oder so) ...

Denke dran, dass es die Remotedesktopbenutzer-Gruppe des XP-Clients und nicht die Remotedesktopbenutzer-Gruppe der Domäne sein muss ...

Genauer gesagt wird der Resolvercache vor dem DNS-Server abgefragt. Die Einträge der HOSTS Datei werden bei Änderung der HOSTS-Datei und beim Systemstart in den Resolvercache geladen. Die HOSTS-Datei an sich wird bei einer Namensauflösung nicht gelesen ...

Die können problemlos mehrere Protokolle nebeneinander benutzen ...

Wenn Du per WLAN intern im Trusted-Netzwerk bist, hat die Watchguard rein gar nichts damit zu tun. Konfiguriere auf Deinem internen DNS-Server eine Zone "Meinname.dyndns.org" und erzeuge dort einen A-Eintrag ohne Namen, dem Du die interne IP-Adresse des Exchange gibst ...

Bis jetzt habe ich verstanden, dass Du von einem Windows 7 Nicht-Mitglied auf ein XP Mitglied via RDP zugreifen möchtest. Bei diesem Vorgang bekommst Du eine Fehlermeldung wie beschrieben. Du möchtest die Konfiguration (auf der XP-Maschine) via Gruppenrichtlinie erledigen ... Was genau hast Du schon eingestellt (Gruppenzugehörigkeit z.B., auf welcher Maschine eingestellt ...) ? Was genau soll über die Gruppenrichtlinie eingestellt werden ?

Einfache Dateifreigabe ist noch aktiv ?

Hast Du den Regkey gesetzt ? Ist irgendwas von Acronis installiert worden ?

Ist da ne Fritzkarte im Server verbaut ?

Prüfe, ob die Zeit des Clients mit der Zeit des Servers übereinstimmt. Prüfe, ob der Client dieselben DNS-/WINS-Server wie die anderen Clients benutzt. Prüfe mit NBTSTAT-c und IPCONFIG /DISPLAYDNS, welche Adresse dem Servernamen zugeordnet ist.

Wie gross sind denn die Profile und was meinst Du mit Netzwerkdateien ? Wieviele Benutzer in den Zweigstellen ? Warum sollen Profile über das WAN übertragen werden, wenn es 2 getrennte Firmen sind ? Sollen die z.B. Officedateien auf dem entfernten Server bearbeiten, also mit dem lokalen Office Dateien vom entfernten Server öffnen, bearbeiten und speichern ? Sowas wäre was für einen Terminalserver, denn die von (V)DSL zur Verfügung gestellten Bandbreiten werden nicht ausreichen ...

Schon mal den Stack bzw. Winsock zurückgesetzt ? NETSH INT IP RESET RESETLOG.TXT NETSH WINSOCk RESET CATALOG aus einer privilegierten Kommandozeile heraus starten

Du erstellst eine primäre Zone, nicht AD-integriert und lässt keine Updates zu. Diese Zone heisst so wie der FQDN des entfernten Servers (also z.B. SBS2008.FIRMA.LOCAL). In dieser Zone erzeugst Du einen Hosteintrag. In diesem Hosteintrag gibst Du nur die IP-Adresse von SBS2008.FIRMA.LOCAL an, nichts weiter. Du hast dann genau 3 Einträge in dieser Zone. 3 mal "Identisch mit übergeordnetem Ordner", der erste ist der Autoritätsursprung (SOA), der zweite der Namenserver (NS) und der dritte der Host (A) ... Damit muss das klappen ... Was hast Du beim NSLOOKUP denn eingegeben ? NSLOOKUP SBS2008 (z.B.) ? NSLOOKUP-Abfragen sollte man generell mit dem FQDN (also MIT abschliessendem Punkt) durchführen ... In dem Beispielfall also "NSLOOKUP SBS2008.FIRMA.LOCAL." Willst Du nur nach dem Hostnamen auflösen, musst Du Dir Gedanken über eine Suffixsuchliste machen ...

Du könntest im DNS-System eine neue Zone erstellen. Beispiel: Der FQDN des entfernten Servers lautet SBS.ENTFERNT.LOCAL. Also erstellst Du eine Zone SBS.ENTFERNT.LOCAL und erzeugst in dieser Zone einen Hosteintrag mit der IP-Adresse des Servers, gibst aber keinen Namen an ...

http://msdn.microsoft.com/en-us/library/aa505956.aspx Das wirkt aber nur bei verbindungsorientiertem Datenverkehr ...

Ja, wie Du gesehen hast, kannst Du die Firewall für XP dort zwar einschalten, aber die Ausnahmen zumindest für XP dort nicht definieren (für >= Vista aber schon) ... Die Ausnahmen für XP definiert man unter Computerkonfiguration - Richtlinien - Administrative Vorlagen - Netzwerk - Netzwerkverbindungen - Windows Firewall ...

Wo hast Du das eingestellt ? Unter Computerkonfiguration - Windowseinstellungen - Sicherheitseinstellungen - Windows Firewall mit erweiterter Sicherheit ? Du hast eine XP-Maschine und für die werden die Ausnahmen woanders definiert ...

Die Alternative wäre Remote Web Workplace ... Aber ich werd da auch nicht schlau draus ... Aber mal ganz davon ab ... Der SBS 2003 ist kein Terminalserver und lizenzrechtlich darf man per RDP da nur rauf, um ihn zu verwalten und nicht, um "richtig" zu arbeiten ...

Naja, ob RDP/Leitung der Grund ist, lässt sich ja leicht feststellen, wenn man einfach mal was anderes als die Konsole benutzt (Active Directory Benutzer und Computer, Exchange Verwaltung oder ähnlich). Wir verwalten SBS Server auch via RDP und sogar bei Kunden, die schlechtere Leitungen haben ... Da gibt´s zumindest keine Geschwindigkeitsprobleme mit RDP ...