Office 2007 setup using group policy

[Steve Boyce]

I just started trying it out and I have some questions. Please note, we do
not have SMS server.

(1) Apparently the ONLY way to use GP is to modify the config.xml file, and
even then there are major restrictions (only 4 things can be edited).
Correct?

(2) The edited config.xml file should be located within the network share in
the same filder together with the .msi file - in my case, ProPlus.WW.
Correct?

(3) I so far tried this on just one PC, and it did not work correctly. (For
instance, it prompted me for the key that I entered in config.xml, and it
ignored that I did not want publisher included in the installation) With
office 2003, the entire installation process was finished by the time the
logon screen was reached. With office 2007, this appears however not to be
the case - it does something before the logon screen all right, but after I
logon, it then does some more installing. What is going on here? What
happens if the first person to logon does not have admin rights on the PC?

(4) In this scenario (installation using group policy), the "Update" folder
does nothing. Correct?

(5) How will I apply the usual monthly flood of security updates in this
scenario(installation using group policy)?

Thanks, Steve

 

[Mike]

I had a similar problem (among others). Deploy via GP would not work - error
in the app log indicating a problem with the msi. When I tried to run the
..msi file directly I received a pop-up with "Error 1713. Setup cannot install
one of the required products for Microsoft Office Professional Plus 2007.
According to MS, Office 2007 cannot be installed that way:
http://support.microsoft.com/default.aspx/kb/926279
I have tried to install it manually on three machines now over the top of
Office 2003 using setup.exe and each has been an absolute nightmare. If
anyone has any solutions, please enlighten!

Mike

 

[Mike]

I had a similar problem (among others). Deploy via GP would not work - error
in the app log indicating a problem with the msi. When I tried to run the
..msi file directly I received a pop-up with "Error 1713. Setup cannot install
one of the required products for Microsoft Office Professional Plus 2007.
According to MS, Office 2007 cannot be installed that way:
http://support.microsoft.com/default.aspx/kb/926279
I have tried to install it manually on three machines now over the top of
Office 2003 using setup.exe and each has been an absolute nightmare. If
anyone has any solutions, please enlighten!

Mike

 

[Mike]

I had a similar problem (among others). Deploy via GP would not work - error
in the app log indicating a problem with the msi. When I tried to run the
..msi file directly I received a pop-up with "Error 1713. Setup cannot install
one of the required products for Microsoft Office Professional Plus 2007.
According to MS, Office 2007 cannot be installed that way:
http://support.microsoft.com/default.aspx/kb/926279
I have tried to install it manually on three machines now over the top of
Office 2003 using setup.exe and each has been an absolute nightmare. If
anyone has any solutions, please enlighten!

Mike

 

[Mike]

I had a similar problem (among others). Deploy via GP would not work - error
in the app log indicating a problem with the msi. When I tried to run the
..msi file directly I received a pop-up with "Error 1713. Setup cannot install
one of the required products for Microsoft Office Professional Plus 2007.
According to MS, Office 2007 cannot be installed that way:
http://support.microsoft.com/default.aspx/kb/926279
I have tried to install it manually on three machines now over the top of
Office 2003 using setup.exe and each has been an absolute nightmare. If
anyone has any solutions, please enlighten!

Mike

 

[Steve Boyce]

From my point of view, it does "work as advertised" if the first person who
logs on has admin rights on the PC. The install is not able to complete
outside of a user context before anyone logs on. The problem I mentioned in
my point 3 was occurring because I was testing with a non-admin user. Thus,
effectively remote installation and management via GP has been crippled
(quite apart from the removal of the .mst functionality). I can't see any
design necessity for this; it seems more like a policy decision to force me
to buy SBS screw more money out of me per desktop. This is a topic that
seems like it rates a phone call to a journalist...

Steve

 

[Steve Boyce]

From my point of view, it does "work as advertised" if the first person who
logs on has admin rights on the PC. The install is not able to complete
outside of a user context before anyone logs on. The problem I mentioned in
my point 3 was occurring because I was testing with a non-admin user. Thus,
effectively remote installation and management via GP has been crippled
(quite apart from the removal of the .mst functionality). I can't see any
design necessity for this; it seems more like a policy decision to force me
to buy SBS screw more money out of me per desktop. This is a topic that
seems like it rates a phone call to a journalist...

Steve

 

[Steve Boyce]

From my point of view, it does "work as advertised" if the first person who
logs on has admin rights on the PC. The install is not able to complete
outside of a user context before anyone logs on. The problem I mentioned in
my point 3 was occurring because I was testing with a non-admin user. Thus,
effectively remote installation and management via GP has been crippled
(quite apart from the removal of the .mst functionality). I can't see any
design necessity for this; it seems more like a policy decision to force me
to buy SBS screw more money out of me per desktop. This is a topic that
seems like it rates a phone call to a journalist...

Steve

 

[Steve Boyce]

From my point of view, it does "work as advertised" if the first person who
logs on has admin rights on the PC. The install is not able to complete
outside of a user context before anyone logs on. The problem I mentioned in
my point 3 was occurring because I was testing with a non-admin user. Thus,
effectively remote installation and management via GP has been crippled
(quite apart from the removal of the .mst functionality). I can't see any
design necessity for this; it seems more like a policy decision to force me
to buy SBS screw more money out of me per desktop. This is a topic that
seems like it rates a phone call to a journalist...

Steve

 

[Steve Boyce]

(I meant SMS not SBS in the post below) Since there was no reply, I've got
to assume my assumption is basically correct and MS have removed the ability
to administer Office 2007 (in any meaningful sense) via GP. It is necessary
to purchase Systems Management Server to get to the same point that we were
with Office 2003, with all the security updates deploying automatically every
month.

Steve

 

[Steve Boyce]

(I meant SMS not SBS in the post below) Since there was no reply, I've got
to assume my assumption is basically correct and MS have removed the ability
to administer Office 2007 (in any meaningful sense) via GP. It is necessary
to purchase Systems Management Server to get to the same point that we were
with Office 2003, with all the security updates deploying automatically every
month.

Steve

 

[Steve Boyce]

(I meant SMS not SBS in the post below) Since there was no reply, I've got
to assume my assumption is basically correct and MS have removed the ability
to administer Office 2007 (in any meaningful sense) via GP. It is necessary
to purchase Systems Management Server to get to the same point that we were
with Office 2003, with all the security updates deploying automatically every
month.

Steve

 

[Steve Boyce]

(I meant SMS not SBS in the post below) Since there was no reply, I've got
to assume my assumption is basically correct and MS have removed the ability
to administer Office 2007 (in any meaningful sense) via GP. It is necessary
to purchase Systems Management Server to get to the same point that we were
with Office 2003, with all the security updates deploying automatically every
month.

Steve

 

[Bob Buckland ?:-\)]

Hi Steve,

The use of GPO deployment is going to be somewhat limited. To improve what you can do with the MS Installer to deploy Office, the
Setup.exe based customization and deployment tools, which use .MSP files for customizations (and the MS Installer doesn't and so
you're correct that the Office 2007 \updates folder content would be ignored if you use a GPO method to deploy) the enhancements on
one side sort of took away (probably not intentionally) from another deployment approach.

The Config.xml can be located in a separate location as long as you include a way to 'point' to it. One of the issues with using
the customized config.xml (other than there are a number of them with the same name <g>) is that you can end up, in cases where you
have different setups for different groups/folks if you 'forget' to use different ones (default vs custom for example) you can get
some unexpected results.

As with prior Office installations that rely on the MS Installer support (MSIexec.exe) elevated privleges are needed to install.

==============
I just started trying it out and I have some questions. Please note, we do
not have SMS server.

(1) Apparently the ONLY way to use GP is to modify the config.xml file, and
even then there are major restrictions (only 4 things can be edited).
Correct?

(2) The edited config.xml file should be located within the network share in
the same filder together with the .msi file - in my case, ProPlus.WW.
Correct?

(3) I so far tried this on just one PC, and it did not work correctly. (For
instance, it prompted me for the key that I entered in config.xml, and it
ignored that I did not want publisher included in the installation) With
office 2003, the entire installation process was finished by the time the
logon screen was reached. With office 2007, this appears however not to be
the case - it does something before the logon screen all right, but after I
logon, it then does some more installing. What is going on here? What
happens if the first person to logon does not have admin rights on the PC?

(4) In this scenario (installation using group policy), the "Update" folder
does nothing. Correct?

(5) How will I apply the usual monthly flood of security updates in this
scenario(installation using group policy)?

Thanks, Steve>>
--

Bob Buckland ?
MS Office System Products MVP

*Courtesy is not expensive and can pay big dividends*

 

[Bob Buckland ?:-\)]

Hi Steve,

The use of GPO deployment is going to be somewhat limited. To improve what you can do with the MS Installer to deploy Office, the
Setup.exe based customization and deployment tools, which use .MSP files for customizations (and the MS Installer doesn't and so
you're correct that the Office 2007 \updates folder content would be ignored if you use a GPO method to deploy) the enhancements on
one side sort of took away (probably not intentionally) from another deployment approach.

The Config.xml can be located in a separate location as long as you include a way to 'point' to it. One of the issues with using
the customized config.xml (other than there are a number of them with the same name <g>) is that you can end up, in cases where you
have different setups for different groups/folks if you 'forget' to use different ones (default vs custom for example) you can get
some unexpected results.

As with prior Office installations that rely on the MS Installer support (MSIexec.exe) elevated privleges are needed to install.

==============
I just started trying it out and I have some questions. Please note, we do
not have SMS server.

(1) Apparently the ONLY way to use GP is to modify the config.xml file, and
even then there are major restrictions (only 4 things can be edited).
Correct?

(2) The edited config.xml file should be located within the network share in
the same filder together with the .msi file - in my case, ProPlus.WW.
Correct?

(3) I so far tried this on just one PC, and it did not work correctly. (For
instance, it prompted me for the key that I entered in config.xml, and it
ignored that I did not want publisher included in the installation) With
office 2003, the entire installation process was finished by the time the
logon screen was reached. With office 2007, this appears however not to be
the case - it does something before the logon screen all right, but after I
logon, it then does some more installing. What is going on here? What
happens if the first person to logon does not have admin rights on the PC?

(4) In this scenario (installation using group policy), the "Update" folder
does nothing. Correct?

(5) How will I apply the usual monthly flood of security updates in this
scenario(installation using group policy)?

Thanks, Steve>>
--

Bob Buckland ?
MS Office System Products MVP

*Courtesy is not expensive and can pay big dividends*

 

[Bob Buckland ?:-\)]

Hi Steve,

The use of GPO deployment is going to be somewhat limited. To improve what you can do with the MS Installer to deploy Office, the
Setup.exe based customization and deployment tools, which use .MSP files for customizations (and the MS Installer doesn't and so
you're correct that the Office 2007 \updates folder content would be ignored if you use a GPO method to deploy) the enhancements on
one side sort of took away (probably not intentionally) from another deployment approach.

The Config.xml can be located in a separate location as long as you include a way to 'point' to it. One of the issues with using
the customized config.xml (other than there are a number of them with the same name <g>) is that you can end up, in cases where you
have different setups for different groups/folks if you 'forget' to use different ones (default vs custom for example) you can get
some unexpected results.

As with prior Office installations that rely on the MS Installer support (MSIexec.exe) elevated privleges are needed to install.

==============
I just started trying it out and I have some questions. Please note, we do
not have SMS server.

(1) Apparently the ONLY way to use GP is to modify the config.xml file, and
even then there are major restrictions (only 4 things can be edited).
Correct?

(2) The edited config.xml file should be located within the network share in
the same filder together with the .msi file - in my case, ProPlus.WW.
Correct?

(3) I so far tried this on just one PC, and it did not work correctly. (For
instance, it prompted me for the key that I entered in config.xml, and it
ignored that I did not want publisher included in the installation) With
office 2003, the entire installation process was finished by the time the
logon screen was reached. With office 2007, this appears however not to be
the case - it does something before the logon screen all right, but after I
logon, it then does some more installing. What is going on here? What
happens if the first person to logon does not have admin rights on the PC?

(4) In this scenario (installation using group policy), the "Update" folder
does nothing. Correct?

(5) How will I apply the usual monthly flood of security updates in this
scenario(installation using group policy)?

Thanks, Steve>>
--

Bob Buckland ?
MS Office System Products MVP

*Courtesy is not expensive and can pay big dividends*

 

[Bob Buckland ?:-\)]

Hi Steve,

The use of GPO deployment is going to be somewhat limited. To improve what you can do with the MS Installer to deploy Office, the
Setup.exe based customization and deployment tools, which use .MSP files for customizations (and the MS Installer doesn't and so
you're correct that the Office 2007 \updates folder content would be ignored if you use a GPO method to deploy) the enhancements on
one side sort of took away (probably not intentionally) from another deployment approach.

The Config.xml can be located in a separate location as long as you include a way to 'point' to it. One of the issues with using
the customized config.xml (other than there are a number of them with the same name <g>) is that you can end up, in cases where you
have different setups for different groups/folks if you 'forget' to use different ones (default vs custom for example) you can get
some unexpected results.

As with prior Office installations that rely on the MS Installer support (MSIexec.exe) elevated privleges are needed to install.

==============
I just started trying it out and I have some questions. Please note, we do
not have SMS server.

(1) Apparently the ONLY way to use GP is to modify the config.xml file, and
even then there are major restrictions (only 4 things can be edited).
Correct?

(2) The edited config.xml file should be located within the network share in
the same filder together with the .msi file - in my case, ProPlus.WW.
Correct?

(3) I so far tried this on just one PC, and it did not work correctly. (For
instance, it prompted me for the key that I entered in config.xml, and it
ignored that I did not want publisher included in the installation) With
office 2003, the entire installation process was finished by the time the
logon screen was reached. With office 2007, this appears however not to be
the case - it does something before the logon screen all right, but after I
logon, it then does some more installing. What is going on here? What
happens if the first person to logon does not have admin rights on the PC?

(4) In this scenario (installation using group policy), the "Update" folder
does nothing. Correct?

(5) How will I apply the usual monthly flood of security updates in this
scenario(installation using group policy)?

Thanks, Steve>>
--

Bob Buckland ?
MS Office System Products MVP

*Courtesy is not expensive and can pay big dividends*