Part of what I do involves managing Pearson PowerSchool, our Student Information System (SIS). One of the common annoyances teachers have had in years past with PowerSchool is opening it's gradebook. The gradebook is a Java application that requires logging into PowerTeacher and downloading a JNLP file every time you want to open it up if you're on a Mac (as all of our staff are).

With PowerTeacher Gradebook 2.6 Pearson has created a new Gradebook application that can be installed into the Applications folder and initiate the Gradebook (including future updates to the Java app itself). Unfortunately the app isn't signed and thus cannot be opened on 10.8 when initially dragged to the Applications folder with the default Mac App Store and identified developers setting in Gatekeeper. For teachers that have administrative access to their machine, walkthroughs aleady exist for resolving this issue but for those of us who are administering our deployments through a management suite such as Casper this takes some strategic thinking.

My goal was to avoid setting Gatekeeper to be wide open in order to accomodate this one application. Initially I started to follow the method outlined on Charles Edge's excellent blog Krypted. This method utilizes the scptl command to create a label for the Gradebook and whitelist it. This is how the security assessment policy subsystem of OS X manages rules for application security. Unfortunately this didn't resolve the problem when attempting to open the Gradebook application. According to Charles's post, the scptl framework isn't perfect and feels like it's still just a start to Apple's security framework management with Gatekeeper. This is all I can chalk my outcome of the process to at the moment but let's head onward and upward to the resolution.

I called JAMF support to see what insight they could offer. Let me just say that JAMF support is astounding and they have some brilliant engineers who understand OS X deeply. After reading this Apple Knowledgebase article JAMF support found that the error message we were receiving was related to the OS thinking that the application had been modified by someone other than the developer. Stepping back from the situation for a minute I'm really unsure how this isn't a bigger issue that Pearson has had to address. The application itself was downloaded directly from their teacher portal once logged into our account so the permissions were inherited upon that download but that's neither here nor there. If you're in a similar situation, the fix may be to change the ownership of the application to root:wheel using the change ownership command below.

*sudo chown -R root:wheel /Applications/Gradebook.app*

This worked successfully for me and allowed our teachers to open the application with standard accounts and for me to push it out to our teachers through Casper without a problem.