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 3rd option, "SCCM with Office CDN fallback" or "Lean Install".
Lean install examples:
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.
Office may need to be reconfigured to make changes to Office deployments without changing the version, like adding a language or Project/V.... 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 2nd Install Scenario in detail in terms of content size:
IT Pro wants to perform a 2nd 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.
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.
Tip: There are several ODT features which can benefit from approach (FallbacktoCDN, MatchPreviousMSI, MatchInstalled, MatchOS)
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.
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.
*In this way, we ensure one proxy configuration is set for WinINET and WinHTTP regardless of application caller and network API used.
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.
Sample commands to set WinINET and import into WinHTTP:
C:\Windows\System32>bitsadmin /util /setieproxy localsystem MANUAL_PROXY proxy.contoso.com:8080 ";*.contoso.com"
C:\Windows\System32>netsh.exe winhttp import proxy source=ie
Sample commands to reset:
C:\windows\system32>bitsadmin /util /setieproxy localsystem RESET
C:\windows\system32>netsh winhttp reset proxy
The proxy server\network 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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.