/build/static/layout/Breadcrumb_cap_w.png

Create MST file for Office 2003

Hi all,

We're dealing with the following situation,

Our Package/MSI distribition tool can't work with MST files (VAI Deployment Center)
So in most cases we apply the transform on the MSI using MS Orca
Works fine in all cases.....but....

With office 2003 we encounter a problem with the product key.
These are our steps:

1 - Admin install to disribution location, (setup /a)
2 - Running the Admin install works, we don't have to enter a Product key
3 - Create a MST using MS "C.I.W."
4 - Apply te MST on the MSI with Orca and we save de new MSI as Transformed.msi
5 - running the Transformed.msi doesn't work, we have to enter the Product Key

So why make a new MST only containing the Product key using WISE InstallTailor? Won't work: search google on "office 2003" + InstallTailor

Any suggestions?

0 Comments   [ + ] Show comments

Answers (9)

Posted by: craig16229 19 years ago
Third Degree Brown Belt
0
subsense,

This is unusual. Just to confirm, are you saying that the admin install did not prompt you for the key? I have never done and admin install that did not prompt for it. Are you certain that the media you have is volume license?

Craig --<>.
Posted by: subsense 19 years ago
Purple Belt
0
@Craig

No, the actual admin install did prompt for a key, but when installing FROM the admin install to a client you won't get a prompt, and yes, we use a Volume License,
Posted by: craig16229 19 years ago
Third Degree Brown Belt
0
subsense,

I would make every attempt to find a way to deploy the original Office .msi in a "best practice" manner, with your .mst file being applied at the time of install. If that means not using VAI Deployment Center for Office and using AD Group Policy or some other tool to push out Office, I would do it.

It sounds as if - in the past - you have actually re-compiled Office .msi's because of not being able to use .mst's. If this is what you have done, have you made sure that the original GUID for the those .msi's have not changed? If they change, it can lead to complications and problems down the road. For example, an .msp from Microsoft cannot be applied against an admin install of Office if the GUID has been altered.


Craig --<>.
Posted by: subsense 19 years ago
Purple Belt
0
Craig,

In the past we installed Office during our unattended installation of Windows XP SP1.
We now have to make the choice between deploying office using VAI DeploymentCenter (Wich works great with the PRO11.msi!!) or an installation during de unattended setup.
A clean install during setup sounds like a more stable environment, disadvantage is that a user who wants use Office11 has te re-install there workstation.

What would you choose?

Thanks[;)],
Posted by: craig16229 19 years ago
Third Degree Brown Belt
0
I prefer to keep the OS install process separate from software deployment; IMO it gives you more flexibility.

Have you ever talked to the developers of VAI about the inability to use .mst's?

Craig --<>.
Posted by: subsense 19 years ago
Purple Belt
0
Yes, there will be soon a release of VAI Deployment Center in which we can use MST's.

The problem we have when deploying office seperate is that the application "hangs" on a user, not on a machine. With roaming users this can give extra trouble......

I believe that both methodes have there pro's and con's, especially with Office.

Thanx for the reponses!
Posted by: MSIMaker 19 years ago
2nd Degree Black Belt
0
You can do this...I did it for MS Project once and it worked.

Open the Office msi and go to the Property table.

Create a key called ProductID....exactly like that. It has to be that case for all letters.

Add the Office Product key with the dashes included and save the msi. It wont try to recompile the files so you should be ok.

When the user installs it.....it wont ask for a key but on its first startup....it will. The key will be filled in the spaces already and the user only needs to hit enter and its done.

As I said it worked for MS Project....so its worth a try until you sort out a reasonable deployment method.
Posted by: MSIMaker 19 years ago
2nd Degree Black Belt
0
I must say tho.....that I agree with Craig 100%. You are charting very murky waters if you try this sort deployment and if you get into trouble you wont be able to troubleshoot it easily.

If you find that Office "hangs" on startup for users.....then find out why....permissions or for roaming users maybe a DFS or DNS problem is stopping them from seeing the Office Application Data in their profile.....etc etc.

MS does spend alot of time to try to make the Office Family very workable for most companies/people and if the problem is your environment then you should concentrate of fixing it in my opinion. Sorry not ranting.....just hoping you dont build a big rock for your own back to carry.

OMG did I really defend Microsoft then?......time for a valium.
Posted by: pcdrobbie 19 years ago
Yellow Belt
0
Help Please.

I'm in an environment that buys many retail versions of Office and the office products. With Office 2002(XP) and earlier, my predecessor created a deployment package that installed, then on first use, required to the user to put in a Product Key. The application then will not work without a valid key. I am trying to figure out how this was done, but an trying with Office 2003. I cannot find a solution.

I noticed the post in this subject that says to put insert a Property "ProductID" for MS Project. Have you seen this work with the full office suite? I'm not able to make it work.
Do you know of another property that might have to be changed?

Any help would be greatly appreciated.

Rob
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ