I had to re-image and re-configure a rebellious Mac Pro in one of our labs, but in the end forgot to enable Remote Management. Instead of wasting precious calories walking back to the lab, I found a way to enable it using terminal. Run these commands after SSH-ing into the remote machine:
cd /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/sudo ./kickstart -activate -configure -access -on -privs -all -restart -agent
This usually happens when you SSH into a different computer, reinstall the OS on that computer, and try to SSH into it again. In order to fix it you’ll need to delete a line of text from the “known_hosts” file.
This command-line tool displays a history of user accounts that were logged into the computer as well as the time and date of access from up to 2 months prior. It will even tell you the amount of time users spent logged in. I’ve had to use this method several times to catch high school students who were using their college friend’s usernames and passwords to login to our lab computers. So here’s how, its really simple..
The “Other” account option at the mac login screen is enabled by default. Networked users can login via Active Directory (AD) or Open Directory by choosing this option. However, in some enterprise situations it’s safer to hide the “Other” option. For example, our Art Department’s file server uses AD to manage student access to its its network sharepoints. One day I noticed a student was logged into the server itself (it’s located in one of the labs and looks like any other computer…don’t ask). Not good. By hiding the “Other” option from the login screen I was able to prevent students from locally accessing the server.
When you install CS6 using AAMEE, updates are disabled by default. If you feel the need to update anything in any of the Adobe applications, you’ll have to open AAMEE and create an update package installer. The only downside to this is that AAMEE searches the web for official updates, but not plugins or add-ons that are normally downloaded and installed manually. Thank goodness there is a simple workaround to all of this:
There will be an error trying to open Auralia after the image has been deployed. I don’t know why the problem occurs but after contacting Auralia support and conversing with them through email after a couple of weeks the error still persists.
The situation is that there is a corrupt database file. Every time a student logs in, Auralia cannot start unless it reads settings out of that db file.
If you’ve created a custom user template (when creating an image) and forgot to delete the user’s login keychain, this alert will appear each time a new user logs in.
jamauai's Sysadmin Blog 