As highlighted in previous posts, I’ve been following the advice of the Windows Intune team on setting up a caching solution, in this case ForeFront Threat Management Gateway as a means to accelerate the Windows Intune and Office 365 deployments.
What I’ve found is that the initial Windows Intune installation components that are installed don’t benefit greatly from the caching my setup. It seems to be hovering around 50MB for a Windows 7 Enterprise system that has been completely patched prior to the Windows Intune installation, but MS suggest it could be up to 120MB. The attraction is just how effectively it caches Windows Update and Microsoft Update downloads, as well as the packages that are being distributed via the Windows Intune online software distribution.
The simplest way to put it is that it works incredibly effectively in aiding the patching of multiple systems. Of course the more varied your Windows versions and service packs are, the more of a chance that there are some items that will be a one off download and hence not really benefitting, but overall you will still see some bandwidth savings.
Here are some numbers for those of you who like numbers. This is data I obtained from patching a bunch of Windows 7 Ultimate and Windows 7 Enterprise machines with varying degrees of updates installed..Note that a few new machines had already been using the cache at this point, so it had a head start.
Installing Windows Intune and allowing it to install all available updates on an RTM version of Windows 7 Ultimate would required roughly 1.5GB of data to the client, but only generated 165-205MB of Internet traffic. Windows 7 Ultimate and Enterprise with integrated SP1 generated 250MB of client traffic, but only 50MB of that came from the Internet, and that 50MB was the Windows Intune client downloads at the start of the upgrade process.
For a handful of machines these numbers are very impressive, but hopefully you aren’t encountering too many PCs out there that haven’t been updates since they were switched on. The other element in play here is that these are just the numbers for Windows Updates, I hadn’t gotten around to installing Office 365 Pro Plus yet, which was one of the requirements for these machines.
I downloaded the 32 bit Office Pro Plus installer from the Office 365 portal, extracted the files out into their folder structure, and then downloaded and extracted Office 2010 SP1 into the Updates folder, and created a package that was just under 1GB in size. After the lengthy compress and upload process in the Windows Intune console I realised that this really wasn’t the best approach, so I removed the updates and created the new package. I will discuss the reasoning behind this in my next post. The Lync client was repackaged and uploaded into the online storage space, a much faster process due to the smaller file size.
Then it was time to ensure that all of the required, applicable updates were made available through Windows Intune. The ones that aren’t currently available through Windows Intune are as follows.
Microsoft Online Services Sign-In Assistant – Needed to downloaded separately
KB2597011 – Hotfix not currently available via Windows Intune Updates, needs to be repacked and uploaded as managed software
KB2523130 – Hotfix not currently available via Windows Intune Updates, needs to be repacked and uploaded as managed software- EDIT - This update is included in Office 2010 SP1, so it isn’t required here
KB2597051 – Hotfix not currently available via Windows Intune Updates, needs to be repacked and uploaded as managed software
At this point the question becomes should we package them all up as one software package for Windows Intune to distribute, or should be upload them individually? I will go with individual, for reasons that I will outline in the next post. The Microsoft Online Services Sign-In Assistant is an MSI file, so we don’t need command line options for Windows Intune, while the other three, being hotfixes, all need to /quiet switch added before uploading. At this stage the Windows Intune Managed Software screen looks like this.
There are a couple of things that require further explanation at this point. The number of packages available has been minimised due to all of the clients being Windows 7 64 bit with Office 2010 32 bit installed. If I was deploying a 32 bit client OS, I would need the 32 bit Sign In Assistant as well as the 32 bit Lync client. If they were running the 64 bit version of Office 2010 they would need the 64 bit hotfixes deployed. This is just a small example of where implementing a standard desktop OS and application suite really does start reducing overhead, even in a simple manner if being compared to a full SOE.
Now that everything is prepared, it’s time to deploy the software to the appropriate computer groups, and for the first round of testing I just deployed it to a group with a single machine to ensure that all went smoothly. As you could imagine, the first time all of those software installs, as well as the additional Windows and Office updates they would trigger with my existing update approvals, the download process did take time, but then thanks to the caching, the subsequent installs onto additional PCs as I increased the deployment scope benefitted from all of the updates being delivered via the TMG cache, so the bandwidth savings were astronomical. There were a few teething issues with the hotfixes that I am still troubleshooting, but otherwise it’s been clear sailing.
Finally, going back to answer the question asked in the post name, just how effective is ForeFront TMG for caching Windows Intune? For approved updates and software distribution, the answer is outstanding. Having all of the patches and updates delivered out of the cache really does change how you can approach deployment moving forward. The initial deployment of the Windows Intune client pieces don’t really benefit, but the chances are that there are going to be some accompanying updates that will make that a non-issue for most people.