By far, the most important prerequisite for successful Office 365 ProPlus deployment is network configuration. 

 

Unlike older versions of Office, Office 365 ProPlus was designed from the ground up to work with cloud services such as Microsoft Content Delivery Network (CDN).  Microsoft recommends IT Pros “Bypass or white list endpoints on network devices and services that perform traffic interception, SSL decryption, deep packet inspection and content filtering” when accessing Microsoft Office 365 service endpoints.  

 

We often find customers apply “legacy” network configurations for on-premises only products to Office 365 ProPlus which can lead to slower product adoption, poor product performance, and higher cost of ownership.  The network requirements are documented in Office 365 URLs and IP address ranges document.

 

The goal of this blog is to clarify how IT Pros can optimize Office 365 ProPlus deployments with a proxy server in order to leverage a new concept called Hybrid or “Lean Installs”.

 

In terms of Office 365 ProPlus general deployment, we have several broad approaches. We’re going to focus on the 3^rd option, “SCCM with Office CDN fallback” or “Lean Install”.

 

• On-premises only – download and mirror all content from CDN on-premises. Enterprise customers have a variety of install packages (Base Office, Visio, Project, Visio + Project, second installs for languages).  All Office 365 ProPlus builds are cumulative and are updated monthly which can make this cumbersome and difficult to maintain as each permutation requires refreshed content.
• Cloud only – installations from the Office portal and update workflow occur using CDN. End users in the enterprise are normally not Administrators so self-service installations from portal.office.com are blocked.  Further, installation from CDN doesn’t currently support custom configuration files to exclude applications and so forth.
• SCCM with Office CDN fallback or “Lean Install” – IT Pros use SCCM (which has elevated permissions and allows custom configuration.xml files) to deploy Office 365 ProPlus but can either omit all or portions of the installation source and use CDN content.

SCCM is not a requirement to adopt “Lean Install” approach. If you are using 3rd party deployment tool, identify user context of process using process monitor and adopt proxy strategy below.

Lean install examples:

1^st Install

SCCM package contains all Office 365 ProPlus content and only subset of languages. You support 12 languages but only include two primary languages in the application source to minimize content and include AllowCdnFallback as Enabled within configuration.xml.  During the Office 365 ProPlus installation process, the Office Deployment Tool (ODT) looks first for source files in local working directory. If the language pack files required aren’t available in local source location and the AllowCdnFallback setting within configuration.xml is set to True, then the ODT will leverage the Office CDN for the missing ones.

 

2^nd Install

Office may need to be reconfigured to make changes to Office deployments without changing the version, like adding a language or Project/Visio. In this case, we only want the required bits to perform the change and nothing else.

 

All example scenarios above depend on the CDN to fetch content when embracing these new “Lean Install” approaches.  The primary reason we want to lean on the CDN is because it allows Office 365 ProPlus to only download the bits it requires for the change request resulting in the smallest network payload possible. 

 

Exploring 2^nd Install Scenario in detail in terms of content size:

IT Pro wants to perform a 2^nd install to add Project to an existing Office 365 ProPlus installation on one machine. 

 

If we use SCCM on-premises only strategy:

SCCM will download full Office content from CDN ~2GB.  SCCM will then copy this content to all distribution points to support scenario.  Let’s assume an enterprise customer has 50 distribution points, 2 GB * 50 = 100 GB per month every month (build needs to be up to date as to not downgrade client introducing security concerns).  Office 365 ProPlus builds are cumulative, irrespective of channel, so this content changes each month.

 

If we use SCCM with Office CDN fallback:

SCCM calls ODT Setup.exe /configure to add Project, only ~41 MB will be downloaded from CDN. 

Make sure to use MatchInstalled parameter in your XML

We expect most customers will download and cache all Office 365 ProPlus content one time to existing machines to perform an upgrade to Office 365 ProPlus but once installed we recommend to leverage the lean technique going forward.

Having “lean” applications in SCCM also means they rarely need to be updated. An occasional refresh of the Office Deployment Tool (ODT) is good idea. (Less than 10 MB)

Tip: There are several ODT features which can benefit from approach (FallbacktoCDN, MatchPreviousMSI, MatchInstalled, MatchOS)

 

Proxy Challenge

To be clear, even if the lean installation is triggered by an admin user, it still requires the computer (System account) to be able to access the internet in order to support all installation scenarios.  Most of the customers we visit in the field prohibit computers from accessing the internet directly.  Typically, only Users can access the internet through a proxy server or via PAC file.  These User settings are defined as WinINET proxy setting you’ll find in Internet Explorer. 

Standard proxy configuration in Internet Explorer

So, what about the local SYSTEM account needed by SCCM?  If customers follow guidance to allow users and computers direct access to Office 365 endpoints, everything “just works”.  However, often we find customers only configure network proxy for Users and therefore the “lean install” scenarios fail. (Installation will hang as Office Deployment Tool running as SYSTEM process will fail when attempting to access Office CDN)

 

OK, what can we do to solve problem?  Configure additional proxy settings using Microsoft Windows HTTP Services (WinHTTP) and Background Intelligent Transfer Service (BITS) for System Account.   

 

Recommended actions

1. Configure WinINET Proxy for SYSTEM
2. Sync configuration from WinINET to WinHTTP

*In this way, we ensure one proxy configuration is set for WinINET and WinHTTP regardless of application caller and network API used.

In my lab I use PSEXEC.EXE to accelerate testing.

From elevated command prompt, run PSEXEC.EXE -s -i cmd.exe.  This will launch cmd.exe process in the SYSTEM context to simulate SCCM package etc.  Type whoami from command line to verify.

C:WindowsSystem32>whoami
nt authoritysystem

Sample commands to set WinINET and import into WinHTTP:

C:WindowsSystem32>bitsadmin /util /setieproxy localsystem MANUAL_PROXY proxy.contoso.com:8080 ";*.contoso.com"
C:WindowsSystem32>netsh.exe winhttp import proxy source=ie

Sample commands to reset:

C:windowssystem32>bitsadmin /util /setieproxy localsystem RESET
C:windowssystem32>netsh winhttp reset proxy

The proxy servernetwork team should only allow computer access to internet URLs as defined by Office 365 URLs and IP address ranges document as well as any other URLs that they want to explicitly allow the Computer account to access.

 

In summary, configuring a SYSTEM proxy enables adopting a “lean” Office 365 ProPlus deployment strategy which can greatly reduce complexity and cost of ownership to operate Office 365 ProPlus. 

 

Additional Reference Documentation on proxy configuration for Windows

Use Group Policy to apply WinHTTP proxy settings to Windows clients

bitsadmin util and setieproxy