Crashplan Pro + Drobo Pro = Warm Fuzzy Feeling

We have just recently implemented Crashplan Pro as a primary backup strategy for our Mac machines.  We will slowly be rolling this out to all of our Mac users, especially laptop users and potentially PC users as well.  A few things that we love about Crashplan Pro.

  • They have a 25% discount for non-profits.  Just ask them.  I love vendors who do this.
  • Crashplan is easy to use from the server perspective and invisible to the end user.
  • It is very flexible and simple while remaining powerful.  They have really hit the sweet spot on this.  You don’t need a PhD to configure it.
  • Users can back up from anywhere across the internet.  That’s right… anywhere.  Meaning my Macbook Pro is still being backed up even when I have it at home.
  • They offer a 30 day trial.  You can run it, fully featured, for 30 days before making a decision.
  • Multiple backup targets.  My Macbook can back up to my local firewire drive AND the crashplan server.  Ok, so I’m paranoid.

Implementation was easy.  We installed the server product on an older server chassis and connected it first to local storage, which was fine but not really enough for all of our users.  Next we purchased a 16 Terabyte Drobo Pro (8 drives x 2TB).  For less than 3k for 16TB, the Drobo Pro is a great backup storage solution.  It’s iSCSI, which makes it a snap for connecting to the Crashplan server, and while I’m not convinced that I would use a Drobo for primary storage of mission critical data, this is a great product for backup data (video archiving, files, etc).  Besides, I trust EqualLogic to handle my primary storage anyway.  We’ll use this same storage (and server) to also store our Veeam backups of our VMware servers.  Now, I should also mention that we have a great offsite backup solution for our critical data.  I highly recommend you look into One Safe Place if you are looking for offsite storage.  I realize that Crashplan offers offsite, but the SQL and Exchange tools that One Safe Place provides are amazing.  I would never recommend that you only backup data onsite, you should always offsite mission critical data in some fashion, but in this case we are talking about the data that resides on individual laptops, not servers.

Licensing for Crashplan is simple.  Once you have purchased your license, you just enter the license key into the server (one time) and your clients will be licensed.  In our case, we purchased 25 licenses.  One of our hurdles to implementing more Mac computers on our campus was backup.  I should also mention that the Crashplan Pro client works for both the PC and the Mac, so users on both platforms can backup to the same server.  Mac users and PC users can use the same client licensing.

There had been lots of discussion around this solution amongst Church IT guys from around the country.  If you are church or business owner looking for a solid backup solution, you should look at Crashplan Pro.

Adding Macs to an Active Directory Domain – Part II

In a previous post, I discussed our process for adding Macs to our Active Directory domain and the issues we encountered with the native Apple Directory Utility.  In this post, I will discuss why we chose to go with AdmitMac for our deployment.

In my original testing we had several issues with getting AdmitMac to work.  Namely, getting the drive mappings to display on the user’s desktop on login.  However, one thing that I have come to appreciate about the folks at Thursby software is the quality of their technical support.  Even though we were not a licensed customer, one of their support reps spent an hour on the phone with me walking me through the configuration step-by-step.  Don’t let that give you pause, there really isn’t so much that I needed an hour of support… it really is simple, but he walked me through everything and answered a ton of questions.  Good stuff.

So let’s talk about the reasons that we used AdmitMac.  First, AdmitMac is easy to install.  The wizard will walk you through several options and will install a new item into your Directory Utility.  Notice that it does not use the built-in active directory service.


Once the software is setup, you will go into the AdmitMac Service to make any changes.  You will be given several options for authentication.



Notice here that you are able to give the users the same options for local or network home that you can give them using the Apple utility, however now in one place.


The local login policy was the one major issue we found with the built-in Apple AD service.  Using AdmitMac, you can set the number of times a user can login remotely before needing to attach to the domain again, AND the user will have administrative priviledges when they are remote as well.  Not having administrative privledges remotely with the same user account was the deal breaker for us, and what ultimately pushed us to this solution.


Here you can set who is the admin of the computer, either domain users or groups.

By default, domain users are placed into a new set of folders on the local hard drive, specifically Macintosh HD/domain/domainname/username.In addition, the AdmitMac product has a “home mover” utility that will take the local user account that already exists and make a copy of the files into this new folder structure, with all the appropriate permissions in place.  Thus, little to no impact on the user.

I was able to successfully use “home mover” to move my files into the new structure.  Note that if the user’s home directory is huge, and there won’t be enough diskspace to make a copy, AdmitMac will let you know before it starts.

Overall, we have had zero issues with our AdmitMac deployment over the past month.  I would recommend you take a look at Thursby software if you are looking for an easy to use solution for Macs and Active Directory.

Adding Macs to an Active Directory Domain – Part One

We continue to add more and more Mac computers to our network.  Up until now, we have been happy to simply have the Macs be standalone machines, and haven’t wanted to undergo the learning curve to add them.  We are now at a point where managing user accounts and access has become difficult, and we want to move all of our Mac users onto network accounts.  Thus begins our journey into the abyss.

Starting out, the Mac integration seems simple enough.  Using the built-in Directory Utility, you are able to bind the Macs to the domain with very few issues.  Simply entering the fully qualified name of the active directory domain and clicking “Bind” should do the trick and add the machine to AD just like a Windows machine.


You are presented with several advanced options during this process.


Our first hurdle was determining what each of these options do.  In a nutshell, here were our findings (and our default settings above.)

  • Force local home directory:  This is something you will want to do, especially if you want applications to be available when users are off the network.  Not checking this box will place a ton of files on your server in the “network user home” directory.  That means that applications get installed here, the library folder is here, music is here, etc.  Not a good thing if you are a laptop user or are ever offline, and it creates more network traffic as well.
  • Use UNC path from AD:  Checking this box will map the AD user home folder upon login and will place it on the dock by default.  This is pretty useful if you have users who use their network folder a bunch.  In our situation, our network home folder in the windows environment was mapped to the user’s My Documents using Group Policy and offline files, so most of our users have a lot of documents there.
  • Default user shell:  Just leave it as it is.  /bin/bash works just fine.
  • Create mobile account at login:  This is the most tricky one. So we’ll talk about it later in detail.

Here is what show up under the mappings tab of Directory Utility.


Unless you really have a need to change anything here, it works great when left alone with the defaults.  And then we are left with the administrative tab.


The administrative tab is important for administering the machine.

  • Prefer this domain server: This is fine if you really want to set it, but is not really necessary in our case.
  • Allow administration by:  This is useful when the user is connected to the network and will allow the active directory network user account to make changes on the local machine… if they are a member of one of the groups added here.  In our testing, this seemed to only take effect at the GROUP level not at the user level, meaning we were unsuccessful in adding an individual user here for administration.  ALSO NOTE <ALERT> i.e. this is important! This seems to work fine when a user is connected to the network, however, what happens when the user is at home and can’t see the network?  Any guesses?  If you guessed that the user’s admin privileges are not cached and the user WILL NOT have administrative privileges when they are offline, you are correct.  Impact of this is that a network user goes home and while at their house needs to install an update, etc.  Because they can no longer see the network they will not be able to approve the update unless they have a second local user account with admin rights.  Not good, and probably confusing to the user.  This is a pretty major flaw in my opinion.

Mobile Accounts

Let’s talk a little more about creating mobile accounts. Creating the mobile account at login seems like a great thing to do.  In fact, it is the ONLY way that your users will be able to login using their network credentials when they are offline.  (Under Tiger, there was an option to cache credentials, which has now been replaced by Mobile Accounts.)  As we have previously mentioned though, if the user is offline they are no longer an admin, which really limits the ability of the user to administer the machine when off the network.  In addition, the mobile account user will be able to sync their folders between the network and the local machine.  This is great in theory, however not nearly as intuitive as Microsoft’s offline files, which automatically determined the latest version and save the appropriate one.  In the Mac implementation of sync, the user has to choose which version of the file to keep, which is dangerous in my opinion, and an extra burden on the user.  We choose NOT to sync the files for these reasons.

So where did we finally land on integrating our Macs with Active Directory?  Due to the limitations of offline administration and creating mobile accounts we decided to take a look at a few third party products.

Next time:  How we implemented Macs in Active Directory with Admitmac.

Mac with Parallels and the PC network

We’ve slowly been migrating our Arts department over to the mac platform, since they already use macs for Final Cut and some of our graphics apps.  We’re a windows network, and I’m a windows guy, so that transition has not been one I was especially looking forward to.  To my suprise (I can hear the mac guys giggling in the background) I’ve found the mac to be very stable and very easy to implement.  We’re using Parallels as a way to integrate our "Windows Only" apps.  With the new drag-and-drop functionality between XP and OS X, the seamless mouse controls, and coherence mode… I can’t determine why I need my PC laptop any longer.

This video really shows off what it can do.  Remember, until 6 months ago, I hated the mac and wouldn’t touch them.   I guess you can teach an old dog new tricks…