Landschaftsgest

Hi, wenn bei einem GPO eine Einstellung gesetzt und wieder mit "nicht konfiguriert" versehen wird, "zählt" dieses "nicht konfiguriert". Schön zu sehen ist so was, wenn man sich im GPMC die Einstellungen anzeigen lässt. Alle Werte, die noch nie angefasst wurden, haben auch den Wert "nicht konfiguriert", tauchen hier aber nicht auf. Wenn allerdings eine Einstellung wieder zurück gesetzt wurde auf "nicht konfiguriert", wird diese Option bei der Zusammenfassung angezeigt. Dann natürlich mit "nicht konfiguriert"... Wird beim Login nun ein GPO verarbeitet, die so einen "nicht konfiguriert" (vormals konfigurierten) Wert hat, stört sich ein nachfolgendes GPO, in dem nun wieder ein Wert für diese Option gesetzt ist. Das war eigentlich des Rätsels Lösung...

Hi ja, das war mein Kollege. Eigentlich wollt eich das übernehmen... Na ja, Mittlerweile haben wir es hinbekommen. Ein Policy, die vor der Ordnerumleitung abgearbeitet wurde, hat verhindert, dass die Dokumente umgeleitet wurden. Funktioniert nun wieder.

Hallo zusammen, in einer GPO wurden Ordnerumleitungen konfiguriert. Es werde z.B. Desktop, Bilder, Download, Dokumente und noch ein paar weitere Ordner auf ein Netzlaufwerk umgeleitet. GPO ist aktiv und funktioniert auch soweit bis auf eine "Kleinigkeit": Der Ordner "Dokumente" bzw. "Eigene Dokumente" bleibt lokal. Im Share werden die funktionierenden Ordner angelegt. "Dokumente" taucht dort nicht auf. Habe schon viele Informationen dazu gesehen. Aber alles, was ich bisher probiert habe, war erfolglos. Selbst ein neues GPO, in dem nur "Dokumente" umgeleitet werden, habe ich erstellt, auf eine "Sonder-OU" verlinkt, User dort platziert, gpupdate etc. durchgeführt: ohne Erfolg. Per gpresult wird angezeigt, dass die entsprechende GPO angewendet wird. (sonst würden die restlichen Ordner ja auch nicht umgeleitet werden) Da es sich um eine "alte" AD-Struktur handelt, würde ich gerne wissen, wie ich da weiter komme. Also welche "Tools", Befehle oder was auch immer ich nutzen kann, um dem Problem auf die Schliche zu kommen. DC´s sind 2012R2 Fileserver ist 2008R2 Clients laufen mit W7 32 und 64 Bit Nach viel "Rumspielerei" habe ich auch schon die Registry auf einem Client "manipuliert". Unter HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders habe ich bei "Personal" den richtigen UNC-Pfad zum Share eingetragen. Damit hat das dann funktioniert. Daher kann ich wohl den File-Server und die dortigen Berechtigungen ausschließen. Ein wünschenswerter Zustand ist dies allerdings nicht... Eventlogs auf den betreffenden Systemen sind soweit ohne Auffälligkeiten. So, nun sind die gefragt, die dieses Problem evtl. schon mal hatten. Ganz alleine stehe damit ja nicht da. Denn in den weiten des Internetzes gibt es haufenweise Threads zu diesem Problem. Aber wie schon weiter oben geschrieben, hat mich das (noch) nicht zum Ziel gebracht... Vielen Dank schon mal für hilfreiche Kommentare

Hi Nils, besten Dank für die aufklärenden Worte. Im DHCP ist "leider" Option 015 - DNS Domain Name gesetzt. Das kann ich dann raus nehmen. Den Rest werde ich dann sehen, wenn es an die Testphase geht. Vielen Dank an alle Beteiligten. Gruß L

Das "passende Design" interessiert mich nun aber doch... Vom Prinzip her dürfte es "nur" die DNS-Weiterleitung sein. Wenn die bei einem migrierten System so funktioniert, dass dieses System die neue Welt findet, dann sollte es technisch keine Hürde darstellen. Allerdings kann ich aktuell nicht beurteilen, was "Sonderlocken" im DHCP sind...

Wenn ich - theoretisch - die Systeme in der neuen Umgebung manuell konfiguriere (IP), ist es sicherlich kein Problem. Aber da es sich auch um PC´s mit automatischer IP-Konfiguration (DHCP) handelt, wird dies sicherlich nicht ganz einfach werden. Die migrierten PC´s bekommen ja immer noch die DHCP-Settings der alten Umgebung. Theoretisch sollten sie ja die neue Umgebung (DC und was sonst alles noch migriert wurde) per DNS-Weiterleitung finden. Aber ich habe aktuell keine Möglichkeit, das mal eben in einem Lab zu testen. Dass das nicht gerade die beste Idee ist, war mir klar. Aber die vorhandenen Netzwerkstrukturen sollen weiter benutzt werden - wenn es geht... Edit: Es geht um eine eher kleine Umgebung mit max. 200 Systemen/Accounts

Hm, ich dachte mir sowas, daher der Fred hier. Na ja, schaun wir mal, was da noch so an "Meinungen" kommt... THX

Hallo Gemeinde, ist es möglich, bei einer Cross-Forest-AD-Migration (Heraustrennen einer Abteilung aus dem Unternehmen) das selbe IP-Netz für die neue Struktur zu nutzen, wie die Quell-Struktur? Habe da "Bedenken" beim Thema DNS. Wenn ein PC migriert wurde, bekommt er ja noch die IP/DNS-Informationen vom "alten" DHCP-Server. Da für das Vorhaben eine DNS-Weiterleitung konfiguriert werden muss, frage ich mich, ob diese dann auch für die migrierten PC´s/Systeme funktioniert? Für alle hilfreichen Antworten bin ich dankbar. Gruß L

Auch Moin, den Standort würde ich dann der Zentrale zuordnen. Den DHCP-Server anpassen, damit ein DNS-Server ebenfalls aus der Zentrale genutzt wird. Die DHCP-Server-Autorisierung für den Dienst sollte erhalten bleiben, oder? Dann kann ich "quasi" loslegen. Vielen Dank & Gruß Landschaftsgestalter

Hallo zusammen, die Kurzfassung steht ja eigentlich schon in der Überschrift. Was ich allerdings wissen möchte ist, was erwartet werden kann, wenn ein DC an einem entfernten Standort zum Member-Server heruntergestuft wird. Der DC führt aktuell zusätzlich DHCP und DNS aus. Was passiert, nach dem er mit dcpromo heruntergestuft wurde hinsichtlich DNS, DHCP und AD-Authentifizierungen? Es gibt ansonsten keine weiteren DC´s am Standort. Hintergrund: Exchange 2016 soll eingeführt. Dazu muss das Function Level Windows Server 2008 R2 sein. Der DC am entfernten Standort läuft allerdings noch mit Windows Server 2003. Daher kann das Function Level nicht auf Windows Server 2008 R2 angehoben werden. Die Gründe für den DC am entfernten Standort sind heute nicht mehr gegeben (Traffic durch Authentifizierungen und DNS-Anfragen zum HQ sollten vermieden werden, da nur "dünne" Leitung vorhanden war). Mit der heutigen Infrastruktur wird der DC vor Ort nicht mehr zwangsläufig benötigt. Daher die Entscheidung den DC erst mal herunter zu stufen und später dann ganz abzuschalten. Vielen Dank schon mal für evtl. Antworten

Soo, was soll ich sagen: Wie schön wäre es, wenn das DNS funktioniert, wie es soll... Habe ja 2 Alt-DC´s. Beide sind DNS-Server. Alt-DC1 kann alles korrekt auflösen, Alt-DC2 nicht - jedenfalls was die Auflösung von Namen aus der neuen Welt angeht... Ich denke mal das Thema "Reverse Lookup" kann et acta gelegt werden... Besten Dank für eure Hinweise Cheers

Hi, tja, da werde ich auf jeden Fall mal drüber nachdenken... Die Frage, die sich mir dann stellt, ist: Wenn der "alte" DNS-Server eine Reverse-Zone hat die z.B. so aussieht: 0.1.in-addr.arpa und die neuen DNS-Server IP-Adressen wie folgt besitzen: 1.0.5.0/16 wie geht der "alte" DNS-Server damit um? Prüft er erst im "kleineren" Netz - also in der dafür vorgesehen Reverse-Zone - oder schaut er einfach in die "große" Zone, und geht dann je nach Ergebnis in die "kleinere" Reverse-Zone? Noch mal eine Verständnis-Frage: Wird eigentlich die Reverse-Zone aus der jeweils anderen AD-Umgebung benötigt? Aufgefallen ist mir das ganze Dilemma nur, weil ich beim Einrichten des Forwarders auf dem alten DNS die Namen von irgendwelchen Systemen bekommen habe, die es gar nicht gibt. Hier werden ja die IP-Adressen der zuständigen DNS-Server für die jeweilige Domänenweiterleitung eingetragen. Manuell kann man an der Stelle nichts konfigurieren, oder? Cheers

Hallo zusammen, habe da mal eine Kleinigkeit: bei einer Cross-Forest-AD-Migration gibt es in der alten Welt auf den DNS-Servern eine Reverse-Lookup-Zone für ein sehr großes Netz. Die neue Welt befindet sich unglücklicher Weise in einem Teil dieses IP-Netzes. Beim Einrichten der DNS-Forwarder in der alten Welt fiel auf, dass die DNS-Server aus der neuen Welt nicht ordnungsgemäß per IP aufgelöst wurden. Eine Namensauflösung (Name -> IP) funktioniert allerdings. Nur reverse gibt es halt ein "kleines" Problem. Dieses möchte ich nun umgehen. Die Konfiguration der alten Welt ist allerdings alles andere als "best practice". Die erwähnte Reverse-Zone ist auf dem alten Windows-DNS eine sekundäre Zone. Der Master für diese Reverse-Zone ist ein nicht-Windows-DNS-Server. Nun könnte man diesen nicht-Windows-DNS-Server manuell konfigurieren, so dass in der Reverse-Zone die richtigen Namen hinter den IP-Adressen gefunden werden können. Allerdings bedeutet dies einen relativ großen Aufwand... Noch kurz eine Anmerkung: Die entsprechenden IP-Adressen werden nicht doppelt verwendet. Die Reverse-Zone in der alten Welt wird "automatisch gefüllt" - heißt, es gibt nur die Einträge in der Zone aber tatsächlich werden diese IPs nur als eine Art "Platzhalter" eingetragen... Wie können wir das nun umgehen? Fragen nach dem "Warum wurde das denn überhaupt so gemacht?" kann ich nicht beantworten... Ebenso wenig brauche ich keine Hinweise, dass man "so etwas" nicht macht... Cheers

Hi ho, bräuchte mal kurz eine "Vorgehensweise", wie ein Knoten in einem TMG-Array wiederhergestellt werden kann. Ich habe allerdings nur folgende Infos: TMG 2010 mit Server 2008R2 es gibt keinen extra Konfig-Server Es sind TMG-Server zu einem Array zusammen "geschaltet". Ich weiß, dass ein einzelner Knoten per Konfig export und später dann mit Konfig Import "relativ" einfach wiederhergestellt werden kann. Aber die Konfig das "schrubbeligen" Knotens ist nicht vorhanden, weil der Knoten nicht mehr da ist... Wie wäre hier zu verfahren? THX schon mal

Hallo zusammen, suche mir gerade nen Wolf. Ich habe in Erinnerung, dass ein MS-Cluster in einer virtuellen Umgebungen einige Limitierungen hat. (z.B. kein Thin-Provisioning der Disks, keine DRS oder HA-Mechanismen...) Nun finde ich diesen Artikel abernicht mehr. Hat sich da etwas geändert? Also gibt es diese Limits nicht mehr? Ich würde dies gerne noch mal nachlesen... THX