soulseeker

Hi@all, mir ist aufgefallen, dass die PTR-Einträge von diversen (aber nicht allen) Clients, die in mehreren Netzen sind (LAN/WLAN), oft doppelt auftauchen, also nicht dynamisch aktualisiert werden. Der Host (A)-Eintrag ist nicht doppelt und aktualisiert sich auch immer ... Das Intervall für Nichtaktualisierung ist derzeit 1, das Aktualisierungsintervall 7 Tage ... der Scavenging-Prozess läuft alle 3 Tage über das DNS. Die Leasedauer ist 8 Tage. Die DNS-Server sind AD integriert und laufen unter Win2016. Dynamische DNS-Aktualisierungen per DHCP ist (momentan noch) für alle Scopes aktiviert. Betroffen sind die Clients, die zwischen dem WLAN und LAN-Scope hin- und herwechseln. Leider auch jede Menge Androids/Iphones ... deshalb überlege ich, ob die dynamische DNS-Registrierung per DHCP überhaupt so ene gute Idee ist ... ich würde am liebsten nur Windows-Rechner im DNS sehen und nicht unbedingt "Iphonevonxyz" - das ist leider netztechnisch nicht sauber hier getrennt. Was für eine Einstellung könnte ich aber wegen der doppelten PTRs noch übersehen haben? Viele Grüße Marcel

Ok, das ist jetzt peinlich. Das war wohl doch nur ein User, der in einer aufgebrochenen OU war. Sorry und trotzdem danke ....

In der Sicherheitsfilterung steht nur der Standard "authentifizierte Benutzer". Aber die Computer brauchen doch keine speziellen Berechtigungen ... die GPO hängt (hing) halt nur ganz oben und wurde dann auf die tieferen OUs vererbt, wo irgendwo die Benutzer liegen, die ja hier die Berechtigung haben.

Dürfte doch hier keine Rolle spielen (ist auch nicht aktiv), da diese GPO doch auf "alle" OUs vererbt wird, also auch auf "irgendwelche" OUs mit Benutzern. Dort sollte doch dann der Benutzer-Teil dieser GPO ausgeführt werden. Und warum funktioniert das ganze dann zwei OUs tiefer ... Und warum bei Clients? Zu viele warums ... ;)

Nein, ist in diesem Fall nicht unterbrochen... aber selbst wenn, die Gpo soll ja beim User ziehen und nicht auf dem Computerobjekt. Zum User wurde sie vererbt.

Hi@all, ich habe gerade ein merkwürdiges Problem entdeckt ... und zwar habe ich eine neue GPO mit Benutzereinstellungen erstellt und direkt im root verlinkt, Die Richtlinie wird dann vererbt. User, die sich an Servern anmelden, haben die Einstellungen jedoch nicht erhalten und gpresult /h zeigt auch grund: abgelehnt - leer. Ich habe mir nochmal die OU angeschaut, in der diese User liegen - dort wird die Richtlinie auf jeden Fall vererbt. User, die sich an Clients anmelden, ziehen diese GPO jedoch. Ein WMI-Filter ist auf dieser GPO nicht aktiv. Nachdem ich die GPO tiefer verlinkt habe, wo dann die Users-OUs beginnen (und die Richtlinie ohnehin besser aufgehoben ist), funktioniert es jedoch sofort sowohl bei Clients als auch Servern. Eine andere GPO, die ebenfalls von ganz oben kommt und ebenso nur Usereinstellungen enthält, wurde bislang immer angewandt, dort habe ich allerdings die Server per WMI absichtlich ausgenommen. Woran kann das liegen? Viele Grüße Marcel

Hab leider gerade kein Testsystem mit dem Fehler. Ich schaue mir das nach meinem Urlaub noch mal genauer an, ich wollte jetzt erst mal nur sicher sein, dass das Update zunächst wieder zurückgestellt wird. Danach lasse ich es nochmal über meine Testgruppe laufen.

Aha ok. Das findet hier einmal am Tag statt. Wenn die Installation beim Client also Fehlschlag sollte und mittags wieder der Wsus kontaktiert wird, verschwindet das Update also bei zurückgezogener Genehmigung aus der Pipeline? Nebenbei - verteilt ihr die Funktionsupdates eigentlich per Wsus? Vg und danke Marcel

Hi@all, ich habe mal eine Verständnisfrage zum WSUS. Ich habe (versehentlich) ein Funktionsupdate freigegeben (1803), das auf vielen Clients Probleme bei der Installation verursacht. Bis ich dazu komme, das Problem zu lösen, habe ich die Genehmigung erst einmal zurückgezogen. Eine Entfernung per WSUS geht ja bei diesen Upgrades ja ohnehin nicht. Wenn der Client das Update aber bereits downgeloaded hat, ist es aber bereits zu spät, oder? Beim nächsten Neustart wird das Update dann automatisch installiert ... die einzige Möglichkeit, die man dann hat, wäre den Win Update-Dienst zu beenden und den Ordner "Softwaredistribution" zu löschen. Also meine eigentliche Frage - wenn ich die Genehmigung zurückziehe und das Update (bzw in diesem Fall ein Upgrade) bereits vom Client gezogen wurde, ändert das nichts mehr, oder? VG Marcel

Da hast du grundsätzlich recht ... aber es gibt hier auch jede Menge IP-Telefone, Accesspoints etc bei denen ich nicht genau weiß, ob diese nicht evtl. doch gerne über DNS kommunizieren möchten. Außerdem evtl. noch den ein oder anderen A-record, der mal manuell erstellt wurde (für was auch immer). Ich bin da lieber etwas vorsichtig :).

Naja, evtl. kurzzeitige Serviceunterbrechungen, wenn irgendwas kurz mal nicht per DNS erreichbar ist. Außerdem kann ich nicht immer unterscheiden, ob es sich um einen "echten" statischen DNS-Eintrag handelt, oder es ein "statischer Bind-Eintrag" ist, der aber eigentlich ein dynamischer sein sollte und der wieder von selber auftaucht.

Hi, danke, interessanter Artikel ... Im wesentlichen ist es ja schon so konfiguriert, außer das im DHCP die DNS-Option derzeit auf "immer aktualisieren" steht. Ich vermute mal, dass Iphones und Androids beim DHCP-Server ohnehin eine Aktualisierung anfordern werden, so dass ich damit nicht viel gewinnen werde. Mein "Haupt-Problem" sind ohnehin die abertausende an alten statischen Einträgen, die ich nur manuell löschen kann.

Hi, ja, DHCP ist derzeit so konfiguriert ... und wir nutzen User Cals. Ich muss jetzt nicht zwingend Androids und Iphones im DNS auflösen, daher meine Frage, wie ihr das mit der DHCP-DNS-Aktualisierung so haltet. Ich denke mal, wenn ich für den gesamten WLAN-Scope die dynamische Aktualisierung abschalte, bin ich schon mal einen Schritt weiter ... die Windows-Devices dürften sich dann ja trotzdem noch über die Nic-Einstellung im DNS registrieren.

Hallo zusammen, ich muss leider nochmal mit einer Frage nerven :) Ich habe vor kurzem unseren DNS-Server von bind zu Windows migriert, da gab es das unschöne Problem, dass sich alles und jeder im DNS registriert hat und die Einträge direkt "statisch" waren. Das sind sie unschönerweise auch nach der Migration, weshalb ich derzeit damit beschäftigt bin, die alten statischen Einträge aufzuräumen. Dabei habe ich festgestellt, dass Androids und Iphones sich immer noch selbst registrieren können (dann aber dynamisch) und das gefällt mir nicht wirklich. Zwischen unser Client-Nomenklator steht dann android_1234 und lieschenmüllers_iphone. Wir haben derzeit noch kein separaten Scope für Mobile devices. Im DNS ist "nur sichere" aktiv. Im DHCP ist dynamische Registrierung jedoch erlaubt. Ich hatte eigentlich erwartet, dass sich trotzdem nur Domänenmitglieder dynamisch registrieren können, aber da im DHCP Option15 mit Domänensuffix gesetzt wird, reicht das wohl aus, um einen Client als "sicher" einzustufen. Mich würde mal interessieren, wie ihr sowas verhindert. Mir fallen jetzt nur folgende Möglichkeiten ein: 1. Separates VLAN für mobile devices mit eigenem DHCP-Scope ohne Option15/dynamische Registrierung 2. Dynamische DNS-Aktualisierung für den WLAN-Scope ausschalten und auf die Option "Adressen dieser Verbindung in DNS registrieren" im Windows-Netzwerkadapter vertrauen Viele Grüße Marcel

Allerdings sind ein paar Sachen immer noch etwas strange. Ich habe jetzt „nur sichere Updates“ angetickt und das DNS mal etwas aufgeräumt, da z.B. auch hunderte Androids dort eingetragen waren. Allerdings registrieren die sich nun immer noch, bzw. wieder. Dann habe ich Subdomains mit mx-Einträgen (für SAP) angelegt, die nicht automatisch auf den anderen DNS-Servern erscheinen … erst, wenn ich diese auch auf dem anderen DNS anlege, erscheinen die jeweiligen DNS-Einträge. Ist das evtl. normal? [edit} Die Androids reggen sich wohl wegen der DHCP-Option "DNS-A-und PTR-Einträge für DHCP-Clients, die keine Aktualisierung erfordern ... Das mit den Subdomains hake ich mal als "seltsam, aber so steht es geschrieben" ab ...

Hi, Ich habe mir einen DC geclont und _msdcs neu angelegt ... danach kann ich DNS trotzdem nur für die Gesamtstruktur replizieren. In den Subdomains steht die Option übrigens überall auf dem mittleren Setting "... in dieser Domäne". [edit] So, heute hatte ich eine Remotesession mit MS und jetzt funktioniert es. Ursache: Die AD-Verzeichnispartition DefaultDomainDNSZones war korrupt - diese wurde gelöscht und neu angelegt. ntdsutil ntdsutil: partition management server connections: connect to server localhost server connections: q list delete nc DC=DomainDNSZones,DC=contoso,DC=local Danach DNS Server-Dienst neu starten, die Partition wird neu erstellt repadmin /syncall Anschließend kann man die Zone ins AD schicken VG Marcel

Kann durchaus sein, aber das war dann vor meiner Zeit.

Sorry, alter DC bedeutet nur "vor längerer Zeit installiert", nicht gelöscht. Der ist also noch aktiv.

Irgendwie ist hier immer noch einiges "komisch". Die Clients stehen durch die Gruppenrichtlinie alle auf NT5D5 und jeder hat als Zeitserver irgendeinen Domänencontroller. Das dürfte ja so richtig sein, denn die Domänencontroller haben als Zeitserver alle den PDC und der PDC pool.ntp.org In der Praxis ist es nur so, dass ich heute herausgefunden habe, dass ein (relativ neuer) DC ohne vorherige manuelle NTP-Konfiguration sich irgendeinen alten DC als Zeitserver gegönnt hat. Dieser alte DC stand auf "local cmos". Scheinbar wird die Client-GPO nicht auf die anderen Domaincontroller ausgerollt (auch wenn gpresult was anderes sagt), denn alle anderen DCs stehen auch nicht als NT5D5 sondern auf allsync ... aber immerhin nutzen diese nicht "local cmos". Ich habe dann auf dem alten 2008-DC in der Registry das gleiche eingetragen, wie auf den DCs , die korrekterweise mit dem PDC syncen und das Announceflag auf "a" gesetzt, dann hat er sich auch den PDC geschnappt. Der andere, "neue" DC hat als Zeitserver aber immer noch den alten DC (den ich gerade manuell "korrigiert" habe). Was läuft denn da noch falsch? Die Zeiten passen jetzt zwar, aber warum stehen die DCs auf "allsync" und warum synct ein DC mit einem "nicht PDC", so wie ein Windows client? [edit] Ich habe auf dem DC nochmals das hier ausgeführt: w32tm /config /syncfromflags:domhier /update Jetzt passt alles.

Ja, so sieht es (jetzt) nach Neuerstellung aus. Vorher war mcds nur als Unterordner/Subdomain unter meiner root-Domain zu finden.

Hi, Ich habe mir einen DC geclont und _msdcs neu angelegt ... danach kann ich DNS trotzdem nur für die Gesamtstruktur replizieren. In den Subdomains steht die Option übrigens überall auf dem mittleren Setting "... in dieser Domäne".

Ok, das mit der Standard-Verzeichnispartition war wohl falsch. Was bei meinem DNS-Server auf jeden Fall "anders" ist, ist der msdcs-Eintrag. Dieser existiert nur als Unterordner unter meiner root-Namenszone contoso.de Ich habe diesen auf dem geklonten DC gelöscht und versucht, neuzuerstellen: Delete the _msdcs subfolder under contoso.com Create a zone called _msdcs.contoso.com, allow Secure Updates, and set the Replication Scope to Al DCs in the Forest. Right-click contoso.com, create New Delegation, type in _msdcs, then give it itself as the IP address, then run: ipconfig /registerdns restart the netlogon service (whether in Services, or net stop netlogon && net start netlogon) Hat augenscheinlich geklappt, aber das ändert leider nichts am Grundproblem. Der DNS-Server crasht immer noch, wenn ich die mittlere Option wähle (nur im AD der eigenen Domäne). Wähle ich aber die Option "auf allen DNS-Servern der Gesamtstruktur", dann klappt es übrigens (auch ohne das Neuanlegen von mcds). Ist aber ungünstig, da ich nicht möchte, das unser DNS in die Subdomains repliziert wird. Mal schauen, ob dem Support noch was einfällt. Nebenbei - haltet ihr die Neuerstellung des msdcs-Eintrages für wichtig und sinnvoll? Das der so aufgebaut ist, wie aktuell, liegt vermutlich am bind-Import.

Ok, einen Schritt bin ich weiter - es fehlt offenbar die Standard-Verzeichnispartition im Namenskontext DC=ForestDNSZones,DC=Domain,DC=DE Die kann ich ja über den DNS-Server erstellen. Ich werde vorher aber testweise mal einen prod. DC klonen und in einem isoliertem Netz hochfahren ... dann führe ich die Änderung durch und schaue, ob ich die Zonen danach AD integrieren kann.

Ich mache mal einen auf ... ich werde dann mal hier berichten, was dabei rauskommt.

Hi, ja, ist schon wichtig und ist eine mittelständische Umgebung. Auch wenn man sich jahrelang mit Bind begnügt hat, will ich das unbedingt gerade ziehen. Hier registriert sich z. B Lieschen Müllers Iphone fröhlich selber im DNS, ein ziemliches Chaos. Ich habe leider auch nichts brauchbares ergoogelt und bei solchen Fehlern im Zusammenhang mit dem Ad ist mir nicht wohl dabei, selber zu fummeln. Trotzdem Danke und Gruß Marcel