PSD Wizard does not automatically start, have to manually start PSDstart.ps1 & task sequence does not complete...

When running the MDT .ISO on a machine the PSD selection wizard does not come up automatically. If I hit F8 and browse to X:\Deploy\Scripts and run PSDStart.ps1 the menu loads. When I select a task sequence and run it, it formats the disk, downloads and installs the image and it stops at the gather step (Installation Progress disappears) after applying the image and does not restart nor does it continue. Is something missing in the latest version? Please help!

had the same problem in my lab, but - starting manually the powershell scripts leads to an error message called - unblock file - so i unblocked the whole MDT Deployment Share via Powershell. i guess there is an ADS which flags all files as internetbased ?

had the same problem in my lab, but - starting manually the powershell scripts leads to an error message called - unblock file - so i unblocked the whole MDT Deployment Share via Powershell. i guess there is an ADS which flags all files as internetbased ?

Thank you for suggesting this. I looked at all of the files and none of them had the flag on them. I also ran Unblock-File on the whole deployment directory and tried again with no luck so I'm not really sure what's going on here since when I start the script manually it runs. Any other help would be appreciated.

We have the same issue, the PSD selection wizard does not come up automatically , have you had any progress or help yet?

I haven't had any progress or help with this as of yet. In the documentation it states the below to debug but the command line to run PSDStart.ps1 isn't even in the file.

By adding the -Debug parameter to the PSDStart.ps1 command line in Templates\LiteTouchPE.xml you get an option to enable debug when starting a deployment. Enabling debug will start transcripts of every scripts, as well as echoing all output to the screen in a separate PowerShell window during imaging.

Pretty sure I have it narrowed down to changes to the unattend. Specifically the addition of PSDPrestart. I have not narrowed down what is breaking it with that new process specifically, but if I comment out the PSDPrestart.ps1 file, PSDStart.ps1 starts as expected,

https://github.com/FriendsOfMDT/PSD/commit/feefb9b2c7863553a521fa8642be9a2af0ffa133#diff-42cc5cb1ec232b8e8dc2982f41c7e9194abf2f9ec090ca263a8ac55c66538281

I was able to get this working after building a few test environments in my lab. Its a pretty simple root cause. When you download the .zip file (clone) run Unblock-File -Path "C:\CHANGETOYOURPATH\PSD.zip" or browse to the folder you downloaded the zip file to and right click, unblock then extract the .ZIP file to a folder on the root of the C:\ drive. When you run the hydration script do NOT use ISE to run any of the installation scripts. This will solve the issue.

@jpascucci I did that but didnt resolve issue... also is there any more detailed documentation?

I found that if I remove the "-windowstyle hidden" argument from Deplomentshare\PSDResources\Prestart\PSDPrestart.xml (while inside PE) and I call the PSDPrestart.ps1 from command prompt (F8), instead of jsut closing immediately, it now tells me the that the files are restricted due them coming from the internet. I checked all file and none of them are blocked.

I decided to then add this command in the PSDUpdateExit.ps1 file:

# Do any desired WIM customizations (right before the WIM changes are committed)
If ($Env:STAGE -eq "WIM") {
    # CONTENT environment variable contains the path to the mounted WIM
    Write-PSDInstallLog -Message "Entering the $Env:STAGE phase"
    Write-PSDInstallLog -Message "CONTENT = $Env:CONTENT"
    Write-PSDInstallLog -Message "Unblocking all file content in WIM"
    $PSDArgument = "Get-ChildItem $Env:CONTENT -Recurse | Unblock-File -Verbose"
    $PSDProcess = Start-Process PowerShell -ArgumentList $PSDArgument -NoNewWindow -PassThru -Wait
    Write-PSDInstallLog -Message "Wait a while for MDT to catch up"
    Start-sleep -Seconds 10
}

Now every time I compile a new ISO, it will unblock all files in the content folder before it commits the WIM and builds the ISO. Seems to work for me.

@arwidmark @DeploymentBunny I guess we can close this right?

This issue has been fixed in the latest version.