BOfH_666

OK ... vorher muss ich sagen, dass ich mich überhaupt gar nicht mit GUIs in Powershell beschäftige und auch nicht auskenne, ABER ... Du versuchst innerhalb einer Funktion auf eine Eigenschaft eines Objekts zuzugreifen, welches die Funktion nicht kennt. Stattdessen solltest Du einfach den Wert als Rückgabewert der Funktion ausgeben und damit weiterarbeiten. Also statt: $Ausgabe_Feld.text = $ZeitServer_Test_Ausgabe Einfach: $ZeitServer_Test_Ausgabe Wie Du das allerdings in Deine GUI eingebaut bekommst, kann ich Dir leider auch nicht sagen. Ich bin aber sicher, dass das einer der anderen Kollegen hier drauf hat ... hab ein bissl Geduld, bitte!

OK. Als Erstes bitte: In Zukunft solltest Du Code, Fehlermeldungen, Konsolen-Output oder Beispiel-Daten als Code formatieren. Nicht als Zitat und schon gar nicht als Bild. Du hast jetzt aus 3 verschiedenen Richtungen gehört, dass es eventuell keine gute Idee ist, eine Funktion innerhalb einer Funktion zu definieren. Wie wär's, wenn Du einfach mal probierst, die Funktionsdefinition für "ZeitServerStart" außerhalb der Funktionsdefinition von "Funktion-ZeitServer_Test" zu packen und schaust, was passiert? Unabhängig davon wäre es bestimmt hilfreich, den kompletten Code zu sehen, oder wenigstens ein größeres Stück, welches einem potenziellen Helfer ermöglicht, den Code auszuführen und evtl. die gleiche Fehlermeldung zu erhalten. Dafür hilft es manchmal, den betreffenden Code-Schnipsel so weit "abzuspecken", dass er ohne den eventuell viel größeren Rest des Scripts läuft.

Ohne die komplette Fehlermeldung kann man nur raten ... Du definierst die Funktion "ZeitServerStart" innerhalb der Funktion "Funktion-ZeitServer_Test". So lange die Funktion "Funktion-ZeitServer_Test" noch nicht gelaufen ist, existiert also die Funktion "ZeitServerStart" noch nicht ... isses vielleicht das? Übrigens ist es Best Practice die Funktionen in Powershell in der gleichen Art und Weise zu benennen, wie die cmdlets - also die Form "Verb-Nomen" zu benutzen - und dabei die empfohlenen Verben zu benutzen. Die kannst Du Dir mit Get-Verb auf der Konsole anzeigen lassen.

Die vorhandene Software-Verteilung benutzen, um die gewünschten Module auf die gewünschten Maschinen zu bringen.

... entfällt ... ignorieren bitte ...

Na dann, Danke für die Ergänzung, und Willkommen im MCSEborad.

... danke

Ah, OK. Dann ging die Frage an die, die den Edge bei sich verteilen/benutzen.

Na, das meinte ich doch. Also benutzt ihr kein automatisches Approval!? Hattet ihr denn schon mal Probleme bei der Testgruppe mit dem Edge, die ein Rollout des Updates verhindert haben?

Hmmm ... aber das bist Du doch bei automatischem Approval quasi ... !? Wir hatten beim Edgium tatsächlich noch keine Fehler, die uns aufgefallen wären. Vermutlich. Alles, was ich gelegentlich checke, ist die Compliance-Prozent-Zahl des automatischen Deployments. Das ist je nach Wochentag des Releases nach ca 2 Werktagen bei über 75%. ... achja ... wir haben ca 1000 Clients

Puuhhh ... Gott sei Dank. ... ich war schon kurz davor, mich, ob meiner Gleichgültigkeit gegenüber ein paar ungepatchten Edge's, zu schämen. ...

Und ihr haltet wirklich alle Clients nach, die keine grünen Haken haben? ... so viel Mühe machen wir uns gar nicht damit. Wir verteilen den Edgium per Auto-Deployment über SCCM. Ich checke zwar sporadisch, ob das im Allgemeinen noch läuft wie es soll, aber einzelne Clients prüfe ich nicht explizit.

Nur mal aus Neugier ... gebt ihr die Edgium-Updates manuell frei oder werden die automatisch approved? Wenn ihr die automatisch freigebt, ist der WSUS ja quasi nur der Cache, der den Traffic über die WAN-Strecke ein bissl verringert. Wäre es nicht vielleicht eine Überlegung wert, den Edge, seine Updates direkt von MSFT ziehen zu lassen? ... macht das vielleicht schon jemand so? .. wenn "ja", gibt's negative Erfahrungen oder Nachteile?

Für einen erfahrenen Scripter eine machbare Sache. .... ABER .... ... manchmal ist es effizienter/effektiver/schneller/besser, einen Fehler einfach zu umgehen, statt ihn aufwändig zu beseitigen.. Lass Dir mal den Tipp von Jan durch den Kopf gehen, das Script und die nötigen Quellen erstmal auf die betreffenden Rechner zu bekommen und das Ganze dann komplett lokal auszuführen. Nach dem KISS-Prinzip ... einfach ein bissl Komplexität reduzieren.

Ja - man könnte das so irgendwie hinfrickeln, aber das ist wirklich keine gute Idee. Ich gehe davon aus, dass es sich um mehr als 2 oder 3 Rechner handelt, die in einem Unternehmensnetzwerk arbeiten, richtig? Wie wird denn sonst Software installiert? Wie Dukel schon empfohlen hat - eine Softwareverteilungslösung wäre die viiiieeel bessere Option dafür.

Das Startup und das Shutdown-Script laufen mit dem Konto und den Rechten des "lokalen Systems". Diese haben üblicherweise keine Rechte irgendwo in einem Netzwerk. Was willst Du denn eigentlich mit dem Konstrukt erreichen? Vielleicht gibt es ja eine bessere Methode, die Dir nur noch nicht eingefallen ist. ... aber sag jetzt bitte nicht "Ich will eine Datei vom Netzwerk-Share auf den lokalen Computer kopieren"!!!

Jup. Es läuft also, wenn Du es mit Deinen Zugriffsrechten ausführst, aber nicht, wenn es als Shutdown-Script ausgeführt wird. Was ist denn der wesentliche Unterschied zwischen den beiden Situationen? Das heißt, Du hast das Script also dazu gebracht, Dir aussagefähige Fehlermeldungen zu generieren?!? Und was waren die Fehler?

???? Wie macht sich das bemerkbar? Debuggen!

Nur zur Info: Du hättest es nicht nochmal posten müssen. Du hättest Dein Original-Beitrag korrigieren können.

Kennst Du das Konzept einer Internet-Suchmaschine? ... bevor Du hier Fragen stellst, solltest immer erstmal wenigstens eine kurze Suche starten, ob das nicht eventuell schon ausreicht, um Dich aufzuschlauen.

Möchtest Du damit andeuten, Libre Office würde keine komplexen Office-Funktionen bieten? ... nach meiner Schätzung dürfte für mind. 85 % aller Office-Nutzer der Funktionsumfang von Libre-Office mehr als ausreichend sein.

Das hättest Du initial ruhig mal mit "anreißen" dürfen. Ich würd mir wieder das Leben einfacher machen und die Verknüpfung für den Start der Anwendung einfach ins das Startmenü der betreffenden Anwender packen ... also nach "C:\Users\<USERNAME>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs" z.B. ... oder in einen Unterordner davon. Von dort dürfen sich die Anwender das ja gern selbst an Start oder Taskleiste anheften.

OK, na dann hallo erstmal und willkommen im MCSEBoard! Wir schreiben hier keine gebrauchsfertigen Scripte auf Anfrage. Aber wir können Dir mit Deinem Script/Code helfen. Also was hast Du denn schon? Hast Du denn schon mal danach gesucht. Ich bin mir ziemlich sicher, dass man sowas schon quasi fertig findet, wenn man die richtigen Begriffe in seine Lieblings-Suchmaschine einklimpert. z.B. Dein hier verwendeter Betreff auf englisch und ein bissl abgewandelt ... Exchange create mailbox folder for selected users ... eingegeben bei Google.

Ich verstehe die Frage nicht so ganz. Du hast die Frage im Scripting Forum gestellt. Brauchst Du jetzt Hilfe beim Befehl? ... das wäre New-MailboxFolder und vielleicht Get-ADGroupMember für den Anfang. Oder brauchst Du Hilfe beim Script? ... Du kannst es als geplante Aufgabe laufen lassen und die Gruppe (mehrmals) täglich prüfen und bei neuen Mitglieder in deren Mailbox den gewünschten Ordner erzeugen. ... Wo genau hängst Du denn?

Oppps ... hatte ich überlesen ... Danke.