daabm

Danke @tesso

Hat da möglicherweise der Absender nur einen Link eingefügt statt des Originals?

Man löscht Profile nicht mehr durch das Entfernen des Profilordners. Entweder über das GUI oder über Win32_UserProfile.

Hmmm - hohe Anzahl von Geräten und kein AD, das paßt für mich nicht zusammen. Was ist der Grund dafür? Und die Aufgaben ansich - alles relativ einfach mit Powershell oder anderen Skriptsprachen umzusetzen. Woran genau scheiterst Du?

Kontraproduktiver Kommentar - mir geht es defintiv nicht um das Verheimlichen von Lösungen, sondern um das unaufgeregte (und gern unkommentierte!) Feststellen des eigentlichen Problems. Wer mich kennt, sollte das eigentlich wissen, aber ok, erst mal druff. Danke dafür... Edit: Das gleiche gilt auch für den darauf folgenden Kommentar BTT: Ich würde erst mal Batch streichen und auf Powershell umsteigen. Die Einstiegshürde ist nicht besonders groß, sehr viele (sehr sehr viele) Standardanforderungen in der Administration lassen sich googeln und Du wärst unendlich viel flexibler.

Weil nicht jeder KI mag, die Mails vorsortiert? Mir geht schon der Junkmail-Filter von Outlook.de auf die Nerven... @SBK das scheint derzeit tatsächlich nicht zu gehen :-( Ich hab nur das hier gefunden: https://docs.microsoft.com/en-us/office365/admin/setup/configure-focused-inbox?view=o365-worldwide Aber das bezieht sich auf O365, nicht auf die lokale Office-Installation...

Ich hab dazu wso viele Anregungen und Meinungen, daß ich möglicherweise die Größengrenze eines einzelnen Beitrags sprengen könnte, wenn ich jetzt alles dazu schreibe 1. Batch ist Grütze. Nicht nur, weil Powershell unendlich flexibler ist, sondern auch, weil Batch über UNC extreme Performance-Issues hat. Vor allem über langsame Leitungen. Datei öffnen, Zeile lesen, Positionsmarker setzen, Datei schließen, Zeile ausführen. Und das für JEDE EINZELNE ZEILE im Batch... 2. @echo off schaltet nur die Ausgabe des jeweiligen Befehls in der Konsole ab. Die Ausgaben der Befehle an sich werden sehr wohl ausgegeben. 3. Batch-Verschachtelung ist so Grütze wie Batch. Wenn schon, alles in eins rein. 4. Läuft das asynchron oder synchron? Wenn asynchron: Probleme mit Netzlaufwerken in Explorer oder Anwendungen sind vorprogrammiert. Wenn synchron: Desktop erscheint erst, wenn es fertig ist. Wenn die Shares nicht erreichbar sind: 30 Sekunden Wartezeit pro Share... (Genauer 29,56 ). 5. bis 99. spare ich mir hier mal - kannst mich ja mal direkt kontaktieren. Edit: Grad fällt mir 5. ein: Net use x: /d trennt die Verbindung. Aber nur, wenn da keine offenen Dateien sind, sonst kommt ne Rückfrage und das Skript bleibt stehen. Wenn schon "net use x: /d /y"... Edit 2 Ich werfe noch 6. hinterher: Startup und Logon Skripts sollten IMMER lokal liegen und lokal aufgerufen werden. Nur dann laufen sie auch, wenn keine Domänenverbindung besteht. Bei dem Skript hier ist das aber sinnfrei, weil es keinerlei Errorhandling oder "Situationserkennung" implementiert. Damit also dann auch nicht weiß, daß es offline ist (RootDSE nicht erreichbar) und nichts (oder nur wenig) machen sollte. Und man kann das nach dem Herstellen einer VPN-Verbindung auch automatisch ausführen, da gibt es so komische Events, die das signalisieren Um noch die Anfangsfrage zu beantworten - Datei ausführen, Ergebnis als XML erstellen; Beides sollte rein lokal passieren, und ins Netz kopiert wird dann, wenn das Netz auch verfügbar ist. Dann klappt es auch mit dem Nachbarn.

Jetzt pack den Tiger wieder in den Tank und mach ihm keine Angst - das passiert seltener, als man denkt. Mitbekommen tust ja immer nur, wenn es NICHT klappt...

Ich würde schon den Trigger an die Event-ID hängen und dann im aufgerufenen Skript die Anzahl (oder was auch immer) konkret auswerten...

Ich würde noch gerne nach dem eigentlichen Zweck fragen. Das Erscheinen von Notepad wird es ja wohl kaum sein Für so was würde ich übrigens auf WMI-Eventing zurückgreifen. Da muß eben KEIN Skript in einer Endlosschleife laufen, sondern WMI löst einen Eventtrigger aus, wenn was bestimmtes erscheint/geändert wird/verschwindet.

Geht im laufenden Betrieb - da authentifiziert sich ja i.d.R. nur selten jemand, und die morgens bei der Anmeldung ausgestellten Kerberos-Tickets gelten per Default 8 Stunden. Machst Du das am späten Vormittag, sollte niemand etwas bemerken, wenn es nicht grandios in die Hose geht

Und die Begrifflichkeiten sind noch etwas unscharf Wurde ja schon erwähnt: WDS/MDT sind ein reines OS-Deployment, ggf. mit integrierter Installation von Zusatzsoftware. Danach kommt aber _nichts_ mehr, Du kannst ein per MDT mit installiertes Office darüber nicht aktualisieren. Das braucht eine "richtige" Softwareverteilung.

WDS ist in 15 Minuten installiert und eingerichtet. MDT kann Wochen dauern

robocopy /xj... Ich bin raus.

Sehr unübersichtlicher Artikel, aber technisch sehr fundiert - der Autor hat das Problem voll verstanden ?

Works as designed. Entsperren und Anmelden sind zweierlei.

Ja, die GPP reichen - bis es mal irgendwelche Probleme gibt, dann bist mit denen sofort - sorry ***. Kaum Logging, keinerlei verwertbare Infos in den Logs, ich verzichte dankend Und ich hab leider schon öfter gesehen, daß es nicht so funktioniert wie geplant - auch wenn in den GPO-Settings kein Fehler erkennbar war.

Sind wir schon wieder bei Symlinks?

Dann schick den Testserver doch mal in die Zukunft

Clients Standalone, keine Domäne - vergiß alles, was Du da als Lösung möchtest. Wird nur Gefrickel... ym2c. Citrix-Farmen stellen keine Laufwerke bereit, sondern Anwendungen. Hol Dir jemand ins Haus, der die richtigen Fragen stellt und der dann darauf antworten kann. Per Forum wird das ein endloses Diskutieren von Experten, Semi-Experten und Ahnungslosen

Sunny verweis nicht immer auf die GPP, die sind immer noch Grütze. Für Drucker und Laufwerke immer Skript, wenn man "irgendeine" Skriptsprache halbwegs spricht oder in der Lage ist, Google zu bedienen...

Und das hat auch einen Grund... Alle großen Verteilverfahren kopieren ZUERST nach lokal und führen dann von LOKAL aus. Warum wohl?

Bissele OT: Alle Server-Editionen seit 2008 unterstützen AppLocker. Bei Terminal Servern also gar kein Streß. Bei den Client SKUs sind es leider nur die Enterprise Varianten, für alle anderen muß SRP genommen werden. SRP hat Vorteile (flexiblere Regeln), aber auch gravierende Nachteile - nämlich kein Eventlogging, und die effektiven Regeln sind schwieriger zu verstehen.

Schwupp sind wir woanders - Deine Vorgehensweise ist mir zu sprunghaft und zu wenig lösungsorientiert, ich bin raus...

Echt, man kann nicht festlegen, ob ein User Domain Admin ist oder nicht? Kann ich mir fast nicht vorstellen...