Software Deployment

hi

I am using cacls, too. Subinacl for registry.

but why does wise not support such a feature?

no, we don't have a contract, yet.

We still use wise 4.2 but I am now evaluating 5.5 vs. Installshield admin studio 6.

Yes, that would be great if you could post this feature.

regards

Olivier

The ability to now check hotfixes and patches against the software database

how does that work?
is there an automatic update of the microsoft patch list?

Thx for calling them and thx for the kb #.
http://www.wise.com/KBArticle.aspx?articleno=1340

I now understand the problem.

regards

Olivier

thx for your help and answers.

do you use this "preflight" feature?

hi doug

sounds very good.

I'll check that feature out.

cheers

good time to you, too

Olivier

Wise support is certainly getting much better than it used to be...but I have to hope that their QA process improves as the last 2 updates caused some headaches across the Wise user base. Myself included.

One thing that I do to avoid using things like regini and subinacls to change registry perms is to use tools like Regmon to identify the locked down areas of the reg that the app is trying to access and add the keys and values to the registry table manually (if necessary). Then change the perms in the LockPermissions table. Just add "Everyone" to the User column and the number string to the Permission column to assign the access you need. The SDK has the settings - or you can create a bogus entry - set the desired perms to the bogus value, grab the numeric string from the LockPerms table and use that numeric string to set the values and key entries to the desired access level. It can be tedious work at times, but it ensures that the changes are made by the MSI at install-time and there is no need for external scripts. Additionally, the MSI install will apply the changes every time and there is no fear of a script aborting for some reason and leaving the machine in an unknown state after a failed install.

One thing that this technique allows you to do is to set perms on a key as well as the values located within the key in question. You can only set perms to existing values in the GUI. ( I use Wise 5.5 ) I like the idea of having the MSI do most, if not all of the changes made to a machine during install. Another bonus is that it all gets removed when uninstalled - unless you tell the MSI to leave the keys. That may be desired for HKCR entries, But CurrUser and LocalMachine should always be removed.

As far as propagating perm settings down an entire key - that is something that I dont think will be added to either Installshield or Wise. I have worked closely with Installshield in the past - and that was something that has been suggested to them thousands of times... I have attended their preview events several times for Admin Studio and that was one of the first questions that was asked by engineers attending the product evals.

The reason that they wont add the feature is that it would be too easy to select a root level key like HKLM\Software\* propagate Full Access to Everyone. Its a dream feature - and it could be done easily. But that would make it too easy to open the entire registry and would destroy the idea of a locked down operating environment - or so I am told by the folks that write the code.

- Ph

hi

it's the first time I hear of that table

LockPermissions table

Just start the SDk and reading the docs about that table entrie.

thanks for the input

gruss

Olivier

On XP I use secedit and the Security template snap-in for mmc to change permissions on files / folders / Registry /services with a custom action.

Works well and is much better than the offerings within most packaging tools.

Hi Olivier,

Its off topic but don't believe some of the myths posted regarding Installshield in this thread. Both are tools for creating packages. They have different methodologies and some differing features but if you are an accomplished packager you can use either to do your job.

I have found their support to be responsive and highly useful (I haven't used Wise's support so I can't say how theirs is). When used properly, Installshield AdminStudio generates MSI files that do not require an .exe (actually it does this pretty much by default). One thing a lot of people who are experienced in Wise don't understand is that you don't need to use ISscript. It sucks. So don't use it. Its there, sure, its a feature, but if you don't want it (and I'd suggest that you don't) then don't use it. That way you have no need to have a .exe stub installer. By default, Installshield Adminstudio will not use isscript, so you actually need to conciously create an isscript custom action for it to use it.

It does conflict analysis, application isolation, patch analysis etc. Installshield is a complete packaging solution. It has a different interface to Wise and a different methodology that may not suit your needs.

I'm not saying I prefer one over the other. I'm just saying that they both do a job, in different ways, and its worth evaluating each to see which suits your needs.

Rgds

Paul

I always use Secedit.exe and an inf file for both file and registry permissions. One of the reasons is that if you use group policy to lock down your workstations and use other tools to unlock or permission keys they sometimes have issues. Keys not unlocked etc.

Using secedit which is a purpose built MS tool almost ensures success in my opinion. I have yet to have any issues at all whereas I have had problems using Reggrant and also the Lockpermissions table.

Paul,

I use Wisescripts for my custom actions in my Wise MSI's and they dont need an additional engine to run them.

Does Installshield need the ISscript engine to run custom actions? If it doesn't then all good. I'm not really sure which is why I'm asking.

I think the main danger with ISScript is not in the repackaging process at all. Each packager can use whatever it takes to complete the installation process safely.

The main problem is if you decide to deploy a vendor msi with say ISScript engine version 6 included and another vendor msi later with engine version 5 and the vendor install is sloppy then you may break the ISScript engine entirely. I have seen this happen before and its ugly as it gets.

Where I work we took the stance to not allow the ISScript engine to be installed and while its more work to have to repackage vendor msi's...it pays off because we are not forced to manage the additions it brings with it. The same can be said for Merge Modules. We don't use them so we are not forced to manage them. These sort of considerations are what needs to happen at the start of any large scale enterprise project.

Hi Jim,

I agree, Installshield installs with ISScript are a pain in the neck and are very common. I do the same as you after I wrestled with different versions of isscript which casued some conflicts with some legacy packages I inherited. Repackaging these is the way to go, though you can also decompile the isscript and take whatever it does into a vbs script (I've done this a couple of times, its tedious but it works, assuming you know vbs and isscript).

However, you don't need isscript to create custom actions. If your custom actions are VBS, or dll calls, or anything other than Isscript based custom actions then it will not require the isscript.msi.

Haven't had any problems with merge modules yet, can you fill me in as to any problems you have heard of or experienced with them?

Hope that helps

Paul

Sorry for the late reply Paul

My only concern with merge modules is the management of merge module versions within a large organization. What if you decide to upgrade versions.....you will have to do regression testing on every app that uses that merge module. Who is going to manage that?

What if only 1 file within the merge module is different from the one currently installed.....wouldn't it be smarter to just add the single file instead of adding a whole new module.

This is all hypothetical of course......but with 30,000 workstations I have to think like this on a daily basis. One mistake and I could put 800 plus suburban bank branches offline at 9AM. If that happens....I'll come see you for a job :)

Got Runtime Error 713 on my MSI. help anyone