Software Deployment

You must enter the license key when performing an administrative installation for office products.

It might be possible, but definitely not easy. Office has a LOT of custom actions in it and many of them hinge on the licence key. This is why using almost any tool other than the MS Office Custom Installation Wizard to modify or transform Office breaks the EULA.

I'd approach it this way...

- Start out by using the Office CIW to create the main transform, which will contain a licence key.
- Using ORCA, the only MSI editing tool that's low level enough to have a shot at working, create a 2nd transform that contains ONLY a license key.
- See if you can install office with the main transform 1st and the licence key only transform 2nd. If it doesn't, then the license key is imbedded somewhere else in the main transform, probably a custom action or encrypted in the binary tables. Your only shot from there is to reverse engineer the custom actions. Good luck.
- If it does work, (definitely let us know!) try taking it 1 step further and remove the license key in the main transform. This way you don't end up distributing 2 licence keys.

Then again, if I had to bet on it... I'd put my money on it not working. Micro$oft loves to pull out their best tricks and obfuscation for licensing.

Unlike previous versions of MS Office you no longer need to perform an administrative installation to set up a network installation source with MS Office 2003. You can simply copy the compressed files from the CD ROM up to the distribution point on the network and run the Custom Installation Wizard to create your transform containing your Firm's preferred settings.

Using this method has several advantages;
1. You can use multiple transforms to account for differing license keys, and/or settings.
2. It greatly simplifies patching of MS Office. You can apply patches directly to the Workstation without having to patch the administrative installation point and push out a reinstall of the entire Office suite.
3. You can take advantage of the Local Installation Source functionality that is now available which makes remote deployments much easier to manage and patch.

I have had good results using the Compressed CD ROM files launched from a network DFS distribution point directly via GPO (Machine policy). Office patches applied directly to the workstations has also been very successful for me using this method (but unlike a "Local Installation Source" installation your workstations may still need connectivity to the Office distribution point during the MSP patching).

I am currently working on Using WSUS to push my Office patches in addition to Windows updates.

Hmmm. Interesting.

I suppose - like with many processes - it comes down to what will work best in a given environment.

It seems to me, though, that the better approach is to still create an administrative installation point of Office 2003, but specify that the entire installation is to be locally cached to the computer when you create Office 2k3 transforms. This option appears on page 8 of the Custom Installation Wizard. By doing this, you get the advantages of an administrative installation as well as the flexibility you are looking for in applying patches.

I'm not sure I follow the issue of different license keys, but - again - every environment has its unique needs. If you have an Office 2k3 Enterprise disc (and, therefore, volume licensing), should you not just be able to add to your license agreement as needed and continue to use the same key? I would rather keep track of one key than several, but I also know that some companies make it hard for admins by split everything up by cost center.

Craig --<>.