Office 2019 Version Numbers

[Nicholas Mahendra]

Thefollowing table provides a list of the version and build numbers for each update to Microsoft 365 Apps released in the following update channels: Current, Monthly Enterprise, Semi-Annual Enterprise (Preview), and Semi-Annual Enterprise. Each entry in the table links directly to the release notes for that release. These release notes provide information about features, security updates, and non-security updates that are included in the update to Microsoft 365 Apps.

This version number is used for stamping the installation files of Outlook and is also used in the Registry, with the most known Registry hive being;

HKEY_CURRENT_USER\Software\Microsoft\Office\\Outlook

Outlook was first introduced in Office 97 which had the version number 8.0. The version numbering of Office itself skips number 5 and 6. This is because since Office 95 (version 7.0), all Office applications started sharing the same version number. Word at the time was in its 6.0 version and with that it had the highest version number. Its next version for Office 95 would become version Word 7.0 so that version number was taken for the entire Office 95 suite.

Outlook 98 was initially a free download and later remained as a free upgrade for Outlook 97 users adding new features - most notably support for non-Exchange accounts. Its availability has been pulled shortly before the release of Outlook 2000. As its release was outside the normal release cycle of the Office suites (to which the version numbers have been tied), the version number of Outlook 98 could not be a full version higher than Outlook 97.

Since Office for Mac 2011, Outlook replaced Entourage but has a completely different development team (they are even located in a different State!) and originally another development cycle. While it does share the same version number, originally, Office for the Mac is released 1 year after its Windows counterpart. This is no longer the case since Office 2019.

I read on my Windows based systems (via Remote Powershell) what is installed on their computers.

This creates a report. I am having some difficulties looking into the evaluation of the Microsoft Office software.

The solution lies within the rest of the build number. These numbers specify which version of Office you have.

Clearly we are using Office 365, but I want to know whether they are all up-to-date.

With the rest of the build number, you can get that finer grain of the version.

You could look them up at this Microsoft site. There you can find for instance that Build 14527.20234 is Version 2110.

It will only run if it needs to OR if you force it to (parameters -ForceCSV or -Output).

I added this to prevent the script starting the lookup everytime when you -for example- are polling 50 computers at the same time. The evaluation part prevents that, but can be overriden with the two mentioned parameters.

The CSV output then can be evaluated on other systems without the need of installing or pushing this function.

To keep the answer as short as possible, I removed as much Write-Verbose and comment lines as possible.

You could check and have an overview in the Microsoft 365 Apps Admin Center. This would be the Microsoft Cloudway of seeing all your Office365 Installations and should work out of the box (no scripting or configuration needed). You can check the documentation here -us/deployoffice/admincenter/inventory or see the techcomunity articel here -365-blog/inventory-on-microsoft-365-apps-admin-center-goes-ga/ba-p/2500065 . This is not the way to update all of your installations, but to see every installation and export this via csv and use it in a script to update. I hope this helps someone. Picture of Inventory

Is there anywhere (ideally official) that has a list of build numbers that we can compare our versions against?

Just to summarise: we know what our installed versions here are, we are looking for the most recent version numbers to make sure what we have is up to date.

Has anyone ever managed to do something clever with Confluence's attachment version numbers where they're somehow displayed in or on the attachment?

Use case being:

User prints off an attachment, and we know which version they've used because there's a nifty field in the footer or something that displays the Confluence attachment version number.

The attachment is only attached to confluence. The attachment isn't changed by confluence as it uploads. Perhaps there is nice version helper app on the marketplace. I couldn't find any with a quick search.

This is a problem because the relevance checks to see if the version number for Microsoft Office is less than the current Semi-Annual version update number. However, this causes an issue for computers that were previously set to a Monthly update path as the version numbers will almost always be higher than what the Semi-Annual Channel fixlet is looking for. This is going to cause out of date Monthly cycle computers to report back as Not Relevant for the recent Semi-Annual Office 365 fixlets that are being published and not be applicable for Office 365 updates.

Essentially if I have a version of 365 that updated on May 22nd through the Monthly Channel with a Version number of 11601.20230 the relevance for the 365 patch views it as not relevant despite 10730.20348 being a more recent version.

I remember when Microsoft announced that Windows 4.0 would be known as Windows 95. At the time, it seemed like a radical, unnecessary change -- naming software with years instead of version numbers? Inconceivable! How will users of Windows 3.1 possibly know what software version they should upgrade to?In retrospect, switching away from software version numbers to years seems like one of the wisest decisions Microsoft ever made.Users don't care about version numbers. Major, minor, alpha, beta, build number.. what does it all mean? What users might care about is knowing whether or not the software they're running is current. A simple date is the most direct way to communicate this to the user.A model year is easy to understand. Why should it take two arbitrary numbers and a decimal point to identify what software you're using? We identify tons of consumer products using a simple model year designator. Software should be no different.Version numbers don't scale. Once you get beyond ten versions, what's the point of meticulously counting every new release? Better to stamp it with a date and move on.

Microsoft Office 2003 is a far more meaningful name than Microsoft Office 11. And Firefox 2007 would be a much better name than Firefox 2.0 for all the same reasons.But version numbers live on, at least for programmers. Here's a quick survey of version numbers for the software running on my machine at the moment:7.0.6000.163868.1.0178.0011.112.7.0.02.5.10 / build 69032.0 build 09300122.1848.2579.334752.0.50727.3122.0.0.11.8.20061.20418As you can see, there's not even a commonly accepted pattern for version numbers. In .NET, the version number convention is:(Major version).(Minor version).(Revision number).(Build number)But it's hardly universal. And even if it was, what does all this meticulously numbered version data get us? What does it mean? Why have version numbers at all? It's partly because version number is an expected software convention. And partly because programmers never met a piece of arbitrarily detailed metadata they didn't love. Personally, I like to think of version numbers as dogtags for your software. Like dogtags, they're primarily designed for use in the event of an emergency.In the event of a software problem-- if, on the battlefield, you hear someone screaming "medic!"-- it is useful to consult the dogtags so you know exactly what version of the software you're dealing with.But software version numbers, even arbitrarily detailed programmer version numbers, can't seem to avoid dates, either. Jensen Harris explains the Microsoft Office version numbering scheme:The most interesting thing to watch for is the first 4-digit number you encounter. In the examples above, 5608 and 3417. These are what we refer to as the "build number." Every few days during the development cycle, we compile all of the code in Office and turn it into a "build": essentially an installable version of all the work everyone's done up until that point. Eventually, a build becomes "final" and that is the one that ends up on CDs and in the store.The 4-digit build number is actually an encoded date which allows you tell when a build was born. The algorithm works like this:Take the year in which a project started. For Office "12", that was 2003.Call January of that year "Month 1."The first two digits of the build number are the number of months since "Month 1."The last two digits are the day of that month.So, if you have build 3417, you would do the following math: "Month 1" was January 2003. "Month 13" was January 2004. "Month 25" was January 2005. Therefore, "Month 34" would be October 2005. 3417 = October 17, 2005, which was the date on which Office 12 build 3417 started. For Office 2003 and XP both, "Month 1" was January 2000. So, the final build of Office 2003, 5608, was made on August 8, 2003.

So Microsoft Office version numbers end up containing three relevant bits of data:the software generation (Office 97, Office XP, Office 2003, Office 2007), which is patently obvious to anyone using the software-- and can be directly inferred from the build date anyway.the date of the build.the number of builds done after "code freeze".Of those three, how many are actually useful to users? How many are useful to developers?On the whole, I encourage software developers to avoid confounding users with version numbers. That's what leads to crappy ideas like SID 6.7 and even crappier movies like Virtuosity. We brought it on ourselves by letting our geeky, meaningless little construct of major and minor version numbers spill over into pop culture. It's not worth it. Let's reel it back in.Whenever possible, use simple dates instead of version numbers, particularly in the public names of products. And if you absolutely, positively must use version numbers internally, make them dates anyway: be sure to encode the date of the build somewhere in your version number.

3a8082e126