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.

Microsoft office uninstall - not registered in PDQ inventory

Hi, I've been using PDQ Deploy to push out Office 2016 throughout our organisation. I found that the standard MS install process wouldn't uninstall office 2010 as part of the upgrade, so eventually linked together a couple of packages. One uninstalled 2010 and the other installed 2016.

What I didn't check before I pushed this out was whether Office 2010 still remained in any way. Unfortunately when I use PDQ inventory to see which machines weren't available during the push, I can't differentiate between a 2010 machine and a 2016 (I',m using Collection LIbrary>Office Suites>Microsoft Office) - they all say they have both. Clearly, I have screwed up and each machine, despite having 2010 uninstalled, retains some setting that registers within PDQ inventory as stilll having Office 2010.

So can you help me extracate myself from the hole I have dug. Is there a report that I can run that will check for the existence of Word.exe  perhaps or something a bit more sophisticated?





Date Votes
  • This registry key is your friend: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall


    Create a registry scanner for that key, you can drill down a little bit into it on a test machine to get the exact strings for both versions of Office, 10,12,14,16, blah blah blah. I can't remember which correlates to which off the top of my head.

  • I too have had trouble with bits of Office being left behind after an uninstall. OffScrub worked really well for me. Unfortunately the original webpage seems to no longer exist. I was able to find a GitHub repo with a copy of it though:

  • Here's Microsoft version of Fixit to fully uninstall all version of 2013/2016 office. This one is for Office 2010. Unfortunately, you cannot push this through PDQ. It needs to be run manually on each machine. There's a power shell workaround to push this out, but it wasn't a success for me.

  • What issue were you having with the Powershell?

  • Just trying to make it run thorugh PDQ. It works if run manually locally, but not with PDQ... also I can't see any progress making it hard to determine where it went wrong.

    For the script to works you need to use microsoft provided ps1 script + Offscrub command. I don't feel like playing with it that much, and I only have 15 machines that need clean up... so It is more efficient for me to manually run the diag one machine at a time.

  • Thanks Sam & Colby for the heads up on those tools

    Stephen, that key doesn't have a value set on my x64 win7 office 2016 machine. I found a key that might help, although because its specifically for Word maybe isn't perfect (there are equivalents for other Office apps):


    For an office 2016 application the value would be Word.Application.16

    So I amended the Applications scan profile to include a registry scan ( I would upload a pic here but the site tells me I can only upload jpeg, gif or png and size limit is 2MB - my pic is somewhere between 124KB and 215KB and I have tried as gif, jpg or jpeg with no success, although it appears fleetingly and is then removed).

    The scan checks the Registry for "Keys in HKEY_CLASSES_ROOT\Word.Application\CurVer"

    I have run the scan against the "All Computers" group.

    I have created a custom report with the following value filters:


    Registry>Value Name>Equals>CurVer

    Registry>Value>Starts With>Word.Application.16 [i've put "starts with" but have also tried contains & equals]

    I run this report and get nothing. I don't know how to access the data that the scan is returning or even if the scan is returning anything.

    I'm assuming I'm an idiot, its a good bet.



  • Jonathan,

    The registry path that Stephen gave you is the correct registry path for all Office applications installed on your machine.

    Inside of "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall" you should see a subkey (folder) that begins with "Office16.Something" (Mine is Office16.PROPLUS) housing all the registry information for Office 2016 including the "UninstallString" value for your application. Above "Office16.Something" you can also see all the KB updates for office in GUID form.

    If your goal is to fully remove remnants of Office 2010 you can use the following article to fully remove all traces.

  • One more thing...

    If it's a 32-bit version of Office installed on a 64-bit OS, your registry path is


  • HI Brandon,

    I've got nothing under that registry path. I have a whole load of GUID entries and the only ones that relate to office 2016 have the following display names:

    Microsoft Office 64-bit Components 2016

    Microsoft Office Shared 64-bit MUI (English) 2016

    Microsoft Office Shared 64-bit Setup Metadata MUI (English) 2016

    but other than that, I go from MPlayer2 to PROSetDX no microsoft, no office

    However I feel we might be digressing. I need to find out a way to use PDQ inventory to differentiate between machines that have no office/office 2016/office 2010 installed. I'll remove Office 2010 totally from those that have had 2016 installed.



  • Jonathan,

    It's not a digression as those registry values "must" be present to have a successful install of Office. Something has gone terribly wrong during your uninstall/install process.

    You are telling me that after a successful scan in PDQ Inventory, that under "Applications" for "ProblemMachine" you are still seeing both Office 2010 and Office 2016?

    I created a Report for someone else in another thread to assist in removal of Office applications but if your registry is jacked up, you may have a really rough time with the repair.

    See below:

    You can run a report to find what Office application versions and architecture are running on your machines.

    I started by creating my columns as such:

    I then ran these filters against the registry on the machines.

    The results are below:

    If the registry path houses "WOW6432Node", it's running a 32-bit version of Office on a 64-bit machine.

    If the registry path houses "Microsoft\Windows\CurrentVersion" the Office Version matches the "Host" Architecture which is also displaying on this report.

  • Quick update: Our posts crossed. As I suspected, I am an idiot. It is a 32 bit install and the reg key was under \Wow6432Node. I'm studying the rest of your post now.


  • There are no idiots here. Asking questions is the smartest thing anyone can do!

    We all learn together.

    PS: Yes it's cheesy but its true.

  • Appreciate your patience!

    Brilliant, progress. Thanks Brandon for your definitions for the report and the 32 bit ref. That gives me some info. The challenge I now have is that any given machine can report values for both

    \CurrentVersion\Uninstall\Office14PROPLUS and


    It looks like that despite my deployment uninstalling office 2010, it leaves the registry key behind, so I can't see which machines haven't been updated.

    Is there a way to exclude machines that have a specific registry key (i.e. CurrentVersion\Uninstall\Office16.PROPLUS)?


  • Kind of off topic but maybe using File search instead of Registry. I have not done this before, but in theory it should works. Using wildcard on File search, and find the excel/word/outlook/etc.exe and look for its product version. This should also works the same same registry..but better because you will only have one result for excel/word/outlook. 


    Here's my uninstall for Office 2013 on PDQ Deploy.

    I use PDQ Inventory to find the uninstall cmd line, then use PDQ Deploy and use Command Prompt deploy option to uninstall Office product. 

    Under Conditions I use these criteria to ONLY run if it is H&B 2013. The File will check product version if it is 15 or 16 (we don't have 14 or 2010 in our environment so I am not worried). The Registry will check if it is 2013 H&B or O365.

    Below are the Conditions screenshot for H&B and O365.

    What you could do is maybe using this setup and see which one failed/skip and which one run. The command can be ANYTHING. Maybe do GPUPDATE /force for the command. If it is Office 2010 it will run, and skip 2016. 

    What do you think?

  • If you're looking to exclude 2016 from the reporting just change the reports Registry Key to the full value of 2010 to find those machines with only 2010.

    See below:

    Obviously, replace the "Office14.Click2Run" with your version.

  • If I may interject a little something, instead of a report, he could do a collection. The filters are the same between creating the report brandon is doing, and creating a collection. You could just hit "New Collection From Report" in the report window to do it actually, that will give you something to Deploy to in PDQ Deploy. If you're just looking to clean up after the 2010 uninstallation, once you have your collection from report a powershell step in a package to remove the registry key would be your best friend, and I'd also maybe check for the existence of Offce 14 folders in Program Files and Program Files (x86)


    Something like this:

    #Remove all registry entries related to the 2010 version

    $items = Get-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\**Office14**"

    Foreach($item in $items)

    Remove-Item -Path $item.PSPath -Force

    Write-Output "Removed:`n $($item.ParentKeyName) `n $($item.PSChildName)"


    #Remove Program Files Entries

    If((Test-Path "C:\Program Files\Microsoft Office\Office14")){

    Remove-Item -Path "C:\Program Files\Microsoft Office\Office14 -Recurse -Force"

    Write-Output "Removed Office14 folder from C:\Program Files\Microsoft Office"


    If((Test-Path "C:\Program Files (x86)\Microsoft Office\Office14")){

    Remove-Item -Path "C:\Program Files (x86)\Microsoft Office\Office14" -Recurse -Force

    Write-Output "Removed Office14 folder from C:\Program Files (x86)\Microsoft Office"

  • Just FYI, I fixed a Couple Typos I saw in the script above (Missing "" in the Test-Paths, and the closing ) for the If's. Also I had Office15, should be 14 for the registry key bit. 


    Let me know if that works well for you.

  • Just an update. Thanks for all your feedback guys, much appreciated.

    Brandon - machines with Office16 installed will also have an entry for the current version being Office14 - screen shot below. I would like to be able to filter for the non-existence of Office16 rather than the existence of Office14. The existence of Office14 doesn't mean that Office16 hasn't been installed too.

    Sam, thanks for your info, am looking at that now.

    All the best