Use PDQ Deploy to push In-Place Windows 10 Upgrade

Comments

13 comments

  • Christian Bacher

    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
    Comment actions Permalink
  • Mike Resnick

    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
    Comment actions Permalink
  • Christian Bacher

    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
    Comment actions Permalink
  • Chris Pohts

    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
    Comment actions Permalink
  • Scott Wood

    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
    Comment actions Permalink
  • Mike Resnick

    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
    Comment actions Permalink
  • Mike Resnick

    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
    Comment actions Permalink
  • Dan Jackson

    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
    Comment actions Permalink
  • John Rehill

    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
    Comment actions Permalink
  • Dan Jackson

    @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
    Comment actions Permalink
  • Steve

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

    0
    Comment actions Permalink
  • Mark Hamric

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

    0
    Comment actions Permalink
  • Alex Alexandre

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

    0
    Comment actions Permalink

Please sign in to leave a comment.