More Windows Intune documentation has hit the Microsoft download center, this time it’s the What’s New in the Windows Intune April 2012 Pre-Release document.
The document covers the following information, which gives a pretty good idea of where Windows Intune is heading.
Greater Control with a New Sign-in Service
Updated and New Administration Consoles
Mobile Device Management
The Windows Intune Company Portal: A New Self-Service Portal for Your End-Users
Enhanced Group Management
Integration with Microsoft Active Directory Domain Services Recommended Policy Settings
Mobile Security Policy
Improved Alert Customization
New Updates Views for Update Compliance
Automatic Windows Intune Client Software Removal
^ Scroll to Top
Mentioned in the pre-release document in the last post, the Windows Intune April 2012 Pre-Release Online Help is now available, here are the links to currently available topics. Enjoy!^ Scroll to Top
Seeming to fulfill many of the predictions that there will be a new Intune beta available during the Microsoft Management Summit this week, the Windows Intune April 2012 Pre-Release Getting Started Guide is up on Microsoft’s download pages, ready for your consumption.
Stay tuned in as we analyze it and eagerley await our beta invite to come through!^ Scroll to Top
Microsoft has had some information on using MDT 2010 to build operating systems with the Windows Intune client installed already, but I thought it was worth taking a look at the process in MDT 2012 RC, and an approach for partners who may need to build images for several of their clients.
Two of the critical things to remember when deploying the Windows Intune client to new computers is that it needs internet connectivity to complete the installation. If you want to keep your build environment isolated from your production network, take a look at some of my previous posts on Threat Management Gateway as a potential solution which also offers other benefits.
The second critical thing to remember is that you can’t deploy the Windows Intune client and then run sysprep prepare for an image capture, as the machine will have already registered itself with the Windows Intune service.
Here’s a step by step guide to adding Windows Intune to your MDT 2012 RC environment.if you need to create an image for capture which includes the Windows Intune setup files and runs them after the Windows Out of Box Experience (OOBE), stay tuned, I’ll cover that in an upcoming post.
What I’ve done here is created three separate folders, each with the Windows_Intune_Setup.exe and WindowsIntune.accountcert file for three different fictitious companies I need to deploy Windows 7 to.
As we drill into the Contoso folder, you see the files for Contoso including their unique certificate.
If you right mouse click on Applications, you will see the New Application shortcut. Click this to add Contoso’s Windows Intune install to MDT 2012.
Here we choose Application with source files.
Now we can populate the details. Technically this is not the V2 client, but using a naming scheme that is consistent and easy to recognize for ease of updating in the future if Microsoft releases a new install package.
Here I have selected the Contoso folder for the source files.
We can change this folder name if we like, or alternatively you could follow a folder structure such as WindowsIntuneClient\Intune Client 1 etc to prevent the root applications folder from getting too cluttered.
Running the Windows_Intune_setup.exe with the /quiet command ensures it runs in an unattended manner.
You can quickly review the summary to ensure that everything matches your goals.
And finally we can see the progress and save the output for documentation purposes.
Next up we need to add a command to a Task Sequence to install the client, which we can do by going to the properties of the Contoso Task Sequence I had created earlier.
At first you are presented with the General tab, but it’s the Task Sequence tab that we need.
On the Task Sequence tab, we choose install a single application.
And then we can hit OK and we are ready to go!^ Scroll to Top
For all the praise that Windows 7 has received since it’s release, there’s still a great deal of Windows XP out there. You see it on people’s laptops in cafes and on planes, you see it in kiosks, you may have it in your own environment or see it when you visit your customers.
The benefit for partners
One of the big benefits of Windows Intune for the Microsoft partner community is that they can target many of their non-Software Assurance (SA) customers to the latest version of Windows on the desktop, which otherwise may not have been a regular topic of conversation. For those of you who have been in the IT game for a while, you probably remember that back in the pre-Windows XP days, desktop upgrades, especially for the SMB market, were something that was more regularly done. Not necessarily in the same timeframes as Microsoft’s much more aggressive release cycles back then, but more regularly than today.
Most SMB customers don’t have SA on their desktops, which means retail upgrades are usually the option that needs to be investigated when new versions of Windows are required for upgrade scenarios, but for many of these customers the Enterprise upgrade within the Windows Intune subscription provides a good alternative.
Two main things went wrong. Firstly the long delay between the release of Windows XP and the release of Windows Vista. Users got extremely comfortable with the Windows XP interface, and the technical teams that deployed and supported new versions of the OS got extremely adept at using the Windows XP deployment and management tools. Microsoft allowed XP and its ecosystem to become the status quo.
The second piece of the problem was Windows Vista itself. The initial release, along with the drivers that were available at launch time, left a great deal to be desired. Over time though, Windows Vista’s performance did get better, especially in the time leading up to and including the release of the first service pack. Microsoft’s anemic hardware requirements and recommendations also hurt that initial release, and some machines that were shipped as Vista capable were far from it.
By the time these performance issues were addressed, it was too late for Vista to succeed, no matter how Microsoft marketed it. IT departments breathed a sigh of relief as it bought them a few more years of being comfortable with their existing environment, and users were happy as they didn’t have to migrate and learn anything new.
During this time I was working a great deal with Microsoft’s OEM partners on the Vista OPK (the OEM version of the WAIK), and faced similar challenges here too. The resistance to moving across to new tools and deployment methods impacted their production images which they had been perfecting for years. Changes to unattended setup and a different approach to imaging and testing were just some of the issues OEMs had to overcome.
What was the impact?
For those who watched the Vista experience without getting involved, they missed some major updates to the support and deployment tools, so by the time Windows 7 was on their radar, they really had a great deal of learning to do. For those who had deployed or at least tested Vista in a limited scope, the learning curve was smaller.
This again meant that some felt alienated by the changes on the administration and deployment side clung to their XP world, while others rejoiced that they finally could see a valid replacement for the aging OS. The good thing for both groups though was that tools like the MDT and it’s forerunners got easier and more powerful, so the learning curve for new deployments continued to get easier.
Why isn’t everyone on Windows 7 already?
The list here is long and varied depending on who you talk to, but it may be as simple as time and money for some. For others it could be application compatibility issues that they fear. Others just may not care, happy to let their Windows XP environments run themselves into the ground before investigating alternatives.
Obviously you don’t want to have to work with those in the last category, as it means a rushed deployment of a new environment that is going to an absolute headache for all involved. Planning an upgrade, or in this case I prefer to see it was a migration, from XP to Windows 7, takes time and testing if it is to be a smooth process. Software and hardware compatibility testing , user training and more should all be part of the larger test plan.
What’s the solution?
Well, Windows Intune isn’t the answer for everyone looking to get Windows 7 licenses. If someone already has a management solution and anti malware software in place that they are happy with, they should perhaps look at some of Microsoft’s licensing programs to see what best suits their needs.
For those keen on Windows 7 now and needing the additional cloud services that Windows Intune provides, it should definitely be investigated. For those keen on Windows 7 upgrades, but getting distracted by all of the Windows 8 activity, Windows Intune is still a great option because the upgrade to Windows 8 is something that Intune subscribers will be able to take advantage of. Sure, it may not be an automated deployment through the cloud onto their desktop, but not too far into the Windows 8 release cycle I’m pretty sure this is going to be one of the options on offer, just make sure to bring your own Internet connection.^ Scroll to Top
It wasn’t until I was responsible for overlooking Asia Pacific in a previous job that I realised how much easier I had it being a native English speaker in a country with English as the primary language as far as the IT world went. The sheer volume of content that is available in English by default, and then translated to some other languages if someone is willing to fund it, combined with the ability to read and process the available content, were really something that I had taken for granted.
The Microsoft Desktop Optimization Pack (MDOP) 2011 R2 Language Update is now available to MSDN and TechNet subscribers, as well as Volume License customers. This release contains localized versions of Diagnostics and Recovery Toolset (DaRT) 7.0 and Microsoft BitLocker Administration and Monitoring (MBAM). Languages included in this update are: English, French, German, Italian, Japanese, Korean, Portuguese (Brazilian), Simplified Chinese, Traditional Chinese, Russian, and Spanish.^ Scroll to Top
Mentioned in my previous post which highlighted DaRT as a valuable MDOP component for all types of Windows Intune customers, there is great news that the DaRT 8 Beta sign up is now open.
Head on over to the sign up page on Microsoft Connect to check out the the Diagnostics and Recovery Toolset (DaRT) 8 Beta’s support for the Windows 8 Consumer Preview compatibility, new hardware platforms, an updated image creation wizard, as well as native USB deployment support.
Check out the DaRT8 Beta Q&A for more information.^ Scroll to Top
Continuing on the theme of the last few posts and updating and distributing software via Windows Intune, I thought it was time to address a few of the issues I’ve encountered since working with Windows Intune. These may be publically documented, but if so, I haven’t seen the links yet.
The first mystery I encountered was the discrepancy between the traffic showing on the client NIC properties during the update process. The best way to explain this is that it seems that Windows Intune will front load many of the updates that are approved for that machine, even if they aren’t going to be installed this time round. This means that if you really wanted to monitor the traffic, you need to do it prior to each reboot, and sum it up for the total traffic received. Otherwise you will see scenarios where there is almost no traffic generated for a large number of system updates which appear to have been downloaded to install.
There was one file in particular which highlighted what was happening, and that was the Windows 7 SP1 file being copied into the C:\Windows\SoftwareDistribution folder a reboot or two before it’s installation. My aggressive update and update auto approval is heavily responsible for the amount of traffic generated, but the end result is still good.
That also confirmed something I was curious about, which was how Windows Intune treated the SP1 installation. Was it like Windows Update, where it would determine what updates were actually required, or the WSUS approach of giving the client the full binary for installation. In this case, it’s the full installation, which aligns more with the view that Windows Intune’s update approval process is like WSUS in the cloud, with Windows Update really just providing the back end infrastructure.
The second mystery solved was the problematic KB2523130 hotfix. Turns out that it isn’t required once Service Pack 1 of Office 2010 is installed, thus the high number of install failures I was seeing with it. This also reinforced my view around staying away from monolithic installation approaches, I’ve removed this update from my managed software list without any need to create or update any existing packages.^ Scroll to Top
As I was uploading Office 2010 Pro Plus (from the Office 365 subscription), I noticed that Office 2010 Service Pack 1 was not part of the update. At first this struck me as a bit odd, considering that you would normally want the users to receive the latest version of the software, but after some consideration, I decided it’s the better approach to only distribute the RTM version.
Why was this? There are several reasons I can think of immediately, possibly more once I’ve had time to think about it some more.
What if the users only need Office 2010, not Office 2010 SP1?
This is the best way to deal with any application compatibility issues that may have arisen between the RTM and SP1 versions for a custom add in, for example. Granted, I don’t think this is really the top reason, but listing too many different versions of Office 2010 for download in the Microsoft Online portal could get confusing. Just supplying the RTM version also means you only need one package deployed to your Windows Intune Software Distribution storage, and you can then use update approvals to determine which computers get moved to SP1, and which stay on RTM
Does integrating the patch save any time?
Office 2010 doesn’t slipstream the SP1 bits into the existing install, instead it runs the new updates after the initial installation from the Updates Folder. This may minimise the delay between when SP1 gets applied, but it is still running the full SP1 installation.
Does integrating the patch save any bandwidth?
As far as bandwidth savings are concerned, making a large, monolithic install could have negative bandwidth implications. What if some of the clients already have Office 2010, and have done the SP1 update via Microsoft Update, and it’s already cached in your local proxy server? The monolithic package can’t take advantage of that, because it’s a different encrypted, compressed file.
Does this have an impact on future updates Microsoft releases?
It’s fairly safe to assume that there will be an Office 2010 SP2 at some point in the future. If we assume that the way to update the RTM install files to SP2 is to once again drop them into the Upgrades folder, do you want to go through this package and upload process again, or is it just easier to approve the updates via Windows Intune and let Microsoft’s distribution servers provide the files? That’s pretty easy if you ask me, just leverage Microsoft’s work, don’t reinvent the wheel.
Is it using my precious online storage for no reason?
The 20GB allowance that is currently provided with a Windows Intune distribution may be more than enough for some companies, but nowhere near enough for others. Before you start purchasing additional online storage, does it make more sense to remove bits that can delivered in smarter ways while leveraging Microsoft’s infrastructure.
What about integrating hotfixes that may not be available from the Windows Intune update service yet?
Again, keep them as separate packages. Once they go live, you can remove them from your managed software list easily. Decide on an easy to follow naming scheme that will allow them to be recognised easily.^ Scroll to Top
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.^ Scroll to Top