ConfigMgr and Office365 Click-to-Run

Like many organizations we are migrating towards cloud offerings where it makes sense, and Office is no exception. With that said, we have begun transitioning from the MSI install of Office 2013 to  Click-to-run via Office 365 (O365). With my organization being global with lots of customization we had a choice to make in relation to updates. You have 3 basic ways of maintaining Office 365 Click-to-Run.

1. Get Updates from Microsoft Office CDN
2. Get Updates from local UNC Path
3. Package as App-V

All of these methods are well documented. For us we choose the second Option (B) which gives some control over its Updates vs the other two. With the first option it was all in the hands on MS, we were not comfortable with that as we have had troubles with Office patches in the past. While we have experimented with App-V, I was concerned about using it for Office due to its footprint since its on every machine and in constant use, especially for Outlook and Lync. I see us changing to the first method long term, as rumors abound about Office 2016 Click-to-run changing the update process.

Source

First part is to get the content which is covered very well so I wont really touch on it. Simply put, you call an XML against ODT to grab the content from the Office CDN. I created a simple shell script to download it at 2AM every Monday, Wednesday and Friday and email the results. Sometimes I'll manually run it such as on Patch Tuesday. One thing I don't like about ODT is it ALWAYS downloads the latest. Already got it? Here let me download that for you again. I would like it to check and not download the current version again if it already exists locally. Next version of the script will do some revision control and other ideas I have.

This content is managed on a File Server with 32-Bit and 64-Bit together. Originally these were separate but since you state the bit level via the install XML they were merged for easier management. We maintain the last 5 versions on site.

Replication

IMO we moved back 10 years with Office 365 Updates. No SUP, WSUS, MU, etc. It updates via a scheduled task that checks 3 times a week and after login. So for arguments sake, daily. Since we chose Option B we get it from a UNC path. Being global it doesn't make sense for O365 to go across the globe to some File Server so we used DFS so its "local". Reminded of FRS replication problems from my Modular Messaging days, I chose to have ConfigMgr do replication instead of DFS. Plus, we have these SCCM Servers all over with the content so I wanted to use that. In other words, DFS namespace folder points you to the closest source and SCCM servers are the Folder Targets.

Within SCCM we have a package with the following folder Structure at its root.

 Dev   - Future Use, if you have Test, you should have Dev.
 O2013 - Some systems had their MSOCache removed so the MSI O2013 content is here
 Prod  - Production
 PTG   - Patch Testing Group
 Test  - Testing

Under each folder you have the Office\Data structure. Nothing special. Currently PTG gets the updates a month before production, basically when released by MS. To gripe, I wish MS would have Feature Updates separated from Security Updates. Its rough making a client UI change. With MS releasing Skype For Business this month, it effectively has stopped us from updating O365 until we resolve Skype For Business. If they fix a zero-day next month, we'll have to choose between that and Skype For Business.

Skype For Business was released as part of the April cycle so its located under 'Test' while the Lync team tests it out and does anything they need to do before we let it loose. With how this folder structure was done, we can add more folders for testing, or O2016 release, or ...

O365 gets its alternative update path via HKLM\SOFTWARE\Microsoft\Office\15.0\ClickToRun\Configuration\UpdateURL. This points to the UNC path for the updates source. '\\my.domain.com\Updates\O365\Prod' for example but any Namespace root will work. Since they are all in the same place, just change 'Prod' to 'Test' or whatever. This path is set initially during install by the XML. More below on that.

For the package, there's no programs, just content. On the Data Access tab you check the boxes so it will publish have the content outside the Content Library via UNC.

This will let it behave similar to previous SCCM versions and place the content at \\SCCMServer\SMSPKGD$, whatever D is in your case. So now for DFS you add an entry for \\SCCMServer\SMSPKGD$\PACKAGEID. We also have 1E Nomad so you can use \\SERVERNAME\NomadSHR$\PACKAGEID_Cache in that case. We now have the O365 content at all DPs and end-points can pull O365 Updates.

Configuration

You can do this, but since its SCCM, we have to automate the Updates path also! We used Compliance settings to set UpdateURL in the registry.

Each Compliance Setting is setup very similar with the only difference being the UpdateURL UNC Path.

Under Settings we have the following:

For Compliance Rules we have this one rule:

Under Relationships we point to a Configuration Baseline.

For the Baseline we have the configuration data set.

And the following for the deployment to a collection. It checks and mitigates daily.

This in turn points to some collections. These are pretty simple in that for Prod its limited to the All Workstations Collection as well as excludes the other O365 Update Collections (Test, PTG, etc) and for the other non Prod ones, they each point to an AD Group that we put user objects into. Since we have a few Citrix Server installs, those are handled as well.

WorkFlow

Now that all this is setup the management is pretty easy. The Script downloads the new version, we get email its here. We then copy the version into the appropriate folder in the package and replicate it. Thats it. Clients will update O365 on their own from here. We could automate further as needed.

Side note on the folder structure. Point the UpdateURL to the root folder that 'Office\Data' will be in. The O365 update process will navigate down. Also, the v32_version.cab (or v64_version.cab) and v32.cab (or v64.cab) are the same file and are located in the Office\Data folder. Everything else lives under the version folder.

Office 2016 Click-to-Run Beta

The current version of O2016 Beta ODT only downloads the two main stream files for each bitlevel so you will have to manually download the following files. Be sure to change the version (16.0.3823.1010 shown below) to the version of choice. The structure and naming convention is the same as for O2013 bits of O365. You'll need to take the v32_version.cab (or v64_version.cab) and rename to v32.cab (or v64.cab and put up a directory under Data.

 http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be\Office\Data\16.0.3823.1010\i640.cab  
 http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be\Office\Data\16.0.3823.1010\i320.cab  
 http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be\Office\Data\16.0.3823.1010\i321033.cab  
 http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be\Office\Data\16.0.3823.1010\i641033.cab  
 http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be\Office\Data\16.0.3823.1010\s320.cab  
 http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be\Office\Data\16.0.3823.1010\s640.cab  
 http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be\Office\Data\16.0.3823.1010\s321033.cab  
 http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be\Office\Data\16.0.3823.1010\s641033.cab  
 http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be\Office\Data\v32_16.0.3823.1010.cab  
 http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be\Office\Data\v64_16.0.3823.1010.cab  

Download

This script is provided as-is, no warranty is provided or implied.The author is NOT responsible for any damages or data loss that may occur through the use of this script.  Always test, test, test before rolling anything into a production environment.

You can find the download script along with some download XML files referenced in this post here. You will need to tweak them for your environment. Additionally, you will need to download the latest ODT from Microsoft and blat.exe for email.

-Kevin

Driver is not applicable to any supported platform

"The selected driver is not applicable to any supported platforms."

Wait, what? We are on SCCM 2012 R2 CU3 (CU4 any day!) so we should not get something like this. Did I somehow get some secret Windows 10 drivers somehow? Lots of mis-written INF files? This is strange. 

In my last post I was talking about one time driver injection. We've moved past that as we liked the Toshiba device and decided to buy a large number of them so they need to be setup in SCCM. Initially, a Toshiba INF driver was mis-written to state it supported 64-Bit when the DLL it called for were 32-Bit only. BSOD's all around. After fixing that I still had to address this supported platform problem. While trying to import drivers we would get this error about several of them, mostly NIC drivers not being imported due to being unsupported . In the case of the Toshiba, the physical NIC did not import, however the WiFi driver imported, so after sysprep the Toshiba started imaging over the wireless interface. That was fun, I don't recommend that.

Looking at the INFs they were written in normal Intel fashion and even making some modifications to strip down to Windows 8.1 did nothing. Digging through the SCCM logs was not a ton of help either. AdminUI.Log, DriverCatalog.Log, SMSAdmin.Log, Setupapi.app.log, you name it. All just said the same thing, driver not applicable. Those actually gave an error code of 0x80070661.

Turns out the issue is due to our Site Server being on 2008 R2. Specifically with the OS. The signing in these drivers is using a newer method thats not native in 2008 R2. Microsoft released KB3025419  which states to install KB2837108 and KB2921916 to update the OS to support the newer signing method in ConfigMgr. Coincidentally both this KB and the Toshiba device came out at the same time. After applying the hotfix and restarting (not required but the KB states to do anyway) we are now able to import these newer signed drivers and image the Toshibas up successfully and quickly.

-Kevin

One Time Task Sequence Driver Injection

Its that time again, testing out new equipment. Today I am looking at the Toshiba PORTÉGÉ Z20t-B at the moment. Nice device IMO, pretty new. Traditionally we use DELL so the drivers provided via Toshiba  Laptop Builder are formatted different then the CABs that DELL Provides. While all our Task Sequences were created to be brand agnostic, we did have to create some structure to deal with another manufacture for the file system and driver store. Before that point though, I wanted to quickly image up a system to begin testing without doing the driver work in ConfigMgr. Just in case we don't like the device and have to remove drivers. This way we don't. It also allows me to image up a single random machine with our task sequence such as Apple or a white box type system.

In other words, this solution allows a tech to deploy a ‘one off’ machine and build their own driver package and drop it in the designated folder, and the imaging process would inject them and then use them.  

This howto assumes you are using USB to bootstrap the system so SCCM can deploy to it, however with PXE and Optical there are ways to do this via those methods.

On the USB thumb-drive we create a folder in the root call OneTimeDrivers. In this folder we put all the drivers for the device. Say the extracted .CAB from Dell or the extracted ZIP from Toshiba Laptop Builder.

For the Task Sequence, create a 'Run Command Line' step and put it with the Apply Drivers or Apply Driver Package steps that you use today. I do it after those as I have drivers grouped by virtual or physical then apply the Intel Chipset drivers, then the manufacturer drivers (previous posting.) 

 DISM /Image:%OSDISK%\ /Add-Driver /Driver:%_SMSTSMediaRootPath%\OneTimeDrivers /forceunsigned /recurse  

The step needs a condition. Choose 'Folder Properties' and set the path to '%_SMSTSMediaRootPath%\OneTimeDrivers'. This way it will check for the OneTimeDrivers folder and run if present.

Keep in mind you'll need to remove or rename this folder on the USB stick, otherwise it will run on equipment you don't want it to. Also of note, the variable OSDISK shown above is created from the Partition Disk step, which many people use in ConfigMgr and MDT. If you do not then you'll need to change OSDISK to where Windows is being deployed to such as 'C:\'.

For an Optical or PXE PE instance you could just do multiple folders for the first few volumes, say up to F for the condition. Unless your doing alot of volumes you should be fine. As long as the USB stick with OneTimeDrivers folder is present it will run.

-Kevin