I have the following situation:
--------------------------
1. I would like to standardize commonly shared DLLs and registries on 5000
PCs(Win95, NT and 2K environment) by using Merge Modules.
(i.e. Files and registries under Windows folder, System folder, Common
Files...)
2. I try to repackage every single existing applications (appx 1200
different apps) in MSI format and combine Standardized Common DLLs.
3. Whenever I find new files and registry that can be part of Common DLLs, I
would like to include them in right Merge Modules and officially post them
on intranet and distribute to every single desktop.
What I have done is:
-------------------
1. Categorize and create MSI files of all the default merge modules that
come with ISWI 2.01 into 3 as follows;
- Common DLL (Generic DLLs)
- Common RTM (Language specific Runtime Modules)
- Common DBC (Database Connectivity related)
2. Before I run InstallShield Spy to create MSI file for existing apps, I
install those 3 apps on base PC as a baseline.
3. Run Spy and get the delta.
4. Analyze shared files and include merge modules(which can be duplicated
with my Common Packages).
5. Create separate merge modules that is not part of default MSMs.
6. Repackage(Update) Common Packages with brand new Merge Modules.
7. The final production package should be able to deliver any updated merge
modules with it and scheduled Common Package distribution will ensure all of
desktop's Common DLLs are up-to-dated and corrected properly regularly.
What I found as merge module candidates other than default are;
-----------------------------------------------------------
1. Oracle version 7, 8 ODBC Drivers
2. PeopleSoft ODBC Drivers
3. Passport Portal
4. Seagate Crystal Report v8.0
5. Old Microsoft DLLs
6. Java2 Runtime
7. Adobe Common Files
8. Microsoft Shared
9. Real Player
10. Macromedia
11. To be identified
My Questions on all of these are;
-------------------------------
1. Is this valid thought? We are using software distribution tool call -
Novadigm(same idea of MS SMS). It is a good tool but have a lot of issues on
DLL and registry conflict. I try to be relied on resiliency that MS set with
MSI on resolving those issues.
2. When I repackaged a application and run dependency check, it finds those
DLLs (Old MS DLL i.e. vb40032.dll ...) and put them on right places (even
create one.)
Is this means the Default Merge Module already has those but doesn't deploy
until I ask for it?
Or, it means the Default Merge Module didn't have one but just added it on
top of itself.
If it is the first case, How can I deploy those hidden files by default?
(BTW, I run msiexec /i for all the merge modules and MS Old DLLs is not
showing up.)
If it is the later case, is it permanent update or temporary? if it is
permanent, when I repackage Common Packages, is it include new files and
registries? If not, how can I add them up as part of MSM?
3. What is the best way of collecting (or subscribe) reliable MSMs? where
can I find it? http://www.installsite.org and
http://support.installshield.com/ are the most reliable sources?
I am really appriciated to you guys who read this big note in advance.
I hope I can get some answers on this so that I can go home early!!!! :)
----------------------------------
Young Pae young.pae@bchydro.com
PC/LAN Specialist 2
BCHydro NCS Application Support
Software Certification and Distribution
1-604-515-8547