Yesterday I wrapped up the deployment and proof-of-concept of deploying Office 2010 with SP1 via System Center Configuration Manager 2007 R3. It was a nice one: branch distribution points, client deployment in a mature XP network, etc.
Here’s a rough idea of what I did:
- Install a site server in the central site. Local SQL installation to make backup/recovery more manageable via the ConfigMgr backup task. Boundaries were defined (the IP subnets in the ConfigMgr site). Enable auto discovery from AD every hour. Small network (by ConfigMgr standards) and it’s good to get changes frequently if using groups for collections.
- Deployed branch distribution point in the local site. I set the sample one up as a protected BDP. This associates the subnets of the branch office with the BDP, restricting access to clients in that site.
- Deployed some ConfigMgr clients to test machines by hand. I did not enable client push installation (proof of concept).
- Packaged Office 2010 using setup /admin. Note I used SETUP_REBOOT in the setup properties (Office Customization Tool) and set it to Never. This prevents Office 2010 setup from rebooting the machine if previous versions of Office are running during setup. If this situation occurs, Office 2010 setup would reboot the PC with no notice to the user – bad! Instead, I’ configured the package program to let ConfigMgr reboot the PC (no matter what – probably not a bad thing anyway).
- Slipstreamed Office 2010 Service Pack 1 into the package.
- Distributed the package to the Site Server’s distribution point and to the BDP. Force the BDP to download the package by running the BDP maintenance task in the BDP server’s Configuration Manager client (Control Panel).
- Setup up a proof of concept collection.
- Advertised the package setup program to the collection. Forced policy refresh on the test machines by running the machine policy refresh in the ConfigMgr client (Control Panel).
- Sat back and watched the goodness.
For production deployment:
- We wanted to restrict client deployment impact on the network. I copied the client setup files into SYSVOL and created a .bat script to run CCMSETUP with the flag to define the site name. That would copy the ConfigMgr client setup files to DCs in every site. I setup a GPO to run a startup script that would execute this .bat file. That GPO could be linked to appropriate objects in AD to force setup of the client on machines. They’d install from the local SYSVOL and eliminate any WAN impact. Eventually, the GPO can be removed/unlinked, and client push installation can be enabled, thus hitting those last few machines that haven’t rebooted (to get the startup script to run) or any new machines that are added to the domain. I also find that this scripted solution tends to get me better results in a mature XP network.
- Office 2010 is to be deployed 1 site at a time. The AD sites/OUs don’t match the physical sites (not all that unusual) so I setup a collection definition where: (system role = workstation AND (network configuration IP address = 192.168.1.% OR network configuration IP address = 192.168.2.%). This will include all XP (or later) PCs on the site’s subnets in the collection, and exclude server machines.
From there, a new advertisement can be created to run the Office 2010 SP1 install at a pre-scheduled time. ConfigMgr reports can be monitored to see which exceptions (problems) need to be dealt with. The clients in the site will install from the local BDP.
For following sites, one at a time:
- Add the branch office subnets to the ConfigMgr site boundaries.
- Install a BDP and protect it with the site’s subnets from the boundaries list.
- Distribute the Office 2010 package to the BDP.
- Create a new collection specifying the subnets with the % wildcard.
- Advertise the Office 2010 package program.
For something like this, you need to test, test, test. You cannot test enough. Sounds like a lot of work, but your up front time investment saves a bunch of time and money on the back end, versus a manual install to hundreds or thousands of PCs. This works out being not so bad if you license intelligently too: ConfigMgr + SQL combined with a (desktop) Core CAL Suite (includes a bunch of CALs and a ConfigMgr management license). And after that, you have a fine solution in ConfigMgr to manage the entire life cycle of the PCs you manage:
- Zero touch OS image deployment
- Software deployment
- Patching (MSFT and third party)
- Desired configuration management (2012 adds auto rectify)
- Software/hardware auditing
- License auditing/usage measurement
- Power monitoring/policy enforcement (saving money!)
- 2012 also adds “user centric computing” and Android/iOS device management
- Reporting on more than you could dream of … all the way to identifying those machines that you need to replace.
- And Dell/HP are fully invested in it as a solution, recognising the power it adds for their customers.
Jeez, I’ve totally gone over to the dark side of sales 
Despite that, I love ConfigMgr; it allows me to play out my megalomania fantasies, even if they are limited to absolutely everything in the AD forest that I can get a ConfigMgr client onto.