Software Deployment

Hey Benners,

First off are you creating a transform in ORCA or editing the MSI directly. I'd recommend creating a transform if you want to edit the MSI.

What registry keys are you trying to add? and when you say they are being deleted, are you saying that they keys you add are just not being set after the install, or that they exist prior to the install and are actively being deleted?

Usually registry files can be deleted either via the RemoveRegistry table or through a custom action.

Also, when you added the new component did you tie it to a feature via the FeatureComponents table?

Cheers
Steve

Hi brenners,
this is definitely the wrong package for doing such things!
1. It is too big and complex to begin with.
2. There is a better way to do this job!

Use 'Custom Installation Wizard' from the O2k3 Resource Kit to generate your MST.

Regards, Nick

ORIGINAL: brnn8r

Hey Benners,

First off are you creating a transform in ORCA or editing the MSI directly. I'd recommend creating a transform if you want to edit the MSI.

What registry keys are you trying to add? and when you say they are being deleted, are you saying that they keys you add are just not being set after the install, or that they exist prior to the install and are actively being deleted?

Usually registry files can be deleted either via the RemoveRegistry table or through a custom action.

Also, when you added the new component did you tie it to a feature via the FeatureComponents table?

Cheers
Steve


Hi Steve,
I am editing the MSI directly, what I am trying to do is automatically integrate Service Packs and Hotfixes into the original msi by using a program I am working on in AutoIt. If you are unaware AutoIt is a scripting language that can be used to automate tasks etc and I am using the normal method of creating an Admin Install Point (AIP) and then updating the AIP using the switches msiexec /p .... etc. I will describe the process a bit more.

The program has a GUI where users select their Office version to be updated, the process then automates the integration of the Service Packs and Hotfixes into a created AIP. When using this method of Integration the registry entries that show the update is installed are not added to the MSI and so the update is listed by Microsoft Update as required when in fact only the reg entries are.Originally I created a reg file that added them after Office was installed but now have found how to add them to the MSI with AutoIt so they are added by the setup.

I know that I could create a transform and that is the better route but I do not know how to do this unattendedly and it would be easier to stick to the reg file method, but I am trying to improve the program and this is the route I am trying.

The reg keys responsible are located in the HKLM hive and this is the key I am adding the new reg entries to. SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\9040110900063D11C8EF10054038389C\Patches

If I edit the MSI and deliberatly put an error in the key format a 1404 error occurs and I can look in the registry and see the keys are added but at sometime and for some reason during the sequence they are removed and I cannot see why despite looking thorugh the MSI with Orca. As I understand it the RemoveRegistry table is responsible for removing entries during the setup but this is processed before the WriteRegistry action, there is also another table called Regsitry2 that if I add the entries to they remain after setup has finished. The problem with this is although Office 2003 has this table, Office XP does not and I would like the program to support multiple versions.

Regarding the FeatureComponent I did add the components to it as specified by the procedure in the link in the first post and the same thing happened. If I manually import a registry file with the keys in those to are deleted during the setup but I cannot find any other reference to this particular key in the MSI that would mark it for deletion.

I could post the setup log if that would help identify the action that may be responsible but it looks as though I may need to create my own table and custom action that runs later in the sequence, maybe just before the InstallFinalize action. I anyone could point me to a webpage that describes the procedure for doing so I would appreciate it, If I had something to follow I know would work it would help me rather than following tying together scraps found on MSDN and the web and not knowing if I am doing the method correctly.

@ Nick
I agree this is a complex package, especially for me but I thought hey I am only adding some simple reg entries to tables and components already there ho hard can it be [:(]. I have used the O2k3 resource kit and Custom Maintainence Wizard to create CMW files that only install certain Office apps but as there will be others using the program I would want the process to be as automated as possible.

Thanks all and apologies for the long post.
benners

Hey Benners,

Well, for most of the packaging projects I've worked on, Office had always been done as this was usually the highest priority. So, I've never really had to go into depth on it which is a shame [:(].

I'm guessing, and I could be wrong here, that Office has a custom action that reads the registry2 table and writes those registry entries.

I have used Autoit to automate user interaction before, but I'm not sure why you want to use it. Are you getting the users to patch the admin installs of Office?!? and how are the users actually getting the application installation? couldn't you just have an admin share say \\server\apps\Office and place the administrative installs of the different versions of Office and then patch them. e.g.
msiexec /p a_patch.msp /a \\server\apps\Office\2003\pro11.msi /qb
Then script/SMS/etc.. the install for a user. Using a transform if you want to add these reg keys.e.g. msiexec /i \\server\apps\Office\2003\pro11.msi ALLUSERS=1 TRANSFORMS=your_transform.mst /qb

Also you could add a VBScript custom action in the MST rather than another table. And just have something like the following.Option Explicit
On Error Resume Next
Dim WshShell : Set WshShell = CreateObject("WScript.Shell")
WshShell.RegWrite("HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\
UserData\S-1-5-18\Products\9040110900063D11C8EF10054038389C\Patches", "whatever", REG_SZ)
Set WshShell = Nothing



Also there are some good reasons why you shouldn't modify the MSI directly. I can't remember all of them but I think you can invalidate your application support from the company who provided you the software and also could potentially break future patches for Office as they will be expecting the origional MSI. It may be unlikely but could happen.

Cheers
Steve

ORIGINAL: brnn8r

Hey Benners,

I'm guessing, and I could be wrong here, that Office has a custom action that reads the registry2 table and writes those registry entries.

I have used Autoit to automate user interaction before, but I'm not sure why you want to use it. Are you getting the users to patch the admin installs of Office?!? and how are the users actually getting the application installation?
Cheers
Steve


Hi Steve,
There are two custom actions that relate to Registry2 they are
ScheduleRegistry2
WriteRegistry2
only ScheduleRegistry2 is called during InstallExecuteSequence and WriteRegistry2 is only referencecd in the CA table.

When I say users it is not in the context of corporate users but users of the program. The program link is http://www.siginetsoftware.com/forum/showthread.php?t=91 and a link to the changes I have made is here http://www.siginetsoftware.com/forum/showthread.php?t=361

Corporate users will factor into the equation for these users as some are Admins just wanting a one click solution to updating their Office product for rollout, it maybe used for RIS to install or reload machines but this programs purpose it to provide this one click option.

I could use the VBScript option but there are 9 reg entries required for each Hotfix and currently 10 Hotfixes for 2k3 and 18 for XP so I would have to add a vbs script to the MSI as well as the CA which for me would be the same as adding a new table or using Registry2. It's a pity Microsofy can't write better software and add the entries for MU or do the same checks as Office Update (OU) which shows the products as up to date.

Thanks
benners

use the office resource kit to write additional registry keys.

www.microsoft.com/office/ork

Download ORKTOOLS.EXE use this to create the transform and add any new registry.

Writing to the Registry table will not work as office has some override actions which use a custom / separate table to write the registry. I think from memory its Registry2 or something weird like that. Its been a while since I looked at this app in particular.

ORIGINAL: jmcfadyen

use the office resource kit to write additional registry keys.

www.microsoft.com/office/ork

Download ORKTOOLS.EXE use this to create the transform and add any new registry.

Writing to the Registry table will not work as office has some override actions which use a custom / separate table to write the registry. I think from memory its Registry2 or something weird like that. Its been a while since I looked at this app in particular.


I tried an mst a while ago and the reg entries still didn't stick, prolly for the same reason that the edited ones don't, whatever that is. The idea is to have a one click solution for users to make it easy and quick so it lookslike I will have to learn how to add a new table and feature to run just before InstallFinalize, any ideas on the best way?, I have never done this big an edit before and wouldlike to know Iam doing it correctly beforehand.

Thanks

there is a special section in ORK to add registry. I remember checking this after using ORK previously and found the changes did not end up in the registry table as one would expect. I also recall adding registry via the registry table in Office also did not work as expected.

Even when adding new components and assigning those components to features.

ORIGINAL: jmcfadyen

there is a special section in ORK to add registry. I remember checking this after using ORK previously and found the changes did not end up in the registry table as one would expect. I also recall adding registry via the registry table in Office also did not work as expected.

Even when adding new components and assigning those components to features.



I have used transforms before with no problem but with Office the entries are added by the MST and deleted before the install has finished. I think I have identified the problem and it appears to be the PublishProduct action that is deleting the keys, it even deletes them if they exist prior to installation.

I was wondering if there was a way to make the entries stick or if I could change the sequence #, create an new MST and use that. There is also the Registry2 table in Office 2003 and because the sequence # is higher than PublishProduct if I add the entries there they stick but I also want to use this for Office XP and there is no Registry2 table in that msi.

Thanks

I have used transforms before with no problem but with Office the entries are added by the MST and deleted before the install has finished. I think I have identified the problem and it appears to be the PublishProduct action that is deleting the keys, it even deletes them if they exist prior to installation.

I was wondering if there was a way to make the entries stick or if I could change the sequence #, create an new MST and use that. There is also the Registry2 table in Office 2003 and because the sequence # is higher than PublishProduct if I add the entries there they stick but I also want to use this for Office XP and there is no Registry2 table in that msi.

Thanks

I would create either a custom action that uses the 'MODIFYPROFILE' tool, SECEDIT, or REG depending which Hive you need to modify. I would use 'MODIFYPROFILE' or SECEDIT most likely. You can also do it outside the MSI by calling the MSI frm a batch file and then running a command line to enter the registry information. But if it MUST be embedded then create a custom action.