MurdocX

"Start-Process" ist auch eine Anweisung die direkt ausgeführt wird. Falls das Cmdlet eine Ausgabe (Ergebnis) hat, dann wird diese in die Variable $java_setup abgelegt. Start-Process - TechNet https://technet.microsoft.com/de-de/library/hh849848.aspx Lass die Variable einfach weg und schreibe das "Start-Process" unter deine Uninstall-Routine Um der UAC noch genüge zu tun, musst du noch den Parameter "-Verb RunAs" in "Start-Process" mit einbauen. Sonst wird deine Anwendung als Benutzer und nicht als Administrator ausgeführt. PS: Für zwischen Ausgaben kannst du "Write-Host" benutzen. Bsp: Write-Host "Installiere nun..."

Nachdem ich mich weiter schlau gelesen habe, möchte ich noch einen Punkt in die Runde schmeißen... "Workflow" Wissenswertes https://powershell.org/powershell-workflow-when-should-you-use-it/ https://blogs.technet.microsoft.com/heyscriptingguy/2012/11/22/the-basics-of-windows-powershell-workflow-when-to-use-it-and-why/ Damit kannst du "ForEach"-Schleifen mit dem Argument "parallel" laufen lassen. Das sieht dann in etwa so aus: workflow A { foreach -parallel ($item in $collection) { } } Aufgaben werden Parallel ausgeführt und sparen Dir noch mehr Zeit. Vielleicht bekommst du nun deine Auswertungen nun viel schneller.

Ich habe die unnötigen Leerzeilen mal entfernt und strukturiert. Das ist wichtig, damit man den Code im Nachgang auch wieder lesen kann. Das Debugging wird wesentlich erleichtert. Am Besten gleich angewöhnen. Das Ergebnis sieht das so aus: $java_setup = (\\fileserver\install\Java8u101\jre-8u101-windows-i586.exe /s) if ($objJavaProgramList = Get-WmiObject -Class Win32_Product | Where-Object {$_.Name -like 'Java*' -and $_.Version -ne '8.0.1010.13'}) { ForEach ($objJavaProgramItem in $objJavaProgramList) { $objJavaProgramItem.Uninstall() } { $java_setup } } else { exit } Du hast einen Block der keine Funktion besitzt.... { $java_Setup }... Nachdem ForEach mit "}" beendet wurde, macht der Rest keinen Sinn ;-) Setze es einfach unter "....Uninstall()" In der Powershell solltest du die Programme über "Start-Process" starten, damit die übergebenen Argumente "/s" nicht falsch oder gar nicht interpretiert werden. (Bsp. Start-Process -FilePath -ArgumentList )

Powershell ist eine OO-Programmiersprache mit sehr viel Power, das hast du richtig erkannt. Allerdings ist die Logik dahinter nicht anderst, als bei anderen Sprachen. Kannst du eine, kannst du "quasi" alle. Es wäre allgemein sicher von Nützen, wenn du dich mal mit einer Programmiersprache deiner Wahl auseinandersetzt. Hier hilft auch viel lesen von anderen Skripten und versuchen diese zu verstehen. Am Besten mal in der ISE debuggen und die Variablen nach den einzelnen Vorgängen auslesen.

Danke, das freut mich zu hören. Dann ist das damit ja die Lösung ;-) Du könntest noch das ein oder andere Protokollieren. ( Bsp. msiexec.exe /? ) Wenn die Uninstall()-Funktion von dem WMI-Objekt sauber funktioniert, dann würde ich diese auch so einsetzen. Um auch den Rest der Forum-Benutzer glücklich zu machen, können wir das Ganze noch auf einen "Einzeiler" zusammenkürzen ;-) Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like 'Java*' -and $_.Version -lt '8.0.1010.13' } | ForEach-object { Write-host ":: Entferne $($_.Name), Versionsstand: $($_.Version)"; $_.Uninstall() }

Da der WDS ja von Haus aus dabei ist, lässt das sich sicher gut verknüpfen ;-)

Hallo, ich würde die Versionen anhand des Versionseintrag unterscheiden und das ganze nicht so kompliziert machen. Hier wird erst mal alles gesammelt was vorhanden ist. Danach Filtern wir nach allem mit dem Namen "Java" und einer älteren Version als die angegebene. $objJavaProgramList = Get-WmiObject -Class Win32_Product | Where-Object {$_.Name -like 'Java*' -and $_.Version -lt '8.0.1010.13'} Nun können wir im nächsten Schritt alle gesammelten alten Versionen entfernen. Dies kannst du mit einem ForEach durchführen. ForEach ($objJavaProgramItem in $objJavaProgramList) { $objJavaProgramItem.Uninstall() } Anstatt ".Uninstall()" zu verwenden, kannst du deine msiexec.exe Routine durchführen. Das "x" würde ich auch nicht an das Ende setzten, da das eventuell als Protokollierungsoption gewertet werden könnte. So würde ich das ungefähr umsetzen ;) Start-Process -FilePath "msiexec.exe" -ArgumentList "/x $($objJavaProgramItem.IdentifyingNumber) /qn /norestart" Nun genug der Musterlösung.... :o

Jap, nutzen wir. Es funktioniert super und zuverlässig. Regelmäßig deploye ich 140 Rechner parallel per ZTD (Zero Touch Deployment) Unicast

Wir nutzen den PXE-Boot mit unserem WDS. Folgende Einstellungen nutzen wir für Option 67: boot\x86\wdsnbp.com 66: FQDN

Probiere es mal mit "$_.Name", da "$Dyn" auch mit mehreren DynGruppen gefüllt sein könnte, dann klappt $Dyn.name nicht mehr ;-) Dyn = Get-DynamicDistributionGroup $Dyn | ForEach-Object{ Write-Host "DynamicDistributionGroup: $($_.Name)" Get-Recipient -RecipientPreviewFilter $_.RecipientFilter -OrganizationalUnit $_.RecipientContainer | Select-Object Alias, Name }

Das wäre das Skript was du suchen könntest http://www.it-explorations.de/suchen-umbenennen-von-dateinamen-mit-powershell/

Ist die Offlinesynchronisierung eingeschaltet und eingerichtet?

Ich würde die Daten in den Speicher laden und erst dann verarbeiten. Vielleicht bringt Dir das noch einen Geschwindigkeitsvorteil. Schon mal über diese Variante probiert? $objWinEvent = Get-WinEvent -LogName System | Where-Object {$_.Id -eq 4625 -or $_.Id -eq 4768 -or $_.Id -eq 4771 -or $_.Id -eq 4776 } Edit: Korrektur

Probiere es mal mit "Get-EventLog" # Beispiel Get-EventLog -LogName Application -ComputerName . -After '18.07.16' EDIT: https://technet.microsoft.com/de-de/library/hh849834.aspx

Applocker Setzen wir bei uns mit den Default-Regeln ein. Bis auf eine Ausnahme gibt es keine Probleme. Kein einziges Ticket welches auf dem Applocker hinausgelaufen wäre. "VisualStudio...." funktioniert damit nicht, da die Anwendungen im TEMP-Verzeichnis erstellt werden. Eine Ausnahme für TEMP ist nicht drin. EMET Keine Probleme bisher! Es geht leicht auf die Performance, jedoch bei dem Benefit vernachlässigbar. EMET wird bei mir im Image mit verteilt. Windows Firewall Bei uns wird die lokalen Einstellungen, sowie die Gruppenrichtlinien übernommen. Leider ist das bei einem Anwendungsjungel schwer einheitlich zu konfigurieren. Deinstallieren von nichtgebrauchten Packages Halte ich für essentiell. Dank Powershell sind so Remote-Abfragen recht problemlos und einfach. EDIT: Überlegenswert wäre noch die Wechselmedien zu sperren und per Whitelist freizugeben. https://msdn.microsoft.com/en-us/library/bb530324.aspx

Eigentlich heißt es ja "Click-to-run" https://technet.microsoft.com/de-de/library/jj219427.aspx Hat die (erweiterte) Reparaturinstallation geklappt?

Dann eine Reparaturinstallation vom Office durchführen, danach wird es wieder funktionieren. One-Klick-Installation?

Das stimmt. War eine etwas ruckelige Aktion. Hat auch etwas gedauert bis alles wieder sauber lief. Der Exchange 2003er hat aber besonnen reagiert :)

Du könntest deine Domäne umbenennen: https://technet.microsoft.com/en-us/library/cc738208(v=ws.10).aspx Hab ich schon einmal durchgeführt

Danke für die Info. Dann werde ich nächstes Jahr die Messe mal besuchen.

Naja, ich war noch nie dort und weiß nicht ob sich das auch lohnt.. ;) Hehe, ja quasi. Wahrscheinlich Stuttart´er Richtung?

In Bayern ist es auch schön ;-)

Wäre es nicht ca 750km entfernt, würde ich da auch vorbei schauen. Aber viel Spaß euch :wink2:

Ich würde das Office-Paket probieren zu reparieren. Hatte ähnliche Probleme schon mal mit der One-Klick-Installation.

[DateTime]$Date = $(get-date) $date.ToShortDateString() # Ausgabe 1 $date2 = $date.AddDays(1) $date2.ToShortDateString() # Ausgabe 2 => Ausgabeergebnis 23.06.2016 24.06.2016 Eine weitere Variante :wink2: Oder ein Einzeiler ([DateTime]::Parse('23.06.16')).AddDays(1).ToShortDateString()