MurdocX

Prinzipiell nein, wenn du weißt was du tust. ;-) Mit einem Step ist Sysprep auch nicht erledigt. Die Bereinigung vom System solltest du danach noch anstoßen. Windows Updates solltest du bei dem Image schon vorher erledigt haben. Ich empfehle das System in einer VM zu betreiben, um davor noch einen Snapshot anzulegen. Meiner Meinung nach ist das Thema komplex und sollte nicht "einfach mal so" behandelt werden. Fehler im Image bereut man sehr schnell. Wie du den WDS einrichtest, kannst du hier nachlesen: it-explorations.de | Schritt für Schritt Anleitung | Windows Bereitstellungsdienste ( WDS ) http://www.it-explorations.de/windows-bereitstellungsdienste/ @Norbert Da bin ich bei Dir :thumb1:

​Es gibt von Microsoft einen neuen "File Explorer" der auch mehr als 260 lange Pfade unterstützt. So öffentlich ist er leider noch nicht. Ausprobiert habe ich ihn auch noch nicht. Vielleicht aber eine interessante Alternative für alle die das hier lesen. OnMsft | Here’s how to access the UWP File Explorer on Windows 10 https://www.onmsft.com/news/heres-how-to-access-the-uwp-file-explorer-on-windows-10

Anstatt den MDT würde ich das Image über den WDS deployen. Deutlich komfortabler und schneller, als sich erst in den MDT einzuarbeiten.

​Du solltest das/die USB-Gerät(e) aus dem System löschen. Dies kannst du mit dem Tool "usbdeview.exe" von NirSoft durchführen. Danach die Geräte anstecken und installieren lassen.

Mach mal aus deinem "Sort" ein "Select-Object" und bis der interne Test funktioniert, macht man so wenig Argumente wie möglich. Ich würde das "-ComputerName $Computer" auch entfernen, bis das ganze lokal klappt.

Angeber :P

Bitteschön :)

Gut, dann weißt du ja nun wo das Problem liegt und wie du es beheben kannst :) Nachtrag: WinPE-PowerShell contains Windows PowerShell–based diagnostics that simplify using Windows Management Instrumentation (WMI) to query the hardware during manufacturing. You can create Windows PowerShell–based deployment and administrative Windows PE–based tools. In addition to deployment, you can use Windows PowerShell for recovery scenarios. Customers can boot in Windows RE and then use Windows PowerShell scripts to resolve issues. Customers are not limited to the toolsets that run in Windows PE. Similarly, you can build scripted offline solutions to recover some computers from no-boot scenarios. WinPE-PowerShell has the following known limitations: Windows PowerShell remoting is not supported. Any cmdlets that have remoting functionality will return an error. The Windows PowerShell Integrated Scripting Environment (ISE) is not supported. Windows PowerShell 2.0 is not supported. Dependencies: Install WinPE-WMI > WinPE-NetFX > WinPE-Scripting before you install WinPE-PowerShell.

Ja das hab ich verstanden. Was sagst du zu meinem Post?

Dir ist klar, das das im Windows-Setup ausgeführt wird und nicht in Windows? Hast du sichergestellt das dein Boot-Image WMI kann? Bei Windows-Setup (boot.wim) wäre ich mir nicht so sicher ;) Ein WinPE kannst du optional über das Paket "WinPE-WMI" befüttern. Nachtrag: Da das ja ein Powershell-Befehl ist benötigst du natürlich die Powershell & WMI

Ich löse das bei uns so: # Lösche den Projektordner samt Inhalt Get-ChildItem -Path $ProjektPath -Recurse | Remove-Item -Force -Confirm:$false -Verbose -Recurse Get-Item -Path $ProjektPath | Remove-Item -Force -Confirm:$false -Verbose -Recurse

In welcher Setup-Phase wird das Skript ausgeführt?

Startest du die Powershell als Administrator?

Hast du schon das "Besitzer"-Recht der gesicherten GPO und deren Zugriffsberechtigungen geprüft bei denen du "Zugriff verweigert" bekommst?

Als erstes muss man sich das Feld mit seiner Eigenschaft etwas genauer ansehen, bevor versucht wird Daten zu übergeben. [ Attribute accountExpires ] https://msdn.microsoft.com/en-us/library/cc221084.aspx Dann stellt man fest, das es dieses Feld das Format "FileTime" benutzt. In dieses Format sollten die Daten vorher konvertiert werden. $Date = [DateTime]::new(2017,12,26,23,59,00) $Date.ToFileTime() Das Ergebnis kannst du dann übergeben. 26.12.2017 um 23:59:00

Neee, direkt. Über Office365 keine Ahnung.

Wir hatten das zu Exchange 2010er Zeiten ohne Trust über die ADFS und GAL-Sync gelöst.

Bitteschön ;)

Alternativ, weil du es ja nicht für den gesamten, sondern nur für ein Objekt benötigst, kannst du über die Eigenschaft "Items" (ListViewItemCollection) in das Array zugreifen. Dann die Values prüfen und bei bedarf wieder die Background-Funktion BackColor-Eigenschaft (System.Drawing.Color) benutzen.

Oh.. Ich hab diese geändert über $listView.BackColor = "yellow" und das hat gut funktioniert.

Aber vermutlich nicht von Dir, denn wer das Skriptet für den ist das ein Klacks ;-) Schau mal hier: https://stackoverflow.com/questions/20171379/listview-subitems-back-color

Was ist das denn für eine Anwendung? Geschrieben in .Net? Woher kommt der Gedanke das via Powershell zu verändern?

​Die Telemetrie kannst du auf "0 - Sicherheit" setzen. Das geht bei der Enterprise-Variante unter: Computer Configuration\Administrative Templates\Windows Components\Data Collection and Preview Builds\Allow Telemetry ​"This policy setting, in combination with the allow telemetry policy setting, enables organizations to send Microsoft a specific set of diagnostic data for IT insights via Windows Analytics services." Computer Configuration\Administrative Templates\Windows Components\Data Collection and Preview Builds\Limit Enhanced diagnostic data to the minimum required by Windows Analytics

​So müsstest du es z.B. konfigurieren, wenn du einen externen Dienstleister für deinen Exchange nutzt oder nur deine Mails umleiten möchtest.

Musst du doch beim Applocker gar nicht. :rolleyes: