Check the application version in Modern Office

2019-02-11
Ken Puls
Categories: Excel, VBA

In the good old days, it was easy to check the application version in Office with VBA. You just used a little test of Val(Application.Version) to return the number. 12 was Office 2007, 14 was Office 2010, 15 was Office 2013, and 16 was Office 2016. But then Office 365 came out, and 2019, and things fell apart.

Conducting a check of the application version in Modern Office is not as straight forward. From Office 2016 onwards, Microsoft has not revved the Application.Version number - they all show as 16.0 - giving you no way to differentiate between versions. (Bastien discusses this in a blog post a few months ago.) But worse, while he focuses on 2016 vs 2019, there is also no way to test between these and Office 365 subscription versions. As there are now things that work differently for Office 365 than the perpetual licenses, this is another potential problem for developers.

This past week I ran into a scenario where I needed to do exactly this. I needed to find a way to programatically enumerate whether a user is running Office 2016, Office 2019 or Office 365, as I had to do something different in each case.

So how can we check the application version in modern Office?

After doing a little digging, I finally found a registry key that seems to appear in Office 2019 and Office 365, but does not exist in Office 2016. So that was good news. And even better, that key holds values like "O365ProPlusRetail" vs "Office2019ProfessionalPlus". While I haven't tested with other SKUs, this would seem to indicate a pattern I hope we can rely on.

Given that, I've pulled together this function. It's purpose is fairly simple: Test the application and see if it is a perpetual license or a subscription install, and return the version number. So anyone with Office 365 installed should receive 365 as a return, otherwise you'll get a four digit number representing the version you have installed.

Function to check the application version in Modern Office

Function AppVersion() As Long
'Test the Office application version
'Written by Ken Puls (www.excelguru.ca)

Dim registryObject As Object
Dim rootDirectory As String
Dim keyPath As String
Dim arrEntryNames As Variant
Dim arrValueTypes As Variant
Dim x As Long

Select Case Val(Application.Version)
Case Is = 16
'Check for existence of Licensing key
keyPath = "Software\Microsoft\Office\" & CStr(Application.Version) & "\Common\Licensing\LicensingNext"
rootDirectory = "."
Set registryObject = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & rootDirectory & "\root\default:StdRegProv")
registryObject.EnumValues &H80000001, keyPath, arrEntryNames, arrValueTypes

On Error GoTo ErrorExit
For x = 0 To UBound(arrEntryNames)
If InStr(arrEntryNames(x), "365") > 0 Then
AppVersion = 365
Exit Function
End If
If InStr(arrEntryNames(x), "2019") > 0 Then
AppVersion = 2019
Exit Function
End If
If InStr(arrEntryNames(x), "2021") > 0 Then
AppVersion = 2021
Exit Function
End If
Next x
Case Is = 15
AppVersion = 2013
Case Is = 14
AppVersion = 2010
Case Is = 12
AppVersion = 2007
Case Else
'Too old to bother with
AppVersion = 0
End Select

Exit Function

ErrorExit:
'Version 16, but no licensing key. Must be Office 2016
AppVersion = 2016

End Function

If you'd prefer to just download a workbook with the code in it, here you go.

Care to help me test it?

I'd love it if people could give this a try and see if it returns correctly based on the versions of Excel you're running, particularly if you have a flavor of Office 365 or Excel 2019.

Let me know how it goes!

EDIT: I have made a small change to the code and sample file in case "O365" is not at the beginning of the registry key. This should pick it up no matter where in the key the 365 term shows up. I am starting to wonder if this key is only present for Insiders. So if you do test, please let us know what channel you are on in addition to whether or not it works!

38 thoughts on “Check the application version in Modern Office”

XLarium on February 11, 2019 at 9:50 am said:

Hello Ken

Your function comes up with "2016" but it should be "365".
Ben Welman on February 11, 2019 at 10:17 am said:

I have installed Office 365 MSO (16.0.11330.20014) 16 bits. Function respons is 2016.
Ken Puls on February 11, 2019 at 10:30 am said:

Ben & XLarium,

Are you Office Insiders, or running a different channel? I'm wondering if that registry key is only present for Insiders...
Ben Welman on February 11, 2019 at 10:37 am said:

Yes, Office Insider.
Ken Puls on February 11, 2019 at 10:47 am said:

Hey Ben,

So... what version of Office 365 (as in Home & Office, Professional Plus, etc..)? Can you check again? I've just updated the code to test if 365 is anywhere in that reg key, rather than just at the beginning.
Ken Puls on February 11, 2019 at 10:48 am said:

(as in Home & Office, Professional Plus, etc..)
XLarium on February 11, 2019 at 10:58 am said:

@Ken, my subscription is running on the monthly channel - not on Office Insider.
Version 1901 Build 11231.20130 click-and-run

No change with the modified code.
Ben Welman on February 11, 2019 at 11:54 am said:

Ken,
It's Office 365 Home. Function respons is still 2016.
Rob on February 11, 2019 at 12:11 pm said:

It didn't work for me either. I'm on Office 365 ProPlus (Monthly Channel) and it reports 2016.

I checked in regedit and I don't have the key you are looking for "Software\Microsoft\Office\16.0\Common\Licensing\LicensingNext"

I did notice one called "HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Licensing\LastKnownC2RProductReleaseId", however, that has a value of "O365ProPlusRetail"...you might want to take a look at that one.
Ben Welman on February 11, 2019 at 12:19 pm said:

I did also a check on 3 older Excel versions which are installed on virtual machines:

Office Professional Plus 2013 - Function returns 2013
Office Professional Plus 2010 - Function returns 2010
Office Enterprise 2007 - Function returns 2007
Omar on February 11, 2019 at 1:39 pm said:

I'm running Office 365 Personal and not on the Insider stream. The file I just downloaded at 4:35est reports that I am running Excel 365.
Ken Puls on February 11, 2019 at 2:09 pm said:

Rob, that's awesome info. I'm checking with someone else who also doesn't have the key I targeted to see if they have the one you mentioned.
Ivan Bondarenko on February 11, 2019 at 2:48 pm said:

Hi Ken. Function works fine for me.
I'm using Office 365 ProPlus, monthly channel, version 1901 Build 11231.20130 click-to-run
"O365ProPlusRetail" in the registry.
Function returns 365.
ChrisB on April 24, 2020 at 6:16 pm said:

The function works for me on MS Office 2019 MSO (16.0.12624.20424) 64-bit.
Anthony on May 6, 2020 at 5:42 pm said:

Microsoft has got you.

There are OEM versions of office that are App-V installed, so no registry keys that are visible at all when Excel is not running.
Ken Puls on May 7, 2020 at 11:56 am said:

Fair enough, although I can't say that I try to test this when Excel isn't running, as it's usually done via an Excel VBA Add-in, or a .NET based add-in. In either case, Excel has to be open for these tools to manifest themselves.
Lior on August 5, 2020 at 6:03 am said:

Hi Ken,
I desperately need to recognise the Excel version of several users, and most importantly identify those with Office365 which was giving some trouble with parts of my VBA code and came accross your post.
Shouldn't there be a way to determine the exact Office version of post 2016 office (all giving 16.0 response to application.version function) by iqnuiring the application.build number without the need to look for registry entries ?!
Ken Puls on August 5, 2020 at 8:21 am said:

Shouldn't there be? Absolutely yes. Is there? Sadly no. 🙁
Kien Leong on September 28, 2020 at 3:39 am said:

Hi Ken,

Thank you for sharing this function. It worked for me on 365 (Microsoft Excel for Microsoft 365 MSO (16.0.13127.20402) 64-bit

It has been a very useful in solving a problem when MS has added to the Object Model (Comment versus CommentThreaded for example)

I would be very interested to learn more about which versions don't support this method (App-V?) and how widely these are used.
Volker on October 13, 2020 at 5:46 am said:

Hi all,
any news for a solution of this version number problem? (It's not been a problem for me yet, but it may become one.)

I've put off the installation of Office 2019 for a long time. Today I've installed 2019 and to my surprise I've made the discovery that the version number is still reported as 16. A quick search took me to this website.

I've been running Office 2010 and 2016 in parallel and I've been hoping that 2019 will coexist, too. Negative, 2019 saddled on top of 2016. If I click on Show additional licensing information it shows both 2019 and below that entry it shows 2016. I've made a quick check for a few new features of 2019 and the application splash screen at startup also states inmistakenly 2019. So yes, it's Office 2019. (And I may have to create yet another windows installation with Office 2016 for testing. 🙁 )

Ken's macro returns 0, though it is not 'too old to bother with'
arrEntryNames(x) has one entry which reads "MigrationToV5Done"
application.version is 16.0
application.build is 13231

While this entry could easily be added to case 16, who knows if this entry may not also be used for updates to 365? And what other entries might be used in other scenarios/on other machines? Looks like potential proliferation of entries asking for updates everytime another entry has been discovered.

Do we have to worry about our addins?
Microsoft says:
"Add-ins and other extensibility solutions that are compatible with Office 2016 will most likely be compatible with Office 2019 or will require only minimal testing."
https://docs.microsoft.com/en-us/deployoffice/office2019/overview

See also https://www.asap-utilities.com/blog/index.php/2018/10/05/application-version-is-the-new-excel-2019-the-same-as-excel-2016/

Somehow I do not feel easy about this as of now.
Ken Puls on October 13, 2020 at 9:45 am said:

Hi Volker,

There is no hope in sight to resolve this issue. We're all trying a variety of things to figure out how to determine the versions due to this lack of ability, and I'm sorry that mine isn't working for you.

I can confirm that you CANNOT have a 2016 and 2019 install side by side. They both use the Click-to-run installer, so one overwrites the other. The only way to get different versions for testing is to set up virtual machines AND disable updates on them after installing. (Failing to do this may leave you in a situation where your software reports as 2016 but actually provides Office 365. A key indicator is if your "2016" shows an update channel in the About screen.)

I will say that I have no issues bringing code from 2016 -> 2019 -> O365. It's when I have a feature that relies on O365 and I need to check if I have an earlier version that this whole thing comes in to play.
Ken Puls on October 13, 2020 at 9:46 am said:

Hi Kien,

I honestly don't know which versions don't support the method. Wish I did!
Howard Fink on November 12, 2020 at 2:48 pm said:

I need to determine whether or not 365 is being used or not on Macintosh installations. Obviously there is no Registry to check against.

Do you know of a method of determining the presence of 365 on a Mac?
Ken Puls on November 13, 2020 at 9:51 am said:

Hi Howard,

Sorry, but I don't do any work with Mac computers, so really can't help on this.
Jumpy on April 1, 2021 at 10:43 am said:

I'm in the same situation of Rob on February 11, 2019 at 12:11 pm...
Unfortunately your code can't be used as is, but it requires to be modified calling the method "GetStringValue" to the members of the "arrEntryNames" array, recursively. This is because of the fact the string to be searched is in the value of the subkey and not in the name on the subkey (how can I image it is supposed to be in your case).
Would you be so kind to share a regedit screenshot of the "LicensingNext" key in order to see where the string to search exactly is?
Ken Puls on April 1, 2021 at 4:06 pm said:

Hi Jumpy,

I just checked this on my Office version, and can see that this routine will no longer work. It seems that things have moved under the LastKnownC2RProductReleaseId key, which lists all individual apps with their O365 names... I just haven't had the time to work out how to extract those registry values as they are different then the ones listed above.
Jumpy on April 2, 2021 at 7:26 am said:

Hi Ken,
tks for the quick response...
If I understand well what you have told me, the "LicensingNext" key need no more to be scan because all info for O365 is moved to "LastKnownC2RProductReleaseId" key too. Is it right?
So, even for O365, under the "LastKnownC2RProductReleaseId" key, you have a subkey for each Office App installed/licensed, named as "Excel", "Access", "Word", etc..., and valued with a string including the "O365" substring. Is it right?
Ken Puls on April 2, 2021 at 9:46 am said:

That's correct. The full path to the Excel key is now:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\Licensing\LastKnownC2RProductReleaseId\Excel. It is a REG_SZ (string) with - in my case - a value of O365ProPlusRetail
I have the same value for Access, Outlook, Word and others within that LastKnownC2RProductReleaseId branch.
Jumpy on April 2, 2021 at 11:55 am said:

Perfect...
it is the same as in my case, even if I have an O2019 installed on my machine and for each Office App subkey a value set to "ProPlus2019Retail"
Jumpy on April 2, 2021 at 12:32 pm said:

In previous versions of Office you could check even if the product was x32 or x64 on Win x64 because of the use of Wow6432Node folder in registry. Have you need to find this info for recent Office releases?
Unfortunately the Wow6432Node folder seems not to be used anymore

Anyway... many tks for your always quick responses
Jumpy on April 2, 2021 at 2:15 pm said:

I hope it will be useful for you and other...
I have found another registry key from which extract the info we are looking for, including if the Office Suite is installed on x64/x32 bit platform
The key is: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
The subkeys are:
name:ProductReleaseIds, type:REG_SZ, value:ProPlus2019Retail
name:Platform, type:REG_SZ, value:x86

In such a way you can have all the info you need !!!

Would you be so kind to check if this method is ok for you with O365 too?
If yes, which are your data in the registry editor?
Ken Puls on April 4, 2021 at 11:42 am said:

I can confirm that I do have this key on my O365, yes. One thing to be careful with here though, is that ProductReleaseIDs is actually a comma delimited string if there is more than one product registered. (I have a Visio license installed as well.) I'm going to play with this a bit and see if it goes back as far as Office 2016 too. That could be very interesting...
Jumpy on April 5, 2021 at 12:17 pm said:

I have an Office Professional Plus 2016 installed on another machine. I can tell you that the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\ProductReleaseIds subkey Value doesn't not exist in that case.
How does the key value appear with Visio App installed?

If you find something interesting please share it
Trevor on April 2, 2023 at 2:37 pm said:

Thanks Ken. I see there haven't been any comments for a while, so I don't know if you are still interested in feedback. Anyway, if you are ...

Microsoft Excel for Microsoft 365 MSO (Version 2304 Build 16.0.16316.2000) 64 Bit

Microsoft 365 Insider Beta Channel

MsgBox shows 365

Thanks again, Trevor
Trevor on April 2, 2023 at 2:54 pm said:

Would it be valid to add the following to check for 2021?

If InStr(arrEntryNames(x), "2021") > 0 Then
AppVersion = 2021
Exit Function
End If
Ken Puls on April 4, 2023 at 9:01 am said:

Hi Trevor, I have modified the code to include this.
Junior on July 9, 2024 at 4:11 am said:

Hey Ken, i know it´s been a while.
I´m trying to distinguish 2016 and 2019 (further 365) for my application, but my installation (Microsoft Office Professional Plus 2019) returns "2016"

Is there any update on this?
Ken Puls on July 9, 2024 at 8:53 am said:

Hi Junior,

I'll admit, I gave up on this one due to the finicky nature of the registry. It was like playing whack-a-mole to try and get all the SKUs Microsoft sells.

Instead, I test if WorksheetFunction.Xlookup(1, 1, 1). If it does, it is 2021 or higher, if not it is 2019 or earlier.
If WorksheetFunction.Concat(1) returns a result it is 2019 or higher, but if it returns an error, it is 2016 or earlier.

It's cludgy, but if allows building a case structure. The tricky part is finding the functions that exist on either side of the major version cutoffs. 😉