May I make a suggestion? I am in a similar situation, I work for a school system and I have to be able to manage what apps users get and use. In OD, I use MCX to manage the absolute path apps can run from. So, I restrict applications to only be able to run from /Applications, and say all apps can only be ran from here. Then apps that I may want local admin to use but not the user I simply move them into /Applications/Utilities and that way the app is there, but the managed user cannot use them. This also prevents students from running skype from a thumb drive, because the path is not in /Applications. They don’t have the ability to write to the /Applications folder at all, so they cannot drop their own apps in.

Then you can set up a teacher group in OD and not even manage them at all for apps to run. This will be applied via their group policy. I find this more efficient than running approved software lists, because with out digital signing they can just rename the app to an approved one and get away with it, especially if they own it and it is running from their desktop. I tried digital signing in 10.5.2 and it was a hot mess, so I stopped using it. Could be way better now, but I haven’t changed my methods just yet.

Just to add something from my experience…

We had a state assessment testing software suite, which was written in Java and had a self update option, which was not optional. Anytime the State updated their server side, you had to update your client side. So to keep it simple, and easy for the IT staff when I built the package, I left the update folder writable, so that all updates could be downloaded and applied. Well, one student figured out that one nested folder in some application was writable, and they started dropping their own apps in that folder. Lone and behold, one student told another and with in like a week we had 100s of students dropping apps in this folder.

So, I had to create a network policy (via Casper) that hit every student machine, wiped out their Kansas Assessment testing software folder and copied the new one over, and this time that folder [b][u]was not[/u][/b] writable at all. This means that I had to repack the update and push it out manually anytime they put an update out. This is one of the caveats of using folder paths.

The upside to it, is it is really less work in the end. If I look at total “overall cost of ownership,” of my methodology of creating packages and images, this actually benefits me. Since I standardized everything from the base OS image, and then configure everything via post image scripts based on users/groups (students, teachers, middle schools, lower schools, etc.) I have to repack that application anyway to update the image. I use instaDMG and instaup2date python scripts to build my base OS. Then compile that base OS with all my packages in Casper. This allows me to have a pristine up to date image that will go on all my macs in my enterprise. Having this set up this way means I can keep a base image of what every Mac should have, whole deployment wide, and then build post image shell script that pull down packages for those specific group of users.

So, if you are going to keep your images up to date, you might as well repack your packages anyway when they get updated. This also gives you the chance to test the update.

The problem I ran into with the whitelist/blacklist options, were that if you did not use digital signing, the user could just rename the app whatever they wanted. If you did use digital signing, any and every single app with in the application’s contents. Some developers love to put other apps with in their App’s content folder. This gets super annoying to drill through each application with in it’s contents and put a digital signing onto every app with in it.

I went through this in 10.5.2 and gave up on it. It may have vastly improved, but even the iLife apps had issues. For example, garage band would not run because it was not allowing a bom file to go through. So I had to drill into that app in WGM, to that specific bom file in Garage Band, and allow it. After doing that once and seeing it fixed the issue I went to file path immediately.

[QUOTE][u]Quote by: Ebonfyre[/u][p]What about all the supplemental apps that live in the less evident areas of the system, such as CoreServices? How can you possibly ensure that you have all those locations taken into consideration?[/p][/QUOTE]

You have to add the path. For example, Adobe puts an app that validates the license file online in /Library/Application Support/ so I have to approve that path for CS4 to run. I have not had any issues so far with anything from the CoreServices folder.