What is best practice to install MS Access and Office 2003 separately

[Zathara]

What I would like to perform in 7.0 is make one package and have two software resources, both with a dissimilar command line and finding rule, utilize that package. But I don't look to be able to utilize an existing package on a new Software Resource. I can't duplicate the software resource and utilize it two times either. If I have just single Software Resource with two command lines I can't utilize detection correctly. If I make two software resources I have to have two packages so every package server enclose with two copies of the office source files on it. What's the most excellent method to do this?

[Badrunath]

The Office Resource Kit (ORK) facilitates you to make a transform that will setup the necessary configuration of Office Professional for you. So to the extent that I can see, all you have to do is to run the ORK two times, to produce the two configurations of Office, make an install for one version, duplicate it, and after that adapt the clone so that it calls the other transform. On the other hand, you can make a single package lacking Access, and after that make an "update" using the Office Maintenance Wizard from the ORK, that updates the install to comprise Access.

[MahaGuru]

You cannot have single package and two software resources. You can, on the other hand, have several command lines for a solitary software resource. You cannot have several detection rules for a solitary software resource (depends on command line). Do you necessitate a dissimilar detection rule for every command line? If so, you require two software resources which will craft two packages and assume the space two times.

[GeforceUser]

In the over case, if you wish to put all the install files for Office into a solitary package that's fraction of a software resource, you can make several command lines which carry out against .MSP's or just next to the .exe's (.MSP's can just be utilized throughout the first install of Office), but you won't be able to take benefit of in excess of one finding rule. There will be no means to tell, utilizing the similar software resource, whether you have Office or Office + Access or Office + Visio or Office + Access + Visio.

[Bull50]

The original poster referred to Office 2003 applications, and MSPs as configuration files for Office just began with Office 2007. The updates for Office 2007 for example service packs are as well MSPs, so can either be built-in in the Updates folder of an Office 2007 deployment place, or can be organized disjointedly later than Office 2007 is installed on workstations, so it's not completely true that you can just utilize MSPs at install time.

[DotNetUser]

After all, that's one of the major advantages of v7 Software Delivery, the capability to manage the surroundings correctly. It's a disgrace that it has to be completed this way, Office 2003 isn't the just package with one set of source files but dissimilar install choices needing dissimilar detection rules. I am thinking the link in Managed Delivery Policies which just lets you choose rules linked with the package necessitates being broken. So you can choose any rule. The capability to copy rules would be truly helpful too.

[$tatic]

Make a package and Software Resource for the Office 2003 source files with a mannequin command line counting both the Office 2003 (no Access) and Access 2003 transforms. Make divide Software Resources for both of Office 2003 (no Access) and Access 2003, all with its own exposure rule. Create both needy on the Office 2003 source Software resource. Every install command line calls the Office 2003 source file package setup. I will grant it an attempt tomorrow except anybody can shoot it down in flames overnight.