BOfH_666

... schwer zu sagen, ohne den Code zu sehen. Es gibt die ein oder andere Geschichte, die aus der AP nicht funktioniert. Logging ins Skript einbauen? ... ansonsten kenne ich nur den Verlauf in der AP, wo im Zweifel die Exit-Codes stehen.

Wow, die Hilfe ist aber wirklich undurchsichtig/missverständlich. ... hast Du nicht eine Maschine, wo Du das testen könntest und so quasi empirisch ermitteln könntest, wie das zu benutzen ist? Davon unabhängig: Sollte ein "Get"-cmdlet überhaupt irgendeine Einstellung verändern? Ich würde bei einem "Get"-cmdlet erwarten, dass es ausschließlich Informationen ausgibt und nicht den Status eines Systems verändert.

Hallo fritzg1974 und willkommen im MCSEboard. Wenn Du Code postest, solltest Du den als Code formatieren, bitte. .... sieht besser aus und verhindert im Zweifel ungewollte Zeilenumbrüche oder automatische Formatierungen der Forensoftware, die man im Code aber nicht haben möchte. Ich würde Dir empfehlen, den Inhalt der Variablen, die Du benutzt, einfach mal zur Laufzeit des Skriptes , auszugeben. Idealerweise mittels Write-Debug oder Write-Verbose. ... zur Not einfach mit Write-Host. Dann weißt Du, ob überhaupt das bei Get-ChildItem ankommt, was Du erwartest. ... und noch ein dringender Tipp: In Skripten solltest Du generell keine Aliasse verwenden und den Code möglichst ausführlich und lesbar schreiben. Das gilt um so mehr, wenn Du Deinen Code in einem Forum anderen Leuten zeigst, die ihn lesen und verstehen sollen. EDIT: Es ist übrigens eine der Board-Regeln auf Cross-Postings hinzuweisen!!!! https://social.technet.microsoft.com/Forums/de-DE/082e54f3-9fec-42f8-b195-b68bd597d07c/datei-suche-mit-gci?forum=powershell_de#36250f73-b295-446e-93a9-d707b9a190b9 Vielleicht schaust Du Dir die nochmal an: Regeln und Nutzungsbedingungen

Dann musst Du aber davon auch noch Kopien machen, die Du außer Haus schaffst ... wenn schon, denn schon!!

Das Problem sind ja leider nicht die 99% .... sondern das eine Prozent, welches eben nicht weggefischt wird!! .... deshalb sollte es im Idealfall eine Strategie geben, die eben auch den Ernstfall mit abdeckt. Also Backup und Recovery sind mindestens genauso wichtig wie der Bedrohungsschutz an sich.

Schlimmer ... wir sind IT-Profis.

Damit Du nicht nur eine (zugegebenermaßen sehr professionelle) Meinung hörst (bestimmt kommen auch noch weitere) ... hier noch ein oder zwei "Denkanstöße" von mir: Dazu ein eindeutiges Jein!! So etwas wie einen "Standard" gibt es nicht. Die Lösungen und Strategien sind so vielfältig wie das Leben selbst. Das hängt entscheidend von den Anforderungen und Voraussetzungen ab. Wenn das Haupteinfallstor für Schädlinge z.B. der Mail-Client ist, kann Dir die teuerste und beste Firewall auch nicht mehr helfen. Dann kommt die Bedrohung quasi von Innen. Zu viele Einschränkungen können auch das Gegenteil bewirken, weil Anwender Wege finden, einengende und stark hinderliche Regeln zu umgehen. Wenn Du 3 Leute nach deren Meinung fragst, solltest Du Dich darauf vorbereiten mindestens 5 Meinungen zu hören.

<SNCR> Also sozusagen 'ne "Switch-Gurke"? .... oder ein "Gurken-Switch"? </SNCR>

Das würde ich auch annehmen - habe da aber leider auch keine Erfahrung, sorry.

Hast Du denn schon mal probiert, ob Du mit Get-BitsTransfer ein paar nützliche Infos bekommst? ... die anderen BITS-cmdlets sind übrigens am Ende der Doku alle verlinkt.

Man kann MSIExec auch noch mitgeben, dass ein ausführliches Log geschrieben wird. Das würde dann bei der Fehlersuche helfen. Edit: ... und wenn ich mich grad nicht verguckt habe, hat Cisco die Infos und scheinbar auch die Installationsquellen aktualisiert. Vielleicht schaust Du mal vorbei und versuchst es mit der aktuellen Version. https://help.webex.com/en-us/nw5p67g/Webex-Installation-and-Automatic-Upgrade

Lucky me. ... wir setzen hier SCCM ein. Da gibt es fast keine Grenzen.

Definitiv. ... ist ja aber beim Teams-"MaschinewideInstaller" oder EdgeChromium das Gleiche ... bisher funktionierts aber.

Nein. Das ist richtig. Ich wollte es nur noch mal klarstellen. Jetzt zu Dukels Nachfrage: Was passiert denn, wenn Du Dich mit Admin-Rechten auf einem Client-Computer anmeldest und die Kommandozeile direkt ausführst?

Dafür muss die "webexapp.msi" auf dem Zielcomputer in diesem Verzeichnis vorliegen!!! ... nicht auf dem Server!!! Und bei uns funktioniert die Installation ganz hervorragend mit folgender Befehlszeile: msiexec.exe /i <pfad ... \webexapp.msi> AUTOOC=0 PTLANG=DE CREATESHORTCUT=0 /qn Das kannst Du doch ganz leicht umgehen, indem Du die für die Installation nötigen Dateien vorher bereits auf den Client bringst. Einfach vor dem Aufruf der Kommandozeile in ein geeignetes Verzeichnis auf dem Client kopieren und dann entweder mit PSExec oder mit Powershell den Installationbefehl absetzen. Bei 60 Clients kann man das fast noch per Hand einzeln machen, wenn man sich nicht besser zu helfen weiß.

?????? Häh? Was hat der Hersteller denn angegeben? ... und wenn Du das sagen kannst, um welches oder was für ein Programm handelt es sich denn? .... vielleicht den Hersteller wechseln? ... das mag sarkastisch klingen, ist aber ernst gemeint. Wenn der Hersteller keinen zufriedenstellenden Support liefern kann, kann es vielleicht (hoffentlich) ein anderer. Es sind Szenarien vorstellbar, die das machbar erscheinen lassen. Ich bezweifle aber, dass das für Dich die Lösung ist. Deine eigentliche Frage sollte also eher lauten: "Wie installiere ich ein Programm auf allen Rechnern im Netzwerk, ohne mich an jedem Rechner einzeln anmelden zu müssen?" ... richtig? Dafür gäbe es dann zahlreiche Methoden, ja nach vorhandener Infrastruktur und zu installierendem Programm. Das Beste ist einem solchen Fall, die im Netzwerk existierende Software-Verteilungslösung zu verwenden. .... die hemdsärmligste wäre am anderen Ende der Skala vermutlich die Installation per Powershell mittels "Powershell-Remoting" z.B. mit Invoke-Command. Edit: Kann es sein, dass das das gleiche Thema ist wie das hier: ...... ??? Kannst Du mal bitte einen Link zu so einem Video teilen, bitte?

Das ist "Feature by design". Wenn Du ein Konsolen-Programm starten würdest, würdest Du die Ausgabe des Programms dort sehen, wo Du es mittels PSExec gestartet hast - in Deiner Konsole. An dieser Stelle muss die Frage lauten: Was möchtest Du eigentlich erreichen?? Warum sollte denn ein Fenster auf einem entfernten/remote Computer erscheinen, auf dem Du es gar nicht bedienen kannst, weil Du nicht davor sitzt? Also antworte bitte nicht, dass Du Notepad auf dem remote Computer starten möchtest und es dort bedienbar sein soll!

Warum so pessimistisch?? ..... 24\.12\.2\d{3}

... idealerweise achtet man beim Speichern darauf, dass es in einem Format gespeichert wird, welches später von Get-Date zuverlässig als Datum erkannt wird .... hängt von der Spracheinstellung ab ...

<SCNR> Hmmm ... hast Du mal versucht, danach zu suchen? Einfach mal Deine Lieblings-Suchmaschine befragen, sowas findet man üblicherweise in Sekunden. Diese Frage wurde schon tausendmal beantwortet. Und meistens prägt sich das auch noch besser ein, wenn man sich das selbst erarbeitet, als wenn man andere für sich suchen lässt. </SCNR>

So lange, wie Du Dich schon hier rumtreibst, brauchst Du doch kein Licht mehr. ... is wie zu Hause ... den Kühlschrank findest Du doch bestimmt auch ohne Licht, oder?

... na dann wird's aber Zeit ... ... das geht doch aber den meisten von uns zur Zeit genauso ... ich arbeite mit Ausnahme von 3 oder 4 Tagen zwischendurch auch seit 10. März im Home Office und ich habe auch schon seit 15 Jahren keinen Drucker mehr zu Hause. Eine Idee wäre noch, einen auf der Test-VM eingerichteten Netzwerkdrucker "anzuhalten" und dann darauf zu drucken. Dann würdest Du zumindest sehen, ob dort die Druckaufträge ankommen. Dann kann man irgendeinen verfügbaren Drucker benutzen, ohne Zugriff drauf haben zu müssen und vielleicht Kollegen ständig fragen zu müssen, ob da was angekommen ist oder so. ... und dann kannst Du, bevor Du den Druck wieder fortsetzt, die aufgelaufenen Druckaufträge einfach löschen. Das spart auch noch Papier. Unabhängig davon, hat man solche Anforderungen schon häufiger im Netz gesehen/gelesen. Schau doch mal bei PowershellGallery oder StackOverflow oder im Technet in der ScriptGallery oder in den Foren vorbei. Dort findet man mit an Sicherheit grenzender Wahrscheinlich etwas, was man leicht an eigene Anforderungen anpassen kann.

Wahrscheinlich empfehlen sie Dir auch gleich einen PFE, der Dir dabei behilflich sein kann ....

Die Zuweisung ... [string]$CADName = $DropDownBox.SelectedItem ... muss in den Block für die $Button.Add_Click Aktion. Du willst ja die Variable erst zuweisen, wenn Du den Button klickst, oder?

Aber Jan hat Dir doch schon den kompletten, fertigen Code gepostet. Du brauchst ihn doch nur mit den für Dich gültigen Pfaden zu ergänzen und auszuführen. Edit: .... grad erst gesehen ... mit dem Microsoft PDF-Printer wird das eher nicht klappen ... der erwartet ja für jeden Printjob eine Interaktion um die Ausgabe-Datei zu erfahren. nimm einen richtigen Hardware-Drucker!!