Howdy,

This is my first post here, so please be gentle. I am looking into deploying Microsoft Office 2003 (Swedish) via Group Policy. We usually rely on SoftGrid for this where I work, but we're running into a lot of issues getting Office to work properly together with other applications when it's running through SoftGrid. And having relied om SoftGrid, nobody really knows anything about other forms of application deployment. I don't even know where to start!

We are not going to be doing any advanced customization. A full install with the exception of Outlook and InfoPath with Service Pack 3 and the 2007 compatibility pack (for .docx support). Any other updates should be grabbed via Microsoft Update (which includes updates for Office 2003 and later). Essentially, what we want is the centralized equivalent of running around the building with a CD installing the application on each and every single computer. Like I mentioned, updates would be handled by Microsoft Update, so I guess there's no need for an "administrative installation point" (whatever the hell that means :D).

Can anyone please point me in the right direction? Is there perhaps a tutorial or guide for doing this that is aimed at super newbies like myself?

Cheers,
Rickard
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
I had the pleasure of working at a shop that used GPO's to deploy every application, including Office 2003.

Installing office 2003 via gpo is very straight forward, as long as you're not doing anything too complex (ie remote sites, bandwidth restrictions, etc etc.)

From a high level:
- Create an administrative install point for your office installation w/ the msiexec /a command
- Apply any necessary patches to the administrative install point
- Download and install the office resource kit, and use it to customize your install settings via transform
- Create your policy based on user or computer as needed (computer is recommended) and assign it to a security group
- Add machines to security group to install (security group isn't strictly necessary, it just helps you deploy in phases.)

If you need more than that just say the word, I can go as granular with the explanation as you like.
Answered 10/18/2007 by: Bladerun
Green Belt

Please log in to comment
0
Thanks a lot for the help. With the help of your short list and some searching around, I've been successful. I've deployed the app to a test machine and everything appears to have worked beautifully. I do have two follow-up questions though.

1. Will the machines that get their Office this way update it automatically via Microsoft Update? I've read something about installing updates into the administrative install point even after the app has been deployed, but I would rather have the machines do it themselves.

2. How would I integrate the 2007 compatibility pack into the deployment? I guess I could extract the MSI from the .exe Microsoft provides for the compatibility pack and then deploy this seperately via Group Policy, but I would rather have it all in one neat package.

Now I need to figure out why Windows Installer insists on saying

"Error 1324. The folder path Application Data contains an invalid character."

everytime I start one of the newly installed office applications. I've looked in HKCU\.....\User Shell Folders, but I can't see anything out of the ordinary. It should be noted that we do folder redirection of appdata to the user's home directory. We use roaming profiles and the profile folder sizes were getting out of hand with SoftGrid.

Cheers,
Rickard
Answered 10/18/2007 by: Rickard
Senior Yellow Belt

Please log in to comment
0
Rickard,

1) They will indeed get their updates through Microsoft Update or (my preferred solution) Windows Server Update Services aka WSUS - they will not through Windows Update. Windows Update will only update Windows itself.

While you can incorporate Office updates into the install point, the various update mechanisms will not detect that they have been applied. I find it easier just to let WSUS handle those details.

2) The 2007 compatibility pack download is a self-extracting .exe, and if you open it with WinRAR or WinZip you will find a .msi - it stands to reason that you could deploy that with group policies along with Office 2003. Be warned that I've never tried it myself, at the moment I have no need for the compatibility pack. Worst case you will need to create an administrative install.
Answered 10/18/2007 by: pbrutsch
Yellow Belt

Please log in to comment
0
Thanks. What are the benefits to using WSUS as compared to having the computers grab their updates from Microsoft Update directly?

My 1323 error was solved by nuking my profile.

Cheers,
Rickard
Answered 10/19/2007 by: Rickard
Senior Yellow Belt

Please log in to comment
0
With WSUS you will get to manage all the updates for servers and workstations from a central location, getting to roll out updates or deny updates to different OU's etc.

Its more managable and you get reports on how many pcs need a certain update etc. I have just rolled it out across 3 sites and once you get over the first few initial machines catching up with xp sp2 it runs very well.

Still to implement on servers etc but its definately worth doing.

im just looking at GP to deply office 2003 now, what was the command line you used to use an MST you created...im currently just testing on a few machines using a batch file and the install is working fine.

Id want it to install after the user is logged on and not while the user is logging on, but i want the install to start automatically and silent without the user needing to do anything.
Answered 10/19/2007 by: mfoster11
Yellow Belt

Please log in to comment
0
ORIGINAL: mfoster11

im just looking at GP to deply office 2003 now, what was the command line you used to use an MST you created...im currently just testing on a few machines using a batch file and the install is working fine.

Id want it to install after the user is logged on and not while the user is logging on, but i want the install to start automatically and silent without the user needing to do anything.

Well, I didn't supply a command line at all. I setup a software install in Group Policy (advanced, not assigned) and then picked the MST file I created using the customization wizard. This installs the app when the computer boots up (before login is possible).

Turns out, my 1324 error wasn't just a broken profile. Why can't folder redirection just work? :)
Answered 10/19/2007 by: Rickard
Senior Yellow Belt

Please log in to comment
0
when choosing new package for the policy it only allows you to choose .msi so how did you select the mst? or did you add the mst as a modification?
Answered 10/19/2007 by: mfoster11
Yellow Belt

Please log in to comment
0
I added the MST as a modification.

Cheers,
Rickard
Answered 10/19/2007 by: Rickard
Senior Yellow Belt

Please log in to comment
0
yeah thats how ive got it ready to go...just need to test now
Answered 10/19/2007 by: mfoster11
Yellow Belt

Please log in to comment
0
Glad things are working, however there is something very important to note.

Assigning apps through GP has a bit of a catch in how you can patch them. In the case of Office, let's say you wanted to install SP1. Push the app via GPO, then run the SP1 install manually, and you will very likely see a repair kick off when you next launch the app, and when you check the versioning after that, you'll see that the app repaired back to the original version. This is the downside to assigning apps via GPO.

How we handled that scenario is this. In the above example, use the 'msiexec /p' command to patch the administrative install point, then right-click the policy object and redeploy. If you're deploying on a large scale and can't handle everyone reinstalling at once, then you're forced to create an upgrade instead. Basically leave your original install source as is, copy it, patch the copy, then create an upgrade policy that uninstalls the application installed by the original GPO and then installs the new copy.
Answered 10/19/2007 by: Bladerun
Green Belt

Please log in to comment
0
Thanks for the pointer. In this particular case, I don't believe this will be a problem for some time though. I've slipstreamed SP3 into the administative install so any future updates are likely to be only minor (via Microsoft Update).
Answered 10/19/2007 by: Rickard
Senior Yellow Belt

Please log in to comment
0
Hi folks,
@Will:
manual patching and updating is definitely a no go for all managed deployment solutions!
Like Phil mentioned above, the easiest way of doing all the office updates and patches is a WSUS server.

Your approach, with creating a new install point for each sp-level is ok.
However, you could also just patch and redeploy.

@Rickard: For the '2007 compatibility' do the things as Phil suggested in post #4.
Then include the MSI as a new app in your GPO. That's all.

Regards, Nick
Answered 10/19/2007 by: nheim
Tenth Degree Black Belt

Please log in to comment
0
ORIGINAL: nheim

Hi folks,
@Will:
manual patching and updating is definitely a no go for all managed deployment solutions!
Like Phil mentioned above, the easiest way of doing all the office updates and patches is a WSUS server.

Your approach, with creating a new install point for each sp-level is ok.
However, you could also just patch and redeploy.


I'm well aware, I was just using the manual installation as a way to illustrate what would happen if you patch the Office 2k3 GPO deployed install via ANY mechanism, beit manual, WSUS, etc . My point is that you can't use WSUS to patch a GPO deployed installation of Office 2003. Patch and redeploy, or creating a second install point and upgrading in stages is the best approach.

Edit: And by 'best approach' I mean 'only' approach.
Answered 10/22/2007 by: Bladerun
Green Belt

Please log in to comment
Answer this question or Comment on this question for clarity