Software Deployment

Hi.
I usualy use Secedit to set different rights.
I think there is an link somewere on this site that describes how to, but I don´t know were.

/M.N

As a *general* rule, I assign 'Change' rights to INSTALLDIR and 'Full Control' to any registry key that the app makes in HKLM. I use SetACL as the tool of choice where the client disallows my preferred route, a VB Script class wrapper (or WSC) for the ADsSecurity.DLL functions. I use the class/WSC because its syntax is so much easier than SetDACL/XCACLS/choose-any-other.

You may also want to assign rights by default to 'C:\Documents and Settings\All Users\Application Data\[AppName]' and similar locations.

This doesn't trap everything but it's a good start. Anything else can wait for UAT, as for the majority of apps I'm packaging I find that either its UI is completely inpenetrable, it requires a login to some host or some other hold-up.

I wish Wise Studio would come out with its own version of Sanur or CPAU. I find to RunAs an application just makes it simpler.. but then again I am just going for the easier route[:D]

ORIGINAL: cduplessis
Hi,
I would like to know how most of you handle the admin rights issue?
I normally:
Use regmon\filemon to see which areas are accessed by the application.
Then use xCacls or even CPAU.exe to give them either access rights to the folder or RunAs rights. Is there no easier method??[&:]


There isn't for XP and 2000, unless you want to get into Wise Macro or other type of scripting to automate permissions settings. Sometimes even that won't work because you have to open the app and see which reg keys are getting access denied - ( because the app creates them on the fly when opening ), THEN add them to the package. Wash, rinse, repeat until you get no more errors [;)]

I hear that Vista is much easier in some ways becuase it will create a virtual Win32 machine of sorts for apps that attempt to write to system directories, program files etc. It will fool the app into thinking that it's writing there, when in fact it's writing to the user profile area.

this reminds me to look at the Vista forum.

Hi folks,
somebody will have to do it right, i think. If you have an app developer who only knows the admin account, the deployment guys are paying the price. But to open up the hole system, only because it's the easier way can't be the solution at all. I'm afraid, we will be using regmon/filemon for a couple more years. That's the only way to correct the things, the developers have broken. Never had to elevate a hole app with runas and stuff like that. All my users are working on standard user since the rollout of XP.

Another tool to give a try for issues like this, is ACT (Application Compatibility Toolkit).

@Owen: Don't think that Vista will be easier for us on this issues. What Vista's Virtual Store does, is redirect registry/file writes to locked down regions to the users profile. The result will be as many ini-files or HKLM regkey for a given app as users on machine. Not exactly what i want. Therefore Virtual Store is disabled on my Vista packaging VM's.

Regards, Nick

ORIGINAL: nheim
.....If you have an app developer who only knows the admin account, the deployment guys are paying the price. But to open up the hole system, only because it's the easier way can't be the solution at all. I'm afraid, we will be using regmon/filemon for a couple more years. That's the only way to correct the things, the developers have broken. Never had to elevate a hole app with runas and stuff like that. All my users are working on standard user since the rollout of XP.
...
@Owen: Don't think that Vista will be easier for us on this issues. What Vista's Virtual Store does, is redirect registry/file writes to locked down regions to the users profile. The result will be as many ini-files or HKLM regkey for a given app as users on machine. Not exactly what i want. Therefore Virtual Store is disabled on my Vista packaging VM's.

Hi Nick, I haven't really worked with Vista directly yet in any packaging capacity, so when I heard that - wow! I can see where it would be undesirable to clutter up the user profile but IMHO it seems like a good trade-off for better app compatibility. But if you're in a mixed Vista/XP/2K environment and have to do permissions adjusting anyway.....it makes sense.

Agree on not elevating apps or opening entire systems....leaves too many holes. I'm surprised at the number of places still not locking down normal users, and places where IT people do daily functions like reading email, editing documents, etc. with their domain admin accounts. This is an invitation to viruses problems, worms, security holes etc.

Best,
Owen

Microsoft offers a new application manifest with Vista as a method of utilizing the mini registry / file system virtualization in Vista but it is bare bones virtualization. At Microsoft Management Summit I was shocked to see the big name packaging software vendors touting their software as being Vista ready but don't support the new manifests! I think what Microsoft wants their enterprise customers to embrace SoftGrid for the lockdown and I am a big fan of virtualization for commodity desktop environments because it effectively allows bad applications to work with a lockdown plus the other benefits of virtualization. With that being said it is an extra layer of settings that go into the user profile. I agree with aogilmor that this is a necessary tradeoff because I personally hate running around with process monitor and opening up ACL's. What a waste of time!

We rarely use the installation package to change any permissions. This is mainly to allow for the installation of an application by any method and still get the changes in place. Using group policies, I set any changes in permissions for files, folders, or registry settings. During any install that needs to have permissions change, i force a refresh on the GPo after the install is done.