Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are looking into various Office 2010 deployment methods currently.

I was wondering what people suggest?

Currently I am doing it via start up script (ugh) as MS doesn't allow it to install via MSI and GPO.

SCCM is an option, but should I be looking into using App-V instead of SCCM ?

share|improve this question
Forgot to note that will be deploying to Win7 machines x64 only as well. – Kvad Sep 2 '10 at 1:27
Office 2007 to x64-based Windows 7 machines has been working fine for my w/ startup scripts, but I have yet to do Office 2010 to Windows 7 x64 machines. Having said that I'd imagine it'd work fine. – Evan Anderson Sep 2 '10 at 1:29
Ended up doing deployment via SCCM - updates handled by WSUS. – Kvad Nov 29 '11 at 4:10
I'd think of AppV as a complement to SCCM, not an alternative. We deploy Office 2010 as a local install to all machines using SCCM, but deploy some of the 'extra' Office apps like Project or Visio using AppV (controlled by AppV's SCCM integration). – GAThrawn Jan 17 '12 at 17:13
up vote 4 down vote accepted

I just got done deploying Office 2010 to about 1,000 PCs with a startup script and I'm quite happy with it. My Customer doesn't have any entitlement to App-V (or any "application virtualization / streaming") functionality, so installs on the "bare metal" were my only option. Amazingly, we had only a handful of installation failures, and those PCs turned out to be machines that were hopelessly out of date re: Windows updates.

I ended up creating a simple mechanism to allow the user to "opt in" their computer for installation by way of a web page that back-ended to a script which modified group membership for the "Office 2010 Computers" Active Directory group. (This was a K-12 school setting, and I wanted to insure that users weren't surprised by booting up their computer in the morning and discovering an Office 2010 installation starting up.) We set a "line in the sand" date when their computers would have to be updated and most of the users complied happily.

Laptop computers with "iffy" wireless network connectivity and/or AC power were a bit of a challenge, but the opt-in mechanism and a note to users to let them know that they should choose a deployment time when they were connected to a wired port and AC power helped. I don't think we had any failures as a result of laptops with bad network connectivty or losing power, but we probably only have 50 laptops out of 1,000 PCs.

The opt-in script certainly wasn't the most secure thing in the world, but it was only necessary for a limited time and the worst ramification was that a user, I suppose, could opt-in somebody else's computer. (I'd post the code, but as with so many things, it was written as a work for hire for my Customer so I'd have to get their permission. I knocked it together in an evening, so you certainly could too.)

share|improve this answer
I'm bit over the whole doing things on the cheap method ;) But glad to see that it has worked great for you. – Kvad Sep 2 '10 at 1:27
@Kvad: It's not so much "on the cheap" for me (though that often helps) as fear of giving up control of the deployment process to a black-box tool. A startup script-based deployment is easier to troubleshoot, to my mind, than some kind of "packaging" or "application streaming" tool. I am distrustful of black box tools that appear to do "magical" things, basically... >smile< – Evan Anderson Sep 2 '10 at 1:31

As a "core" app I tend not to use App-v to deploy office. I use app-v when I think something might go wrong with the app when I need to ensure an app will work without causing me any headaches with other apps (etc.). In my latest deployment I used a combination of SCCM and scripts to deploy ofice and to pre-cache the install so that on deployment day we could flip a switch and everyone would be on the latest version of office in under an hour.

As far as 64 bit goes we only deployed 64 bit office to folks that needed it (meaning excel power users and jerks that swear they need it and had the political pull to get it). Most users are on a 64 bit win7 platform but we were unsure of how future scripts/apps (sql server) would connect to the 64 bit versions of office

share|improve this answer
Yes I'll be deploying 32bit Office. – Kvad Sep 2 '10 at 4:42

We are using SCCM to deploy Office 2010 and it has worked very well. Most of the customization is done using the 'setup.exe /admin'.

We divide desktops, laptops and servers to different collections(similar to OU in AD) and then further division based on tiers of deployment like IT, Accounts, sales, Executives.

If anyone is looking for Windows 7 deployment, then SCCM 2007/2012 is way to go. It has a little learning curve as some of things just don't work out of box and need to be worked over-and-over again. But the end result is worth the effort.

I used this link as reference for packaging Office 2010 for SCCM.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.