Prior to OS X 10.9 Mavericks here at the college we would use the option in the "Directory Utility" app to mount the Active Directory home drives. This was done by checking off "Use UNC path from Active Directory" but with OS X 10.9 Mavericks & OS X 10.10 Yosemite there was the adoptions of SMB2 which does not play well with Microsoft's version of SMB. We would have drives mounting but not the drives we wanted. We would normally want their home folder mounted as (ex. /studentname) but instead it was now being mounted as (ex. share/studentname). This is how we've been running for the past two years and haven't had much luck fixing it.
Today with the help of a co-worker we were able to come up with an AppleScript that fixes this. Below is the simple script that I saved as an executable app and placed into the /Library/Scripts folder in our images. From here I added the app as a login item in the default profile. Once any user logs in the script would check to see what the users name is then look to Active Directory to poll what their Home Drive is. Next the script converts the backwards slashes "\" (used in the Windows World) to forward slashes "/" (Unix World) then mounts the drive.
I've been testing this on a number of stations and now have it deployed out to some of our labs.
If you want to use this script you need to make sure you go into "Directory Utility" and un-check "Use UNC path from Active Directory" since we no longer need this and now relying on this AppleScript to do the work.
In the script provided you will need to change "DOMAIN" to your campus domain. For an example our college it's just "CAMPUS".
Here's the script below to use or feel free to download it:
When I have the free time I want to convert this into a .plist script to use with launch daemon instead of relying on an app in the login items to make it a little cleaner. Until then this will do the trick and something that I've been looking into for some time now without success.
Hope this helps out others that have been looking for a similar solution.
It's annoying that Apple has no easy solution for something that should be a major & required feature for it's Profile Manager. With the help of the post here https://discussions.apple.com/thread/6855393 by @Strontium90 I had gone ahead and created scripts that I now have running on my server that will backup the Profile Manager Database daily.
I've tested this and I was able to backup the database then erase/reset Profile Manager to scratch then run the restore and have the server backup and running with all the devices, groups etc.
For automatic backups I use the below scripts to automate a scheduled dump of the Profile Manager Database to both a local folder on the server as well as a networked mounted drive so I would have the databases in two locations.
This script is your “LaunchDaemons” script that sets the schedule. In one I’ve provided I have it set to 4:00am daily. You can change this to your preferred time.
Name of file “com.mactech.pmbackup.plist"
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
Once you’ve made needed changes to the above script place it at "/Library/LaunchDaemons /com.mactech.pmbackup.plist”
To load or make the script active you need to load it by running the following Terminal Command "launchctl load -w /Library/LaunchDaemons/com.mactech.pmbackup.plist”
Below is the script that the “com.mactech.pmbackup.plist” file run on the set schedule.
The First line dumps the database to the desktop so the latest dump is right there.
The Second line copies the file and placed it into a folder at "/Profile Manager Database Backups”. You need to either create this folder or rename this line or remove the line if you do not wish to have it.
The Third line copies the file to a network share. I have the server setup to mount the share on login so it’s always there. Change “RemoteServerAddress_&_Share” to your network share.
** For the Second & Third lines the files are renamed by adding the Date & Time (ex. October_13_2015_Time_H04_M00_profileManager.sql).
Here at work we have a 2008 Xserve and for the past couple years I’ve only used it as a simple file share server since the highest OS that could be installed was OS X10.7 Lion. I would love to use the server for more since it has plenty of HD space and when it comes down to it, the Xserve is still a powerful computer.
A couple weeks ago I decide to get the server running with OS X 10.10 Yosemite by doing a couple upgrades along with a OS X 10.10 modified install. At first I upgraded the ram to 16GB then installed OS X 10.10.3 Yosemite with the help of an article here https://github.com/TMRJIJ/OS-X-Yosemite-on-Unsupported-Macs that explains how to create an OS X 10.10 Install on a USB stick or drive that is modified to install on older hardware. Once I had the modified OS Install I plugged into the server and installed 10.10.3 without any issues until I realized how laggy the video was. This was both local video output and through screen sharing.
I think one of the big reason Apple removed Xserve from later OS’s past 10.7 Lion was due to the video card. OS X has become very dependent on the GPU and since the stock video cards in the Xserve are bottom of the line the cards they just could not handle 10.10 Yosemite. So from here I got looking online to find a fix.
After looking around I can across a video here https://youtu.be/9AZzSgIYIac where “N90X” decided to give this same project a try and he ended up swapping out the video card. With the help of this I was able to track down a video card off eBay that was originally a stock card for Mac Pro's. The card I purchased was a "Apple 630-9643 Mac Pro A1289 NVIDIA GeForce GT 120 512MB Video Card”.
As soon as I received the card I quickly installed it to now find the server running smooth video. Both the card video output and screen sharing ran smooth without any issues. So far everything looks great and you would never know this server was never supported.
The one issue I know of for this setup is OS Updates. If I were to update the server to 10.10.4 when it comes out the server will not boot as the update will replace the “PlatformSupport.plist” file which essentially tells the OS which hardware is approved to run. With that said, theres a quick fix, simply replace it. Just keep a backup of the file and once you do an update you can either throw the server into Target mode and replace /System/Library/CoreServices/PlatformSupport.plist or just add in the server model & ID info. For my setup I partitioned the primary HD and keep the old OS X 10.7 Lion install so I just need to boot into the old OS, replace the file then reboot.
All in all Yosemite works great on a 2008 Xserve after modifying a 10.10 Install and upgrading the video card. From here I will be installing Server App and using more features that Server App offers. It’s a great server for DeployStudio, OS Updates and more.
A few images of the server:
Install of OS X 10.10.3 Yosemite on Xserve
Xserve with upgraded ram to 16GB and the new/used video card
Old Xserve Video Card
New/Used Video Card that was needed to get the server running video properly
This past year I've been looking to step away from using Faronics Deep Freeze and find an alternative that will handle a similar task of cleaning the user profiles after a restart, set time or day of the week. Sure Deep Freeze has a lot of benifits but we wanted to look into a cheaper solution. For the past few months I've been running this setup in our busiest area at our campus (our student commons) and it has been working great.
Why do we need it? In the run of a day or week we can have countless users logging into a mac desktop using Active Directory credentials and over time the user profiles can eat away at the HD space. That said your average user is browsing the net and so their user profile may only be a small percentage but mixed in with users that dump files onto the desktop or other areas this space can build up fast. This is where Deep Freeze came into play. Deep Freeze would clean up the computer after a restart or set schedule to help keep the comptuer HD clear of un wanted files.
What do these scripts do? With the below scripts in place they essentialy remove any unwanted users. By default the script is set to remove all users except for the "Administrator" & "Shared" user. All other users will be removed. This can be adjusted easily to add other local users. The script included is set to run at 3:30am every Saturday morning. We went with this since most computers are sitting with a 1TB HD and we do not expect computer to fill up that quick. Having it set to a week also gives users a grace period for their files. If they forget to copy/backup files one day they will still be there the next day (unless it's the next day that the scipt is set to run). The other benifit is that if there is a power bump their files will still be located on the computer once it is turned back on.
How do these scripts work? There are three files as listed below. #1 is the launchd file that will run on schedule to run to run the primary script that does the work. File #1 is the file you can edit to adjust the time or day you wish to have the script run. ** Keep in mind, if you make changes after the script is deployed you will want to make sure you unload the .plist file and then reload the updated file.
File #2 is the actual script that does thew work to remove the users. There arre two main steps. The first step will remove all uses except for "Administrator" & "Shared". The second step dumps the files located in /private/var/folders/*. This folder contains cache files from the users that have logged in. We do not want to remove the fodler itself, just the contents.
File #3 is a simple command script that loads file #1. We use deploy studio for deployment so having this as part of the workflow just loads #1 script so we do not need to send out the command over ARD or manually.
On your Deploy Studio server go to your “DeployStudio” shares. This folder is normally at the root of your HD as the shares folder for Deploy Studio. (This can also be named something else or located elsewhere but most often this is the name and location. In the “Files” folder you need to copy the first two files “com.mactech.cleanusers.plist” & “delete_non_admins.sh”. Next go to the scripts folder and copy the ”load_cleanusers.command” file to this location.
From here open up the “DeployStudio Admin” application. For deployment you need to add these files into a workflow and run these files during post ghost.
To add the two files “com.mactech.cleanusers.plist” & “delete_non_admins.sh” you need to add “File Copy” into your workflow twice as seen in this image.
Since we already added the need files you just need to choose the “File” dropdown menu and pick the files as you can see in these images. As seen in the images you want to make sure each file is placed into the correct location. “com.mactech.cleanusers.plist” will be copied to “/Library/LaunchDaemons” & “delete_non_admins.sh” will be copied to “Library/Scripts”. Also make sure you “Automate” these tasks.
The next step in the workflow is to add “Generic”. With this step in the workflow select the “Command” dropdown menu and choose “load_cleanusers.command”. Make sure you check off “Postponed execution” & “Automate”.
From here the script will be loaded when the computer finishes post ghost.
The script by default that’s included is set to wipe all users except for the “Administrator” & the “Shared” user. If you have other users that you want keep on the system you can alter the “delete_non_admins.sh” script to reflect users you want to keep on the computer. You wouldn’t normally install this on laptops or individual computers but if you do make sure this script reflects the users that need their profiles keep.
As this script sits it is set to wipe the other users every Saturday Morning at 3:30am. You can easily change this by opening the “com.mactech.cleanusers.plist” file and adjusting the “StartCalendarInterval”.
Hope this helps those out that are looking for a DF alternative.