Jump to content

lionheart

Members
  • Content Count

    144
  • Joined

  • Last visited

Community Reputation

12 Neutral

1 Follower

About lionheart

  • Rank
    Junior Member
  1. Hi, also bei mir hat das Löschen und Neuanlegen einer GPO ebenfalls zu diesem Fehler geführt. Ich konnte ihn dadurch nicht lösen. Ich musste die Berechtigung auf der oberstene Ebene der Domäne neu setzen, damit diese auch auf allen untergeordneten GPOs übernommen wurde (Vererbung). Dann war der Fehler auch für alle neuen GPOs behoben.
  2. Hallo Martin, danke für den Tipp. Er hat mein Problem gelöst. Die Syncronisation ist seit gerade eben wieder fehlerfrei!
  3. Hallo Zusammen, ich habe hier ein AD mit zwei Domänencontroller (Windows Server 2012). Seit ein paar Wochen wird mir in der Gruppenrichtlinienverwaltung auf beiden DCs folgender Fehler angezeigt: Darunter erhalte ich eine Liste der betroffenen GPOs. Jede neu angelegte GPO erhält ebenfalls diesen Fehlerstatus, unabhängig vom Ort der Erstellung. An sich funktioniert mein AD korrekt. Die GPOs werden auch alle angewendet. In der Windows Ereignisanzeige auf beiden DCs finde ich keine Fehler. Auch dcdiag läuft auf beiden DCs fehlerfrei durch. Ich habe bereits den Berechtigungen auf den betroffenen GPOs unter "Delegierung" auf "Standard" wiederhergestellt, leider ohne Erfolg. Habt ihr einen weiteren Tipp für mich?
  4. Hallo Zusammen, ich habe hier ein Netzwerk mit einem 2012er Domain Controller. Auf dem Server ist parallel noch die DHCP Rolle installiert. Im DNS-Server ist die Reverse-Lookup-Zone für das Subnetz 192.168.0.0/24 eingerichtet. In meinem Netzwerk befinden sich 40 Windows 10 Clients, 10 weitere Server und 10 Macs. Ich habe nun ein Problem mit der DNS-Registrierung durch die Clients. Früher habe ich die DNS-Registrierung durch den DHCP-Server durchgeführt. Dabei wurden die Einträge in der Forward- und Reverse-Zone korrekt erstellt. Da hierbei aber auch Clients, die keine Domänen-Mitglieder (z. B. Drucker, Smartphones) waren, registriert wurden, habe ich die DNS-Registrierung durch den DHCP Server deaktiviert. Die Forward- und Reverse-Lookup Zonen sind nur für "Sichere" Aktualisierungen konfiguriert. Die Registrierung soll nun direkt von den Clients erfolgen. Die Registrierung in der Forware-Zone funktioniert dabei korrekt. Leider werden aber keine Einträge in der Reverse-Zone erzeugt. Ich habe die PTR-Registrierung per GPO "Computerkonfiguration > Richtlinien > Administrative Vorlagen > Netzwerk > DNS-Client > PTR-Einträge registrieren" mit der Option "Registrieren" aktiviert. Ich vermute ein Berechtigungsproblem. Leider wird am Server und an den Clients in der Ereignisanzeige nichts protokolliert. Habt ihr einen Tipp für mich?
  5. Hallo Jan, ich habe alles so konfiguriert, wie in deinem Link beschrieben. Die AD-integrierte DNS-Zone akzeptiert nur "sichere Updates". Der DHCP-Server ist in den DNS-Optionen so konfiguriert, dass er die "DNS-Einträge nur nach Aufforderung vom DHCP-Client dynamisch aktualisiert". Leider ist es dennoch so, dass der DHCP-Server alle DNS-Registrierungen meiner Windows 10 Clients übernimmt. Schaue ich im DNS-Server nach den Einträgen in der DNS-Zone so wurde der Eintrag durch den DHCP-Server und nicht durch das Computerkonto erstellt. Windows 10 sollte die DNS-Registrierung doch selbst übernehmen können und nicht an den DHCP-Server delegieren. Weshalb fordern die DHCP-Clients den DHCP-Server zur DNS-Registrierung auf?
  6. Hallo Zusammen, ich habe hier ein Active Directory, dessen Clients sich insgesamt in 5x Subnetzen befinden. Der DNS-Server des AD ist so konfiguriert, dass er nur sichere dynamische Updates gestattet. Ein DC und DNS-Server befindet sich nur im Hauptstandort. - Hauptstandort = 192.168.0.0/24 - Zweigstelle 1 = 192.168.1.0/24 - Zweigstelle 2 = 192.168.1.2/24 - Zweigstelle 3 = 192.168.3.0/24 - Zweigstelle 4 = 192.168.4.0/24 Die Clients im Hauptstandort erhalten Ihre IP-Adressen von einem autorisierten DHCP-Server, der auch gleich die DNS-Aktualisierung vornimmt. In den Zweigstellen übernimmt ein lokaler DHCP-Server, der in die Firewall integriert ist, die IP-Zuweisung. Die IP-Aktualisierung am DNS-Server der Clients im Hauptstandort funktioniert fehlerfrei. Problematisch ist nun die Aktualisierung der Einträge von den Zweigstellen. Diese funktioniert nur sporadisch. Besonders problematisch ist die DNS-Aktualisierung, wenn Geräte von einer Zweigstelle im Hauptstandort waren und dort mit einer 192.168.0.0er IP-Adresse im DNS durch den DHCP-Server registriert wurden. Sind die Geräte am nächsten Tag wieder in Zweigstelle, bleibt der DNS-Eintrag bei 192.168.0.0 stehen und wird nicht auf das Zweigstellen-Subnetz aktualisiert. In den Sicherheitseinstellungen des A-Records sehe ich, dass der Eintrag durch den Benutzer des DHCP-Server erzeugt wurde. Der "nicht autorisierte" DHCP-Server in der Zweigstelle hat somit also keine Berechtigung den Eintrag zu aktualisieren, dass müsste somit der Client übernehmen. Ändere ich die dynamischen DNS-Update von "Nur sichere" auf "Sicher und nicht sichere" Aktualisierungen funktioniert alles korrekt. Aus Sicherheitsgründen möchte ich diese Konfiguration jedoch vermeiden. Wie sollte ich meinen DNS-Server für dieses Szenarion konfigurieren?
  7. Ja, habe ich geprüft. Da steht u. a. das Computerkonto mit den Berechtigungen Lesen und Schreiben drin. Sollte also passen. Ich werde die falschen Einträge einmal löschen und manuell registrieren. Ob das etwas gebracht hat, kann ich erst in ein paar Tagen beurteilen. Danke.
  8. Hallo, diese Erfahrung habe ich leider auch schon gemacht. Ich habe mir diesen Beitrag angesehen. Die Konfiguration ist identisch zu meinem Aufbau. Ich kann keinen Unterschied erkennen. Die Mitgliedschaft des DHCP-Benutzers habe ich wie empfohlen angepasst. Daran wird es wohl aber kaum liegen...
  9. Hallo Zusammen, in meinem DNS-Server werden die A-Einträge meiner DHCP-Clients nicht immer aktualisiert. Beispielsweise existiert ein A-Eintrag für einen Client mit der IP "172.20.1.5". Dieser Client befindet sich standardmäßig an einem anderen Standort im Subnetz 172.20.1.0/24. Nun wechselt der Client seinen Standort und erhält vom DHCP-Server dort eine IP aus dem Bereich 192.168.1.0/24. Im DNS-Server bleibt der A-Eintrag weiter mit "172.20.1.5" bestehen. Ich habe zwei DCs, auf denen zusätzlich je ein DHCP-Server augeführt wird. Die DNS-Zone meiner Domäne akzeptiert "nur sichere" dynamische Updates. Der DHCP-Server ist für die DNS-Aktualisierung wie im Anhang zu sehen konfiguriert. Zusätzlich sind im DHCP-Server "Anmeldeinformationen" für die dynamische DNS-Aktualisierung hinterlegt. Der verwendete Benutzer ist Mitglied der Gruppe "DNS-Admins", "DnsUpdateProxy" und "Domänen-Benutzer". Woran könnte das liegen? Habt ihr eine Idee?
  10. Danke Sunny61. Das war der Artikel. Leider hilft der Patch alleine nicht aus, es muss auch der MIME-Type da sein.
  11. Hallo Zusammen, das Problem ist gelöst, allerdings war dazu eine WSUS Neu-Installation erforderlich. Vielleicht hilft es aber jemandem, der vor dem gleichen Problem steht. Der MIME-Type ".esd" muss auf dem IIS eingetragen werden, bevor die ersten Windows 10 Upgrades heruntergeladen werden. Ist dieser MIME-Type nicht vorhanden und es werden Win 10 Upgrades vom WSUS geladen, funktioniert die WSUS-Datenbank im Anschluss für Windows 10 Clients nicht mehr korrekt. Nachträglich kann man das Problem durch das manuelle Bereinigen des WSUS irgendwie beheben, aber der Aufwand und die Erfolgschancen standen für mich in keinem Verhältnis. Deshalb habe ich mich für die Neuinstallation entschieden. - WSUS Rolle installiert - MIME Type erstellt - Upgrades aktiviert und genemigt -> Upgrade 1703 wurde erfolgreich auf den Clients installiert. Irgendwo hatte ich einen MS Blogeintrag in dem dieses Problem beschrieben wurde. b***d nur wenn man einen WSUS schon länger betreibt und z. B. Upgrades für Win 7 > Win 8.1 aktiviert hatte. In diesem Fall kommen halt auch die Win 10 Upgrades in die Datenbank rein. Wie gesagt mein Problem ist gelöst, vielleicht hilft es dennoch jemanden. Was ich jetzt noch immer nicht ganz verstehe, wozu sind die ganzen Windows 10 Produkte im WSUS gut? Ich bekomme Upgrades und Sicherheits-Updates durch das Produkt "Windows 10" verteilt. Wozu benötige ich dann die ganzen anderen eigenständigen Produkte wie z. B. "Windows 10 Creators Update"?
  12. Hallo Zusammen, ich habe hier eine Windows Server 2012 R2 Domäne mit einem installierten WSUS (Version: 6.3.9600.18694). In der Domäne befinden sich ca. 30 Windows 10 Clients. Bisher war auf den Clients weder das Anniversary Update noch das Creators Update installiert. Die Clients wurden von meinem WSUS mit den normalen Sicherheitsupdates versorgt. Jetzt wollte ich das Creators Update im Netzwerk per WSUS verteilen. Dazu habe ich alle erforderlichen Vorbereitungen am WSUS und IIS durchgeführt. https://www.windows-faq.de/2017/05/05/windows-10-creators-update-per-wsus-verteilen/ Unter Klassifizierungen habe ich "Upgrades" aktiviert. Unter Produkte war bisher nur "Windows 10" aktiviert. Dazu habe ich jetzt noch die Produkte Windows 10 Creators Update and Later Servicing Drivers Windows 10 Creators Update and Later Servicing Drivergs Windows 10 Creators Update and Later Upgrade & Servicing Drivergs aktiviert. Das 1703 Update wurde auch heruntergeladen und für die Installation genehmigt. Leider klappt die Verteilung trotzdem nicht. Auf den Win 10 Clients kommt immer die Fehlermeldung "Funktionsupdate für Windows 10 Pro, Version 1703, de-de, Einzelhandel – Fehler 0x80244007". Installiere ich das 1703 Update auf einem Client manuell, wird das Update installiert. Die nachfolgende Versorgung mit Sicherheitsupdates vom WSUS funktioniert im Anschluss auch wieder für die 1703er Installation. Windows 10 und WSUS mag ich einfach nicht verstehen. Ich habe dazu bereits div. Anleitungen, Tutorials und MS Seiten gelesen, aber ich bin noch immer nicht ganz schlau. Mit Windows 10 kamen immerhin 16x Produkte in den WSUS. Welche Produkte und Klassifizierungen muss ich aktivieren, damit meine Windows 10 Clients (OEM- oder SB-Lizenzen) immer das aktuellste Windows erhalten? Habt ihr noch einen Tipp für mein Creators-Update Problem?
  13. Hallo NorbertFe, darum gehts doch jetzt gar nicht. Der DHCP-Server registriert die PCs nicht korrekt beim DNS. Diese sind aber Domänenmitglied und sollen korrekt verwaltet werden.
  14. Ein paar Smartphones per WLAN (4-5). Aber die PCs / Server (60) sind alle Mitglied meiner Domäne.
×
×
  • Create New...