FriendsOfMDT / PSD

PowerShell Deployment
MIT License
471 stars 72 forks source link

Deployment Keeps Failing at Set DriverPath #105

Open Amply5364 opened 8 months ago

Amply5364 commented 8 months ago

Looking at the SMSTS.log I see Executing command line: PowerShell.exe -file "%SCRIPTROOT%\PSDSetVariable.ps1" with a exit code of: Process completed with exit code 4294770688

I then see this: Failed to run the action: Set DriverPath. Unknown error (Error: FFFD0000; Source: Unknown)

I have really been trying to figure this out, but am struggling. Any thoughts.

Sorry if this is not the right place for this question, but I wasn't sure how else to contact anyone.

pimpmyname2 commented 8 months ago

How does your task sequence "Set DriverPath" look like?

Amply5364 commented 7 months ago

Thank you for responding. Update on this issue. So it looks like what the real issue is is that I have not setup https for downloading the operating systems and it was failing on that step, but then when we restarted to try the deployment again it started failing on the setdriverpath step.

We then went and reimaged the computer with another image from our old deployment share and then tried the new deployment share again. This time it got past setdriverpath and got stuck on downloading OS.

I am unsure if there is a way to cleanup a failed deployment in this verison. In previous versions I had used the cleanup vbs script.

Also, now have some questions regarding security of https CA in my production environment.

pimpmyname2 commented 7 months ago

HTTPS is not a strict requirement for deployment. In our environment, we successfully deploy over a local network using HTTP. It's unusual that the download of the OS is failing even though it passed downloading drivers. I recommend utilizing a network protocol analyzer, such as Wireshark, to inspect the network traffic. This could provide valuable insights into the underlying issue.

I recommend reviewing the IIS Configuration Guide provided by FriendsOfMDT on their GitHub repository: https://github.com/FriendsOfMDT/PSD/blob/master/Documentation/PowerShell%20Deployment%20-%20IIS%20Configuration%20Guide.md. This guide provides detailed instructions on properly configuring IIS, which could also potentially resolve the issue you're experiencing :)

Amply5364 commented 7 months ago

Thanks I will try the http option. Do you know the best way to cleanup a failed ps deployment?

GeoSimos commented 7 months ago

Thank you for responding. Update on this issue. So it looks like what the real issue is is that I have not setup https for downloading the operating systems and it was failing on that step, but then when we restarted to try the deployment again it started failing on the setdriverpath step.

We then went and reimaged the computer with another image from our old deployment share and then tried the new deployment share again. This time it got past setdriverpath and got stuck on downloading OS.

I am unsure if there is a way to cleanup a failed deployment in this verison. In previous versions I had used the cleanup vbs script.

Also, now have some questions regarding security of https CA in my production environment.

Can you share any logfiles please? (sanitize them first for sensitive information)

GeoSimos commented 6 months ago

HTTPS is not a strict requirement for deployment. In our environment, we successfully deploy over a local network using HTTP. It's unusual that the download of the OS is failing even though it passed downloading drivers. I recommend utilizing a network protocol analyzer, such as Wireshark, to inspect the network traffic. This could provide valuable insights into the underlying issue.

I recommend reviewing the IIS Configuration Guide provided by FriendsOfMDT on their GitHub repository: https://github.com/FriendsOfMDT/PSD/blob/master/Documentation/PowerShell%20Deployment%20-%20IIS%20Configuration%20Guide.md. This guide provides detailed instructions on properly configuring IIS, which could also potentially resolve the issue you're experiencing :)

Also the HTTPS usage is not the problem usually, something else is happening.