Use PDQ Deploy to push In-Place Windows 10 Upgrade

0

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

Cancel
login to comment
0

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

Cancel
login to comment

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

Cancel
login to comment

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

Cancel
login to comment

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?

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

Cancel
login to comment

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

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

Cancel
login to comment

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.

Cancel
login to comment

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.

Cancel
login to comment

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?

Cancel
login to comment

0

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

Cancel
login to comment

0

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

Cancel
login to comment

0

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

Cancel
login to comment

Reply