testperson

Als ob du noch nicht lange genug dabei wärst. :P *SCNR*

Bin halt abwärtskompatibel. ;)

Ich schließe die Verzeichnisse aus und ergänze um: ... | ? PSIsContainer -eq $false) | Move-Item

Hi, hast du testweise mal ein komplett neues Profil für einen betroffenen User erstellt? Gruß Jan

Hi, Anmelden != Entsperren. ;) Ich würde die Policy entweder nur an den Clients (bevorzugt) oder nur am Terminalserver anwenden lassen. Gruß Jan

Mit foreach müsste ja jetzt die ganze Logik umgebaut werden. ;) An der Stelle sollte es auch mit while($XMLPath = ... -First 1){ [xml]... ... Remove-Item $XMLPath } gehen. Generell würde ich es aber einfach der Herausforderung wegen alles mal mit foreach durchspielen.

Vielleicht: "Ich bin so unentschlossen. Als japanischer Krieger wäre ich ein Nunja."? Manchmal werden halt ziemlich allgemeine Fragen mit wenigen Infos gestellt und eine fix und fertige Lösung erwartet. Ab und an muss man sich dann auch mal ein wenig selber helfen und ggfs. etwas detailierter Fragen. Ich meine, die Antwort auf die eigentliche Frage, wäre sogar nur ein "Nein." gewesen. Ich könnte auch "aus dem Zubehör" eine Hose erwerben, die vorne und hinten oben jeweils Löcher haben, da ziehts vermutlich auch.

Nicht? Wozu kann ich denn den ClientAccessName entsprechend anpassen (https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80)? Set-RDClientAccessName -ConnectionBroker <Mein Broker> -ClientAccessName MeinBroker.MeineDomain.<"Routbare TLD"> Ich kann mir auch die Hose auf den Kopf setzen und mich wundern, dass es untenrum zieht. ;)

Klar. Würde ich aber nicht tun und löst halt auch nicht dein Problem. ;)

Hi, das Trennen alle 30 Minuten (per Default) ist eben auch der Nebeneffekt von "Ersetzen". An dieser Stelle würde ich fürs Laufwerksmapping, mittlerweile, zum Script raten. Gruß Jan P.S.: Wer ist GPIO? ;)

Das passende, eindeutige(?) PDF sollte sich doch anhand der RG Nummer identifizieren lassen? Get-ChildItem $RootVerzeichnis\IN\ -Filter *.pdf | ? Name -imatch $($RGNR + ".pdf") | Rename-Item -NewName {$_.Name -replace $SuchenNach,$RGNR}

Bei welcher eigentlichen Tätigkeit bist du denn jetzt auf dein aktuelles Problem gestoßen? Möchtest du deine(n) Domain-Controller auf Server 2019 updaten ("migrieren"), der Server 2019 lässt sich nicht aktivieren und der/die alten DC(s) sind noch da? Das ist in einer produktiven Umgebung?

Hi, bei mehreren XMLs wäre es ein Ansatz per For-Each die XMLs nacheinander abzuarbeiten oder dir immer nur die erste XML einzulesen. #ForEach Get-ChildItem -Filter *.xml | ForEach-Object { [xml]$xml = Get-Content -Path $_.FullName } #Nur eine XML $XMLPath = Get-ChildItem -Filter *.xml | Select-Object FullName -First 1 [xml]$xml = Get-Content -Path $XMLPath Das Löschen sollte nachher mittels "Remove-Item" zu erledigen sein. Gruß Jan

Kann ich dir nicht sagen, da ich es noch nie gemacht habe / machen musste. Lucky me, was. ;) Damit mir aber später nichts (un)erwartetes auf die Füße fällt, würde ich grade im Hinblick auf den Zeitfaktor einfach neu installieren. Ansonsten halt das AD über den angesprochenen Weg "retten". Gibt es Gründe, warum du die Neuinstallation gerne verhindern wollen würdest?

Hi, das dürfte unterm Strich (zeitlich gesehen) nicht viel unterschied machen. Falls du da schon viel eingerichtet hast, wäre es evtl. eine Überlegung, einen weiteren temporären DC zu installieren, den vorhandenen zu entfernen / neu zu installieren und vorm Hochstufen zu aktivieren. Gruß Jan

Ein käuflich erworbenes bzw. signiertes Zertifikat. (Wenn genug Zeit und Lust vorhanden ist, kann man das auch mit Let's Encrypt "kostenlos" erledigen.)

Hi, generell brauchst du keine CA. Das funktioniert auch mit den entsprechenden selbstsignierten Zertifikaten, die bei Installation erstellt werden. Nur für Terminaldienste würde ich auch keine eigene PKI / CA aufsetzen, sofern es keinen weiteren Bedarf gibt, sondern auf Zertifikate einer öffentichen CA zurückgreifen. Gruß Jan P.S.: Ich würde ebenfalls nicht mit selfsigned Zertifikaten "hantieren".

Hi, das sind so Schritte, die man regelmäßig machen sollte. Generell klingt das nach einem automatisch installierten Sicherheitsupdate (nicht CU) von Exchange. Auf welchem CU ist / war der Exchange denn? Gruß Jan

Und wo ist / war jetzt das Problem?

Hi, um welches Client OS bzw. auf welche OSs soll das GPO wirken? Bei Windows 10 / Server 2016 (bzw. ab Win 8 glaube ich) erreichst du dein Vorhaben durch Dism und Ex- / Import der DefaultAppAssociations. Sobald du die XML per GPO verteilst, wird die logischerweise immer das überschreiben, was der User konfiguriert. An einem PC die Zuordnung einrichten "Dism /Online /Export-DefaultAppAssociations:<Pfad wo du die XML haben willst>" "Dism /Online /Import-DefaultAppAssociations:<Pfad wo die XML liegt>" Gruß Jan

Ach ja, HP AMS... Vielen Dank jedenfalls, das Patchen steht bei uns auch noch an. Da sparen wir uns wohl etwas Troubleshooting bzw. generell den Fehler.

Du hast zu 99% immer noch ein Problem mit SplitDNS. Das andere Phänomen ist vermutlich mit dem Stichwort "AdminSDHolder" zu lösen. Ganz ehrlich: Holt euch externe Hilfe. Zumindest der Exchange macht bei euch ja schon seit (über?) zwei Wochen Probleme! Jetzt bin ich hier aber endgültig raus.

Wenn du SYSVOL jemals von FRS zu DFS migrieren musstest (und diese DCs noch vorhanden sind), dann gibt es die SYSVOL_DFSR Ordner auf eben allen DCs die vorher FRS nutzten. Man _muss_ halt erst mit dem ersten 2019er DC (bzw. um genau zu sein ab Windows Server 2016 1709 (also nur SAC)) auf DFS migriert haben.

Ggfs. AnyDesk (https://anydesk.com/de). Aber keine Ahnung, ob die ähnlich vorgehen wie Teamviewer.

Ein wenig OT: Bzgl. deiner Virtualisierungsumgebung: https://kb.vmware.com/s/article/2145103