Welcome to Dirteam.com/ActiveDir.org Blogs Sign in | Join | Help

Group Policy Blog, by the "GPOGUY"-- Darren Mar-Elia

www.gpoguy.com www.sdmsoftware.com
What were they thinking??--the Office product team strikes again

In a previous post, I talked about the changes that MS made to Office 2007 for deployment via Group Policy. Since I wrote that post, they have pulled the article I referenced so that it is now only available via the cached Google copy. I also went ahead and tried using this method myself--creating an Office 2007 distribution point and customizing it with a config.xml file. All I can say is that once again, the Office product group has made decisions that seem to completely disregard the world around them, in favor of who knows what invisible force that drives them. They have completely made a mess of GP-based deployment of Office--a mode which I know many, many administrators have used for deployment of this behemoth package in the past. It is truly sad what they have done to this. Several people have asked me how to make this work and I just have no good answer for them. Here's what I did, in the hopes that it helps others.

What I simply wanted to do is take my version of Vista Ultimate 2007 and deploy just Outlook, Powerpoint, Word & Excel to a computer (note that per-user deployments of Office 2007 are no longer supported). Of course, I also wanted to plug in my product id so users wouldn't have to enter it. So I modified the config.xml file that came with Office and put it in my distribution point and then rebooted my test client to pick it up. Well, the first time I logged in, after Office 2007 showed that it was installing on the reboot, I indeed had a new Office 2007 program group in my Start Menu but, ironically, it contained shortcuts to all of the applications I had excluded! So, I clicked on one of the shortcuts and it launched this Office Configuration utility, which proceeded to churn away for a while. When I came back to my test system, I was no longer logged in. It had presumably rebooted or logged me out after doing its thing. When I next logged in, only the applications I had expected to find were finally there, with one exception. Despite the fact that my config.xml was excluding Access, it was indeed showing up on the Start Menu. So, it almost worked...Stick out tongue

I've also heard other reports that if you deploy Office 2007 via GP to a system that already has Office 2003, that it will not upgrade that 2003 install but instead will install side-by-side with the older version...yea, that makes sense. Most people want to use two versions of Office...

Needless to say, this is much worse than the way it used to be in Office 2003. My advice--if you use Group Policy to deploy Office today, don't plan on using it to deploy Office 2007.

Just in case you're curious, here is the config.xml I used to customize my Office 2007 installation. The PIDKEY element is where you enter your Product ID. According to the docs, its not supposed to pick up your Company Name but in my case, it did. And, its the OptionState elements where you specify which apps you want (or don't want). The id tags that I use below come from the setup.xml file that exists in the same directory as the Office MSI. However, as you can see below,they are not altogether intuitive. For example, XDOCSFiles is InfoPath! Go figure...

 

- <Configuration Product="Ultimater">
<!--
 <Display Level="full" CompletionNotice="yes" SuppressModal="no" AcceptEula="no" /> 
  -->
<!--
 <Logging Type="standard" Path="%temp%" Template="Microsoft Office Ultimate Setup(*).txt" /> 
  -->
  <PIDKEY Value="#####-#####-#####-#####-#####" />
  <USERNAME Value="User" />
  <COMPANYNAME Value="SDM Software" />
<!--
 <INSTALLLOCATION Value="%programfiles%\Microsoft Office" /> 
  -->
<!--
 <LIS CACHEACTION="CacheOnly" /> 
  -->
<!--
 <SOURCELIST Value="\\server1\share\Office12;\\server2\share\Office12" /> 
  -->
<!--
 <DistributionPoint Location="\\server\share\Office12" /> 
  -->
  <OptionState Id="AccessFiles" State="absent" Children="force" />
  <OptionState Id="GrooveFiles" State="absent" Children="force" />
  <OptionState Id="PubPrimary" State="absent" Children="force" />
  <OptionState Id="OneNoteFiles" State="absent" Children="force" />
  <OptionState Id="XDOCSFiles" State="absent" Children="force" />
<!--
 <Setting Id="Reboot" Value="IfNeeded" /> 
  -->
<!--
 <Command Path="msiexec.exe" Args="/i \\server\share\my.msi" QuietArg="/q" ChainPosition="after" Execute="install" /> 
  -->
  </Configuration>
Posted: Monday, January 29, 2007 1:25 PM by dmarelia

Comments

Anonymous said:

Even worse, in my experience (attempting to install Project 2k7), even when you install the software in this manner the suite still wants to "configure" itself afterword. This requires admin access to the machine, so if the user doesn't have this (mine don't), then it will still fail.

Not to mention the inability to really tweak the install so it's just right for your environment. I manage an office full of social work majors... if it doesn't appear on their desktop, it doesn't exist. The ability of the customization tool to let me specify shortcuts to the desktop was a real boon to me.

It's just so frustrating... they built-in some nifty management tools for the office package itself, and yet these tools won't work for group policies. It's as if one team isn't talking to any of the others.

And their SMS server? A true horror. It's (IMO) conceptually very difficult (4 manuals, 1k+ pages!), has a clunky and weird UI, and I could never get it to work reliably in a lab environment (VMware servers and workstations all running on one system). Plus you have to pay per-seat for it.

It would seem extremely simple to fix this... patch the setup.exe program in a way that allows it to apply the msp patch during a scripted install. That way, all you really need in config.xml is a reference to the patch, which will contain everything else you want.

I can *almost* do this with kixtart, but the requirement of admin privileges makes it nearly impossible.

# February 6, 2007 6:29 AM

Ryans Tech Blog » Office Team Strikes Again… said:

This is pretty funny, and true. Why can’t “they” just make it work?

# April 15, 2008 4:41 PM
Anonymous comments are disabled