Hallo Zusammen

Ich habe einen Windows 2016 Server mit AD eingerichtet. Gerne würde ich die servergespeicherten Profile auch ins Backup einbeziehen, habe aber keine Berechtigungen dazu. Es gibt in der GPO die Einstellung "Sicherheitsgruppe "Administratoren" zu servergespeicherten Profilen hizufügen". Wenn ich die nun aktiviere gilt dies aber nur für die ab dieser Änderung erstellten Profile. So müsste ich allen User die Profile zurücksetzen. Gibt es einen anderen Workaround, damit mein Backup User Zugriff erhält?

Hallo,

ich habe in meiner Domäne zwei Domänen Controller. Der eine mit der PDC Rolle ist ein Windows Server 2012 R2 und der andere ein Windows Server 2016. Das Domänenfunktionslevel ist Windows Server 2008 R2.

Nun habe ich beim einen DC (Server 2016) gesehen, dass ich immer Event 13577 habe:

«Der Dateireplikationsdienst (File Replication Service, FRS) ist veraltet. Um den SYSVOL-Ordner weiterhin zu replizieren, sollten Sie mit dem DFSRMIG-Befehl zur DFS-Replikation migrieren. 

Aufgrund der Meldung gehe ich davon aus, dass die Replikation noch mit FSR stattfindet obwohl ich dachte, dass dies gar nicht mehr funktionieren dürfte unter Windows Server 2016. Die Replikation läuft aber. Wenn ich ein File beim einen DC ins SYSVOL Verzeichnis kopiere wird das File repliziert.

Meine Frage ist nun: Läuft die Replikation wirklich noch mit FRS oder doch DFSR? Wie finde ich das heraus?

Wenn ich Google, beziehen sich die Antworten immer auf Windows Server 2008 R2 aus und nicht 2012 R2 / 2016.

Danke für die Hilfe!

Hallo,

seit einem Ramsonwarevorfall vor 4 Monaten werden die netlogon und sysvol Freigaben nicht repliziert.

Damals haben wir zwei von drei Servern aus der Datensicherung zurückgeholt.

Das AD und die syncronisation des AD funktioniert.

Den dritten Server haben wir dann entfernt und 4 Wochen später durch einen neuen ersetzt

Server 1 und 2 sind 2012R2 und 3 2016

Auch auf den neuen Server synct sich das SYSvol nicht

Gestern habe ich die Server 2 und 3 heruntergestuft und dann wieder zu Domänencontrolern gemacht

AD usw. läuft. die Freigaben für SYSVOL und netlogon wurden nicht angelegt

das habe ich mit der folgenden Anleitung gemacht
https://support.microsoft.com/de-de/help/2958414/dfs-replication-how-to-troubleshoot-missing-sysvol-and-netlogon-shares

jedenfalls angefangen (die übersetzung ist schon irgendwie nicht gut..)

Aktuell (seit gestern Abend)

befindet sich alles im Satuts 2

wartet auf replizierung !

gibt es eine bessere Anleitung ?

mfg

Egbert

Mein Rechner : Dell 7010 i7-3770 16Gb SSD Samsung 840 pro 256Gb NVIDIA quadro 4000 + quadro K600 Meine Server Supermicro 3x2E5620 48GB/ 1x2E5520 48GB; 1x2E5420 32GB/ 1x2E5-2630V3 128GB/ 1x2E5-2680v2 256GB 2x Grid K1 Platten direkt im Server kein SAN Switche DELL 6248 2x mit je 2x10GBIT im STACK DLINK für die APC Datensicherung VEEAM

Hallo miteinander

Prinzipiell funktioniert mein AD echt zufriedenstellend. Es gibt jedoch Standorte welche Mühe bekunden.

Master und Slave DC inklusive AD stehen in Zürich. Wir haben Vertretungen rund um die Welt. Jeder Standort auf der Welt ist per Site to Site VPN an das Mutterhaus in Zürich angebunden.

Folgende Situation: Ein Benutzer in Sydney will einen Dienst nutzen und authentisiert sich gegenüber dem AD, die Authentisierung schlägt fehl. Meldet sich der gleiche Benutzer beispielsweise in Frankfurt an, funktioniert die Anmeldung einwandfrei und der Benutzer kann den angeforderten Dienst nutzen.

Ergo AD funktioniert, der Benutzer kennt Benutzername und Passwort. Der grosse Unterschied zwischen den beiden Standorten ist logischerweise die Round Trip Time der Pakete im Netzwerk. In Frankfurt erreiche ich Werte von rund 9ms und in Sydney rund 300ms.

Die Schwelle ab wann die Authentisierung nicht mehr zuverlässig funktioniert ist bei einer RTT von rund 35ms.

Weiss jemand ob es am AD diesbezüglich Zeitlimiten gibt und ob diese sich ändern lassen?

Die üblichen Verdächtigen können ausgeschlossen werden. Die Zeitsynchronisation aller Netzwerkteilnehmer ist korrekt gewährleistet und die Einstellungen für die Gültigkeit von Tickets des Kerberos Key Distribution Centers sind die voreingestellten Werte welche für mich grosszügig genug erscheinen.

Es hat natürlich jeder Recht, der nun den Vorschlag macht, einfach einen weiteren AD Slave in jede Vertretung zu stellen. Stimmt, kann ich machen, ist aber erst mal Plan B.

Mich nehmen in erster Line die Zeiteinstellungen rund um AD und Kerberos wunder, aber selbstverständlich nehme ich jeden Lösungsvorschlag dankend an.

Vielen Dank für konstruktive Vorschläge und beste Grüsse

dmswissdive

Hallo,

über unseren Exchange 2010 SP3 wir nutzen Benutzerpostfächer als "Gruppenpostfächer". Mehrere Benutzer erhalten dabei über eine Sicherheitsgruppe Vollzugriff, Im Auftrag senden und/oder Senden-als Berechtigung.

Wir haben zwei Zertifikatvorlagen (Exchange Benutzer und Nur-Exchange-Signatur) dupliziert und mit automatischer Verteilung zur Verfügung gestellt. Für den natürlichen Benutzer selbst funktioniert das Signieren der Email damit problemlos im Outlook.

Ich habe weiterhin ein Vorlage für Registrierungs-Agent erstellt und mir ein solches Agenten-Zertifikat ausgestellt. Die bereits konfigurierte Exchange-Benutzervorlage habe ich dupliziert und für den Registrierungs-Agenten konfiguriert. Ich konnte mir darüber ein Email Signatur-Zertifikat für den Account des Gruppenpostfaches erstellen.

Das Zertifikat habe ich auf meinem Client importiert, aber kann das Zertifikat nicht im Trust-Center von Outlook auswählen (es wurde unter Andere Personen abgelegt). Auch wenn ich das Zertifikat manuell in die Eigenen Zertifikate packe, wie mein persönliches S/MIME Zertifikat, kann dieses nicht auswählen, ich bekomme nur mein persönliches zur Auswahl.

Was habe ich hier falsch gemacht?

VG

Sascha

Hallo zusammen

Wir haben zwei Firmenstandorte, an jedem steht ein DC. Die DCs dienen zugleich als Fileserver und synchen sich durch einen VPN Tunnel mit DFS. Es existiert nur eine Active Directory Domäne. Mit Active Directory Sites sind die einzelnen Subnetze konfiguriert, sodass die Clients am Standort A den DC A und die Clients am Standort B den DC B kontaktieren.

Nun haben wir das Problem, dass viele Clients vom Standort A plötzlich DNS und vereinzelt Kerberos Anfragen an den DC B übermitteln, obwohl DC A im selben Netz ist und via Ping, SMB, etc. erreicht werden kann. Zudem dauert gpupdate sehr lange bzw. schlägt fehl, da der Client keine Netzwerkkonnektivität zum Server habe (Eventlog). Primary / Secondary DNS im DHCP stimmen, nslookup Anfragen über DC a funktionieren ebenfalls. Den Virenscanner haben wir zum Test komplett deaktiviert. DC A ist Server 2016, DC B Server 2012 R2.

Habt ihr eine Idee? Über Netzwerkprobleme ist mir nichts bekannt, im Eventlog des DC A ist nichts verdächtiges zu finden.

Vielen Dank für die Unterstützung

Hallo! Folgende Ausgangssituation:

Windows Server 2012 R2 als Printserver in einer Domäne.

Ein Windows 2000 Client soll über einen Drucker auf dem Printserver drucken. Der Client ist nicht in der Domäne.

Ich kann den Drucker hinzufügen und auch die notwendingen Treiber werden installiert. Will ich dann aber einen Druckjob starten, erhalte ich folgende Fehlermeldung:

"Sie haben nicht die erforderlichen Zugriffsrechte für den ausgewählten Drucker". Wenden Sie sich an den Netzwerkadministrator, um die benötigten Rechte zu erhalten."

Zugriff auf den Drucker hat auf dem Printserver "Jeder", was doch eigentlich die nicht Domänenmitglieder beeinhalten sollte?

Ebenfalls funktioniert das Ausdrucken, wenn ich den Drucker direkt, ohne Printserver, verbinde.

Hatte jemand schon mal so ein Problem und kann helfen?

Vielen Dank!

Hallo,

wenn ein Rechner in die Domäne joined bekommt er ja Zertifikate von unserer CA in seinen Speicher unter "Vertrauenswürdige Stammzertifizierungstellen". Leider bekommen unsere Rechner veraltete und abgelaufene Zertifikate neben dem aktuellen der CA? Wo kommen diese her wo kann ich die alten rauslöschen?

Eine weitere Frage ist, wenn ich das Zertifikat der CA erneuere bekommen es die Clients ja nicht automatisch oder? Der ganze Vorgang passiert ja nur einmal beim Join in die Domäne?

Hallo,

wir haben derzeit eine Domäne mit Unterstrich (dc_firma.intern) im Namen und einige DNS Dienste bzw. neue Applikationen können damit nicht umgehen. Daher planen wir den Umstieg auf eine neue Domäne (firma.intern).

Die Domäne läuft heute sowohl in der Domänenfunktionsebene als auch Gesamtstrukturfunktionsebene auf Windows Server 2008 R2. Wir wollen eine neue Domäne auf Windows Server 2016 einrichten.

Geplant ist ein neuer DC mit Vertrauensstellung zum Jetzigen. Bei der Migration werden wir sicher auf das ADMT zurückgreifen, um zumindest die Benutzer und Gruppen zu übernehmen.

Vom Dienstleister wurden wir darauf aufmerksam gemacht, dass jeder Benutzer ein neues Profil auf seinem Windows Client erhält, was mich etwas stutzig macht, da ich ja die Profilinformation samt History mit dem ADMT übernehme. Einzig die Clients (Computerkonten) selbst würde ich manuell in die neue Domäne aufnehmen.

Da wir auch noch eine Office 365 Umgebung nutzen, stellt sich für uns auch die Frage der Anbindung an die neue Umgebung und Integration von Benutzerkonten, da derzeit ja alle auf die jetzige (alte) Domäne zeigen.
Hat jemand schon solche Erfahrungen gesammelt und kann mir hilfreiche Tipps geben?

Vielen Dank.

Chris

Hallo zusammen,

wir haben eine Problem. In der Vergangenheit haben wir einige unsere DCs von Server 2012 auf Server 2016 upgegraded. Das Vorgehen war herunterstufen, unjoin, neu installieren, AD join, hochstufen. Die neuen Server haben exact den selben Namen als die alten und auch dieselbe IP. Das war so gewollt. Von einem Inplaceugrade wird ja seitens Microsoft abgeraten und wäre jetzt ja eh zu spät.

Nun bekommen wir aber schon länger Event ID 1864:

This is the replication status for the following directory partition on this directory server. 
Directory partition:
DC=domain,DC=local
This directory server has not recently received replication information from a number of directory servers.
The count of directory servers is shown, divided into the following intervals. 
More than 24 hours:
1 
More than a week:
1 
More than one month:
1 
More than two months:
1 
More than a tombstone lifetime:
0 
Tombstone lifetime (days):
180 
Directory servers that do not replicate in a timely manner may encounter errors. They may miss password changes 
and be unable to authenticate. A DC that has not replicated in a tombstone lifetime may have missed the deletion 
of some objects, and may be automatically blocked from future replication until it is reconciled. 
To identify the directory servers by name, use the dcdiag.exe tool. 
You can also use the support tool repadmin.exe to display the replication latencies of the directory servers.   
The command is "repadmin /showvector /latency <partition-dn>".

Ein repadmin /showvector /latency dc=domain,dc=local bringt folgende Meldung zum Vorschein:

Caching GUIDs.
..
Site1\ROOT-DC2 (deleted DSA)           @ USN  31227390 @ Time 2018-03-15 10:17:20
Site1\ROOT-DC1\0ADEL:b738d30e-8a3a-4175-ab4f-27bb0652857e (deleted DSA) @ USN  41123970 @ Time 2018-03-20 13:13:06
Site1\SUB1-DC2 (deleted DSA)            @ USN  53882505 @ Time 2018-03-20 15:50:21
Site1\SUB1-DC1 (deleted DSA)            @ USN  59794124 @ Time 2018-03-22 10:03:16
Site2\SUB2-DC2 (deleted DSA)              @ USN  12111634 @ Time 2018-04-12 12:49:55
Site2\SUB2-DC1 (deleted DSA)              @ USN  202422306 @ Time 2018-04-12 15:47:08
Site1\SUB3-DC1                          @ USN  15696469 @ Time 2018-08-13 13:57:02
Site2\SUB2-DC1                            @ USN    653303 @ Time 2018-08-13 14:02:41
Site3\SUB3-DC2                          @ USN  10636306 @ Time 2018-08-13 14:03:47
Site2\SUB2-DC2                            @ USN   1012325 @ Time 2018-08-13 14:05:55
Site5\SUB6-DC3                        @ USN   9335718 @ Time 2018-08-13 14:07:02
Site6\SUB4-DC2                          @ USN   2745623 @ Time 2018-08-13 14:12:03
Site4\SUB5-DC2                          @ USN  130326526 @ Time 2018-08-13 14:12:30
Site1\ROOT-DC1                         @ USN   1623323 @ Time 2018-08-13 14:23:55
Site1\SUB4-DC1                          @ USN  25724705 @ Time 2018-08-13 14:24:10
Site1\SUB8-DC1                        @ USN    6287872 @ Time 2018-08-13 14:24:16
Site1\SUB1-DC2                          @ USN   43936554 @ Time 2018-08-13 14:47:56
Site1\ROOT-DC2                         @ USN   2334008 @ Time 2018-08-13 14:48:48
Site1\SUB5-DC1                          @ USN  25602431 @ Time 2018-08-13 14:49:02
Site1\SUB7-DC1                          @ USN   4156821 @ Time 2018-08-13 14:49:02
Site1\SUB1-DC1                          @ USN   3773274 @ Time 2018-08-13 15:39:50

Im Papierkorb sind diese Objekte nicht mehr, dort haben wir sie entfernt. Wir vermuten, dass die Event ID aufgrund der deleted DSA Einträge kommt. 

Wie kann man sowas bereinigen? Hat hier jemand eine Idee? Wir haben schon viel gesucht und auch schon das metadata cleanup versucht. Aber alles war bisher erfolglos.

Viele Grüße Wolfgang

Moin  Moin!

Ich muss zwangsläufig auf die harte Varriante die FSMO-Rollen von einem toten Server bzw. DC auf einen neuen Übertragen.

Alle Rollen wurden auch ohne Probleme übertragen, ausser der Schema Master. Dort bekomme ich folgende Fehler:

Der Benutzer, mit dem ich das ganze tue, ist in allen Admin-Gruppen eingetragen, Schema Admin, Org.-Admin etc.

CMD ist auch als Admin gestartet.

Wenn ich die MMC für das Active Direktory Schema starte auf den "toten" DC, kann ich darüber das Schema nicht ändern. (Button "Ändern" ausgegraut")

Wenn ich die MMC auf den neuen DC laden möchte, kann diese bereits die .dll Datei zum aktivieren dieser MMC nicht laden.

Ich weiß absolut nicht, was der Fehler oben im Bild zu bedeuten hat bzw. wo ich welche Berecchtigungen ändern muss oder kann.

Könnte mir jmd. weiterhelfen? vielen DANK!

Liebe Grüße

R. Gwisdala

Hallo,

Ich musste meine Testumgebung bedingt durch Fehlkonfiguration einstampfen.

Jetzt habe ich einen neuen DC(Core Server 2016 DATACENTER VM auf selbigem) erstellt, neue AD erstellt. Jetzt wollte ich wie gewohnt den DC als Primären DNS im DHCP angeben. Siehe da: kein Internet mehr.

Gleiche Konfiguration wie bei dem vorherigen 2012R2 Test-Setup.

Im DNS MMC schauts genauso aus wie beim alten.

Bedingt durch unprofessionelle Homelab Hardware ist der Aufbau wie folgt.

VDSL<-Fritzbox (NAT, 192.168.178.1)<-guter Router(NAT, 172.16.66.1)<-DC mit DNS (172.16.66.10)

Beim DC ist 172.16.66.1 als Gateway angegeben und 172.16.66.10 als DNS.

So hat es zwei Jahre funktioniert mit 2012R2.

Kann das sein, dass der Server2016 in irgendeiner Form ein Problem mit dem doppelten NAT hat? Um auf den guten Router von aussen per VPN zu kommen musste ich Windows 10 exklusiv auch die REG anpassen.

Hallo,

wir haben zwei RODCs in verschiedenen DMZs. Einer der beiden registriert sich leider nicht im DNS über die DCs. Die Netzwerkkonfiguration ist aber genau die gleiche wie auf dem anderen RODC.

Praktisch äußert sich das so, dass selbst ein statischer A-Eintrag bei einem Neustart des RODC von den DCs gelöscht wird. Das gleiche passiert auch bei "ipconfig /registerdns"!

Die Netzwerkkarte ist so konfiguriert, dass der Haken bei "Adressen dieser Verbindung in DNS registrieren" gesetzt ist.

Hat jemand eine Idee warum die IP immer wieder gelöscht wird aus dem DNS?

Danke und Gruß
KingHundi

Hallo zusammen,

ich habe folgendes Szenario:

Ich habe zwei verschiedene Domains (Forests) bei denen organisatorisch kein Trust aufgebaut werden kann.

Wenn ich jetzt von einem Client aus Domain-A auf Domain-B auf eine Netzwerkresource zugreife,
werde ich nach Benutzername und Kennwort gefragt.
Nach der Eingabe von diesen Informationen kann ich zugreifen.

Ich kann diese Information auch speichern für spätere Zugriffe (Über den Windows Credential Manager).
In dieser Form:
\\server-a\share
\\server-b\share

Ich kann das jetzt z.B. für den Zugriff auf server-a abspeichern.
Greife ich auf server-b zu, muss ich jedoch erneut die Anmeldeinformationen abspeichern usw.

Jetzt zu meiner Frage, gibt es eine Möglichkeit diese Anmeldeinformation für den Zugriff auf die gesamte Domaine zu speichern?

Nach dem Motto: Verwende für alle Zugriffe auf Domain-a diesen Benutzer.

MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!

Hallo!

Seit einigen Tagen sagt mir Windows die Lizenz laufe bald ab...

Hat jemand eine Ahnung, was ich tun kann, um die Lizenz zu verlängern?

Liebe Grüße :)

Sean

Hallo zusammen,

Seit einer Woche ist es mir unmöglich User Paswörter im Active Directory zurück zu setzen.

Auch neue User können nicht mehr angelegt werden, selbe Fehlermeldung.

Ich habe ebenfalls schon zwei Kollegen zu diesem Thema befragt und nach einigen erfolglosen Stunden haben sie aufgegeben.

"The Password does not meet the complexity policy requirements..."

Wir haben 2 Domain Controller Windows Server 2012 R2 - Domain / Forest funct. Level

Da ich mich seit Tagen ausschließlich mit diesem Problem beschäftige, versuche ich so vollständig wie möglich die gescheiterten Lösungsansätze zu schildern:

Als User vom Client aus kann das Passwort ebenfalls nicht geändert werden

In dem Zeitraum von "es funktioniert nachweislich alles" bis zu "Fehler tritt auf" wurden keinerlei Windows Updates installiert

Nur eine Passwort Policy aktiv - link auf Domain level

net accounts spiegelt die dort hinterlegten settings wieder - auch bei Änderung der Settings ersichtlich

Anpassen / Deaktivieren / Ersetzen der Policy brachte keine Besserung (Komplexität Aus/An, Min. Passwort alter 0, Komplette Passwort Settings auf "not configured" / 0 / deaktiviert / ... gesetzt, etc.)

Durch Fine Grained PW Policy versucht auszuhebeln (Get-ADUserResultantPasswordPolicy zeigte auch hier für alle getesteten User die aktualisierte "Fine grained Policy" an, nicht mehr das GPO, allerdings ohne Veränderung der Fehlermeldung.

Passwort Reset über Powershell resultierte in der selben Meldung

Event Viewer am DC zeigt nur "Audit Failure - an attempt to reset the password was made.." an. Log Level erhöhen brachte keine weiteren Infos

Neue OU`s angelegt und User verschieben / neu anlegen versucht

RSoP zeigt die korrekte Policy als "winning" an, Passwort Settings werden korrekt angezeigt (auch nach allen Policy Änderungen überprüft), aber kein Passwort, egal in welcher Länge und Komplexität wird akzeptiert (8 - 30 Zeichen getestet, immer mit Zahl, Grossbuchstaben, Kleinbuchstaben, Sonderzeichen enthalten, sowohl selbst gewählte Passwörter als auch aus dem Generator stammende werden nicht akzeptiert)

Replication ist laut repadmin OK

Einige abenteuerlichere Ansätze habe ich bereits wieder verdrängt.

Jetzt bin ich mit meinem Latein am Ende und bevor ich eine Migration in einen neuen Forest angehe oder ein Ticket bei Microsoft eröffne, hatte ich gehofft dass vielleicht jemand anderes ähnliches Pech hatte wie ich und vielleicht seine Lösungsansätze mit mir teilt.

Vielen Dank im Voraus!

freundliche Grüße

Hallo,

ich habe folgendes Problem, es ist etwas komplex...

Domain: alt.test.local

dcalt1.alt.test.local

dcalt2.alt.test.local

dort gibt es einen DFS Namespace, der auf zwei File-Server die DFS Replication machen verweist.

\\alt.test.local\meinDFS

Jetzt habe ich in der Domain \\neu.test.local eine beidseitige Vertrauensstellung zur alt.test.local.

Dort stehen zwei (baugleiche) Terminalserver die beide(!) auf die DCs Ihrer Domäne (neu.test.local) zeigen.

Terminal1 kann auf 

\\alt.test.local

&

\\alt.test.local\meinDFS problemlos zugreifen

Terminal2, hat immer wieder Probleme, 

manchmal läuft es, dann wieder nicht.

Zugriff auf:

\\alt.test.local läuft deutlich häufiger gut, als Zugriff auf \\alt.test.local\meinDFS

Meldung ist meist, dass er das im Netzwerk nicht findet oder das kein Logon-Server zur Verfügung steht.

Was immer funktioniert ist:

dcalt1.alt.test.local\meinDFS oder mit der IP auf meindfs... 

Auflösen tut er immer saubern

nslookup dcalt1.alt.test.local 

gibt mir immer die richtigen DCs zurück.. ich bin langsam ziemlich verzweifelt..