daabm

Ein "saublöder" Trick wäre, das Zielverzeichnis auch noch unter einem anderen Laufwerk bereitzustellen - dann rafft der Explorer das IMHO nicht mehr und macht Copy/Delete. Aber auch das kannst Du den Usern schwerlich erklären... :)

Jupp stimmt :-) Ich glaub das war der hier: https://support.microsoft.com/en-us/help/2530309/internet-explorer-group-policy-preferences-do-not-apply-to-internet-explorer-9-in-a-windows-server-2008-r2-domain-environment

Ach stimmt, das war ja das Elend - ich vergaß :)

Shortcuts auf UNC-Pfade funktionieren nicht als Filesystem-Objekt. Mach ne URL-Verknüpfung daraus, das geht. Oder erstelle eine LNK-Datei und kopiere die einfach.

Wenn Du "IE10" auswählst, wird maxversion automatisch auf 99 gesetzt - MSFT hat das selber auch schon gemerkt, daß das Verfahren etwas grottig ist :)

...wenn das als CSV ankommt, könnte man es auch direkt an csvde verfüttern :)

Auf deinem DC laufen die ADWS nicht... Oder die Firewall blockt den Port (9xxx war das glaub.)

Du sollst auch nicht GPO (Administrative Vorlagen) verwenden, sondern Group Policy Preferences - Pfad im Editor: Benutzerkonfig - Einstellungen - Systemsteuerung - Interneteinstellungen. Und auf den Trick mit F5/F6/F7/F8 achten :-)

Das wird nicht gehen - nur der Besitzer und Administratoren haben das Recht, Berechtigungen zu ändern. Und wenn beim Verschieben immer geerbt werden soll, müßte das auch beim "gewöhnlichen Benutzer" passieren. Du verstehst? Das ist ja auch der technisch große Unterschied zwischen Verschieben auf dem gleichen Laufwerk und auf verschiedenen Laufwerken. Beim gleichen Laufwerk ist es hinterher die gleiche Datei wie vorher, sie hängt jetzt nur wo anders rum. Bei verschiedenen Laufwerken ist es eine neue Datei.

Hast Du auch die Rechte auf System/WMIPolicy verglichen? Und ggf. sogar System selbst.

RoyalTS kann das z.B. - aber "richtig machen" ist die bessere Alternative.

...der zweite Client kann ja auch eine VM sein, die die 2. NW-Karte exklusiv nutzt :) Und warum das nicht geht - Du hast einen DNS, der muß beide Zielumgebungen auflösen können. Kann er wahrscheinlich nicht.

Tip aus der Praxis: WMI Filter sind zuverlässiger, die laufen nämlich immer und sind nicht abhängig von AD-seitigen Skripts. Außerdem muß der Rechner danach nicht neu booten, wie das beim Verschieben der Fall ist. Aber jeder ist seines Glückes Schmied :)

Der TO will wohl das alte LocalGPO.wsf nachbasteln - aber das gibt's eigentlich schon fertig neu von Aaron Margosis: https://blogs.technet.microsoft.com/secguide/2016/09/23/lgpo-exe-v2-0-pre-release-support-for-mlgpo-and-reg_qword/ Naja als Übung vielleicht net soo schlecht :) :) :)

Warum? Das funktioniert prima, mit oder ohne List Object Mode :)

Das hab ich doch im Technet auch schon mal gesehen... Egal :) dsa.msc, Menü "Ansicht" - Erweiterte Funktionen aktivieren. Dann nach System/WMIPolicy/SOM, Rechtsklick "Eigenschaften" - "Sicherheit". Sollte so aussehen wie hier: Vergleiche mit einer funktionierenden Domäne (notfalls eine VM hochziehen und promoten, ist schnell erledigt).

Ich kenn das von O2016 so nicht... Screenshots wären vmtl. hilfreich :)

Stimmt, wenn der User kein Admin ist und die UAC nicht angepasst wurde, kommt ein Anmeldedialog. Gibt man jetzt einen Admin-User an, startet der Task Manager als Admin. Gibt man seinen eigenen Nicht-Admin-User ein, startet er als User. Konfigurere das Verhalten des UAC Prompt für Standardbenutzer passend, dann kommt kein Anmeldedialog mehr. Wenn Du wissen willst, woran das liegt: Such mal nach "asInvoker highestAvailable requireAdministrator" :)

Hat da mal jemand im AD mit den Containern unter System gespielt? Ist der einzige Fall, der mir bisher untergekommen ist... Da waren unter WMIPolicy die Rechte falsch.

Und wenn den TO das interessiert, werfe ich mal Tier0/1/2 in den Raum :-) https://technet.microsoft.com/en-us/windows-server-docs/security/securing-privileged-access/securing-privileged-access Wie Blub schon schreibt: Ein Domain Admin macht genau das - er administriert die Domäne und sonst nichts. Das ist NICHT identisch mit dem AD oder GPOs oder Fileservern, das kann man alles ganz easy delegieren.

Prima Beschreibung... Sorry, aber mit "einen Fehlercode" kann hier niemand was anfangen. Und wie Du googelst, weiß ich nicht - frag lieber jemand, der sich auskennt, aber sag ihm Deine Fehlermeldungen bitte im Wortlaut. SCNR...

Ja, und in unserem Fall war das eben keine Datei, sondern eine LDAP-URL. Der Timeout steckt irgendwo im Webzugriff, wenn der Request gedroppt wird, konnten wir im Trace gut sehen.

Wie Nils schon schreibt: In Sites und Services sollten die Standorte, Subnetze und Site Links der tatsächlichen Konfiguration entsprechen. Und dort solltest Du auch prüfen, daß die DCs in den Sites aufgeführt werden, in denen sie tatsächlich sind. Über die Site Link Costs kannst Du ggf. sogar noch eine Priorisierung umsetzen.

Zeig mal Deine Regel... Screenshot hilft

Nö, das ist ja nicht LDAPS spezifisch, sondern allgemein bei Zertifikaten :-) Wenn die im Zertifikat angegebene CRL- oder OCSP-Adresse nicht erreichbar ist (weil z.B. per Firewall geblockt), dann rennt der Revocation Check in einen Timeout von 30 Sekunden. Hatten wir mal beim IE, wo ein CA-Zertifikat (Infonotary) als CRL nicht http:// verwendet hat, sondern ldap:// - und das wurde natürlich nicht durchgelassen, sondern verworfen. Lösung war, die zu der ldap-Adresse gehörenden IPs in der lokalen Windows-Firewall zu blocken, dann geht's sofort.