Use PDQ Deploy to push In-Place Windows 10 Upgrade
#How to use PDQ Deploy to push In-Place Windows 10 Upgrade
Others may have a slicker solution, but I needed any easy way to not only upgrade all workstations from Win7 and Win8.1, but to verify afterwards which computers succeeded and which failed. I will try to make this as basic as possible.
-
Copy the entire contents of your Windows 10 ISO to a network share, such as "\\fileserver\Win10Setup"
-
Create a PDQ Deploy package
-
Add a "PowerShell" step called "Check Win Version" (paste the script below into the Details tab of this step
<# .SYNOPSIS Windows 10 upgrade check .DESCRIPTION This is used the check the whether a computer is READY to upgrade to Windows 10 written by Mike Resnick 06-14-2018 #> $OS = gwmi -Class win32_operatingsystem If ($OS.version -match "10.") { # It is ALREADY Windows 10! # Let's send an exit code that PDQ will consider "bad" write-output "ERROR: Win version is ALREADY Windows 10: $($OS.version)" $host.SetShouldExit(111111111) } Else { # Win version is NOT currently Windows 10 # Exit code should default to 0 write-output "READY FOR UPGRADE: Win version is: $($OS.version)" }
-
Add a "Command" step called "Setup.exe Upgrade". Use the following EXAMPLE (you need your own Product Key):
start /wait \\fileserver\Win10Setup\setup.exe /auto upgrade /migratedrivers all /dynamicupdate enable /telemetry disable /compat IgnoreWarning /showoobe none /pkey XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /NoReboot
-
Add a "Reboot" step
-
Add a "Sleep" step (I used 10 minutes, but you could do 10-20-30-40, whatever you like)
-
Finally, add another "PowerShell" step to verify the Windows version and report back to PDQ. Copy and paste this script into this step:
<# .SYNOPSIS Windows 10 upgrade check .DESCRIPTION This is used the check the whether a computer has COMPLETED upgrade to Windows 10 written by Mike Resnick 06-14-2018 #> $OS = gwmi -Class win32_operatingsystem If ($OS.version -match "10.") { # Great! # Exit code should default to 0 write-output "SUCCESS: Win version is: $($OS.version)" } Else { # This is NOT Windows 10 # Let's send an exit code that PDQ will consider "bad" write-output "ERROR: Win version is: $($OS.version)" $host.SetShouldExit(111111111) }
#What a deployment output looks like When you actually Deploy to a target:
For Successful deployments, if a Target upgraded to Windows 10, the package will report "Successful", and you can click the link under the "Steps" column of the Deployment details to see the reported version of Windows.
The final step "Output" should report something like:
SUCCESS: Win version is: 10.0.17134
For FAILED deployments, if a Target FAILED to upgrade to Windows 10 for some reason, the package will report "Failed", and you can click the link under the "Steps" column of the Deployment details to see the reported version of Windows.
The final step "Output" may report something like:
ERROR: Win version is: 6.3.9600
I hope this is helpful for at least one other person.
Good luck!
Comments
Hi Mike,
thanks for sharing your way here but i'm a littel confused because you are are using powershell steps for things you can do with Deploy/Inventory onboard features. Maybe you don't use Inventory, that could explain your complicated way.
But let me explain:
1. Your "Check Win Version" Powershell Step
This is unnecessary because you can use the "Condition" tab inside your package to make sure the package only deploys to Win 7/8/8.1.
Or you can link inside the package schedule to the Inventory collection for Win 7/8
Later, if you upgrade Win 10 builds (for example 1709 to 1803) you have to activate Win 10 O/S in the condition step and link in the schedule to the build version collection inside Inventory:
2. Your PowerShell step to verify the Windows version and report back to PDQ
It's not a wrong way, but it could be error-prone if your package runs into a timeout before the last step
To track unsuccessful upgrades my first step is a txt file creation cmd:
MD c:\pdq_status\Win_Upgrade
echo "%time%" > c:\pdq_status\Win_Upgrade\Win10_1709.txt
The folder "c:\pdq_status" is linked to a daily file scanner.
If the file exists on a Win 7/8 or Win 10 (build not 1709) device i know the upgrade was not sucessfull. I track this with a dynamic Inventory collection.
If you remove the /noreboot switch from your setup.exe line , you only need 2 steps inside your package (The Win 10 upgrade knows better the time to reboot than you)
The txt file creation
The setup.exe Step
Maybe this helps you to optimize your deployments
Greetings
Chris
Hi Chris,
Thank you for your comments. I wanted to clarify that the first step was also for users that do not have PDQ Inventory. Unfortunately, the edit function on this post is missing, so I cannot update it.
I agree that there are indeed other (and many) ways to create deployments. As I mentioned, others may have a slicker solution, but this is what we needed for our particular process.
I actually started with a package that was simply one step: calling the Setup.exe and letting it reboot. But we found that we had other needs.
I like using "/NoReboot" and having PDQ perform the reboot, so that we can add more steps that are helpful for our processes. During testing, we found that letting setup perform the reboot would prevent the PDQ deployment for performing any further steps. PDQ would just end the deployment once it lost connectivity to the computer. Perhaps others might want to do something like send an email notification right before/after the computer reboots. Without PDQ doing the reboot, that wouldn't be possible. It's just an option we chose. Again, it may be unique for us, but it would not make our processes more efficient to leave it out.
We do use a lot of dynamic collections, but we find it is faster and more reliable to see which specific computers failed or succeeded by looking at the deployment status of our deployments. So, having a "Successful" status using the script is good for us to confirm that the package also verified that the Windows version was "10". Without that last powershell step, the package would still report "Successful" only because Windows Setup rebooted. But, what happens if the reboot fails and Windows Setup rolls back after the reboot? There are different ways to check errors. Again, this is what we found to be more efficient for us. For you, creating a custom file and a custom file scanner is better. I didn't see where you were deleting your file once you verify the upgrade was successful, but maybe I misunderstood?
Thank you for all of the suggestions. It certainly gives me ideas.
-Mike
Hi Mike,
i keep the txt file on the device, it includes a date stamp. This way I’m able to overlook the upgrade history of the device. I know this information is in the registry too, but with the txt file it’s easier to check.
One great disadvantage with your manual reboot step is the concurrent install limit. Your way PDQ needs much longer to upgrade 350 devices.
Let us say, your concurrent Limit is 25. The time until the first reboot is 30min. The Time until the whole upgrade is finished is 1h 30min.
Your way after 1h 30min 25 devices are finished and the next 25 start. After 3h you have finished 50 devices and the next 25 starting
My way after 1h 30min 25 devices are finished, 50 are rebooted and in progress and 25 start. After 3 hours 100 are finished 75 are rebooted and in progress and the next 25 kicking off.
And so on....
It‘s nothing wrong with your way, it’s great to see other solutions.
~Chris
I tried this and did see setup.exe in taskmgr on the target computer (from pdqdeploy installer). However, it remained at 0% CPU and did nothing despite letting it run for well over 30 minutes on a surface. I ran the same command from the surface itself and was prompted for UAC approval. If UAC is enabled, would it keep the pdq job from running because it wasn't receiving a response to proceed? Do I need to disable UAC first on my devices?
Hi Mike
I have the same problems, I see it running in processes, its been running for about 3 hours and has not moved or done any CPU utilization. Any help would be greatly appreciated. I setup it up exactly as specified above. Anyone can help please respond.
Scott
Hi Kyle, First, is there at least 20GB free on the target machine for the setup to expand and install Windows 10?
We have UAC enable on all of our workstations. There is no need to disable UAC for this to work. You may have already done this, but double-check that all of the necessary remote management and Remote UAC is allowed for PDQ (all of these must be configured properly):
https://support.pdq.com/knowledge-base/1023
https://support.pdq.com/knowledge-base/1055
Does your PDQ service account have Domain Admin privileges and full control permissions of the fileshare where the executable is located?
Verify that the Setup.exe step is using a "Command" step and NOT a "PowerShell" step.
If everything is setup correctly in PDQ to run remote commands, there shouldn't be anything inherently blocking calling a "start" command.
-Mike
Hi Scott,
I'm just pasting what I said to Kyle above...
First, is there at least 20GB free on the target machine for the setup to expand and install Windows 10?
We have UAC enable on all of our workstations. There is no need to disable UAC for this to work. You may have already done this, but double-check that all of the necessary remote management and Remote UAC is allowed for PDQ (all of these must be configured properly):
https://support.pdq.com/knowledge-base/1023
https://support.pdq.com/knowledge-base/1055
Does your PDQ service account have Domain Admin privileges and full control permissions of the fileshare where the executable is located?
Verify that the Setup.exe step is using a "Command" step and NOT a "PowerShell" step.
If everything is setup correctly in PDQ to run remote commands, there shouldn't be anything inherently blocking calling a "start" command.
-Mike
I tried following the instructions here to create a package for an in-place upgrade from LTSB 1607 to LTSC 1809. I've already successfully manually done some of these, so I know it's possible and there shouldn't be any issues blocking it. However so far I'm just getting "Exceeded timeout for completion. {0}".
My PDQ Deploy version is 17 Release 1, and my package contains only one Command step which looks like this: start /wait \\servername\sharename$\1809\setup.exe /auto upgrade /migratedrivers all /dynamicupdate enable /telemetry disable /compat IgnoreWarning /showoobe none /pkey (REDACTED)
I tried it on my own staff PC but nothing seemed to happen, I could see processes running but the PC never restarted or did anything. There's 79GB free on my system drive, so it shouldn't be a disk space issue.
Is there some additional step or command line switch that I've missed out? Can anyone suggest anything?
Thanks,
Dan Jackson (Senior ITServices Technician)
Long Road Sixth Form College
Cambridge, UK.
This is the method I've used:
/auto Upgrade /quiet /Compat IgnoreWarning /showoobe none /DynamicUpdate Disable
. Success codes are '0,1641,3010,2359302' (I think default)Did it for about 300 machines with 1709, 1803 and 1809 and it worked. Even going from Win 7 to Win 10 it did the job though I did find on some Win 7 machines there was sometimes an issue with one user profile that I had to remove as it was causing a fail.
@johnrehill what timeout settings did you use? I upped the timeout on mine but I'm still finding it's timing out. Also am I right in thinking the package needs to be set to "pull" rather than "push" so that it runs directly off the network share instead of copying everything to the local PC first?
I have had sucsess with this from 1511 to 1809 but not from 1709 or beyond.
What are you guys using to get rid of the Windows.old folder after updating the OS?
i have tried everything i cant get my workstation to upgrade to 1903. what am i doing wrong.
Did anyone ever get this working? I am running into the same issue as some of the other people on here. Plenty of disk space and all prereqs are met but when I push the deployment setup just like @johnrehill, it never upgrades the machine. I can log into the machine and run the command from the command line and it will upgrade it. I have it set to pull in preferences and upped the timeout settings to 2 hours, but it still times out and fails. Any help or suggestions are greatly appreciated. Thanks!
We got it to work I'd say about 95% of the time pushing it out to our teacher laptops and desktops. On a few dozen of our devices they didn't like something and after the update was applied they restarted and rolled back to 1803.
1. I put a Restart in because, well, most of our teachers don't understand you have to restart a computer once in a while.
2. I put in a 30 second sleep. Can't remember why, but I remember having some issues before I put that there, something about the laptops not being found online.
3. Make sure the 1903 setup and all of the files are sitting in the repository on your PDQ server. Step 3 is Install 1903 - I kept things as simple as possible, these are my parameters: /auto Upgrade /quiet /Compat IgnoreWarning /showoobe none /DynamicUpdate Disable
Make sure Include Entire Directory is checked
4. Sleep - I set it at 700 seconds as Microsoft has to do it's thing on restart, customize to your devices.
5. Reboot
6. Start Menu Folder Ownership Change - you might or might not need to do this, I found ours were having issues with the Start Menu after the update where installed apps didn't show up in the Start Menu, even MS's own programs. It's a known bug and doing it over summer I didn't have time for MS to do an update to fix it.
I put a DOS step in with this command:
call
C:\windows\system32\icacls "C:\ProgramData\Microsoft\Windows\Start Menu" /grant Users:F /t
7. Delete Windows.old I had to have this run 3 times after a 60 second sleep to get it to actually delete Windows.old
Create a batch file with this in it:
TAKEOWN /F %SystemDrive%\Windows.old /A /R /D Y
ICACLS %SystemDrive%\Windows.old /T /grant :r Administrators:F
RD /S /Q %SystemDrive%\Windows.old
Do 3 Commands calling the batch file.
Total time for everything was usually around 30 minutes.
Thanks for all the info posted previously!
For those having issues upgrading Windows 10 to 1903, try executing from a command line:
If anybody has issues with deleting the Windows.old folder, check to see if PDQ Deploy is throwing a "Output exceeded maximum size allowed of 15 MB (actual size: 15 MB)" error. If so, you may need to extend PDQ's max log limit.
Follow the steps posted here:
https://help.pdq.com/hc/en-us/articles/220534667-Output-exceeded-maximum-size-allowed
Correct for this error by increasing the size of the DeploymentSettings.MaxStepOutputSize value:
1. In PDQ, go to Options > Preferences > Database and click on the SQLite Console button to open the SQLite console
2. Run the following command, including the terminating semicolon (this increases the size from 15MB to 200MB)
Can anyone show me the actual deploy package. I am running this and it does not seem to work. Is there a way to show the progress on the computer screen you are updating?
Here's what I used successfully with 1903, hope it helps.
I don't/didn't want anything on the screen showing progress, it's a quick enough of a deployment that watching the PC's reboot after the 1903 update that I didn't want/need and progress on the screen showing. A few PC's decided that after doing the update they didn't want to take 1903 and remained at 1803, those we either redeployed or just did a manual update with a USB drive.
Steps 1 - reboot
Step 2 - 30 second sleep while they reboot before the fun begins.
Step 3 - Delete a Logitech Registry key that was a pain once the update was done because it was missing, so I deleted it prior to the update and that saved us an extra step after the update.
Bat file for that: REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /V "Logitech Download Assistant" /f
Step 4
Step 5 - 700 second sleep time
Step 6 - reboot
Step 7 - there was an issue with the Start menu not showing previously installed software, even Office wasn't showing up, figured out the issue and fixed it with this:
Step 8 - Delete Windows.old folder with this bat file:
TAKEOWN /F %SystemDrive%\Windows.old /A /R /D Y
ICACLS %SystemDrive%\Windows.old /T /grant :r Administrators:F
RD /S /Q %SystemDrive%\Windows.old
Thanks for the manual, but i had some problems with it.
I wanted to Upgrade from 1809 to 1909.
I did it with the following Settings:
Step 1 - Reboot
Step 2 - Sleep (60 seconds)
Step 3 - PowerShell (Remove Windows Features - Need when use of "/MigrateDrivers All" in Step 4 - ReInstall in Step 9)
Disable-WindowsOptionalFeature -Online -FeatureName Printing-PrintToPDFServices-Features
Disable-WindowsOptionalFeature -Online -FeatureName Printing-XPSServices-Features
# Need if a further Installation failed)
$FileName = 'C:\$WINDOWS.~BT\Sources\Panther\compatscancache.dat'
if (Test-Path $FileName) {
Remove-Item $FileName
}
Step 4 - Install 1909
setup.exe /auto Upgrade /quiet /Compat IgnoreWarning /showoobe none /DynamicUpdate Disable /Telemetry Disable /MigrateDrivers All
Step 5 - Sleep 1000
Step 6 - Reboot
Step 7- PoweShell (Insert PowerShell Script)
The batch for deleting "Windows.old" didn't work for me, so i used a PowerShell Script which triggered the CleanMgr
& '.\Windows_Old_Remove.ps1'
File: Windows_Old_Remove.ps1
$path = $env:HOMEDRIVE+"\windows.old"
If(Test-Path -Path $path)
{
#create registry value
$regpath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\Previous Installations"
New-ItemProperty -Path $regpath -Name "StateFlags1221" -PropertyType DWORD -Value 2 -Force | Out-Null
#start clean application
cleanmgr /SAGERUN:1221
}
Else
{
Write-Warning "There is no 'Windows.old' folder in system driver"
cmd /c pause
}
Step 8 - PowerShell (REMOVED - Didn't work for me)
C:\windows\system32\icacls "C:\ProgramData\Microsoft\Windows\Start Menu" /grant Users:F /t
Step 9 - PowerShell (ReInstall Windows Features from Step 3)
Enable-WindowsOptionalFeature -Online -FeatureName Printing-PrintToPDFServices-Features
Enable-WindowsOptionalFeature -Online -FeatureName Printing-XPSServices-Features
I am looking at purchasing the full product but I am for some reason unable to get this to work. It keeps coming back with "ERROR: Win version is ALREADY Windows 10: 10.0.18362". I am trying to update clients from 1903 to 1909.
Paul Lange
Change the version check in the final PowerShell step to look for version: "10.0.18363" that is 1909.
Good luck!
-Mike
I looked at that (Not very familiar with PS scripting) and didn't see that anywhere.
<#
.SYNOPSIS
Windows 10 upgrade check
.DESCRIPTION
This is used the check the whether a computer is READY to upgrade to Windows 10
written by Mike Resnick 06-14-2018
#>
$OS = gwmi -Class win32_operatingsystem
If ($OS.version -match "10.")
{
# It is ALREADY Windows 10!
# Let's send an exit code that PDQ will consider "bad"
write-output "ERROR: Win version is ALREADY Windows 10: $($OS.version)"
$host.SetShouldExit(111111111)
}
Else
{
# Win version is NOT currently Windows 10
# Exit code should default to 0
write-output "READY FOR UPGRADE: Win version is: $($OS.version)"
}
Not having luck even if I take out that script and have
Step 2
start /wait \\servershare\setup.exe /auto upgrade /migratedrivers all /dynamicupdate enable /telemetry disable /compat IgnoreWarning /showoobe none /NoReboot
It just runs and never stops.
Paul Lange
This is the line: If ($OS.version -match "10.")
Just change that line to: If ($OS.version -match "10.0.18363")
You would just need to update that line with each subsequent Feature Update version.
Mike beat me to it! Lol.
Paul Lange
I had originally written this post to upgrade from Windows 8 to Windows. To just do Feature Updates, you can remove the first step and just have the first step be the command-line to upgrade.
In your command, it looks like you aren't including the Product Key parameter. Did you have that in your command? It looks like /pkey XXXXX-XXXXX....
For example:
No our copies are OEM so no need to put in the product key (I don't think anyway). I did take out that first step and it looks like it's working on my test VM at least. We have very little workstations so I know what version level they are so no real need for that first step in my case anyway. Thanks for your help and quick responses.
I am running this command in SQLITE but it doesn't do anything and I am still getting the 15mb exceeded, any idea's?
Kevin Still
Is it possible you ran that against the Inventory database instead of Deploy? Also, I'd highly recommend using the Settings command instead of directly editing the database.
Something from our deployment that i found.
We use the above script and setup.exe command line along with the manual reboot and sleep commands.
We were running the upgrade but it was simply timing out at the setup stage. When i ran the command line manually i found it was asking for a version of windows. This is due to the ISO we pulled down i believe. If anyone else is seeing this you can modify the Ei.cfg file inside of sources and tell it which version you want it to use.
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-setup-edition-configuration-and-product-id-files--eicfg-and-pidtxt
I'm having an issue w/ a 1803 to 1903 upgrade via PDQ. I am able to get the upgrade to kick off, sleep for 20 min to complete the post upgrade boot up stuff (i set it for 20 min since i had a couple that spun for longer than usual) and have a reboot task after that. no matter what I try , I cannot get that reboot to kick off even though the vm has been up and ready for a good 10 min by now. I even verified that PDQ inventory an do a heartbeat, scan, etc so that server can reach it even.....just can't do that post upgrade reboot for some reason. Oddly enough, if i cancel things at this step and run a reboot package on the same machine w/out doing anything else, it does reboot fine. any ideas?