daabm

Servus Günter. Ok, Du bist offen und bereit zu lernen, schon mal gute Voraussetzungen
 
Du willst ja immer Copy-Item ausführen, eigentlich auch immer mit den gleichen Parametern, die nur unterschiedliche Inhalte haben, da wäre Splatting die einfachste Variante. Ganz grob:
 
$Params = @{ Path = $SourceFile Destination = $TargetFolder } Copy-Item @Params  
Den Inhalt von $Params baust Du Dir in Deiner If-Rutsche dann jeweils unterschiedlich zusammen. Geht übrigens auch "gesplittet":
 
$Params = @{ Path = $SourceFile } Copy-Item @Params -Destination $TargetFolder  
Man "könnte" deinen aktuellen String auch an Invoke-Expression verfüttern, aber das ist "bad bad style"
 
Und ansonsten zerlegst Du am Anfang alle Eigenschaften von DateTime-Objekten in Strings, um die dann mühsam wieder miteinander zu vergleichen. Das geht wesentlich einfacher, aber da hab ich grad keinen Kopf dafür, muss gleich erst mal so was "Nebensächliches" wie Abendessen machen

Ich werfe mal "LegalNoticeCaption" und "LegalNoticeText" für den Hinweis vor der Anmeldung in den Raum.
Und "nicht verändert werden" dürfte schwierig werden, aber wenn man nur temporäre Profile verwendet, kriegt man das auch in den Griff.
 
Frage ist nur - "warum"? Also rechtfertigt der nicht geringe Aufwand das Erreichen de uns unbekannten eigentlichen Ziels?

Nichts neues unter der Sonne https://evilgpo.blogspot.com/2013/01/group-policy-preferences.html
(Wie kann ich mit Zielgruppenadressierung IP-Timeouts in den Griff bekommen...)

Wenns per IP geht und per Hostname nicht - UND der Hostname auf die korrekte IP auflöst - hast Du ein Problem mit Kerberos. Und das solltest Du im einen oder anderen Security Event finden. Hintergrund: "Name" macht per Default Kerberos, nur wenn kein SPN gefunden wird kommt NTLM Fallback. IP macht immer NTLM.

Mount Points sollten gehen.

Dein Fehler war nur das fehlende Verständnis für "Contains". Das gilt nur für Arrays, und der Vergleichswert muss einem _kompletten_ Element des Arrays entsprechen.
 
$SampleData = "$env:TEMP\SampleData.txt" $Reader = [IO.StreamReader]::new( $SampleData ) $Results = [Collections.Arraylist]::new() $Queue = [Collections.Queue]::new() $BlockMarker = 'MSH' $MatchString = "PID" $MatchFound = $false While ( $SampleLine = $Reader.ReadLine() ) { $Queue.Enqueue( $SampleLine ) If ( $SampleLine -match $MatchString ) { $MatchFound = $true } If ( $SampleLine -match $BlockMarker ) { If ( $MatchFound ) { [void] $Results.Add(( $Queue.ToArray() )) } $Queue.Clear() $MatchFound = $false $Queue.Enqueue( $SampleLine ) } } $Reader.Dispose()  
Das steckt solange Zeilen in die Queue, bis ein "MSH" gefunden wird. Wenn unterwegs ein "PID" vorbeikam, wird die Queue in $Result gespeichert. Dann zurück auf Los
 
Das meinte ich mit meinem vorigen Post
Du mußt eine Logik finden und korrekt implementieren, die die Aufgabe auch löst.
 
Edit: Nachträglich von Get-Content auf StreamReader geändert, ist einfach Lichtjahre schneller...
Nachtrag: Natürlich geht das auch mit Regex Multiline. Aber da sind wir wieder bei der Wartbarkeit, Regex hat da seine eigenen Tücken. Hab irgendwo mal ein Regex aufgeschnappt, das ich nicht mehr finde - das konnte alle Arten von Kommentaren aus C++-Sourcecode entfernen. War aber komplett unverständlich...

Das soll auch so sein. Sorge dafür, daß die Zertifikate rechtzeitig aktualisiert werden Und nein, die Möglichkeit gibt es für _einzelne_ Zertifkate nicht.

"StrictNameChecking" und "LoopbackCheck" als Stichworte - von DNS-Aliasen stand da nichts bisher...

Genau. Du darfst Dich erst anmelden, wenn Windows kapiert hat, daß eine Domäne verfügbar ist   Und je nach Qualität und Art der Verbindung kann das auch mal ein paar Sekunden länger dauern.

Was soll da passieren, wenn kein Management drum rum auf den Namen angewiesen ist?

Einfach mal nen HW-Monitor und nen Stresstest gleichzeitig laufen lassen und zuschauen, was mit den Temps passiert

Stimmen die AnnounceFlags? 5 darf nur der PDCe haben, alle anderen haben 10. Wenn andere DCs auch 5 haben, halten sie sich für "always reliable" und ignorieren NT5DS...
Edit: Warum ich das vermute? Weil Du schreibst, daß einer alle FSMO-Rollen außer PDCe hat - also hat da mal wer den PDCe verschoben...

1. Wieso abtippen?
2.
 
Das Kennwort, das DC04 in seiner AD-Datenbank für DC03 hat, ist nicht identisch mit dem, das DC03 hat (AD-Replikation in Ordnung?). Oder das krbtgt-Kennwort ist "out of sync".
Erster Lösungsansatz: Dienst KDC auf allen DCs außer dem PDC-Emulator deaktivieren und stoppen (!!!), dann alle DCs neu starten außer dem PDC. Dann 10 Minuten warten und KDC auf allen DCs wieder aktivieren und starten.
Zweiter Ansatz: DC03 SecureChannel zurücksetzen.
Dritter Ansatz: DC03 neu aufbauen.

Ja, das sollte gehen, solange der alte Server noch online ist. Siehe oben - CNAME erfordert DisableStrictNameChecking. Neue Freigaben hast Du dann immer noch, aber per DFS sind die Clients von der Kenntnis des "realen" Ziels entkoppelt, das Du dann beliebig verschieben kannst. Egal wohin DFS zeigt, der Client sieht nur den DFS-Share. Den Rest macht MUP für ihn

klist erzählt Dir schon mal, welche Tickets du hast. Hat der RDS keine SPNs mehr registriert?
klist get TERMSRV/<FQDNdesRDS>
Und so weiter
BTW - "IPs getauscht", bist Du sicher, daß alle DNS-SRV-Records sauber sind?
nslookup -type=ALL _kerberos._tcp.<DomainFQDN>
liefert was genau? (Spoiler: "ALL" muss hier großgeschrieben werden...)

Ist möglicherweise ein Bug im MSI - das muß die administrative Bereitstellung unterstützen.

Wenn Du noch mal genau drüber nachdenkst, kannst Du es vermutlich selbst beantworten
 
Alle GPOs haben eine Versionsnummer. Ist bei einer davon die Version beim nächsten GPUpdate (Start/Logon/Background) anders, wird alles, was darin an CSEs enthalten ist, erneut verarbeitet (Registry, Security, Ordnerumleitung, Applocker, xyz - gibt glaub 45 Stück).
Ist sie überall gleich wie beim letzten GPUpdate, werden nur die CSEs verarbeitet, bei denen "auch ohne Änderungen" aktiv ist. Ausnahme ist Security, das wird alle (weiß nicht mehr genau) x Stunden auch ohne Änderungen zwangsweise angewendet.
 
 
Und Deine Idee zur Konfiguration ist ok.

gpedit.msc zeigt Dir die Einstellungen der "lokalen Policy" an. Die wird dann ggf. von domain based Policies überschrieben.
Und rsop.msc ist deprecated, das kann zu viel nicht anzeigen.

So gesehen: MS macht da, was es will, ja- ist ja auch "ihr" Betriebssystem. Aber das Ergebnis entspricht exakt dem erwarteten

Ich bin jetzt nicht im Code der SACL-Auswertung verbuddelt, aber: Je mehr Einträge die hat, um so mehr Prüfungen müssen bei Änderungen gemacht werden, ob eine davon grad zutrifft.
 
Ist immer ein Trade-Off: Bist Du sehr granular und damit zielgenau, hast Du sehr lange ACLs (S und D), deren Auswertung entsprechend länger dauert. Zielst Du ungenau, bist Du da zwar schneller, erzeugst aber mehr Logeinträge. Ich würde mich im Zweifel für zweiteres entscheiden, weil es im Handling einfacher ist und Event Logging ein erstaunlich lastarmer Mechanismus.
 
Aber probier's einfach aus und überwache die CPU- und Storage-Auslastung der DCs. Unsere haben kaum AD-Auditing, erzeugen aber trotzdem so viele Security Events, daß das 4 GB Security Eventlog in 4 Stunden Rollover macht. Darauf hängt dann natürlich auch noch der Splunk Agent, und trotzdem merkt man das nicht in Perfmon.

Die gleiche Diskussion hatten wir doch grad schon mal Du kannst die Verzeichnisse problemlos umbenennen und dann in der Registry den Profilpfad korrigieren. Der User darf da nur grad nicht angemeldet sein - Shutdown-Skript z.B. Danach noch ntuser.dat laden und Environment/Volatile Environment überprüfen und ggf. korrigieren (wobei das bei Volatile Environment unnötig sein sollte). Ob das ein Domänen- oder lokaler Account ist, ist dabei wurscht.
 
In eurer Automation habt Ihr halt leider die falschen Variablen ausgesucht.

Kannst Du machen wie Du willst. Am Ende muß es auf den Domain Controllern ankommen. Meinereiner macht das in einer GPO, die mit Domain Controllers verknüpft ist. DDP/DDCP ändere ich nicht - Stichwort "dcgpofix". Und die DDP hat "eigenartige" Beziehungen zu secpol.msc auf dem PDC-Emulator

Jepp. "Theoretisch" wird es erst im Domänenkonto geändert, und wenn das erfolgreich war, wird die lokale Version aktualisiert.

Wenn in der bestehenden FR-GPO das hier gesetzt ist

dann kannst Du die Umleitung nicht einfach durch das Entfernen dieser GPO rückgängig machen, ohne daß die Daten wieder zurückkopiert werden. Daher "Konter-GPO"...

Ist normal - Test-Path hat Schwierigkeiten mit Hidden und System Files. Wenn Du auf der sicheren Seite sein willst: Get-ChildItem -Force oder https://stackoverflow.com/questions/46678676/powershell-test-for-hidden-and-system-files

BTW - über wie viele GPOs reden wir hier eigentlich und über wie viele Settings darin? Möglicherweise ist es am einfachsten, HTML-Reports zu erstellen und einfach anzuschauen....
powershell -command "get-gporeport -all -reporttype html -path <dateinamewoauchimmerdiereportsgespeichertwerdensollen.html>"