Installing Outlook 2003 AFTER Office 2003
My employer has over 5000 workstations, all of which run Windows XP SP2, spread out between 90 different offices statewide. A Windows 2003 DC is running at each of those offices. All equipment is kept up-to-date with by means of a central WSUS server.
Our workstations were each imaged (using Ghost) and this image included Office 2003, which is also kept up-to-date through the WSUS server.
We are now planning to change email clients at each workstation to begin using Outlook 2003, but are having problems pushing this software to our workstations via Group Policy. In the past, we've used GP to deploy quite a few applications without any notable problems, until this Outlook thing. This is the process we've tried thus far:
1. Created an Administrative Installation Point in a subfolder of where all our other GP software installs reside.
2. Created an OPS file on a test PC, that suits our needs.
3. Used the CIW from the ORK3 to build our custom MST file
4. Created our GP object in the GPMC, using the 'Advanced' option an supplying our MST file, then 'assigned' this policy to our test computer accounts.
5. Rebooted out test PC and watched as the software seemingly installs...
After this supposed install, the application is simply not there. The files/shortcuts are not being installed, and the event logs at the workstation (and servers) indicate the GP software installation was successful. We have already triple-checked all the access rights, even though an access rights problem would normally be indicated in the event logs. We have even used some advanced logging (including verbose logging) to try to find out exactly where the problem lies, but even these verbose logs indicate everything installed fine. The Outlook 2003 application even shows up in the Add/Remove Programs portion of the Control Panel at the test PC (to supposedly occupy 294.00 MB).
We have already tested our installation by first logging on to the PC (without the GP in effect), and then launching it manually though the command line, using the "SETUPOLK.EXE TRANSFORMS="Our Administative Install Path\our MST file". This works great, but only sets up the profile for the currently logged on user. Subsequent users get the "Welcome" screen and are asked to set things up.
We've even scaled back our policy object to merely install using the OUTL11.MSI file, without any OPS or MST files. The result is the same...no Outlook 2003 at all on the workstation.
A couple seemingly quirky things we've noticed is that our "Trusted Publisher" certificates are being installed, and this option exists within our MST file. We also get the infamous 'Open Office Document' (and its twin buddy whose name escapes me) shortcuts on our "Start" menu, even though these were specifically ommitted during our Outlook 2003 MST creation, as well as the original Office 2003 installation we made our image from. This makes it seem that the GP was in fact beginning to install the program based on our MST settings!?
After reading through this forum the last few days (including tonight), I have thought of a couple other potential fixes to try in the morning, but am not sure if any would make a difference. They are as follows:
1. After the obvious failed GP installation, the test PC's Control Panel shows entries for Office 2003 AND Outlook 2003. We did in fact use the OUTL11.MSI file to build our installation point, so this make sense, but should I be trying to instead use the CMW (instead of CIW) off our already present Office 2003 installation? Remember that Office 2003 was part of our 'base image', but we did include the MSOCache folder and I do not know if this could be leveraged for the Outlook 2003 installation.
2. I'm also concerned that perhaps our WSUS supplied updates to Office 2003 are interfering with the base GP install of Outlook 2003 (I'm thinking about the Windows System File Protection in Windows XP). Various junk email filters specifically for patching Outlook 2003 (and quite likely, other patches) are already being 'Approved' through WSUS, because we've known for a good while that this email client conversion would likely be in our future. We have not yet tried applying updates directly to our 'Administrative Installation Point', but should we?
Each of the last several days, I've pondered this situation at home but have yet to come up with a solution that works when I get back to the office the next day. If anyone has an idea what may me up here, or has had experience installing Outlook 2003 AFTER Office 2003, please let me know though this forum.
Your help would be greatly appreciated.
GT
Our workstations were each imaged (using Ghost) and this image included Office 2003, which is also kept up-to-date through the WSUS server.
We are now planning to change email clients at each workstation to begin using Outlook 2003, but are having problems pushing this software to our workstations via Group Policy. In the past, we've used GP to deploy quite a few applications without any notable problems, until this Outlook thing. This is the process we've tried thus far:
1. Created an Administrative Installation Point in a subfolder of where all our other GP software installs reside.
2. Created an OPS file on a test PC, that suits our needs.
3. Used the CIW from the ORK3 to build our custom MST file
4. Created our GP object in the GPMC, using the 'Advanced' option an supplying our MST file, then 'assigned' this policy to our test computer accounts.
5. Rebooted out test PC and watched as the software seemingly installs...
After this supposed install, the application is simply not there. The files/shortcuts are not being installed, and the event logs at the workstation (and servers) indicate the GP software installation was successful. We have already triple-checked all the access rights, even though an access rights problem would normally be indicated in the event logs. We have even used some advanced logging (including verbose logging) to try to find out exactly where the problem lies, but even these verbose logs indicate everything installed fine. The Outlook 2003 application even shows up in the Add/Remove Programs portion of the Control Panel at the test PC (to supposedly occupy 294.00 MB).
We have already tested our installation by first logging on to the PC (without the GP in effect), and then launching it manually though the command line, using the "SETUPOLK.EXE TRANSFORMS="Our Administative Install Path\our MST file". This works great, but only sets up the profile for the currently logged on user. Subsequent users get the "Welcome" screen and are asked to set things up.
We've even scaled back our policy object to merely install using the OUTL11.MSI file, without any OPS or MST files. The result is the same...no Outlook 2003 at all on the workstation.
A couple seemingly quirky things we've noticed is that our "Trusted Publisher" certificates are being installed, and this option exists within our MST file. We also get the infamous 'Open Office Document' (and its twin buddy whose name escapes me) shortcuts on our "Start" menu, even though these were specifically ommitted during our Outlook 2003 MST creation, as well as the original Office 2003 installation we made our image from. This makes it seem that the GP was in fact beginning to install the program based on our MST settings!?
After reading through this forum the last few days (including tonight), I have thought of a couple other potential fixes to try in the morning, but am not sure if any would make a difference. They are as follows:
1. After the obvious failed GP installation, the test PC's Control Panel shows entries for Office 2003 AND Outlook 2003. We did in fact use the OUTL11.MSI file to build our installation point, so this make sense, but should I be trying to instead use the CMW (instead of CIW) off our already present Office 2003 installation? Remember that Office 2003 was part of our 'base image', but we did include the MSOCache folder and I do not know if this could be leveraged for the Outlook 2003 installation.
2. I'm also concerned that perhaps our WSUS supplied updates to Office 2003 are interfering with the base GP install of Outlook 2003 (I'm thinking about the Windows System File Protection in Windows XP). Various junk email filters specifically for patching Outlook 2003 (and quite likely, other patches) are already being 'Approved' through WSUS, because we've known for a good while that this email client conversion would likely be in our future. We have not yet tried applying updates directly to our 'Administrative Installation Point', but should we?
Each of the last several days, I've pondered this situation at home but have yet to come up with a solution that works when I get back to the office the next day. If anyone has an idea what may me up here, or has had experience installing Outlook 2003 AFTER Office 2003, please let me know though this forum.
Your help would be greatly appreciated.
GT
0 Comments
[ + ] Show comments
Answers (9)
Please log in to answer
Posted by:
tungless
17 years ago
I had something very similar. I was deploying an office install with GP and made an mst for that with the CIW. In this I marked access and outlook (we use notes) as not available. I then needed to install outlook to some pcs with gp, so used the separate outlook msi. It seemed to deploy and install but outlook was not there on the PC.
The fix was to go back to the office mst and edit that with CIW and instead of marking access and outlook as not available, mark them as notavailavle, hidden, locked. My outlook will then deploy ok.
The fix was to go back to the office mst and edit that with CIW and instead of marking access and outlook as not available, mark them as notavailavle, hidden, locked. My outlook will then deploy ok.
Posted by:
havok333
17 years ago
In our testing since the original post, we did try installing Outlook only from the Office 2003 MSI file (Pro11.msi, I think it is), but that of course uninstalls the rest of the Office package. Either that, or re-deploy the entire suite.
One would think there to be a simple solution to this matter, but it has thus far eluded our efforts. We just last week had Microsoft open a ticket with their "Premium Support" staff, so I'll at least post our final solution when we get there.
GT
One would think there to be a simple solution to this matter, but it has thus far eluded our efforts. We just last week had Microsoft open a ticket with their "Premium Support" staff, so I'll at least post our final solution when we get there.
GT
Posted by:
tungless
17 years ago
I did not have outlook deploying from the office msi - It was still deployed from its own msi, but I marked outlook as 'not available, hidden, locked' in the office mst instead of just 'not available' For whatever reason this worked.
Posted by:
KrisBcn
17 years ago
I've made many customizations with Office, but with this issue you ask for I think there should be a single command line to the Pro11.msi to repair its installation adding the Outlook feature but I've seen no public property that allows this...
So I suggest to install directly the outlook.msi (or + custom mst) too...
So I suggest to install directly the outlook.msi (or + custom mst) too...
Posted by:
havok333
17 years ago
Microsoft has suggested this afternoon for us to use the CMW to add Outlook to our existing Office 2003 installation. That sounds well and good except I do not know how to push out the *.cmw file through GP. From what I read earlier, the *.cmw file is applied by a command line option, so we'll see. They've not yet closed the support call, so perhaps they'll come back with more information tomorrow on how we could push this out using GP.
We'll try out your suggestion tungless, as well. We've gotten a few other ideas to try out over the last couple weeks, so I suspect to have a busy day.
Thank you both for the suggestions!
GT
We'll try out your suggestion tungless, as well. We've gotten a few other ideas to try out over the last couple weeks, so I suspect to have a busy day.
Thank you both for the suggestions!
GT
Posted by:
havok333
17 years ago
Sorry, but I had completely forgotten to post as to our final results...
What we ended up having to do was completely reinstall Office 2003 using the CIW, first doing an uninstall of the current Office 2003 and then installing the full Office 2003 suite again. Then we had a batch file apply settings from a CMW file, because we never could get the custom setting to apply otherwise. In order to keep the policy from re-applying the CMW at each reboot, the batch file creates a small txt file on the workstation's hard drive after successfully applying the settings the first time around, and checks for the existence of that file before running again.
This was all setup on a DFS share that was created specifically for this purpose, so the data was replicated to all our spread out DCs across the state, and workstations could get the policy install from their authenticating server. All in all, it was a very rigged up configuration and not at all what we wanted to go with, but it did workout very well. Our only issues were with a specific office having their entire network go down as half the workstations were getting the policy install, and a few scattered slow-link sites. Fortunately, this only had to get us through until this coming spring when we'll deploy all new server's and workstations and we'll be be completely reworking/deleting most all our GP installs using that very handy DFS share! [:)]
What we ended up having to do was completely reinstall Office 2003 using the CIW, first doing an uninstall of the current Office 2003 and then installing the full Office 2003 suite again. Then we had a batch file apply settings from a CMW file, because we never could get the custom setting to apply otherwise. In order to keep the policy from re-applying the CMW at each reboot, the batch file creates a small txt file on the workstation's hard drive after successfully applying the settings the first time around, and checks for the existence of that file before running again.
This was all setup on a DFS share that was created specifically for this purpose, so the data was replicated to all our spread out DCs across the state, and workstations could get the policy install from their authenticating server. All in all, it was a very rigged up configuration and not at all what we wanted to go with, but it did workout very well. Our only issues were with a specific office having their entire network go down as half the workstations were getting the policy install, and a few scattered slow-link sites. Fortunately, this only had to get us through until this coming spring when we'll deploy all new server's and workstations and we'll be be completely reworking/deleting most all our GP installs using that very handy DFS share! [:)]
Posted by:
zlatan24
14 years ago
ORIGINAL: KrisBcn
I've made many customizations with Office, but with this issue you ask for I think there should be a single command line to the Pro11.msi to repair its installation adding the Outlook feature but I've seen no public property that allows this...
So I suggest to install directly the outlook.msi (or + custom mst) too...
Some days ago I was at my friend's house and he told me different funny stories. Indeed he said that he had an unpleasant problem with outlook emails. I remembered that I had as well. To my great surprise the tool, which he suggested me, solved out my troubles for seconds and maybe will help in like problem - [url=http://www.recoverytoolbox.com/open_pst_file.html]open a .pst file[/url].
Posted by:
mazeb00
13 years ago
When you change the guid of the package it will install outlook.
Because the MSI has the same guid now it wont install.
Greetz,
Seb
Because the MSI has the same guid now it wont install.
Greetz,
Seb
Posted by:
anonymous_9363
13 years ago
If anyone were to follow this ridiculous advice, they will run into so many problems with updates, patches and hot-fixes. Seriously, if you resort to this sort of hack in the real world, God help your employer.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.