daabm

Das stimmt. Ohne VPN keine Verbindung zum DC, und ohne DC keine GPOs. Wenn VPN steht und ein DC erreichbar ist, läuft die GPO-Hintergrundaktualisierung ganz normal für alle CSEs, die im Hintergrund verarbeitet werden können. SKripts gehören z.B. NICHT dazu.

Es geht nicht um den reinen Dateinamen, es geht um den kompletten UNC-Pfad... Und Powershell selber - ich weiß nicht, ob die diese Namen überhaupt sieht. Mit Robocopy geht es auf jeden Fall. Ich kenn das vor allem von %temp% und von Weblinks, wenn der Webseiten-Titel etwas "unsinnig lang" ist

Auf File-Ebene kommst Du um EINEN Organigrammbasierten Ast meist nicht rum. Aber warum müsst Ihr unbedingt dieses Top-Down-"Machtprinzip" umsetzen? Ist doch komplett out - wenn einer was persönliches hat, soll er's woanders hinstecken, und ansonsten darf jeder alles sehen, was nicht geheim ist.

Wahrscheinlich wird sie das tun - die meisten verwenden dafür inzwischen Group Policy Preferences, und die verarbeiten auch "ohne Änderungen". Zumindest wenn man's nicht abschaltet. Recht hast Du, soweit es Administrative Vorlagen betrifft, die tun das per Default nicht.

Das mußt Du herausfinden - ist das auch ein Proxy?

Satteliten-Systeme: Identity Management (Forefront/ITIM/Was auch immer), SCCM/Patchmanagement, Antivirus, Backup und und und... Wenn Du ESAE konsequent umsetzt, mußt Du das alles für Tier 0 noch mal separat aufbauen. Jedes System, das auf einem T0-System einen Agenten steuert, der mit Admin- oder Systemrechten läuft, ist automatisch auch ein T0-System.

Mit Start-Process -wait bist Du nicht mehr asynchron. Hängt Dein gestarteter Prozess, hängst Du selbst auch

Die F3-Liste zeigt Dir nur die "GPP-internen" Variablen an. Die "normalen" Umgebungsvariablen kannst Du aber ebenso verwenden.

LOL - ich bin dann hier mal raus.

Ich hab den Schotter damals komplett geskriptet... WIM auspacken, anpassen, wieder in eni WIM reinschieben... Das größte, das ich mal gebaut hatte, enthielt Win 7 Pro und Enterprise, 2008R2 Standard und Datacenter, jeweils 32 und 64 Bit. Und das geht heute noch genauso, also hau rein!

Fällt mir grad noch ein - wenn sie "glücklicherweise" per RDP kommen, ist die Session ja disconnected. Das kriegt man per Skript raus, und ein geplanter Task kann die dann forced abmelden...

Ich würde ja empfehlen, das LAN vom Internet zu trennen - also das DSL-Kabel aus der FB ziehen. Dann passiert garantiert nix...

So geht das nicht. Wenn Du PDFInfo asynchron startest, kommst Du nicht "direkt" an einen Returncode ran. Und so wie Dein Beispielcode oben aussieht, ist das wieder nicht asynchron und hängt dann halt, wenn $PDFInfoToolPath nicht zurückkommt... Multithreading ist nicht einfach am Anfang

Kenn ich nicht - aber bei uns. Da klappt das so prima. (Konzern mit ~6.500 MA)

Wo Du recht hast, hast Du Recht. Im Prinzip Ich sag immer "einmal mit Profis arbeiten" - erwischst Du den richtigen Dienstleister, läuft alles für nur wenig mehr als selbermachen. Erwischst Du den falschen, sieht es aus wie in Deinen Szenarien. Und das ist noch nicht mal von der Firma abhängig, die Du engagierst, sondern von dem individuellen Menschen, der dann kommt. Schwieriges Thema... Bissle wie bei Autowerkstätten

Je kleiner die Umgebung, um so weniger Aufwand ist das Umsetzen der Tier-Trennung. Auf JEDEN Fall unterschiedliche Accounts für Dom-Admin, Member Server und Work-Client! Das kostat fast gar nix Wir verrecken daran grad ein wenig, weil es zu viele Satelliten-Systeme gibt, die dann auch Tier-Trennung machen müßten - und das ist zu teuer und überhaupt...

Wenn die User per RDP auf die VMs gehen, könntest Du mal mit den RDS Host-Settings experimentieren - hab ich aber noch nie gemacht, daher nur als Idee...

esd sagt mir nix, war wohl nach meiner Zeit Aber wenn man daraus ein WIM machen kann, dann kannst Du dieses WIM entpacken und in ein anderes WIM wieder reinstecken. Dauert halt "a weng", geht aber.

Vater von Methusalem - Olaf hat's oben verlinkt...

Dann bau Dir deinen Geheimraum. Viel Vergnügen Ich bin raus.

Einer muß ja auf dem Teppich bleiben - der kehrt den dann auch ab und zu Was ich schon für Klimmzüge gemacht habe, um PSDrive-Operationen zu beschleunigen... Bis hin zum Speichern aller bereits besuchten "Verzeichnisse" in einer Hashtable, damit ich da schnell nachschauen kann, ob es existiert. Weil "nachschauen im realen PSDrive" bis zu 5 Sekunden dauerte...

Wenn Du soviele Sorgen hast: Hol Dir jemand, der sich damit auskennt.

Bei allen großen Herstellern gibt es günstige SoHo-Server im kleinen Gehäuse mit wenig Radau. Die reichen alle...

Huch, Henoch ist ja sogar hier im Forum aktiv Nix für ungut, Edgar... @Adenium Wie auch immer: Wenn Du was aktualisieren willst, während was anderes noch läuft, heißt das Multithreading. Und das ist in Skripts immer etwas - hm - aufwändiger? Heikler? Weiß auch nicht... Theoretisch hast Du nämlich 3 Threads: Main, der das Konsolenfenster anzeigt. #1, in dem der Robocopy läuft. #2, der die Zeit aktualisiert. Ggf. noch #3, der StdOut/StdErr von Robocopy abgreift und auch in Main einblendet. Glaubst Du, daß das mal eben schnell zu realisieren ist?

-Erroraction und Try/Catch lösen das. Und Wait-Process hatte ich gar nicht auf dem Schirm - das ist in Verbindung mit Start-Process sicher ein guter Ansatz.