In This Series: Office 2007 Deployment
- Office 2007 Deployment via Group Policy
- Deploying Office 2007 with Group Policy Startup Scripts
- Installing Office 2007 on Terminal Server
- Set Default Formats for New Office Documents from Windows Explorer
In a previous post I discussed what you need to do to start deploying Office 2007. In that post I referenced a page that Microsoft linked to, but have not actually posted (Use Group Policy to Assign Startup Scripts for 2007 Office Deployment). So in this article I’ll go through a couple of ways you can use Group Policy startup scripts to deploy Office.
To get the most out of your Office 2007 deployment you will need to deploy using SETUP.EXE, not the MSI file. The reason for this is the changes Microsoft has made to Office 2007 setup – there are no more transform files, instead customisation is achieved via Windows Installer patch files (.MSP). Using SETUP.EXE for deployment will automatically apply the patch file during installation.
When deploying applications via a startup script you will need to determine if the software is already installed before attempting to start the install, otherwise the installation will occur on every boot. There are a number of different ways of doing this; the first of which I had hoped would have been a WMI filter such as this:
SELECT * FROM Win32_Product WHERE (IdentifyingNumber <> "{90120000-0030-0000-0000-0000000FF1CE}")or this:
SELECT * FROM Win32_Product WHERE (Caption <> "Microsoft Office Enterprise 2007")The problem with either of these filters is that they will cause the GPO to apply whether Office is installed or not because they evaluate to TRUE. So unfortunately using a WMI Filter to control when Office is installed is out of the question.
A method that is similar to the WMI Filter, but uses a VBscript script to detect the presence of the installed Office applications, could work like this:
Set wshShell = WScript.CreateObject("WScript.Shell")
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set colSoftware = objWMIService.ExecQuery ("Select * from Win32_Product")
For Each objSoftware in colSoftware
If objSoftware.Caption = "Microsoft Office Enterprise 2007" Then
OfficeInstalled = True
Exit For
End If
Next
If OfficeInstalled <> True Then
Set oExec = wshShell.Exec ("\\company.local\Public\Applications\Office2007\SETUP.EXE")
Do While oExec.Status = 0
WScript.Sleep 100
Loop
End IfThis script will detect whether Office Enterprise 2007 is installed and if not start the installation. You could also implement some error checking around this to write an event to the Application log to record errors. One problem with using the Win32_Product WMI class to enumerate installed applications is that the process is slow – enumeration takes about 20 seconds on my laptop (Intel Core Duo T2300, 1.6GHz).
The simplest way to detect if Office is installed before starting the setup program is to check if a file exists. One of the most common files will be WINWORD.EXE. So a script could look like this:
IF NOT EXIST "%ProgramFiles%\Microsoft Office\Office12\WINWORD.EXE" START /WAIT \\company.local\Public\Applications\Office2007\SETUP.EXEDeploying Office 2007 via Group Policy will be challenging and may require you to perform more testing than with previous versions. For smaller organisations that have relied on Group Policy previously Office deployment can still be achieved, however perhaps it’s time to look into something a little more flexible. What I’ve seen of System Centre Essentials so far is pretty impressive and I think it’s just the tool for small organisations. Hopefully I’ve given you enough here to get your Office deployment started. I’d be interested in hearing how others are going with their own deployments.
[Update: 25/06/2008] Microsoft have recently blogged about Office 2007 deployment via Group Policy, which is worth checking out too.
11 Comments
Found this article when wanting to deploy the FileFormatConverters.exe that Microsoft released office 2003 can open the new format.
In case it helps someone, to deploy FileFormatConverters.exe via a GPO I first extracted FileFormatConverters.exe and copied the msi, cab, cat etc across to my installation share.
I then set it up as per any other software installation object and use the following WMI filter:
SELECT * FROM Win32_Product WHERE (Caption LIKE “Microsoft Office%2003%”)
This worked for me as we only have Office 2003 and 2007 on our network.
Hope it helps,
Dave
Nice work Dave, that’s a good tip.
This sounds great. I was thinking something along the same line, only I would right a script that copies the entire install folder to the local drive first(to ease server load, and network traffic during install; then launch the install. The only problem is how to you elevate the permissions to allow end users run the install?
Hi Bryan, the only way you’ll be able to use this method to deploy Office 2007 is to assign the software to your computers. Office 2007 does not support assigning the software to users. When you assign software to computers you won’t have to worry about elevating to allow the install.
Yea… I know about the assigning option in GPO, I test pushed 2007 to a computer and it worked. The problem was it didn’t use the MSP file I created. I didn’t think it would, but others on the web say they have had hit and miss success deploying Office this way and it used the MSP file. Also, I have relatively small network (250 workstations) but I was concerned about the strain on the server if I pushed the installation to that many machines at once. I know I could break it up but that would be a pain in the ass. All I would like to do is publish it and let the users install it when they’re ready… but Microsoft decided to be a dick and remove that option. That really pisses me off, cause for me I think it’s the perfect solution. So I was wondering if there was a way I could elevate the permissions in the script, other than using the runas command as that’s not very secure.
You won’t be able to elevate via a script. You can launch the elevation process via a script but it will still require an administrator to go to the machine to to enter credentials.
If you use the Software Installation feature of Group Policy to assign or even publish Office, the MSP file will not apply, you must either use the CONFIG.XML or use SETUP.EXE. Unfortunately there’s no way around it.
Here’s how to script elevation: http://blogs.msdn.com/aaron_margosis/archive/2007/07/01/scripting-elevation-on-vista.aspx
I think I may have found my answer:
http://technet2.microsoft.com/Office/en-us/library/fff8197f-284d-4837-8086-47cf2cb410ed1033.mspx?mfr=true
It’s the 5th bullet point under the title:
Advantages of using computer startup scripts for deploying 2007 Office
The vbscript as described worked for me apart from the bottom part (Set oExec) I use the following instead:
If OfficeInstalled True Then
Set WshShell = WScript.CreateObject(”WScript.Shell”)
WshShell.Run “”"\\servername\share\Software\Server Software\Microsoft\Office 2007\setup.exe”"”, 3, false
The Using the “”" due to folder name gaps. I’m no code wiz, just mixed and matched, also I assume I could of used the simple script too, thanks for the script came in handy
I just made an installation point, created a MSP and placed in the updates folder then edited the logon script to open the .exe, I found this to be the most simple way for a 50 user based company, the only thing I haven’t found is how to point the user to the closest installation point for our users in another office, don’t want them installing over 2mb link.
Hi Dustin, DFS is your friend. This will allow you to have replicas of your software installation points at different location using the same namespace and computer will connect to the closest replica.
Thanks Aaron, have been looking at implimenting DFS for a little while, just been fixing some other issues and rolling out a new file structure/new server. Sorry little off topic.
Anyway another quick way around this is also having another script with the different location as the exe, then just apply that script to the other office users.