Jump to content

lionheart

Members
  • Gesamte Inhalte

    148
  • Registriert seit

  • Letzter Besuch

1 Benutzer folgt diesem Benutzer

Profile Fields

  • Member Title
    Junior Member

Fortschritt von lionheart

Proficient

Proficient (9/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

12

Reputation in der Community

1

Beste Lösungen

  1. Ok, das bedeutet ich muss den Lizenzserver vom alten auf den neuen Terminalserver migrieren und danach den alten dort anbinden?
  2. Danke für die Rückmeldung. Genau so hab ich mir das vorgestellt. Das hätte ich dann entsprechend über AD-Gruppen sichergestellt.
  3. Hallo Zusammen, derzeit habe ich einen Terminalserver auf Basis von Windows Server 2012 R2. Insgesamt verfüge ich über 30 RDS-Cals. Historisch bedingt wurden diese in 5er Boxen (keine Software Assurcances, etc) von ursprünglich 10x Lizenzen stetig erweitert. Je nach Verfügbarkeit wurden dabei RDS-Cals von Windows Server 2012, 2016 und 2019 gekauft. Diese wurden alle auf diesem Terminalserver Lizenzserver aktiviert. Nun benötige ich noch einen weiteren Terminalserver für ca. 5 Anwender. Dieser wird auf Basis Windows Server 2019 betrieben. Kann ich diesen an den 2012er Lizenzserver anbinden und die 2019er CALs verwenden oder muss ich diese auf dem 2012er deaktivieren und auf dem neuer 2019er Terminalserver einen eigenen Lizenzserver mit diesen RDS-Cals installieren? Wie würde ihr das machen? Ich möchte / kann jedenfalls zum aktuellen Zeitpunkt nicht alle 20 älteren RDS-Cals auf 2019 aktualisieren.
  4. 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.
  5. Hallo Martin, danke für den Tipp. Er hat mein Problem gelöst. Die Syncronisation ist seit gerade eben wieder fehlerfrei!
  6. 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?
  7. 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?
  8. 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?
  9. 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?
  10. 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.
  11. 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...
  12. 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?
  13. Danke Sunny61. Das war der Artikel. Leider hilft der Patch alleine nicht aus, es muss auch der MIME-Type da sein.
  14. 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"?
×
×
  • Neu erstellen...