MurdocX

Als weitere Alternative einfach den Link als Argument in den Eigenschaften der App hinterlegen. Das sollte auch gehen.

Bei uns (auch öffentlicher Dienst) wird das Dokument bei der Einstellung unterschrieben. Das mag bei euch erst mal zu spät für alle Anderen sein, anfangen muss man mal irgendwo. Das wiederum geht nur im Dialog mit der der Personalabteilung.

Da würde ich auf die Problematik mit den "fristlosen" MA und deren die nicht unterschreiben hinweisen und eine Prozessänderung anstoßen. Wenn die GL nicht an die wichtigen benötigten Daten herankommt, spätestens dann wird es ein Umdenken geben. Übrigens: Hut ab und gute Eier in der Hose einem der GF den Zugang zu den Daten zu verweigern

Öfters der schnellere, effektivere und sauberere Weg ist die Neuinstallation. Was bei speziellen Problemen individuell verstellt ist, lässt sich schwer sagen. Ob die Lösung des Problems auch an jeder verstellten Stelle wieder OK ist, lässt sich schwer sagen. Das Resultat könnten weitere "komische" und unerklärliche Folgefehler sein.

Klingt als wäre einiges im Argen. Eine Neuinstallation wird das Problem schnell lösen.

Ich denke das du gerade selber merkst, das du mit deinem Konstrukt etwas überfordert bist. Warum der Ping nicht zurück funktioniert ist jedem hier klar. Dein NAT (SNAT) geht initial nur in eine Richtig. Es ist und bleibt - egal was du dazu schreibst - der falsche Weg für deine Anforderung.

Schön aneinandergereiht dann so: $Data = Import-Csv -Path "C:\Users\user\Desktop\Test.csv" -Delimiter ';' | ForEach-Object { $_.Vorname = 'AA' + $_.Vorname; $_ } | ConvertTo-Csv -NoTypeInformation -Delimiter ';' Out-File "C:\Users\user\Desktop\Test1.csv" -InputObject $Data

Anstatt For, nutze mal ForEach-Object als Übergabe in die Pipe. Alternativ einfach jede Zeile bearbeiten, wie es @Dukel schrieb.

Das bietet keine „mehr“ Sicherheit, nur weil der Port auf einen Anderen genattet wird. Leider kann ich bei den wenigen Informationen die du lieferst nicht mehr dazu schreiben.

NAT ist nicht gleich Routing! Im AD sollte NAT vermieden werden. Ich frage mich was damit erreicht werden soll. Welche Vorteile würden sich denn deiner Meinung dadurch ergeben? Stell den vSwitch auf extern und gut ist.

War das jetzt vorher schon drauf oder nicht? So richtig raus lesen kann ich das nicht.

Ich wüsste nicht das man das "danach" macht :) Falls du andere Wege kennst, dann nur raus damit :)

Das AD hätte vorher vorbereitet werden müssen. Sieht schlecht aus bei Dir. Vermutlich bist du mit einer Neuinstallation schneller dran. Edit: Schau Dir mal das Video an. Dort gibt es eine Schritt-Für-Schritt Anleitung für Dich:

RDP im Allgemeinen - RDP-Verbindungen aufbauen darf der Benutzer, der auf dem zu verbindenden Gerät in der Gruppe der "Remotedesktopbenutzer" enthalten ist. - Auf dem zu verbindenden Gerät muss für den Port 3389 (default) die Firewall-Regel aktiviert sein. Wenn nicht mit irgendwelchen "supa dupa Aufräum- und Verschlankungstools" am System gewerkelt wurde, funktioniert das ganz zuverlässig. Durchaus hatte auch mal das Phänomen das die RDP-Verbindung sich von einem Client aus nicht mehr herstellen ließ. Von tausenden Computern in meinen Fingern gerade mal einer.

Also ist es einen Domänen-Benutzer... und kein lokaler. Die Begrifflichkeiten sollten schon passen. Ob du einen Domänen-Admin delegieren möchtest... Hier geht es jetzt um Deine Sicherheit. Kopier das Skript lieber auf den Client und führe es da aus. Das ist das Sicherste in deinem Szenario.

Und seit wann darf ein „lokaler Benutzer“ auf eine Freigabe zugreifen? Der hat doch im Netzwerk keine Berechtigung Lese dich ich mal in das Thema ein.

Das Zauberwort heißt CredSSP. Du musst die Delegation deiner Berechtigung genehmigen. Dein PC darf nicht einfach deinen Zugang frei Haus nutzen. Schau mal hier: https://docs.microsoft.com/en-us/powershell/module/microsoft.wsman.management/enable-wsmancredssp?view=powershell-6

Bevor ich den Beitrag von @Dukel gelesen habe, ging mir genau das Gleiche durch den Kopf. Der "erdachte Geschwindigkeitsvorteil" geht gegen 0.

Die Antwort: Dementsprechend sollte das kein Problem sein. Die Aufnahme hat einwandfrei funktioniert, nur ohne Mailreminder.

Bei Beiden muss die Firewall (eingehend) offen für RDP und eingeschaltet sein. Das wären die einfachsten Punkte zum Testen.

Kenne ich nicht. Werden die Patches regelmäßig installiert? Aktuell ist ESXi 6.7 U3 auf dem Markt. https://docs.vmware.com/en/VMware-vSphere/6.7/rn/vsphere-esxi-67u3-release-notes.html

AD Basics: Das macht man auch so nicht. Wie soll denn auch der öffentliche DNS-Server deine AD SRV Records haben? Wenn ich den Thread so verfolge, dann stelle ich des Öfteren fest, dass es dir an den Basics fehlt. Das meine ich nicht böse, sondern möchte Dir nahelegen dich damit mehr auseinanderzusetzen.

Ich tippe auf ein Treiber-Problem. Sind die Chipsatz-Treiber aktuell? BIOS aktuell?

Wird der WSUS Clients außerhalb des Unternehmensnetzwerks bedienen?

Welche NTFS-Berechtigungen hast du denn auf der Freigabe? Werden die vererbt? Bitte alles genau beschreiben.