I work for a large university in the midwestern United States, where part of my job is building operating system images and application packages for deployment with Microsoft System Center Configuration Manager. It is a lot of work to plan and build a high-quality, reliable deployment, and so I thought I would start my blog by documenting the process of building a set of Configuration Manager application packages for the latest version of one of the most commonly deployed applications on the planet: Microsoft Office. Numerous blogs have helped me to do my job, and it is my hope that this blog will be a worthy gift back to the online software deployment community.
Although Microsoft Office 2016 has been available for several months, there has not been an outcry for upgrades in my organization. We avoid making changes while classes are in session, so major upgrades tend to be scheduled in the downtime between the summer and fall semesters. I suspect, therefore, that the university will move to the new version in summer 2016, which gives me the time to document the required planning and testing here. We have licensed Microsoft Office Professional Plus 2016; we are not using the Office 365 offering.
Application Packaging Guidelines
Goal: Build a reliable Microsoft Office Professional Plus 2016 application package in System Center Configuration Manager for deployment across multiple operating system versions.
I will explain my philosophy of application packaging and deployment fully in a later post, but for now, I will just list these brief rules for applications deployed through Configuration Manager’s Software Center:
- Installation must be silent.
- The application package must account for all possible dependencies.
- The installation must be reversible.
- First-run prompts must be minimized or preferably eliminated.
Hardware Requirements and Prerequisite Software
Let’s start by taking a look at the System requirements for Office 2016. This will tell us the hardware requirements, which we will need later when building our application package, and any prerequisite software. We must either test for the presence of prerequisite software or build separate application packages for that software. My university has licensed Office Professional Plus, so I will focus on that edition’s requirements. Here they are:
| COMPONENT | REQUIREMENT |
|---|---|
| Computer and processor | 1 gigahertz (GHz) or faster x86-bit or x64-bit processor with SSE2 instruction set |
| Memory | 2 GB RAM |
| Hard disk | 3.0 GB available disk space |
| Display | 1280 x 800 screen resolution |
| Graphics | Graphics hardware acceleration requires a DirectX 10 graphics card. |
| Operating system |
Windows 10, Windows 8.1, Windows 8, Windows 7 Service Pack 1, Windows 10 Server, Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2 For the best experience, use the latest version of any operating system. |
| Browser | The current or immediately previous version of Internet Explorer; the current version of Microsoft Edge, Safari, Chrome, or Firefox. |
| .NET version |
.NET 3.5 required. Some features may require .NET 4.0, 4.5, or 4.6 CLR to also be installed. |
| Other | Internet functionality requires an Internet connection. Fees may apply. A touch-enabled device is required to use any multi-touch functionality. But, all features and functionality are always available by using a keyboard, mouse, or other standard or accessible input device. Note that touch features are optimized for use with Windows 8, Windows 8.1 or Windows 10. Product functionality and graphics may vary based on your system configuration. Some features may require additional or advanced hardware or server connectivity. |
I highlighted the portions that interest me right now; we’ll come back to the hardware requirements later.
At my university, there is little top-down direction regarding which operating system version should be used, and so I must plan to support all of the listed operating systems in order for my application package to be useful to the entire organization. Unfortunately, that means I have to ensure compatibility with ten client operating systems and three server operating systems:
- Windows 7 SP1 (huge installed base in my organization) (64-bit and 32-bit)
- Windows 8 (hopefully no one is running this, but we need to support it anyway) (64-bit and 32-bit)
- Windows 8.1 (small installed base in my organization) (64-bit and 32-bit)
- Windows 10 RTM (hopefully no one is running this, but we need to support it anyway) (64-bit and 32-bit)
- Windows 10 November Update v1511 (small installed base, but our platform of choice for all new installations and reinstallations beginning in summer 2016) (64-bit and 32-bit)
- Windows Server 2008 R2
- Windows Server 2012
- Windows Server 2012 R2
I only worry about software that has actually been released, so the next version of Windows Server is irrelevant at the time of this writing. Also, yes, I know that installing Office on Windows Server is a terrible idea, but Microsoft supports it, so my application package will support it.
You may be wondering why I am so concerned about the operating systems when the Office team has taken care of operating system support. The answer lies in the prerequisites. The various versions of the .NET Framework are installed differently on different operating systems. Each of the required .NET Framework versions must have its own application package in Configuration Manager to act as a prerequisite to the main Office 2016 package. I will cover building the .NET application packages in future posts.
Browser support is less of an issue. Windows 10, 8.1, and Server 2012 R2 have Internet Explorer 11 built in; Windows 8 and Server 2012 have Internet Explorer 10 built in. Both of these IE versions satisfy the requirements. For Windows 7 and Server 2008 R2, we’ll either have to build an IE11 application package or set a condition that checks for IE10 or IE11. My initial thought is to just set a condition because if any Windows installation is on an old version of IE at this point (January 2016), then the user or administrator has specifically blocked it from being installed in Windows Update as well as in the settings of IE itself, and so we should respect that decision and just fail the Office installation. (If I change my mind about this, you’ll find out in a future post.)
Coming Up
The .NET Framework packages are large and complex. They are also applicable to other applications besides Office, so I will cover them first. Next time, we’ll build a single .NET Framework 3.5 SP1 package that works for all 13 platforms listed above. After that, we’ll build a .NET 4.6.1 package. Finally, because Office’s .NET 4.x version requirement is flexible—any version that starts with ‘4’ is OK—we’ll build a package that does the minimum amount of work for a given platform in order to satisfy that requirement, and we will make use of the .NET 4.6.1 package source for platforms that don’t have .NET 4.x included as an OS component.