daabm

Ich versteh Dein Problem nicht :) Vorher: \\Server\Freigabe1 -> D:\Shares\Freigabe1 D:\Shares\Freigabe1 verschieben nach D:\Shares\freigabexyz\freigabe1 Hinterher: \\Server\freigabexyz -> D:\Shares\freigabexyz \\Server\Freigabe1 -> D:\Shares\freigabexyz\freigabe1 Wozu brauchst Du da einen Alias?

Skripten... Win32_Printer ist die Klasse der Wahl.

Wenn Du den Reg-Wert schon kennst: Group Policy Preferences "Registrierung" :)

Hmmm... Wenn ich jetzt nicht ganz auf dem Holzweg bin: Freigabexyz zeigt doch auf irgendein Verzeichnis. Und unterhalb dessen gibt es jetzt ein Unterverzeichnis Freigabe1, das Du einfach wieder als "Freigabe1" sharen kannst. Oder verstehe ich das völlig falsch? :) D:\Shares\Freigabexyz\Freigabe1 ^ ^Das freigeben als "Freigabe1" Das freigeben als "Freigabexyz"

Hm wo ist jetzt das Problem dabei, auf dem "alten" DC eine autoritative Sysvol-Wiederherstellung zu machen? https://support.microsoft.com/en-us/kb/290762 https://support.microsoft.com/en-us/kb/2218556

...und wenn man ROBOCOPY /MIR nutzt (kann man per PowerShell Invoke-Async ja auch starten...) dann muß man vorher auch nix löschen.

Behebe den FRS/DFSR Journal Wrap Error auf dem alten DC :)

Öffne die Exe doch mal mit notepad (jepp), spring ans Ende und such nach was, das nach XML aussieht. Steht da irgendwo was von "requireAdministrator"? :)

MS16-101 und seine bekannten Nebenwirkungen...

Wenn ich raten soll: Euer Deployment hinterlässt irgenwelche Leichen in C:\Windows\System32\GroupPolicy, mit denen gpedit nix anfangen kann...

Prima :) Ein Tipp noch: Wir hängen alle viel zu sehr an Text-Massage... $LocalSignaturePath = $AppData+$SignaturePath - schau Dir mal Join-Path an.

Was ist das für ein Code? Erst suchst Du nach Usern in Deiner InactiveOU, und dann willst Du sie dorthin verschieben? Schwerer Denkfehler, fürchte ich :cool: Ach ne Quatsch - $DisabledUsers wird ja gar nicht verwendet. Aber das hier sieht auch komisch aus: $User = Get-ADUser -Properties * -Filter {LastLogonDate -lt $Days} -SearchBase $searchbase foreach ($User in $Users) { Du speicherst die Suche in $User, iterierst dann aber über $Users?

Klingt für mich nach "Kerberos UDP TIcket Zerhackstückelung"... Zwinge Kerberos mal auf TCP - Google verrät Dir wie :-)

Jaja - und die haben dann alle das gleiche Kennwort, weil die Anwender sonst nen Koller kriegen :) Kommt mir bekannt vor...

Weil der Computerkonfiguration die Benutzer egal sind... Die interessiert sich nur für Computerberechtigungen.

Weil UAC nur für Admins relevant ist... Und der Explorer ist der natürliche Feind der UAC. Entweder deaktivierst Du die Elevated-Unelevated Factory, dann kannst Du einen Explorer auch als Admin starten. Oder - viel besser! - Du besorgst Dir einen alternativen Dateimanager wie Total Commander oder EF Commander, die kannst Du dann auch als Admin starten. Oder Du legst Dir eine eigene Admin-Gruppe an, der Du entsprechende Berechtigungen erteilst, das wäre die beste Lösung. BTW: Beim integrierten Admin-Konto funktioniert das nur deshalb out of the box, weil für dieses Konto UAC im Standard deaktiviert ist.

Naja, steht doch oben eigentlich schon alles... Deaktiviere den KDC auf allen DCs außer dem PDC. Und die startest Du dann neu.

Will er sich neu anmelden oder will er nur die Bildschirmsperre aufheben? Wenn zweiteres, dann prüf mal, ob das hier evtl. aktiviert ist: https://technet.microsoft.com/en-us/library/jj852260(v=ws.11).aspx

Vom AP aus? Dann machs lokal auf dem jeweiligen Server - Ursache dafür ist das oben geschilderte krbtgt-Problem :-)

Jetzt lass mal DNS und DHCP weg - wir reden nur über Domain Controller: dsquery server Das sind alle Deine DCs. Auf jedem lokal fragst Du jetzt mal bitte alle Betriebsmaster ab - aber nicht per GUI, sondern per dsquery: @for %f in (schema name infr pdc rid) do @dsquery server -hasfsmo %f -server %computername% Kannst auch lokal vom Arbeitsplatz aus machen, dann ersetze hinten %computername% nacheinander durch die Namen Deiner DCs. Dann kannst Du weiter überlegen.

"dsquery server -hasfsmo pdc" und die anderen 4 auch prüfen: -hasfsmo {schema | name | infr | pdc | rid} Die sollten in einem Single Domain Single Forest Design alle auf dem gleichen DC liegen. Auf dem machst Du nix. Auf allen anderen: net stop kdc sc config kdc start= disabled shutdown -r Dann warten bis alle wieder da sind, Eventlog Verzeichnisdienst und DFSR/FRS prüfen. Edit: Wenn alles in den Eventlogs grün ist: sc config kdc start= auto net start kdc Was hat DHCP oder GC mit dem ganzen zu tun?

Hm - in den Logs, die ich so schreibe, hat jeder Eintrag einen Zeitstempel. Wenn das bei Dir auch so ist, müßtests Du ja nur den Zeitstempel extrahieren und Dir merken...

Alternative, wenn das DNS nicht integriert werden kann: Verpasse den DCs (auch den zukünftigen) statische IP-Adressen und lass diesen IP-Adressen im externen DNS Schreibrechte geben. Dann können die alle ihre Service-Records selbst aktualisieren.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SrpV2 Löschen...

2 verschiedene Probleme... 1. Du hast mehrere Domain Controller, und das krbtgt-Kennwort ist auf mindestens einem davon nicht mehr synchron... Deaktiviere auf allen DCs mit Ausnahme des PDC den Dienst "KDC" und boote sie dann neu. Damit werden sie gewzungen, sich ein TGT/TGS vom PDC zu holen, können das AD dann wieder synchronisieren und das Kennwort sollte wieder synchron sein. 2. Dein Sysvol repliziert nicht mehr. Entweder auch wegen dem krbtgt-Problem (ziemlich sicher sogar) oder wegen USN Journal Wrap. Das siehst Du im DFSR- bzw. FRS-Eventlog auf den Domain Controllern. Lösung im zweiten Fall: D2-Restore auf allen, die NICHT der PDC sind. Mit DNS hat das nix zu tun :)