daabm

vor 7 Stunden schrieb schmimla21:

So was hatte ich auch vermutet. Allerdings habe ich dasselbe Problem, wenn ich die .xls auf der lokalen Festplatte speichere und die Datei von dort aus geöffnet werden soll...

Kopierst Du die Datei? Dann würdest Du die Sicherheitszone "mitnehmen"... Und was Excel bei Öffnen und dann "Speichern unter" damit macht, da wäre ich dann komplett raus. Ich bin Sysadmin, kein Anwendungsbetreuer

Doch, es ist so daß Microsoft das nicht vorgesehen hat, daß bei der ANmeldung eines Users Dinge laufen, die NICHT im Kontext und mit den Rechten dieses User laufen.

RDP -> Server -> AppLocker. Mehr braucht man da eigentlich nicht. Und für die Schlangenöl-Fans noch den Defender aktivieren, ok

Was meinst Du mit "an ihrem lokale Ort"? C:\Users? Da geht das nie einfach so per Explorer - nimm ne Admin-Commandline... Und wozu überhaupt? Lokale Profile (und damit auch lokale Kopien servergespeicherter Profile) löscht man über Arbeitsplatz - Eigenschaften - Erweitert - Benutzerprofile. Oder über WMI (Win32_UserProfile). Wenn Du nur das Verzeichnis entsorgst, gibt es hinterher Probleme mit Apps.

Wir sind so ein RZ - Du mußt erst mal die Anforderungen klar beschreiben. Vorher gibt's keine sinnvollen Antworten

Die Office-Optionen sind seit längerem schon etwas "übergreifend"

Du hast vermutlich ein Problem mit Sicherheitszonen... Steck den Hostname und den FQDN des Servers im IE in die Trusted Sites, dann sollte es gehen.

Vermutlich würde es dem TO helfen, seine ADMX mal zu aktualisieren

Am 17.8.2019 um 14:09 schrieb speer:

Portzustände durch den Switch nicht rechtzeitig beendet sind. Dadurch wird ein ausführen der GPOs verhindert

Portfast ist aktiviert? Oder wie auch immer das heute heißt Alternativ https://www.gruppenrichtlinien.de/artikel/ssd-zu-schnell-synchroner-startvorgang-nicht-moeglich/

Nimm 24 Bit, das ist genau ein Kasten... SCNR

Und lies Dich mal in die verschiedenen Möglichkeiten ein, wie man administrativ was ausführen kann. Task bei Anmeldung, Logonskript, "Run" etc.

vor 11 Stunden schrieb Terminator81:

jepp Szenario Notebook

nach aktuell denke ich 14 Tagen kann der User sich nicht mehr anmelden .....

 

Nein. Wenn keine Domänenverbindung besteht, geht das unendlich lange. Dein Problem ist ein anderes, aber das hast Du ja noch nicht wirlich beschrieben.

Skript unsichtbar ging mit VB-Script prima - "wscript //B logon.vbs". Heute wäre mir nichts direkt so einfaches bekannt.

Umpf - isses jetzt klar? "User ist Mitglied" und "NICHT User ist Mitglied" Und wir verbinden per Agent - aka "Skript". Besser is das.

Ich hab nix von logon.bat geschrieben - meine heißen immer logon.vbs oder logon.ps1. Wenn da 5 Konsolenfenster aufpoppen, ist das eher Chaos bei der Administration. Und wenn es "irre lange" dauert, ist das auch Chaos bei der Administration. Lang dauernde Anmelde-Tasks startet man asynchron in eigenen Threads. Gibt genug Möglichkeiten dafür.

a) Korrekt. Deshalb auch "synchrone Anmeldeskripts" deaktivieren.

c) Wenn a) umgesetzt, passiert das doch automatisch.

Ich würde aber grundsätzlich was anderes empfehlen:

1. Anmeldeskripts synchron lassen. Hat den Vorteil, daß sie laufen, bevor der Desktop kommt. Das wiederum spart Nerven mit Netzlaufwerken und Druckern. Darf aber dann sonst auch NIX rein, was Zeit kostet.

2. Alles, was länger dauert, über "Diese Programme bei der Benutzeranmeldung ausführen" starten. Das läuft immer asynchron und erst, wenn der Desktop da ist (Run-Key in Registry, sinngemäß)

...und bei GPP könntest Du eine Zielgruppenadressierung auf Datei nutzen - mußt dann halt 2 Items machen. Oder Registry - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun:InstallPath (wenn Du ClickToRun hast, sonst natürlich anders). Geht alles irgendwie

Aber Logonskript würde ich auch beibehalten - gibt irre viel, was damit viiiiel einfacher und zuverlässiger und schneller ist als rein mit GPOs.

Ich kenne die zugehörigen Events jetzt nicht auswendig, aber beim Verbinden mit der Domäne gibt es auf jeden Fall einen Profilwechsel bei der Firewall und ein Network Change Event. Wenn es Windows RAS wäre, "rasman" protokolliert das. Cisco sollte das auch hinbekommen... Ansonsten: Nachschauen

"Anmeldeskripts gleichzeitig ausführen = Aktiviert." ist grob irreführend - das mußt Du deaktivieren. https://gpsearch.azurewebsites.net/#2302

Die englische Erklärung ist besser als die deutsche Synchron ist eben NICHT gleichzeitig. Vor allem nicht im englischen.

Ah - Edit: Ja, Robocopy ist besser. GPP Dateien ist Schrott. Nachteile: Kein Aktualisieren einzelner geänderter Dateien, synchrone Vordergrundverarbeitung (wenn's hängt, hängt die ganze Anmeldung), kein Logging für einzelne Dateien, kein Throttling, kein Multithreading usw usw usw. Schrott halt.

Auf dem Register "Gemeinsam" gibt es so einen Haken "Im Kontext des angemeldeten Benutzers ausführen". Fehlt der, braucht das Computerkonto Zugriff.

Und wie Jan schon schrub: GPP sind ganz brauchbar - außer "Dateien", das ist Schrott (und "Drucker" auch). Wirst Du merken, wenn mal was schiefgeht Skript ist besser.

Gegen Eltern hilft nur ausziehen

Das kann Dir nur MS beantworten. Die Lizenzbedingungen sind - vermutlich bewußt - extrem undurchsichtig.

Was ist an einer VM jetzt ein "richtigerer" Router als ne Fritzbox?

Powerline gilt als Kabel. Möglich ist ein Kabel immer, kommt nur auf den Willen dahinter an. Stichwort "Gebüsch"...

Lege ein Kabel. NAT über WLAN unterstütz die Fritzbox m.W. nicht.

https://www.windowspro.de/wolfgang-sommergut/uebersicht-microsoft-cals-wann-braucht-man-client-access-licenses

Keine IIS-CAL, wenn ohne Authentifizierung...

Du konntest es gut erläutern, ja. Und Du hast auch erläutert, daß Du daran nichts ändern willst...