festplatte.ch

Frage: Darf der Infrastruktur-Master auf einem Domänencontroller laufen, der auch Global Catalog Server ist?

Antwort: Eine übliche Antwort hierauf beruht auf einem falsch verstandenen Gerücht. Hiernach dürfe der Infrastruktur-Master (IM) nur dann auf einem Global Catalog Server (GC) laufen, wenn jeder Domänencontroller (DC) im gesamten Forest ein Global Catalog Server sei. Dieses Gerücht beruht allerdings auf missverständlichen Formulierungen.

Die Aufgabe des Infrastruktur-Masters besteht darin, Objekte der eigenen Domäne mit Objekten anderer Domänen im gleichen Forest zu vergleichen und mögliche Unterschiede (insbesondere domänenübergreifende Gruppenmitgliedschaften) zu korrigieren. Wenn nun der Server, der die IM-Rolle hält, gleichzeitig Globaler Katalog ist, wird er niemals einen Unterschied feststellen, weil er ja bereits eine Teilkopie jedes Objekts im ganzen Forest hat. Daher wird der IM in diesem Fall in seiner eigenen Domäne niemals eine Änderung an solchen Objekten durchführen. Wenn allerdings jeder DC innerhalb der Domäne auch GC ist, hat der IM schlicht nichts zu tun, denn jeder GC kennt ohnehin alle Objekte anderer Domänen. Wenn man sich nun also ansieht, was der IM zu tun hat, wird es klar, dass die IM-Rolle auf einem GC laufen darf, wenn es sich um ein Einzeldomänen-Netzwerk handelt (denn dann gibt es keine anderen Domänen, von denen Objekte repliziert werden). Ebenso klar ist, dass die IM-Rolle auf einem GC laufen darf, wenn der Forest aus mehreren Domänen besteht, aber jeder DC in der eigenen Domäne auch GC ist (kein Bedarf an Objektvergleichen, weil der GC sowieso “alles” weiss).

Domäne A

•A-DC1 (GC + IM)
•A-DC2 (GC)
•A-DC3 (muss GC sein!)

Domäne B

•B-DC1 (GC)
•B-DC2 (IM)
•B-DC3 bis B-DCx (GC oder nicht spielt hier keine Rolle)

In der ersten Domäne muss der IM keine Informationen aus anderen Domänen abrufen, weil der GC “alles” bereits kennt. Die andere Domäne hat den IM auf einem Nicht-GC, also ruft der IM Informationen aus den anderen Domänen ab und repliziert sie bei Bedarf auf die anderen DCs.

Um es also kurz zu machen:

Der Infrastruktur-Master darf nicht auf einem Global Catalog Server laufen, wenn alle folgenden Voraussetzungen gegeben sind:

•es gibt mehrere Domänen im Forest und
•es gibt Domänencontroller in derselben Domäne, die nicht Global Catalog Server sind.

Der Infrastruktur-Master darf auf einem Global Catalog Server laufen, wenn mindestens eine der folgenden Voraussetzungen gegeben ist:

•es gibt nur eine Domäne im Forest und/oder
•jeder Domänencontroller in derselben Domäne ist auch Global Catalog Server

Links:
http://support.microsoft.com/kb/223346/EN-US/
http://support.microsoft.com/?id=248047

Quelle: http://www.faq-o-matic.net

WPAD Funktionsweise
Hinter der automatischen Konfiguration verbirgt sich das Prinzip “WPAD”, was soviel wie “Web Proxy Auto Detection” bedeutet. Über verschiedene Wege kann damit ein Browser die Information erhalten, wie er ein Script erhalten kann, welches die Antwort auf die Frage “Welchen Proxy soll ich nutzen ?” geben kann. Ein Skript könnte wie folgt aussehen:

function FindProxyForURL(url, host)
{
url=url.toLowerCase();
host=host.toLowerCase();

if (shExpMatch(host, “*.domain.tld”) ||
shExpMatch(host, “localhost”) ||
shExpMatch(host, “*domain2*”) ||
isInNet(host, “10.0.0.0″,”255.0.0.0″) ||
isInNet(host, “192.168.0.0″,”255.255.0.0″))
return “DIRECT”;

else
return “PROXY proxy1:8080; PROXY proxy2:8080; DIRECT”;
}

Der Browser benötigt einfach diese Script, und ruft die Funktion “FindProxyForURL” mit den Parametern der URL und dem Hostnamen auf. Das Script gibt dem Browser dann als Antwort den Proxy oder “DIRECT” zurück. Dieses Beispiel nutzt nur einen Teil der verfügbaren Funktionen zur Auswertung von URL und HOST. Der Browser muss natürlich das Script selbst erst einmal erhalten. Zwar können die meisten Browser hier auf eine lokale Datei zugreifen, aber viel interessanter ist eine zentrale Bereitstellung z.B.: auf einem Webserver, den der Browser natürlich ohne Proxy erreichen können muss.

WPAD Konfiguration:
1. Schritt:
Umstellung des Browsers auf “Automatische Suche der Einstellungen”.

2. Schritt
Erweiterung des DNS um einen CNAME Eintrag: wpad
Browser die nicht die Suche per DHCP unterstützen verwenden den DNS. Sie suchen nach einem Ziel mit dem Namen wpad* auf dem die Datei wpad.dat dann auch zu finden ist.
DNS -> ForwardLookup Zone -> Neuer CNAME: wpad dieser verweist auf “euerWebServer”

Wenn man sich mal den Netzwerkverkehr anschaut, dann macht der Browser eine Anfrage (GET /wpad.dat HTTP/1.1) an den Host: wpad, bekommt eine Antwort (HTTP/1.1 200 OK (Content-Type: application/x-ns-proxy-autoconfig) und liest dann den Inhalt der Datei.

3. Schritt
Man erstellt eine wpad.dat Datei und hinterlegt sie auf einem Webserver, damit sie hinterher über http://wpad/wpad.dat gefunden werden kann.
Als Beispiel in die Standardweb Seite eures IIS, dieser ist normalerweise unter C:\inetpub\wwwroot zu finden.

5. Schritt
entweder für den gesammten IIS: IIS Verwaltung -> Eigenschaften des Servers -> MIME-Typen -> Hinzufügen:
oder nur für die WebSeite: IIS Verwaltung -> Eigenschaften deder Seite -> HTTP-Header -> MIME-Typen -> Hinzufügen:

Erweiterung: application/x-ns-proxy-autoconfig
MIME-Typ: .dat

Links:
http://www.msxfaq.de/verschiedenes/wpad.htm
http://www.gruppenrichtlinien.de/index.html?/HowTo/Automatische_Proxykonfiguration_WPAD.htm

Standardmässig gibt DFS auf Anfragen nur NetBIOS Namen zurück. Dies funktioniert ganz ordentlich, solange man sich nicht in einem anderen Forest, Domain etc befindet….
Sobald von ausserhalb der Domaine ein Zugriff auf DFS Ressourcen erfolgt, landet man im Nirvana.

Als unschöner Workaraound könnten die DFS Server beim lokalen DNS eingetragen werden. Oder die DNS-Suffix aller Clients werden mit den Präfixen erweitert.

Das Ganze kann aber auch direkt im DFS umkonfiguriert werden. Folgender RegKey muss auf allen DFS Servern hinzugefügt werden, welche Namespaces hosten:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs
Value Name: DfsDnsConfig
Data Type: REG_DWORD
Value Data: 1

Sind nun schon Namespaces vorhanden, müssen diese inkl. den Targets komplett neu eingerichtet werden. Am einfachsten mit dfsutil.exe arbeiten, Targets exportieren, Export File mit FQDN Namen umschreiben und in die neu konfigurierten Namespaces wieder importieren.

Link:
http://support.microsoft.com/kb/244380/en-us

Normal werden die Proxysettings über User Configurations gesteuert. Dies kann z.B mit den Explorer Maintenance Policy erfolgen.
Es kann aber durchaus nützlich sein, dass die Settings der Proxyeinstellungen über Computer Configurations (Computer Objekt) gesteuert werden können. So können z.B mit OUs Desktops und Notebooks unterschieden und entsprechend über die GPO anders konfiguriert werden.

Damit dies möglich ist, muss die Policy “Make proxy settings per-machine (rather than per-user) aktiviert werden. Diese ist unter Computer Configuration/Administrativ Templates/Windows Components/Internet Explorer zu finden.

Die Settings selbst können nach wie vor im Explorer Maintenance Objekt zentral über den User konfiguriert werden. Es wird keine doppelte Pflege der Settings nötig.

Die Internet Explorer Maintenance Group wird von den Clients als Template angeschaut und somit nur beim ersten Login des User gezogen (und natürlich bei jeder Änderung von dem GPO)
Werden nun Änderungen von den Usern durchgeführt (Proxy, Trusted Sites, local Sites, Startpage, IE-Settings etc…), stimmen danach die Parameter nicht mehr und werden bis zu einer Änderung der Explorer Maintenance GPO auch nicht mehr gesetzt.

Dies kann mittels der Policy “Internet Explorer Maintenance Policy Processing” unter Computer Configuration\Administrative Templates\System\Group Policy umgangen werden, damit das Template bei jedem Boot neu geladen wird. Zusätzlich ist noch SlowLink Detection und Background Processing einstellbar.

Weitere Infos:
http://support.microsoft.com/kb/306915/en-us