Page 1 of 1

After integrated, Office 2003 sp3 cannot depoy with gpo

PostPosted: Sun May 18, 2008 12:39 am
by bbmak
Hi,
I always use gpo to deploy office suite to users, and I try to slipstream all the updates into it.

I try to use it with siginet's office integrator. However, after integrated with the update pack, i cannot be deployed by the gpo anymore.

I hope some experts can help me on this

PostPosted: Sun May 18, 2008 1:26 am
by Siginet
Did you use setup.exe or setup_oi.exe? I never used gpo... so I don't know exactly how you do it. But setup_oi.exe is the office integrator setup file. You can pass any of the same params to it as you would the original setup.exe. In the next release there will be no setup_oi.exe. The oi will replace the original setup.exe instead. :)

PostPosted: Sun May 18, 2008 2:53 am
by bbmak
Siginet wrote:Did you use setup.exe or setup_oi.exe? I never used gpo... so I don't know exactly how you do it. But setup_oi.exe is the office integrator setup file. You can pass any of the same params to it as you would the original setup.exe. In the next release there will be no setup_oi.exe. The oi will replace the original setup.exe instead. :)


i use the PRO11.MSI to deploy office 2003 sp3 to users, and i also customize which packages to install to users by using .mst(transformation file).

If i am using setup.exe, i will need to use startup script to deploy.

Are there anyway to customize the package, that setup_oi.exe installed?

PostPosted: Thu Jun 19, 2008 9:58 am
by TwoJ
I'm in the same boat

I really wanted to deploy office by GPO, but the only way in 2003 is with msi packages with an optional mst transformation package.
Originally i didn't want to use the office integrator because of this, that an exe would need to be deployed by startup script and it is not as nice.

What i wanted to look at is in the mst i think if you use the ork (office resource kit) tool for creating a office mst file there might be a section for doing chained installed and other things possibly registry entries.

If anyone who uses ork wants to let us know - if not i will see the next time i use it

PostPosted: Fri Jun 20, 2008 12:14 pm
by Siginet
The new beta OI also has a lot of new features for using mst's and such. :) Much thanks to benners!

PostPosted: Sun Nov 09, 2008 2:40 pm
by bbmak
yup, i think the developers should work on gpo deployment too because I know a lot of people are using that for installing office

PostPosted: Mon Nov 10, 2008 4:42 pm
by benners
bbmak wrote:yup, i think the developers should work on gpo deployment too because I know a lot of people are using that for installing office


Does the current build not work with GPO?, I have never used this method and don't know much about the requirements apart from what is posted above but can you not run the MSI from a cmd line and add the PIDKEY with that. As the reg entries are run via the MSI there is no need to use the setup.exe unless you wanted to use options in the setup.ini.

If you could explain the method used for GPO and what is required from the OI we maybe able to get something working.

PostPosted: Mon Nov 10, 2008 5:37 pm
by TwoJ
GPO deployments, which are tied into Active Directory and Group Policy will allow you too push out a software based on a user/group/computer in AD.

Problem is that microsoft decided to push only their own msi/mst format - so no 'native' exe, or bat, or cmd, etc. Nothing knocking msi/mst - its a good system - only problem is when you have software that doesn't come as msi/mst.

You can try your hand a WISE or adminstudio to convert an exe to msi, or run a login script where you can launch an exe, but the benefit of the mst is that you can customize the package.

Example - I deploy by GPO Adobe Reader, you get yourself the adobe customization wizard, unpack the adobe reader 9, run through the wizard, take off stupid stuff like the EULA, adobe promo stuff, desktop icon, etc. All those customizations are saved in the mst. Then in group policy you specify a server share (eg \\server1\apps\adobe\9\en\gpo) point it to the msi, and then specify the transforms (mst), select which group you want to deploy it to. Then when those users/computer start the computer - you get the login window where it says 'Installing managed software - Adobe Reader 9', so that when the user actually can login, the program is already installed, they click on a pdf and it opens up, no nag screens, no EULA.
Typically most networks, adobe reader is the top deployment, also office 2007 compaatibility pack, 7zip (now available in msi), Java (Roguespear), Flash (Roguespear), Shockwave(Roguespear), etc.
Roguespear has a lot of great stuff in msi, also appdeploy.com is a great resource.

Anyways - Office is up there as well - problem is that there always seems to be mixes of office because of licensing, some users are on XP, others on 2003, others 2007, so for most smaller companies its easier to put the office flat files on the network, then going through the trouble of creating a mst and creating the GPO (group policy object).

All this to say that for real requirements for a GP deployment is that it has to be a msi and an optional mst.
Will the integrator before it would create a exe bootstrapper that i believe would also modify the registry to include the hotfixes that were slipstreamed into the source. Without modifying the registry - microsoft update wouldn't recognize the hotfixes even if they were slipstreamed

The requirements for GPO deployment is that all info must be in msi/mst files, when you create a mst for office with the 'office resource toolkit' (ork) you can include the product key, company name, all the hundred if not thousand things you want to customize about office.

If you are saying that the office with updates can be run with just the msi and everything is good with MU, then i think things should be fine for gpo deployment, just make a mst that has your product key.

Now does the msi with updates work for the admin install as well as for the 'direct integration' method? MS only designed office to be deployed by admin installs for deployment so it would be interesting to see.

I'll try to give this a shot when i get time, but don't let me hold anyone else from trying!

PostPosted: Mon Nov 10, 2008 5:56 pm
by benners
TwoJ wrote:GPO deployments, which are tied into Active Directory and Group Policy will allow you too push out a software based on a user/group/computer in AD.

Problem is that microsoft decided to push only their own msi/mst format - so no 'native' exe, or bat, or cmd, etc. Nothing knocking msi/mst - its a good system - only problem is when you have software that doesn't come as msi/mst.

You can try your hand a WISE or adminstudio to convert an exe to msi, or run a login script where you can launch an exe, but the benefit of the mst is that you can customize the package.

Example - I deploy by GPO Adobe Reader, you get yourself the adobe customization wizard, unpack the adobe reader 9, run through the wizard, take off stupid stuff like the EULA, adobe promo stuff, desktop icon, etc. All those customizations are saved in the mst. Then in group policy you specify a server share (eg \\server1\apps\adobe\9\en\gpo) point it to the msi, and then specify the transforms (mst), select which group you want to deploy it to. Then when those users/computer start the computer - you get the login window where it says 'Installing managed software - Adobe Reader 9', so that when the user actually can login, the program is already installed, they click on a pdf and it opens up, no nag screens, no EULA.
Typically most networks, adobe reader is the top deployment, also office 2007 compaatibility pack, 7zip (now available in msi), Java (Roguespear), Flash (Roguespear), Shockwave(Roguespear), etc.
Roguespear has a lot of great stuff in msi, also appdeploy.com is a great resource.

Anyways - Office is up there as well - problem is that there always seems to be mixes of office because of licensing, some users are on XP, others on 2003, others 2007, so for most smaller companies its easier to put the office flat files on the network, then going through the trouble of creating a mst and creating the GPO (group policy object).

All this to say that for real requirements for a GP deployment is that it has to be a msi and an optional mst.
Will the integrator before it would create a exe bootstrapper that i believe would also modify the registry to include the hotfixes that were slipstreamed into the source. Without modifying the registry - microsoft update wouldn't recognize the hotfixes even if they were slipstreamed

The requirements for GPO deployment is that all info must be in msi/mst files, when you create a mst for office with the 'office resource toolkit' (ork) you can include the product key, company name, all the hundred if not thousand things you want to customize about office.

If you are saying that the office with updates can be run with just the msi and everything is good with MU, then i think things should be fine for gpo deployment, just make a mst that has your product key.

Now does the msi with updates work for the admin install as well as for the 'direct integration' method? MS only designed office to be deployed by admin installs for deployment so it would be interesting to see.

I'll try to give this a shot when i get time, but don't let me hold anyone else from trying!


Thanks TwoJ
The update entries are included in the msi and although a few people have had a problem with the entries I haven't. What I have done is change when the entries were added, it used to be if Office wasn't installed but now it is if Office isn't being unistalled.

I did notice that sometimes some Office keys were left in the registry, I can't remember the exact key but it had 'registration' in the name and was thinking that this maybe causing the problem.

The registry entries themselves are not added to the normal Registry Table they are added to one named Registry2, this is why Office XP still has the reg file. During installation the normal registry entries are added by the WriteRegistryValues but the key our entries are added to is removed when PublishProduct runs so they cannot be added with a reg file or mst file before this action. What I have tried is moving the WriteRegistryValues sequence after the PublishProduct so the entries stick, this installed and uninstalled OK but I don't use Office at all so don't know if this would exhibit any other problems during normal use.

If this method works successfully there would be no need for the reg file for Office XP hopefully :) . I don't know why the PublishProduct deletes these keys but from what I have been told it would probably require hacking the msi.dll and if I could do that I wouldn't be using AutoIt for the OI ;)