lionheart

Wohl wahr... :)

Ok, das bedeutet ich muss den Lizenzserver vom alten auf den neuen Terminalserver migrieren und danach den alten dort anbinden?

Danke für die Rückmeldung. Genau so hab ich mir das vorgestellt. Das hätte ich dann entsprechend über AD-Gruppen sichergestellt.

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.

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.

Hallo Martin, danke für den Tipp. Er hat mein Problem gelöst. Die Syncronisation ist seit gerade eben wieder fehlerfrei!

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?

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?

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?

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?

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.

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...

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?

Danke Sunny61. Das war der Artikel. Leider hilft der Patch alleine nicht aus, es muss auch der MIME-Type da sein.

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"?

Hallo Sunny61, Danke für deinen Post. Anbei meine GPO.

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?

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.

Ein paar Smartphones per WLAN (4-5). Aber die PCs / Server (60) sind alle Mitglied meiner Domäne.

Guten Morgen, ich habe beim Benutzer "DHCP-Admin" alle Gruppe entfernt. Er ist nur noch Mitglied der Gruppe "Domänen-Benutzer". Danach habe ich DC1 und DC2 neu gestartet. Leider hat sich an der Situation auf DC2 nichts geändert. Die DNS-Aktualisierung durch den DHCP-Server schlägt weiterhin fehl. Anschließend habe ich noch etwas anderes ausprobiert. Ich habe DC2 ind die Gruppe "DNSUpdateProxy" aufgenommen und einen Systemneustart ausgeführt. Das Problem besteht weiterhin. DC2 kann keine DNS-Aktualisieurng ausführen. :( Ereignis-ID Bedeutung 00 Das Protokoll wurde gestartet. 01 Das Protokoll wurde beendet. 02 Das Protokoll wurde aufgrund von unzureichendem Speicherplatz temporär angehalten. 10 Für einen Client wurde eine neue IP-Adresse geleast. 11 Eine Lease wurde von einem Client erneuert. 12 Eine Lease wurde von einem Client freigegeben. 13 Es wurde ermittelt, dass eine IP-Adresse im Netzwerk verwendet wird. 14 Eine Leaseanforderung konnte nicht erfüllt werden, da der Adresspool des Bereichs erschöpft war. 15 Eine Lease wurde verweigert. 16 Eine Lease wurde gelöscht. 17 Eine Lease war abgelaufen, und die DNS-Einträge für eine abgelaufene Lease wurden nicht gelöscht. 18 Eine Lease war abgelaufen, und die DNS-Einträge wurden gelöscht. 20 Eine BOOTP-Adresse wurde einem Client geleast. 21 Eine dynamische BOOTP-Adresse wurde einem Client geleast. 22 Eine BOOTP-Anforderung konnte nicht erfüllt werden, da der Adresspool für BOOTP des Bereichs erschöpft war. 23 Eine BOOTP-IP-Adresse wurde gelöscht, nachdem sichergestellt wurde, dass sie nicht verwendet wird. 24 Der Bereinigungsvorgang für die IP-Adresse wurde gestartet. 25 Statistik der IP-Adressenbereinigung. 30 DNS-Updateanforderung an den benannten DNS-Server. 31 Fehler beim DNS-Update. 32 Das DNS-Update war erfolgreich. 33 Das Paket wurde aufgrund der NAP-Richtlinie verworfen. 34 Fehler bei der DNS-Updateanforderung: Die maximale Anzahl von DNS-Updateanforderungen in der Warteschlange wurde überschritten. 35 Fehler bei der DNS-Updateanforderung. 36 Das Paket wurde verworfen, da sich der Server in der Failoverstandbyrolle befindet oder der Hash der Client-ID abweicht. 50+ Codes über 50 werden für Informationen über die Erkennung nicht autorisierter Server verwendet. QErgebnis: 0: Keine Quarantäne, 1: Quarantäne, 2: Paket verwerfen, 3: Probe, 6: Keine Quarantäneinformationen Probezeit: Jahr-Monat-Tag Stunde:Minute:Sekunde:Millisekunde. 00,07/25/17,06:58:19,Gestartet,,,,,0,6,,,,,,,,,0 55,07/25/17,06:58:20,Autorisiert (Dienst gestartet),,contoso.local,,,0,6,,,,,,,,,0 01,07/25/17,07:11:50,Angehalten,,,,,0,6,,,,,,,,,0 00,07/25/17,07:19:42,Gestartet,,,,,0,6,,,,,,,,,0 55,07/25/17,07:19:42,Autorisiert (Dienst gestartet),,contoso.local,,,0,6,,,,,,,,,0 30,07/25/17,07:22:12,DNS-Aktualisierungsanforderung,192.168.100.121,pc3.contoso.local,,,0,6,,,,,,,,,0 11,07/25/17,07:22:12,Erneuern,192.168.100.121,pc3.contoso.local,5CEE37007760,,1795248000,0,,,,0x4D53465420352E30,MSFT 5.0,,,,0 31,07/25/17,07:22:12,DNS-Aktualisierung fehlgeschlagen,192.168.100.121,pc3.contoso.local,,,0,6,,,,,,,,,9005

Also nur Mitglied der "Domänen-Benutzer"? Das mit dem Failover-Cluster ist mir bekannt, aber bisher bin ich mit einer 50:50 Aufteilung der IP-Adressen über zwei DHCP Server ganz gut gefahren. Es muss doch aber eine Ursache geben, weshalb die DNS-Aktualisierung nur von DC1 funktioniert..

Hallo Zusammen, ich habe hier eine Windows Server 2012 R2 Domäne mit zwei Domaincontroller (DC1, DC2). DC1 ist der primäre DC, DC2 wurde als sekundärer hinzugefügt. Auf beiden Server ist zusätzlich ein DHCP-Server konfiguriert und für die Domäne "contoso.local" autorisiert. Beide DHCP Server sind in den IPv4 Eigenschaften identisch konfiguriert. Unter dem Register "DNS" sind die Option "Dynamische DNS-Aktualisierung > DNS-Einträge immer dynamisch aktualisieren", "A- und PTR-Einträge beim Löschen der Lease verwerfern" und "DNS-Einträge für DHCP-Clients, die keine auto...., dynamisch aktualisieren" aktiviert. Unter "Erweitert" ist bei "Anmeldeinformationen" ein AD-Benutzer (dhcp-admin) hinterlegt. Der Benutzer ist Mitglieder der Gruppen "DHCP-Administratoren", "DHCP-Benutzer", "DNSAdmins", "DNSUpdateProxy", "Domänen-Admins" und "Domänen-Benutzer". Nun zu meinem Problem. Auf DC1 funktioniert die dynamische DNS-Aktulaisierung fehlerfrei. Alle DHCP-Clients werden korrekt am DNS Server registriert bzw. der Eintrag angepasst. Auf DC2 funktioniert die DNS-Aktualisierung nur sporadisch. Für manche Clients funktioniert die DNS-Aktualisierung fehlerfrei, bei anderen Clients schlägt die Aktualisierung mit der Fehler-ID 31 fehl. Ich verstehe das Problem nicht, entweder es funktioniert oder es funktioniert nicht. In der Windows Ereignisanzeige sind keine Fehler oder Warnungen zu finden. Im DHCP Log auf DC2 findet sich folgender Fehler: 30,07/24/17,09:16:32,DNS-Aktualisierungsanforderung,192.168.100.122,pc1.contoso.local,,,0,6,,,,,,,,,0 10,07/24/17,09:16:32,Zuweisen,192.168.100.122,pc1.contoso.local,3C970EBE208D,,3387120868,0,,,,0x4D53465420352E30,MSFT 5.0,,,,0 31,07/24/17,09:16:32,DNS-Aktualisierung fehlgeschlagen,192.168.100.122,pc1.contoso.local,,,0,6,,,,,,,,,9005 Zeitgleich gibt es aber auch erfolgreiche Aktualisierungen: 30,07/21/17,12:07:09,DNS-Aktualisierungsanforderung,192.168.100.138,pc2.contoso.local,,,0,6,,,,,,,,,0 10,07/21/17,12:07:09,Zuweisen,192.168.100.138,pc2.contoso.local,,5901A1780,0,,,,0x4D53465420352E30,MSFT 5.0,,,,0 32,07/21/17,12:07:09,DNS-Aktualisierung erfolgreich,192.168.100.138,pc2.contoso.local,,,0,6,,,,,,,,,0 Ich vermute die Neuanlage eines Eintrags klappt immer. Nur bei der Aktualisierung bestehender DNS-Einträge gibt es auf DC2 Probleme. Habt ihr einen Tipp für mich?

Ja. Der Datenträger wird praktisch als "interne Festplatte" verwendet. Augeblendet ist nichts. Das Verhalten tritt unter Windows Server 2012 auf.

Hallo Leute, ich habe hier mehrere Windows Server, die täglich auf eine externe USB-Datenträger (3.0) gesichert werden. Die Datenträger werden dabei täglich gewechselt. Vor Kurzem habe ich 7x neue USB-Festplatten gekauft. Bei 3x Festplatten bekomme ich in der Traybar das Symbol zum Auswerfen des Datenträgers. Bei 4x Festplatten erscheint nach dem Anschließen keine Option zum Auswerfen, obwohl der Datenträger erkannt und verwendet werden kann. Alle Datenträger sind vom gleichen Hersteller / Modell. Woran könnte das liegen?

Hallo Leute, ich habe mir zu Testzwecken einen Exchange Server 2013 installiert. Meine AD-Domäne lautet "test.local". Zusätzlich ist der Server auch von extern über die Domäne "abc.com" erreichbar. Ich habe bereits ein paar Benutzerpostfächer für beide Domänen eingerichtet. E-Mails an "xxx@test,local" werden innerhalb der Exchange Organisation und von Extern an "xxx@abc.com" erfolgreich zugestellt. Jetzt habe ich ein Raumpostfach als Ressource angelegt. Dem Postfach sind zwei E-Mail Adressen (Besprechung1@test.local, Besprechung1@abc.com) zugeordnet. Diesen Raum kann ich innerhalb meiner Exchange Organisation problemlos nutzen und z. B. Besprechungsanfragen senden. Diese werden automatisch importiert und bei den Benutzer im Outlook angezeigt. Möchte ich nun Besprechungsanfragen von einem externen E-Mail Konto (Kein Exchange Konto) an Besprechung1@abc.com senden kommt im Exchange nichts an. Der Termin erscheint in keinem Kalender. An meine Absenderadresse erhalte ich keine "Unzustellbarkeits-Rückantwort". Wie kann ich testen warum die Terminanfrage von Extern nicht ankommt? Geht das überhaupt von einem externen E-Mail Konto? Problem selbst gelöst. Man muss einfach für das Raumpostfach den Parameter -ProcessExternalMeetingMessages auf "$true" setzen. Leider ist der Punkt im Exchange 2013 GUI nicht aufzufinden, dass geht anscheinend nur per Powershell-Befehl. :shock: Get-mailbox %mailbox% | Set-CalendarProcessing -ProcessExternalMeetingMessages: $true