Software Deployment

By "repackaging" Project 2003, do you mean using Wise to capture the installation and then recompile a new .msi?

When you created your transform, did you use Wise, or the Office 2003 Custom Installation Wizard to generate the .mst?

Craig --<>.

Regarding the first question, yeah, that's what I meant - do a "before" capture, install the app, do an "after" capture, compile the new .msi.

Regarding the transform, I used the Custom Installation Wizard from the Office XP Resource Kit. The problem I encountered when I tried to create the .mst was that I was unable to find where to place the product ID code (PIDKEY). (At one point during the wizard, as I recall, you are presented with some Properties you can modify; I didn't see any place in there where you could enter the key.)

I also used Orca in an attempt to directly modify the .msi but there too it wasn't clear (at least to me) where to enter the PIDKEY. Of course, I coulda just missed it. I could have possibly created a new row in the Property table called PIDKEY and tried that, I suppose, but I didn't attempt that.

jbonbright,

A software deployment best practice is to never capture an installation of an .msi and recompile it into a new .msi. In a few rare instances this rule can be broken to address very specific problems or situations, but it is never done with Microsoft .msi's. You can read more here:

http://itninja.com/blog/view/at-command-line-problems-after-ie-4+0

Your transform (.mst) is almost certainly not working properly because it is being generated by the Office Custom Installation Wizard from a non-Microsoft .msi.

Likewise, avoid modifying Microsoft provided .msi's (especially the Office line) directly. Use only the Office Custom Installation Wizard to acheive the modifications you need.

If you have the Enterprise version of Project, you can create an administrative installation point using the "setup /a" option from the command line. The structure that is created will have the product key embedded, and will not prompt for it at the time of installation.

Craig --<>.

Thanks for the info. There seems to be widely differing opinions on repackaging .msi's. We've done it here for years with good results, though, as I mentioned earlier, repackaging sometimes is problematic with .msi's from some manufacturers, notably Microsoft and a few others. Still, common practice HERE is to attempt a repackage of an .msi first, then explore other avenues. One of the main reasons for that is that it enables us to create unattended packages that can be installed under regular-user context (in conjunction with Always Install Elevated keys.)

Regarding the transform, I was running the OCIW against the Microsoft .msi, not the .msi that was created during the repackage attempt.

Regarding using Orca, I've read similar advice to yours about directly modifying the manufacturer-provided .msi's. I did this, however, in an attempt to solve my issue AFTER I couldn't get the transform to do what I needed it to do.

I'm aware of the setup /a option, but we don't employ installing apps via administrative installation points, so that wouldn't help me. My directive was to create a self-contained CD as the method of distribution. In other cases, especially enterprise-wide deployments like critical updates, we use Tivoli to push the packages out to all the endpoints. (Hopefully soon we'll make the transition to AD...)

Just out of curiosity, how do you handle installing Office updates, since the product GUIDs are changed once you repackage a Microsoft .msi?


Craig --<>.

I'm not sure we've EVER repackaged a Microsoft product, given the problems associated with doing that, but, given my short tenure here (two months), I could be wrong about that. Interesting question, though - I'll have to check that out and let you know...

Ah, okay.

I was getting the impression from your information that repackaging Microsoft .msi's was something that was not uncommon in your environment.


Craig --<>.

Pardon my interruption but I was reading this thread in hopes of some ideas on a Project 2000 automated installation. I've been struggling with Project 2000 more than any other MS product which seems strange since when installed from our CD, it doesn't seem to need the CD after install. Yet when installed from all of the packages I've tried, it fails for whatever reason. At first, it would just call for the CD to read the MSI. After playing and tweaking it and trying administrative install points, it would just have errors regarding settings and the Help seciton.

Anyway, I've been getting our apps into Ghost AutoInstall packages for a while now and since most of them come as MSI's, I've been repacking them that way with our settings. I've never had a problem with any app not funcitoning or with updates. Even with Office updates. Is it possible that Ghost knows how to retain the GUID info as a part of it's own MSI package?

A reason you may not be able to get your transform to work is that you are calling the MSI directly. You may want to try installing with the EXE using your CIW created mst.
After a lot of troubleshooting using system center essentials, using the exe was the only way that worked for me.

Start->Run->cmd

In command prompt:
Navigate to the directory of the install files
setup.exe TRANSFORMS="project2003_transform.MST" /qb-

where project2003_transform.mst is the name of the transform you created.
This will start the installation with the EXE file but will apply the .mst to the .msi that it calls.

Hope this helps, let me know if it does! =]