soulseeker

Ach so - fun fact - Bedingte Weiterleitungen kann ich im AD speichern.

Hi@all, ich habe vor einigen Wochen unsere Zonen von einem alten Bind-Server zu einem Windows DNS-Server migriert. Primärer DNS ist nun ein Win2016-DC, sekundäre ein weiterer 2016-DC, sowie noch die beiden (alten) Bind-Server. Soweit läuft alles, ich möchte im letzten Step nun die Zonen im AD speichern (sichere Updates aktivieren), sowie Scavenging aktivieren. Die Zonenalterung ist schon aktiviert, es fehlt hier nur noch die globale Option "Veraltete Ressourceneinträge aufräumen". Die Speicherung im AD führt jedoch zu einem Problem. Ich habe dies zunächst bei einer (nicht ganz so wichtigen) Reverse Lookupzone durchgeführt. Dabei erscheint die Fehlermeldung: "der Replikationsbereich konnte nicht gesetzt werden. Weitere Informationen erhalten Sie unter ... . Ein Serverfehler ist aufgetreten". Danach stützt der DNS-Service dankenswerterweise ab. Wenn ich den Service neu starte, ist die Option "im AD speichern" zwar aktiv, aber mit der Win2000-Kompatibilitätsoption. Sobald ich die mittlere Option "auf allen DNS-Servern, die in dieser Domäne ausgeführt werden" anklicke, erscheint der gleiche Fehler. Ich habe allerdings Zweifel, ob mit der Win2000-Kompatibilität wirklich eine AD-Replikation erfolgt, da immer noch das Zonenfile unter c:\windows\system32\dns liegt. Auf meinem Testserver verschwindet das bei einer Änderung auf AD-Replikation. Kennt jemand dieses Problem? Ich finde bislang keine einfache Lösung, nur sowas wie hier: https://social.technet.microsoft.com/Forums/windowsserver/en-US/29025d19-e542-4821-a0ea-8bc178de61d3/issue-creating-adintegrated-dns-zones?forum=winserverDS Grüße Marcel

Ich meinte die Client-Richtlinie. Ok, wenn ich sie ganz oben habe kommt diese ja zuerst und die PDC Richtlinie (mit wmi Filter) danach. Ich dachte erst, ich verknüpfe die Client Richtlinie auf einzelne Ous aber das bringt mir ja nix.

ok, in der Anleitung stand halt evtl dd-Richtlinie verwenden. Ich habe ja ohnehin schon eine eigene gebaut, die verknüpfen ich dann mit meinen Clients und Server-Ous und alle sind froh und synchron. Müssen die anderen DCs denn diese Richtlinie auch bekommen? Danke nochmals!

Ok, jetzt habe ich aber doch noch zwei Fragen :) ... Ich habe die GPO für den PDC aktiviert, hat funktioniert. Dann habe ich die Client-GPO auf einem Test-Client aktiviert, nach einem Neustart fragt dieser dann auch meinen PDC. Aber warum muss in dieser GPO time.windows.com stehen? Wenn ich diese Einstellung in die Default Domain Policy packe, dann wird diese doch auch wieder auf den PDC ausgerollt ... soll ich die PDC-GPO dann "erzwingen", damit diese last writer bleibt?

Ich gehe auch mal davon aus, dass hier irgendwas manuell zerfummelt wurde. Ich gehe dann mal den Artikel mit der GPO durch, vielen Dank euch :)

Hi zusammen, ich habe heute einen neuen (2016)-DC als vm installiert und diesem alle FSMO-Rollen übertragen. Anschließend habe ich den Zeitserver eingerichtet mit w32tm /config /manualpeerlist:“0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org“ /syncfromflags:manual /reliable:yes /update Der neue DC hat den neuen Zeitserver auch, aber die anderen DCs benutzen immer noch den "alten" 2008-PDC, der aber keiner mehr ist. Wie lange dauert das, bis sich das "herumspricht"? Eigentlich bin ich davon ausgegangen, dass sich das zügig repliziert. Danke und Grüße Marcel

Ich weiß jetzt, woran es liegt. Der Win DNS hat vom bind scheinbar eine DNS-Zone ohne dieses Timestamp-Feld erhalten. Daher bekomme ich auch die Fehlermeldung beim aktivieren der Alterung - dann vervollständigt der Win-DNS-Server seine DB mit dieser Spalte. Habe ich bei einer anderen, weniger gut gefüllten Zone gerade ausprobiert. Alterung aktiviert, DNS neu gestartet, zack, Timestamp erscheint Bei der großen Prod-Zone habe ich mich das allerdings noch nicht "getraut". Ich denke mal, dann werde ich u.a. das Problem haben, dass alle A-Records statische Einträge werden und nicht von der Alterung erfasst werden. Letztlich werde ich wohl nach und nach alle Clients aus dem DNS entfernen müssen, damit sie sich "dynamisch" neu registrieren.

Moin, vielen Dank für die Antwort und die Hilfe. Hast du denn vielleicht auch schon einmal von diesem merkwürdigen Problem mit der fehlenden Spalte gehört? Wenn ich die DNS-MMC von einem anderen Client lade, dann fehlt diese Spalte auch.

Hallo zusammen, mich plagt gerade folgendes Problem: Zunächst einmal gibt es hier ein Windows AD mit Linux (Bind)-DNS-Servern. Fragt mich bitte nicht warum :(. Diese sollen nun aus verständlichen Gründen abgelöst werden. Ich habe daher auf einem Windows2016-DC die DNS-Rolle konfiguriert, die Zone übertragen und diesen zum primären DNS-Server gemacht. Sekundär ist derzeit einer der alten Bind-Server. Soweit ist erst einmal alles bestens, außer, dass ich noch kein Scavenging konfiguriert habe und die Zone noch nicht AD-integriert ist. Der DNS-Server an sich funktioniert. Sobald ich in der Forward-Lookupzone aber nun die Alterung einrichten will, erscheint folgende Meldung "Sie habe die Alterung auf dem primären Standardserver aktiviert, wodurch sich das Zonendateiformat ändert ... die Zonendatei wird möglicherweise von DNS-Servern auf Windows 2000/2003 nicht geladen". Ich habe es daher noch nicht aktiviert, da ich dann nicht sicher bin, ob der Bind noch was mit diesen DNS-Daten anfangen kann. Deswegen ist das ganze auch noch nicht im AD gespeichert. Bevor ich die Zone ins AD repliziere, hätte ich sie auch gerne "gescavenged", da sich durch jahrelanges nicht bereinigen und der nicht sicheren dynamische Updates jede Menge Müll angesammelt hat. Zweites Problem - mir fehlt die Spalte "Zeitstempel" in der übertragenen Zone. Die Zeitstempel sind aber in den einzelnen A-Records sichtbar, wenn diese dynamisch aktualisiert worden sind. Es fehlt nur die Spalte im DNS-Manager. Ist das ein Win2012/2016-Bug? Ich sehe nur "Name, Typ, Daten". In den Delegierungen bzw. Forwardern ist die Spalte übrigens zu sehen. Ich habe nur diesen ähnlichen Fall gefunden, aber ohne Lösung - https://social.technet.microsoft.com/Forums/en-US/b60d251e-f4fe-4ada-afd9-39388cf99abb/missing-column-in-dns-manager?forum=winserverDS Ich wäre ja kein Problem, noch einen zweiten Windows-DNS-Server aufzusetzen, aber ich kann derzeit noch nicht auf den alten Bind-Server verzichten, da dieser als DNS-Server für einen Wust an Linux-Servern fungiert. Ich kann die IP auch nicht ohne weiteres einem anderen Windows-DNS-Server zuweisen, da der Bind-Server schlauerweise auch noch andere Funktionen hat. Also wäre es ganz gut, wenn der als sekundärer DNS-Server weiter hier rumgammelt. Danke für eure Hilfe VG Marcel

So, hab mal wieder Zeit dafür gefunden und siehe da - nachdem ich Outlook anywhere konfiguriert und das Zertifikat des Exchangers zur vertrauenswürdigen Stammzertifizierungsstelle erklärt habe, funktioniert es mit entsprechenden Exchange-Proxyeinstellungen im Outlook-Profil. Danke nochmal an alle!

Danke, ich versuche das mal. Heute waren leider andere Projekte wichtiger.

Mit Einträgen in einer Hosts-Datei. Per Telnet oder Browser erreiche ich den Hostnamen ja auch. Wie gesagt, vom der Test-Umgebung komme ich problemlos ohne DNS-Konfiguration zum Prod-Exchange. Outlook anywhere ist auf dem Ex2007 scheinbar doch aktiv, wird aber nicht genutzt. Ich muss mir mal anschauen, wie ich Outlook anywhere auf dem 2013 konfiguriere. Ich dachte eigentlich, das ist out of the box aktiv und muss nur veröffentlicht werden. Das fällt hier ja weg, da der Testserver über alle Ports vom Client erreichbar ist.

Die virtuellen Verzeichnisse schaue ich morgen nach. Bei 2013 habe ich da noch nichts angefasst. In der Testumgebung setze ich nur selbst erstellte Zertifikate ein. Ich kann mal versuchen, das auf meinem Prod-Client zu installieren, aber derzeit komme ich ja nicht mal so weit, dass Outlook den Server kontaktiert. Schon klar, dass der Exchange2013 nicht korrekt konfiguriert ist, deshalb frage ich ja ;). Aber nochmal zur Sicherheit - muss für einen Exchange-Zugriff von Domäne1 auf Domäne2 wirklich Outlook anywhere mit ins Spiel kommen? Kann ich das ohne eine CA in der Testdomäne überhaupt ans Laufen bekommen?

Das klingt zwar alles recht logisch, aber von der Test-Umgebung nach Prod funktioniert es ja auch. Wir nutzen produktiv noch Exchange 2007, da ist Anywhere nicht konfiguriert, es gibt auch keine DNS-Weiterleitung auf dem Test-DNS. Das Zertifikat habe ich in der Test-Domäne auch nur bei der Nachfrage von Outlook auf dem Client installiert. Soweit komme ich aber gar nicht, wenn ich mich von der Prod-Domäne in die Test-Domäne verbinden will. Derzeit wird der Server schon bei der Profilerstellung nicht gefunden. Soweit war ich aber beim ersten Versuch zumindest schon mal, da wurde der Exchange gefunden und die Mailbox aufgelöst. Nur beim Start von Outlook ging es dann nicht weiter. Nochmal zusammengefasst: in der Testumgebung läuft Ex2012 und in der Produktivumgebung Exchange 2007. Outlook kommt aus der Produmgebung nicht zum Exchange2012, aber die Verbindung aus der Testumgebung zum Exchange 2007 klappt (ohne Anywhere, DNS).

Hi@all, ich hätte da mal eine Frage. Ich habe zu Testzwecken eine Testdomain + Exchange2013 aufgesetzt. Innerhalb dieser Domain funktioniert alles, OWA und auch Outlook als Client haben Zugriff (läuft auf einer separaten VM mit Win7). Das ganze soll eine Testumgebung für unser Programmierer-Team werden. Leider wollen die Kollegen sich auch mit dem Outlook aus der Produktiv-Domäne und einem zweiten Profil zum Test-Exchange verbinden. Das haut aber leider noch nicht hin. Mein erster Versuch war ein DC+Ex2013 All in one-Server. Da konnte Outlook auf einem Client aus der Produktivdomäne zumindest den Server und die Mailbox auflösen, startete aber nicht, da keine Verbindung zum Exchange möglich war. Mein zweiter Versuch war, DC und Exchange zu trennen, aber jetzt findet Outlook nicht mal mehr den Exchange-Server, wenn ich ein neues Profil erstelle. Die Windows-Firewalls sind aus, telnet 25/589 funktioniert, ebenso OWA von der Produktiv-Domäne in die Testdomäne. Ich habe den Exchange2013-Server sowohl über die IP-Adresse, als auch über den FQDN (hosts) getestet. Den Exchange-Server habe ich als Proxy-Ausnahme im IE eingetragen. Übrigens funktioniert der Outlook-Zugriff aus der Testdomäne in die Prod-Domäne problemlos. Eventlogs bringen mich im Moment nicht weiter :(. Habt ihr eine Idee? Besten Dank und Grüße Marcel Hoffmann

Hi zusammen, ich habe ein merkwürdiges Problem auf einem unserer Server. Als Rolle läuft dort ein Lync-Frontend-Server - ist der einzige und somit durchaus wichtig. Letztens wollte ich einem Lync-Problem auf die Spur gehen und habe direkt auf dem Server ins eventlog geschaut ... anschließend gabe es äußerst merkwürdige Probleme mit dem Server - Dienste beendeten sich Reihenweise, MMC stürzte ab, Taskmanager ging nicht auf, lauter out of memory-Fehler, obwohl der Arbeitsspeicher scheinbar noch nicht voll war. Hat ne Zeit gedauert, bis mir klar war, dass das Öffnen des eventlog an sich das Problem ausgelöst hat. Ich kann mit diesem Server während der Arbeitszeit nicht viel experimentieren, ich würde daher heute Abend das eventlog einfach versuchen zu löschen. Ggfs mit diesem Script: Kennt jemand dieses Problem? Grüße Marcel

Hallo zusammen, ich habe einen 2012R2-Fileserver aufgesetzt, dieser hat 3 Nics in drei Subnetzen (einmal Management mit Standardgateway, zweimal "eigene" Netze für SMB ohne Standard-GW). Die gleichen Netze habe ich auf einem 2012er-Coreserver aufgesetzt. Die Nics hängen auch an verschiedenen Switchen. Wenn ich ein Iso-File vom Fileserver auf den Coreserver kopiere, dann wird eine Nic komischerweise aber nie verwendet (und zwar eine aus dem SMB-Netz). Wenn ich testweise alle verwendeten Nics deaktiviere und nur die im Multichannel nicht benutzte Nic übrig lasse, dann funktioniert der Filetransfer über diese Nic aber auch. Wenn ich dann aber wieder die anderen aktiviere, werden diese auch wieder nicht benutzt. Mir fällt als Ursache nur ein, dass eine Nic auf dem Coreserver evtl. nicht kompatibel ist. Auf dem Fileserver sind alle vom gleichen Typ, auf dem Coreserver jedoch nicht. Ich habe mal geprüft, ob die Nics auf dem Coreserver RSS und RDMA unterstützen, das ist der Fall. Hat da jemand Erfahrungen? Danke und viele Grüße Marcel [edit] Hmm ich denke ich habe es ... ich habe auf dem Coreserver Nics getauscht, so dass die beiden dedizierten SMB-Netze beide Broadcom verwenden (vorher war eine Intel im Spiel). Jetzt multichannelt es auf allen Nics.

Das hier klingt interessant: http://community.spiceworks.com/topic/478564-dfs-files-dissapearing Irgendwas mit ipv6 scheinbar ...

Hmm mit domhier steht das ganze aber wieder auf "local cmos clock" ... nicht so sinnvoll bei Azure. Nur wenn ich >w32tm /config /syncfromflags:manual /manualpeerlist:zeit.domain.de eingebe, wird der richtige NTP-Server gefragt. Mit dem "out of sync" hatte ich mich verguckt - das waren millisekunden. ;) Unwissenheit - vermutlich. Oder keinen Bock gehabt, komischerweise war der WMI-Filter schon vorhanden, nur nicht verwendet.

Ok, jetzt habe ich es kapiert, besten Dank an euch beide. Keine Ahnung, warum das hier so falsch konfiguriert war. Allerdings wundert es mich trotzdem, dass die Zeit trotz gleicher logon-server unterschiedlich war. Aber egal. Die Zeit zwischen dem Blech-DC und dem ESX-DC ist nun synchron. Bleibt jetzt nur noch mein Azure-Problem, der läuft 40 Sec nach und nutzt als Source das hier: Bei Hyper-V wüsste ich, wo ich den NTP-Abgleich mit dem host deaktivieren müsste, aber nicht bei Azure. [edit] was haltet ihr hiervon: http://stackoverflow.com/questions/17239608/can-you-setup-an-azure-server-to-sync-with-a-outside-ntp-server [edit2] das scheint es zu sein, jetzt ist auch auf der Azure-VM unser PDC-Emulator als NTP-Server eingetragen, allerdings schleicht sich nun wieder ein leichter delay von einigen Sekunden ein. Ist das normal? Ich habe mit w32tm /monitor noch nie in dem Maße angeschaut, wie heute ... Kerberos-Probleme gibt es ja eigentlich erst, wenn die Zeitserver mehr als 5 Minuten auseinander liegen.

Danke Norbert, diese Seite habe ich zeitgleich gefunden :-) Derzeit ist es wie folgt: Default Domain Policy hat NTP-Settings. Das löse ich nun also auf. Ich habe eine neue Policy erstellt, ebenso meinen WMI-Filter. Damit sollte also nur der PDC-Emulator mit dieser Policy versorgt werden. Ich verstehe allerdings Schritt zwei nicht - warum werden hier die Domainmembers mit time.windows.com konfiguriert, der PDC-Emulator aber mit pool.ntp.org? Ich denke den Domain-Members sollte ich dann den PDC-Emulator geben? Und was ich auch merkwürdig finde (sorry, wenn ich hier Unwissen offenbare) - wenn ich w32tm /query /source auf einem Client ausführe, dann verwenden alle Clients derzeit einen der verschiedenen DCs. Das wird aber nirgendwo per GPO konfiguriert, habe ich gerade mit gpresult /h geprüft. Ist es normal, dass bei unkonfigurierten Clients in einem AD die DCs automatisch als Zeitserver verwendet werden?

Ok, ich sehe gerade das die NTP-Einstellung in der Domain controllers policy vorgenommen wird. Soll ich diese GPO-Einstellung dann besser entfernen und die DCs so konfigurieren, wie du es beschreibst?

Hallo zusammen, nachdem heute früh die Anmeldung an unserem Terminalserver nicht mehr funktionierte, bin ich schnell dahinter gekommen, dass die Zeitsynchronisation bei uns nicht richtig läuft. Wir nutzen 3 DCs, einen auf Blech (Win2008R2), einen als VM (Win2008R2/ESX) und einen in der Cloud (Win2012R2/Azure). Alle DCs haben als Policy ptbtime1.ptb.de und die Clients nutzen dann mal den einen und mal den anderen DC als Zeitserver. w32tm /monitor zeigt aber, alle 3 DCs auseinanderlaufen, teilweise um 80 Sekunden. Der Blech-DC und der ESX-DC zeigen mir zumindest den gleichen NTP-Server an, aber warum sind die nicht im Sync? Beim azure-DC wird ein anderer NTP-Server verwendet, vermutlich, weil das ganze ja unter Hyper-V läuft und die Azure-VM diesen als NTP benutzt. Wie bekomme ich meine DCs wieder synchron? Ich habe w32tm unregister /register / resync durchgeführt aber es ändert sich nichts. Wenn ich die Zeiten manuell ändere, laufen sie bald wieder auseinander. Die ESX-Hosts habe ich auf unsere DCs als Zeitserver umkonfiguriert, aber das ändert auch nichts :(. Viele Grüße Marcel

Danke für den Tipp, aber unsere Clients laufen alle schon auf Win8 und 8.1 ...