daabm

Bei Firefox aktiviert man den Firefox-Sync und gut ist. Und Templates - was für Templates? Die von MS Office kannst per GPO umleiten, die von OO/Libre stecken in der Config.xml (oder wie das Ding heißt) und müssen per Skript umgebogen werden. Alles machbar und viel weniger Probleme auf Dauer.

Dann wird wohl einer der Remote-Computer aus sein. Daher mein Hinweis auf Jobs und ggf. mit Test-NetConnection abfangen. Ein Oneliner wird das nicht, wenn es schön und schnell sein soll

Der Path erscheint mir auch eigenartig - ich bin zwar kein WPP Profi, aber ohne absolute Pfadangabe, wo landet das dann? %ProgramFiles% oder %Systemroot%?

Nein, nicht in EINE Variable, dann wird daraus nämlich EIN Rechnername. COmputername kann eine Liste verarbeiten, aber das muß eine kommagetrennte Liste von Rechnernamen (oder Variablen) sein. Und ist so auch nicht zielführend. BTW: Wenn einer der Rechner nicht erreichbar ist, hängt das ganze bis zum Timeout (beim Kopieren genauso). Wenn das einigermaßen performant sein soll, wirst um Jobs nicht herumkommen Wir fangen langsam an. Schleifchen kommen später

Get-Help Foreach-Object -Examples :-) $PCListe = @( 'PC', 'PC2' ) # oder per Get-Content aus einem Text Foreach ($PC in $PCListe) { #mach irgend nen Kram mit $PC }

So wie Dukel sagt - die "eigentlichen" Benutzerdaten holt man mit FR (= Folder Redirection ) aus dem Profil raus, und damit ist das Profil wertlos für den Benutzer und kann lokal bleiben...

Ja mußt Du - Schemaänderungen führt nur der Schemamaster aus.

Hm - "referral" heißt, daß der LDAP-Server, mit dem Du grad verbunden bist, die Funktion nicht ausführen kann, weil ihm was fehlt. Wer ist Schema-Master? (netdom query fsmo) Ist dein adsiedit mit dem verbunden? Und was sagt "repadmin /showreps"?

Ich hätte noch Steine, könnte also den ersten werfen

User sollen sich ihre Drucker selber aussuchen - macht am wenigsten Arbeit. Was machst Du, wenn der User nur suspended und nicht runterfährt?

Hast Du verwaiste DCs in deiner Domäne? Für so was müssen alle DCs online und erreichbar sein...

Eigentlich gar nicht. Entweder RUP (dann roamt es mit dem Profil und wird beim Logon/Logoff kopiert und verlangsamt die Anmeldung und macht auch sonst jede Menge Ärger), oder FR (dann liegt es auf dem Umleitungsziel und nur da, macht aber noch mehr Ärger). Jan sagt es, ich sage es: Laß RUP bleiben. Und wenn Du FR verwendest: Leite die Datenverzeichnisse um (Dokumente etc), aber nicht AppData. Der wenige Kram, der da drin für den Benutzer relevant ist, kann auch von einem Logon/Logoff-Skript kopiert werden (Benutzerwörterbücher oder Templates in Office z.B. - wobei ich die per GPO eh ins Homelaufwerk schieben würde...).

Wurstel Dich hier mal durch: http://h10032.www1.hp.com/ctg/Manual/c00731218 (schon älter, aber vielleicht gilt es immer noch ) Laut der Doku muß das Zertifikat immer auch Serverauth enthalten, weil es automatisch wohl auch für den integrierten Webserver verwendet wird. Und irgendwo anders hab ich aufgeschnappt, daß nicht die CA-Kette enthalten sein darf, sondern nur das eigentliche Zertifikat.

Dann ist das auf dem Weg vom BSI in unsere Sicherheitsrichtlinien irgendwie mutiert - sicherheitsrelevant ist Verfügbarkeit bei uns nicht... Ok, wieder was gelernt

Best Practice laut MS ist inzwischen eine Subdomain der eigenen Internet-Domäne zu verwenden. Damit hat man alle Möglichkeiten...

Eine Woche Urlaub und so viele Fragen :-))) Im Prinzip ist es egal, ob Du A-G-DL-P oder A-G-L-P oder A-G-DL-L-P machst. WIchtig ist das grundsätzliche Prinzip dahinter: Globale Gruppen sind "Rollen". Rollen definieren Aufgaben, für deren Durchführung bestimmte Berechtigungen erforderlich sind. Lokale Gruppen (Domain local oder Server local) definieren genau diese Berechtigungen. Und durch geeignete Verschachtelung erhält jede Rolle die für sie erforderlichen Berechtigungen. Mit der zwischenzeitlich eingeführten SID-Compression (zusätzlich zur größeren Default-Ticket-Size) sollte das kein Problem mehr darstellen. Globale Gruppen sind IMMER drin. Was ist daran unüblich? Wir leeren auf allen Non-DCs die lokalen Admins und füllen die dann bedarfsorientiert auf. Für Dienste, die unter Service-Accounts laufen, hat das keine Auswirkung, da bereits bestehende Anmeldesessions davon nicht beeinflußt werden.

Warum haben die Leute immer so panische Angst davor, was im Schema zu ändern? Den Default-SD kann man ja bei Bedarf sogar wieder zurückändern - und ja, wir haben das auch immer so gelöst: Erst Default-SD für die jeweilige Objektklasse angepaßt, dann per Skript alle bereits bestehenden Objekte dieser Klasse aktualisiert.

Abgesehen von dem seit Jahren unsupporteten Betriebssystem könnte ihm ja auch mal jemand helfen Using the BurFlags registry key to reinitialize File Replication Service replica sets Edit: Ich werd alt - sehe grad "Zugriff verweigert" da war's dann doch wohl MS16-072 oder was in der Richtung...

Ich glaube, die Fehlersuche geht in die falsche Richtung. Office verwaltet doch die Dateiöffnung durch andere User selber über seine .lck Files (oder wie die genau heißen) - oder ist das nicht mehr so?

Auf dem QNap muß ein User Mapper laufen, der die Pinguin-UIDs und GUIDs in Windows-SIDs übersetzt und umgekehrt. Damit das klappt, muß der User Mapper beim Start natürlich einen DC erreichen. Wie oft der Mapper das dann erneut versucht, das mußt Du bei QNap herausfinden. Ansonsten wurde alles gesagt.

AppData in der Ordnerumleitung leitet nur AppData\Roaming um, nicht .\Local oder .\LocalLow. Das paßt also schon. Der Unterschied zwischen RUP und FR: Das Benutzerprofil liegt während der Verwendung IMMER lokal auf dem Rechner, wird zur Anmeldung dahin kopiert und am Ende wieder zurück. Umgeleitetete Ordner sind NICHT mehr Bestandteil des Profils, sondern liegen statisch immer da, wohin sie halt umgeleitet wurden. Und wie Jan würde ich auf RUP verzichten (außer in einer RDS-Farm).

Kleine Korrektur: Verfügbarkeit gehört da nicht rein, dafür Nichtabstreitbarkeit. Oder auf englisch: Confidentiality, Integrity, Nonrepudiation.

1. Wurde ja schon angemerkt - das Suchen von 1000 Adressen in jeder einzelnen Zeile geht schneller als die Logdatei 1000 mal zu lesen 2. Umstellen - dringend. .Net Streamreader - das Inet liefert Dir das HowTo dazu. Get-Content ist um Potenzen langsamer. 3. += ist böse. Besser ein .Net ArrayList (oder wie das heißt ) verwenden, auch da liefert das Inet. 4. Pipes vermeiden - immer und überall. Pipes sind auch schnarch...

Ne, so machst Du das nicht. Schau mal hier: https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html Wir setzen das grad im RZ-Betrieb um und es funktioniert prima. Wenn man die OU-Namen passend zu den Namen der administrativen Gruppen wählt und die Server sich immer direkt in ihrer "Anwendungs-OU" befinden, kann man das sogar mit einer einzigen Preference erschlagen Kurz zusammengefaßt: Finger weg von Restricted Groups, und Finger weg von direktem Zuweisen von Benutzerrechten zu AD-Gruppen. Immer eine lokale Gruppe erstellen und berechtigen und die dann mit den AD-Gruppen nach Bedarf füllen. 2 Ausnahmen: Lokale Admins (klar) und Remote Desktop Users - da funktioniert es warum auch immer nicht, da muß tatsächlich die Standardgruppe Remote Desktop Users verwendet werden.

Nein. Die Skript-CSE schreibt nur die Skripts aus GPOs in die Registry, ausgeführt werden sie immer als letztes. Als Lösung würde ich vorschlagen: Erstelle 4 Preferences. 1 und 2 löschen beide Drucker, 3 und 4 erstellen mit ILT den korrekten neu.