BOfH_666

Der erscheint, weil Du mit der ersten if-Bedingung danach suchst. Nur um sicher zu gehen - wo hast Du die eingefügt? Bitte Deinen kompletten Code posten - so wie Du ihn verwendest! Übrigens suchst Du damit 2 mal nach dem englischen Begriff. Wenn Du Dir Jans Code nochmal ansiehst, merkst Du vielleicht, dass er nach den Deutschen oder Englischen Begriffen sucht. Wenn sicher ist, dass Du nur Deutsche oder nur Englische Ergebnisse bekommst, kannst Du das jeweils andere auch weglassen. Schwer zu sagen, ohne Deinen Code zu sehen und ohne Dein System zu kennen. Achja ... und bitte nicht immer die kompletten Beiträge zitieren, sondern nur das, worauf sich Deine Antworten oder Nachfragen beziehen.

Vermutlich tut er das. Weil ich es nicht kannte, hatte ich danach gesucht und die erste Fundstelle genommen, die ich gefunden hatte, um mir einen Überblick zu verschaffen, worum es eigentlich geht.

.... ich bin davon ausgegangen, dass er den Code aus der Gallery nimmt .... Get-WUInstall. noch tiefer reingucken kann man mit dem so genannten ScriptBlockLogging .... https://www.windowspro.de/wolfgang-sommergut/powershell-kommandos-eventlog-aufzeichnen

... und wenn Du ihm -IgnoreReboot mitgibst und den Reboot am Ende des Skriptes selber auslöst?

Ja, da hilft dann nur eine Fehlerbehandlung im Skript mit einem vernünftigen Logging. Wie schon im anderen Thread geschrieben - versuchen, die Ausgabe umzuleiten ... so könntest Du vielleicht sehen, welche Fehlermeldungen generiert werden, wenn welche generiert werden.

Ah, ok. Jetzt verstehe ich den Zusammenhang. Ne sorry, da muss ich wieder mal passen. Das Skript aus der Gallery wäre mir persönlich auch deutlich zu komplex und tut zu viele unterschiedliche Sachen. Vermutlich würde ich's mir bestimmt eher selbst aus kleineren Teilen zusammenbauen ... aber ich würd' mir natürlich auch die ein oder andere Idee aus dem Skript "borgen". Ich hab's mir nicht soo genau angeschaut - hat das Ding einen Verbose-Modus? Du könntest versuchen die Ausgabe umzuleiten, wenn das Ding Ausgaben erzeugt.

... 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 ...