Software Deployment

Try repackaging the app then try and deploy it via group policy in active directory, this will allow self heals to happen and possibly allow the features that require admin access to run.

That might not cut it cdupius, it sounds like the app itself is trying to do stuff not permitted under standard user security levels. If I followed the post correctly, the app works when you have admin rights, doesn't when you don't. Here's my two cents worth...

First off, no application requires local admin rights to function, no matter what the developers tell you. (that's a big pet peeve of mine) The true translation of that statement is that the application requires additional security rights that just so happen to be included in the "Administrators" security level, which of course includes rights to just about everything. That's like squishing a roach with an elephant. Total overkill, and a MAJOR security hole...

I strongly suggest that whenever a vendor states their application requires local admin rights, call them on it. Hold their feet to the fire and ask them exactly why does this requirement exist. Force them to justify it. (They will NEVER be able to!) The underlying truth is that they are ignoring MS SW Development Guidelines for the Windows OS. They are most likely putting data in the wrong place (i.e. user data in a system area) and decide to force you to DISABLE ALL SECURITY ON THE ENTIRE MACHINE to accomodate the shoddy design of their single application. (Yes, that what giving Local Admin rights is effectively doing!) Make it perfectly clear to the developer how TOTALLY UNACCEPTABLE that is!

But since this means relying on someone to fix a problem they were too clueless to notice in the first place... you often have to fix their app yourself.

What you need to do is find out exactly what additional security rights the application really needs. You can do this by turning all the security audits on and finding out exactly what is being denied access. Once you know exactly what the app is not being permitted to do, go into the Local Security Policy Editor and create a local security policy that grants access to only the specific files/registry keys/etc that the application needs.

This will produce a nice little .INF file that you add to your package. It should go in Windows\Security\Templates. At the end of your package install, add a custom action that launches SECEDIT.EXE and applies the security policy template that you created. (RTFM for details. "Custom Action" is in your packaging app and Secedit.exe is in Windows help)

Viola! With the new local security policy, you opend up access rights just enough for the application to function, and no more. The locked-down secure environment is maintained, and nobody has any of that %$&^# local admin crap.

Very true. Developers are under huge timelines and push out a lot of crap. Also keep in mind that it must make it past QA as well, so if it does not get fixed in QA then whos fault is it?

Daveinmn, I think you need to run a snapshot and capture the install and look deep into what is being installed where and pay great attention to registry keys and locations. The answer lies in your snapshot.

I'd call it the "vendor's" fault, which is an entire company, not an individual. To be brutally honest, I don't care about the vendor's internals, just the end product. That's what I'm buying and I expect a certain level of quality. One factor being that it doesn't break other apps, and security.

For this instance, though, I really don't see what a snapshot will tell you . If it works as an admin but not a user (I think that's what he wrote up there) then I'm 99% certain that it is installed correctly but Windows Security is denying access to some piece of the app. It might be trying to write to the Progeam Files directory, Local Machine registry hive, or something else not permitted with standard User rights. Turning the Security Audit on to log everything, then running the app as a user until it fails will log an Access Denied in the Security log. That's what you need to open up in the local policy.

Of course you may need to go through that process several dozen times until you find every brick wall the app will run into... In the meantime I usually have the vendor's customer service rep on the phone. Poor them. [:(]

The snapshot will show you a list of all of the file copy and registry addition/modification processes. You could very well see an obvious area that is locked down that has ...I dunno... INI files or log files or something that is definately being written to on a regualar basis like at application launch. That is where the snapshot will halp you. It may also be a HKLM registry entry that is being modified on app launch, so you could assign permissions to that specific key via a group policy or a specific registry key. The after snapshot is going to be where you find the problem, or at least the place to start.

Once could do it that way, but that only tells you which files/regkeys have the potential of being denied access. The security audit will tell you exactly what was denied.

Probably the best approach would be a combination of the two. That will permit you to discern some trends so you don't have to go through the failures one at a time. It will be much easier to see if an entire directory or subkey needs to be opened up.

Personally when i build a new package I check it before even doing a test intstall to remove the obvious points of failure.