Important Notice: On February 29th, this community was put into read-only mode. All existing posts will remain but customers are unable to add new posts or comment on existing. Please feel to join our Community Discord for any questions and discussions.

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.

  1. Copy the entire contents of your Windows 10 ISO to a network share, such as "\\fileserver\Win10Setup"

  2. Create a PDQ Deploy package

  3. 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)"
     }
    
  4. 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
    
  5. Add a "Reboot" step

  6. Add a "Sleep" step (I used 10 minutes, but you could do 10-20-30-40, whatever you like)

  7. 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!

0

Comments

49 comments
Date Votes
  • 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.

    enter image description here

    Or you can link inside the package schedule to the Inventory collection for Win 7/8

    enter image description here

    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:

    enter image description here

    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)

    1. The txt file creation

    2. The setup.exe Step

    enter image description here

    Maybe this helps you to optimize your deployments

    Greetings

    Chris

    0
  • 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

    0
  • 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

    0
  • 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?

    0
  • 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

    0
  • 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

    0
  • 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

    0
  • 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.

    0
  • This is the method I've used:

    1. Extract the ISO to a directory in the repository
    2. Point the 'setup.exe' in the root and use the parameters /auto Upgrade /quiet /Compat IgnoreWarning /showoobe none /DynamicUpdate Disable. Success codes are '0,1641,3010,2359302' (I think default)
    3. Conditioned to only run if no user is logged in (for safety)
    4. I have a schedule set but left the 'Stop deploying to remaining...' unchecked as I set this to run on a Sunday when no-one is around
    5. For package steps I use first a workstation reboot to resolve any pending reboots, software installs, pending updates etc. and then do the install.
    6. I've found there are some packages that will block an install such as the Intel Graphics driver or HP Drive Encryption/ProtectTools but if you know how to decode the setup error log in the hidden windows setup directory

    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.

    0
  • @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?

    0
  • I have had sucsess with this from 1511 to 1809 but not from 1709 or beyond.

    0
  • What are you guys using to get rid of the Windows.old folder after updating the OS?

    0
  • i have tried everything i cant get my workstation to upgrade to 1903. what am i doing wrong. enter image description here

    1
  • 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!

    0
  • 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.

     

     

    0
  • Thanks for all the info posted previously!

    For those having issues upgrading Windows 10 to 1903, try executing from a command line:

    "\\YourServerPath\setup.exe" /Auto Upgrade /MigrateDrivers All /ShowOOBE none /Compat IgnoreWarning /Telemetry Disable

    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)

    insert into Settings ('Name', 'Value') values ('DeploymentSettings.MaxStepOutputSize','209715200');
    0
  • 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?

     

    0
  • 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

    1
  • 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

    0
  • 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. 

    0
  • Paul Lange

    Change the version check in the final PowerShell step to look for version: "10.0.18363"    that is 1909.

    Good luck!

    -Mike

    1
  • 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. 

    0
  • 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.

    0
  • Mike beat me to it! Lol.

    0
  • 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:

    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
    0
  • 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. 

    0
  • I am running this command in SQLITE but it doesn't do anything and I am still getting the 15mb exceeded, any idea's?

     

    insert into Settings ('Name', 'Value') values ('DeploymentSettings.MaxStepOutputSize','209715200');
    0
  • 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.

    PDQDeploy.exe Settings -Name 'DeploymentSettings.MaxStepOutputSize' -Set 209715200
    0
  • 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

     

    0
  • 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?

    0