Sign up for Office 365
Learn more about Office 365
Originally published to the Office 365 Preview blog.
Office 365 ProPlus offers flexible software delivery options to suit organizations of all sizes and desktop service architectures. From small businesses where users often install their own software, to large enterprises where hundreds of applications are centrally delivered by the IT department to every user, Office 365 ProPlus installation adapts to your processes and workflows.
Self-installation of Office 365 ProPlus allows users to install Office on their personal PCs directly from www.office365.com. After the administrator has created the user account, the user can log in to the Office 365 service and install Office 365 ProPlus. Users will need to be local administrators on their PCs when self-installing and the installation will always be the most up-to-date Office build and be enabled to receive automatic updates.
When the user initiates the installation, a small setup file (roughly 400 KB) is downloaded and run from the local PC the filename (for example: Setup.X86.en-us_ProPlusRetail_56f7d927-5bf8-435e-a240-9eaeef2f53c5_.exe) contains the installation parameters and what is loaded from the content delivery network site (http://officecdn.microsoft.com/) where Office installation files are stored.
Software installation page in Office 365
Self-installation may be appropriate in certain organizations where users have administrative privileges and are expected to install their own software. Self-installation rights may also be provided in well-managed organizations where users by definition cannot install software on managed computers, but are given access to Office 365 ProPlus installation on home or personal PCs. Administrators may also centrally disable the right for user self-installation, but this is a global control within the Office 365 Admin Portal and will apply to all users in the tenant.
Process for managed self-installation or home and personal device installation in a managed environment
In the process flow above, the IT administrator may optionally define Office configurations using local configuration management tools like Group Policy prior to publishing self-installation steps to end users. End users will be responsible for installing any required add-ins, dependent applications or standardized Office templates if needed and in the self-installation scenario, users are by default configured to receive automatic monthly updates from the Office 365 service.
Most large organizations use enterprise software distribution or image-based deployment automation to install software on behalf of their users. Office 365 ProPlus enables these tools and processes to install Office either from the network or with support from the Office 365 online service. As with the download process the Office Deployment Tool uses setup.exe to install and configure Office 365 ProPlus. These tools are designed with flexibility in mind so an administrator can point the setup engine at local, network or Web-based file sources.
The configuration XML file governs the installation process to determine what products, architectures, languages, and versions are installed and from which sources. It also allows the administrator to suppress installation and first run experiences, accept licensing agreements on behalf of the user, determine where installation logs are stored, enable or disable automatic software updates and configure where Office looks for updates.
Process for on-premises software delivery of Office 365 ProPlus
With these tools you can follow classic enterprise software distribution approaches where software installation files are installed via local cache or directly from the management or distribution point. New to Office 365 ProPlus is the ability to distribute just the setup.exe file and instruct that Office Click-to-Run packages are installed from the Office 365 online service (http://officecdn.microsoft.com/). This is a great scenario in off-LAN situations when VPN connectivity to a management point is slower than the target machine’s connection to the Internet.
Because installations are usually much faster than with previous MSI-based packages, deploying Office pre-installed in a custom Windows image will not save as much time as with previous Office releases and it allows you to pre-cache Office Click-to-Run builds with multiple language support within a captured Windows image (WIM) file, then use scripting automation or your favorite task sequencing engine to install Office directly from the local file source within the WIM file. It is also recommended to install Office native to the language of the operating system as opposed to using language packs atop the EN-US installation of Office, but both options are still possible with Office 365 ProPlus and Click-to-Run.
The configuration XML file governs both what is downloaded and how Office Click-to-Run is applied to the target computer. The controls relevant to using setup.exe /configure are the following.
Parent control to determine source, architecture, product and languages to download.
From local folder:
<add SourcePath="%deployroot%\applications\Office365" OfficeClientEdition="32">
<Language ID="en-us" />
From local network:
<Add SourcePath="\\Server\Share\Office\" OfficeClientEdition="32" >
Used to uninstall Office products.
Multiple products may be nested under the <Add> control and multiple languages may be nested under the <Product> control.
Office 365 ProPlus
<Language ID="en-us" />
<Language ID=”ja-jp" />
<Language ID=”es-es" />
Location where the Office is installed from. If SourcePath is unspecified, setup will first look for installation source in the local folder and if not present it will look to the CDN source.
<Add SourcePath="%Applications%\Office\" OfficeClientEdition="32" >
<Add SourcePath="C:\Source\Office\" OfficeClientEdition="32" >
<Add SourcePath="http://source. contoso.com/Office" OfficeClientEdition="32" >
Determines the architecture of the product to download, 32 or 64 bit. Note: 32-bit is still the recommended architecture for new Office versions. Cross-architecture installations are not permitted; if a 32-bit Office version is already installed on a system, the 64-bit Click-to-Run package will not install and vice versa.
Language determines the language DAT files to be downloaded with the Click-to-Run package.
<Language ID=”ja-jp" />
<Language ID=”es-es" />
<Language ID="en-us" />
<Language ID="fr-fr" />
Configures automatic updating behavior. Updates may be either from the public Office 365 service, local location, local file share or private http:// site.
To use a local file share:
<Updates Enabled="TRUE" UpdatePath="\\Server\Share\Office\" />
To use the CDN:
<Updates Enabled="TRUE” />
<Updates Enabled="False" />
Set to determine the installation display experience. Level options are None and Full. You can also accept the end user license agreement (EULA) on behalf of your users with the AcceptEULA command.
<Display Level="None" AcceptEULA="TRUE" />
<Display Level="Full" AcceptEULA="FALSE" />
The logging control lets you determine he log name and path where logs are written to.
<Logging Name="OfficeSetup.txt" Path="%temp%" />
<Logging Name="OfficeSetup.txt" Path="%deployroot%\smsosdlogs\" />
This command forces an install, uninstall or update. Office Click-to-Run updating is designed to be a background experience and updates are applied when a user closes and reopens the Office program. This property in the configuration file will force the operation without prompting the user, so there is some chance of data loss when programs are closed.
<Property Name="FORCEAPPSHUTDOWN" VALUE="1" />
This element is used when the installed version number is greater than the target version number. This would be used in roll back scenarios if you detect an issue that requires you to roll back to a previous version.
<Add SourcePath="\\Server\Share\Office\" Version=”15.0.4128.1014” OfficeClientEdition="32" ForceDowngrade=”True”>
My sample install.xml file contains the parameters to install the Office package downloaded in the previous steps. Version is omitted, so the latest version will be installed silently as 32-bit EN-US with additional parameters:
<Add SourcePath="\\YourServer\YourShareName\Office Deployment Tool\"
<Updates Enabled="FALSE" />
Setup command to install Office 365 ProPlus with the above parameters
%ProgramFiles%\Microsoft Office 15\ folder post installation
Once Office 365 ProPlus is installed, it will be interesting for those familiar to Office MSI-based installs to peruse the %ProgramFiles% directory and explore the files in place.
The primary virtual file system components are stored in %Program Files%\Microsoft Office 15\root\vfs and these locations help enable enough isolation so that older versions of Office applications installed via MSI-based packages do not conflict with the Office 365 ProPlus installation.
In simple terms, the Click-to-Run installation works by putting in the service to manage the virtual file system in the first few seconds of the installation (up to “10%” in the installation user interface progress screen) and the rest of the installation performs other required tasks to integrate with Windows and cache the files onto the local hard drive. At 10% since the installer hands off additional task to the service, the system account (interactive Session 0) manages the remaining processes to install Office. As of Office 365 ProPlus Preview, this also means that the system account needs access to the share or location where Office installation files are kept.
The flexibility in the deployment model means that anything capable of running an elevated command – with access to the file share or location where Office 365 ProPlus files are store – that process can perform the installation. You can use anything from login scripts to software distribution tools.
Office 365 ProPlus promises to be “always-up-to-date” in many ways and the design of the service is to not allow Office desktop applications to ever go more than a year out of date. For many users and in all self-installation scenarios, updates will stream regularly from the Office 365 public service. Managed organizations with Office 365 ProPlus have control over the update process to ensure that software updates do not introduce compatibility or similar issues prior to authorizing software updates for their managed PCs.
The software experiences and mechanisms for Click-to-Run also change fundamentally, as tools like Microsoft Update and corresponding MSP files are not involved in software updates. Likewise, management tools like Windows Server Update Services (WSUS) and products controlling WSUS like System Center Configuration Manager 2012 are not distributing software updates to Click-to-Run software running on managed PCs. Instead, to support the application virtualization underpinnings and enable unobtrusive, background updating a new software update management service and related options with been developed. In this model, the user will not see software updates being applied or forced to close applications – unless instructed to do so by the administrator distributing and automating the update. Updates are applied in the background and simply by normal use of closing and re-opening the Office program, updates are applied to Office.
How software updates are applied in Click-to-Run
The software update process in Click-to-Run functions by first discovering what is already installed, examining the updates being delivered and only applying the differential files. As an example for the software update, the installed Office programs may have 90% of the files in common with the updated build, so only 10% of that new build needs to be downloaded and applied to the already installed Office 365 ProPlus build. The high level process is that the administrator will push a software update to the PC, the Office update services in the PC will interrogate and discover which files are required to update the build, then deltas are applied in the background until fully-cached and once fully-cached the user simply needs to close and reopen the Office program in normal use for the updated build to apply. If the administrator decides the update needs to be applied immediately for security or other reasons, she can use the FORCEAPPSHUTDOWN property in the configuration file accompanying the new build. We will get into the options and mechanics of updates below.
Another fundamental difference compared to the MSI packaging and update model is that updates are cumulative update builds of the entire Office suite. That means if your organization with a tendency to only apply for example only the required or security-focused updates for Excel each month and wait until the Service Pack for optional updates and updates to other Office programs to be applied, this will change and required plus optional updates for all programs will be applied for a monthly Office 365 ProPlus build.
Automatic updates can be turned on or off and the user’s ability to access update controls are managed by Group Policy or the configuration file during installation for managed PCs with Office 365 ProPlus. There are three primary update options in Office 365 ProPlus:
Click-to-Run Software Update Options
Updates can be delivered via managed locations or enterprise software distribution. Most larger organizations with enterprise software distribution will likely use the option of rerunning setup or in some cases relative file paths to manage software updates. The same update process for applying only delta files is consistent with rerunning setup.
Automatic updates are default enabled with Office 365 ProPlus installations. They can be turned on or off and managed by Group Policy or the configuration file during installation for managed PCs with Office 365 ProPlus. Automatic update services run daily to look for updates.
The targeted products to download within the <Add> command. Multiple products may be nested under the <Add> control and multiple languages may be nested under the <Product> control.
Includes the automatic updates state, update path and location. If unspecified, the download will look to http://officecdn.microsoft.com/.
<Updates Enabled=”TRUE” /> (Note: this is default and if unspecified will be configured)
<Updates Enabled="TRUE" UpdatePath="\\Server\Share\Office\" /> (Note: used when published to a managed location)
<Updates Enabled=”FALSE” />
This is the automatic update service and may be enabled or disabled. The service runs daily and examines the “%updatepath%\data\v32.cab” or “%updatepath%\data\v64.cab” and contained versiondescriptor.xml file to check for the authorized or most recent build available to apply updates from.
<Updates Enabled="TRUE" UpdatePath="\\Server\Share\Office\" />
This is part of the Updates control and can be a UNC path (hard or relative), HTTP or local file path. If automatic updates are enabled, this optional path tells the service where to look for updates
<Updates Enabled="TRUE" UpdatePath="%OfficeUpdateShare%\Office\" />
<Updates Enabled="TRUE" UpdatePath="http://contosocdn.contoso.com/updates" />
The Office update service runs as a scheduled task daily to check the specified update location or the Office 365 service (http://officecdn.microsoft.com/) if left unspecified. You can control the update path to configure where the update service looks for updates. If you disable updates, then updates must be applied by rerunning Office setup.
Administrators can direct the update service to look at a managed file source to apply new builds of Office 365 ProPlus. The UpdatePath control described in the configuration XML file controls where the update service looks for software updates – this may be a local, UNC or HTTP path. By using the UpdatePath, the administrator is electing to not use the most up-to-date builds available on the Office CDN service. It also means the administrator is responsible for downloading updated builds and copying them into a highly available and central file share or HTTP location. This option suits organizations when PCs can access a file location with low latency. It can also be used in more dispersed environments with relative paths and managed file replication services, but most large organizations with enterprise software systems will opt for distributing updated builds as new software installations or packages.
The UpdatePath contains data and files downloaded from the Office CDN service. They can be downloaded automatically using scheduled tasks to download the most updated version or version numbers can be specified when downloading Office 365 ProPlus builds. A KB article will be published to support.microsoft.com with available build numbers as they are published, but it will be simpler for most administrators to define a scheduled task to download builds into an Office 365 ProPlus source folder in an organization’s software library.
The when running the “setup.exe /download configuration.xml” file without specifying a build number, it will download the contents of the Office\Data\ folder as depicted below:
Office Data Folder with contents from multiple Office 365 ProPlus builds
The v32.cab or v64.cab files – corresponding to Office architectures – are used by the update service to discover the newest or validated build of Office 365 ProPlus to be applied. These cabinet files contain a hash.txt and versiondescriptor.xml to indicate by default the newest build, but can be modified to point to validated or tested builds using the backup files (example v32_15.0.4128.1009.cab) by copying and renaming the backup cab file to “v32.cab” or “v64.cab”. When the administrator downloads new Office builds from the Office CDN service, it downloads a new v32.cab or v64.cab, the corresponding backup cabinet files and the folder with the build version specified. It is important that the folder names with the corresponding build versions are not renamed to ensure paths resolve during installation or software updating.
The software update service runs the equivalent of Office setup to download and apply Office program cache from the public or local file locations defined via the UpdatePath control in the configuration XML file. In large organizations with enterprise software distribution (ESD), there may be several software distribution or management points where the ESD agent will look for installation file source. In these environments, it may be difficult to define an UpdatePath valid for all users and in many cases, you may not know the management point location assigned to the PC’s ESD agent. Instead of writing to inject the path of the management point dynamically into a configuration XML file just before installation time, the better approach will likely be to rerun Office setup for each software update. In this case, the administrator will set the Updates control to be disabled (<Updates Enabled=”FALSE” />) to disable the daily scheduled task to look for Office software updates. In this case, Office 365 ProPlus will remain on the same build initially installed until setup is rerun with a different build number.
When using the option to rerun setup, it is advised to run update installs from the management or distribution point versus pre-caching updates on the PC prior to initiating the update installation. The reason for this is that the update package will be the size of a complete Office 365 ProPlus install – around 1 GB – and if your organization manages ten thousand users that would mean 10 TB of network traffic to pre-cache updated and tested Office builds to be used as file source for Office updating. If you install the updated build from your distribution points, then you can avoid the majority of that network traffic. A good rule of thumb would be to perform the initial installation from local pre-cached file source and use a network location, the cloud service or management point to perform software updating.
Another option you can use with ESD is to just deploy the setup.exe along with its corresponding configuration XML file and direct Office setup to the public Office 365 service for installation file source. This hybrid scenario then limits the amount of information delivered by an in-house software distribution mechanism and leverages the Internet to perform much of the heavy lifting and large file caching operations. The administrator still controls the Office version applied and in cases where VPN connections to the network are challenged but needs to transfer much less information directly from the network – about 500KB per PC.
Hybrid delivery of setup and configuration files with installation or updates delivered from the cloud
Administrators will have about a one-year time window of time to test and validate Office builds and can run Office setup to determine the build number to install on users’ PCs. In many cases, organizations will elect to not distribute every updated Office 365 ProPlus build and instead elect to suspend or disable automatic updates. In this context, the administrator can use either the method of defining the UpdatePath and keeping that location up-to-date with builds at they become tested and validated or distributing Office setup packages and rerunning setup for software updates. The administrator maintains control and can determine which builds are deployed – with the option to skip a maximum of 11 months of builds between each update. Monthly update cadence is recommended in this model, but in some cases if there is not enough time for adequate testing or compatibility issues are detected, administrators may skip deploying updates into production until they are ready.
For more information about Office 365 ProPlus configuration, read the Click-to-Run for Office 365 Configuration.xml file and Customization overview for Click-to-Run articles on TechNet.
241 Microsoft Team blogs searched, 68 blogs have new articles. 204 new articles found searching from
Good morning, hello to all our regular readers and hello to anyone joining us for the first time.
Aunque sigo teniendo mi opinión respecto a dar también a la suite de Office en la nube el nombre de Office
We are just testing Office365 in our company. This is a great article, thanx a lot!
In case you missed it, Jeremy Chapman (Senior Product Manager at Microsoft for Office) has a series of