In the previous blog posts we got to the point of being able to pick and download a particular build of Office 365 based on one of the available channels. In this post we’ll essentially go through the basics of how to deploy the Office 365 “media” downloaded, then in separate blog posts I’ll show it wrapped for ConfigMgr and Altiris.
Again, keep in mind the whole point is to deploy an OLDER version of Office 365, so that we can then turn around and scan the install, find it “vulnerable”, be able to use that in a lab/demo environment, and then ultimately use the management tool of choice to update the Office install to the appropriate current version.
If you need to re-visit any of the previous blog posts, here’s a quick summary;
Part 1: Office 365 ProPlus Testing, the pickle
Part 2: Office 365 ProPlus Testing, the basics
Part 3: Office 365 ProPlus Testing, getting the bits…
As I eluded to in part 3, the nuts and bolts of both downloading as well as installing – or technically even updating the software is controlled largely by the configuration.xml file. In it we configure what product(s) we’re installing, if we’re excluding any of the individual Office pieces, as well as items such as source location, update behavior, etc.
For the purpose of this article, I want you to think of the deployed content as a static package. We’ll end up essentially copying the entire install media to a local package cache (using either ConfigMgr or Altiris), then perform the install locally. What this also means, is that the source is not really a dynamic content location – it’s a fixed set of files, that allows us to deploy the exact bits we’ve wrapped in the application delivery package context.
This approach is likely what you’d want to do, if you deployed a “current” version of Office 365, you’d create application packages periodically with the static content, roll it out through your ConfigMgr DP or Altiris SS infrastructure and let the clients have fun with the install locally. There are obviously other ways to doing it, and some may ultimately be better in various scenarios – but for now I’ll keep it simple, and just deal with the idea of the static package delivery.
What we need to know for deployment
Let’s refresh what the directory structure looked like for our downloaded media/install files:
The root of our directory contains the setup executable, the configuration.xml file as well as an Office subdirectory. As we drill into the Office subdirectory further we see:
Inside the Data directory we see a small cab file containing information on the build as well as an additional subdirectory labeled with our build number (7369.2055), that was downloaded in a previous post. What we also see, is that the main content for O365 is contained within:
Essentially we have two files the “stream.x64.en-us.dat”, which I assume is the english UI content, and then the stream.x64.x-none.dat, which I assume is the main O365 content for all languages. In this scenario we’ve only specified “en-us” as the language in the configuration.xml, but my expectation is additional languages would simply add additional language specific .dat files, allowing a moderate growth in the over-all content size.
To summarize the method of deployment here’s the command line parameters for the setup tool:
That means we essentially need to run the command line “setup.exe /configure configuration.xml” to perform the installation of O365. In my previous post Office 365 ProPlus Testing, getting the bits… we looked at some of the elements, look there for a summary and additional content.
Here is the configuration.xml file that allowed us to setup the media for O365, 64-bit, version build 7369.2055 of the (not so current) Current Channel:
[code language=”xml”]
<Configuration>
<Add OfficeClientEdition="64" Version="16.0.7369.2055" Channel="Current">
<Product ID="O365ProPlusRetail">
<Language ID="en-us" />
</Product>
<Product ID="VisioProRetail">
<Language ID="en-us" />
</Product>
<Product ID="ProjectProRetail">
<Language ID="en-us" />
</Product>
</Add>
<Display Level="Full" AcceptEULA="TRUE" />
<Logging Level="Standard" Path=".\ODTlog.log.txt" />
</Configuration>
[/code]
Also included is Visio and Project, as well as logging and acceptance of the EULA, so no prompting will be performed.
If you payed a lot of attention to the previous blog-post you’d know there are additional configuration elements for adding a SourcePath and UpdatePath, however as we’re using an entirely local install source, and for both ConfigMgr and Altiris, where we utilize a “local package cache” both have a semi-random location. In ConfigMgr it’s random across the environment, in Altiris it’s technically a “known cache location”, but in both scenarios the default behavior of the setup application saves us. Be default if no SourcePath is defined within the configuration.xml it will assume the base path of where the setup application was executed from as the source location for the install bits! This means we simply run the “setup.exe /configure configuration.xml” command stated above, with the configuration.xml above and all will be good!
To read about how to configure the deployment for ConfigMgr or Altiris:
Part 5 – Deploying O365 with ConfigMgr (coming soon..)
Part 5 – Deploying O365 with Altiris (coming soon..)
References
O365 Deployment with ConfigMgr: https://technet.microsoft.com/en-us/library/dn708063.aspx
Deploying O365 from local source: https://technet.microsoft.com/en-us/library/jj219423.aspx