Mobile Accounts: Cont.

As we’ve begun to setup our MacBooks with mobile accounts we have run into a few fairly severe problems. The first, and most difficult problem has been the Mobile Accounts selectively choosing which rules to follow when first building their user accounts.

When you are setting up Mobile Accounts you use the Workgroup Manager tool to set rules for the syncing process. These allow you to specify which files on a users computer are synced and at what intervals. This way you can tell the server to Sync all of the users important documents, while ignoring iTunes Libraries or iMovie files that would eat gigs of server space. When first enabling mobile accounts Apple does a pretty good job with the default rules knowing not to back up such files as the Library Cache but by default it syncs user/~ which would be every file within the users home. In addition to adding movies, pictures, and music to the do not sync list we removed to user/~ which would effectively only sync the documents folder. We even went into the documents folder and put the Microsoft User Data into the do not sync folder. The idea was to be extra careful so that the syncing would not overwhelm our very limited bandwidth.

What we did not take into account was that in order to build an accurate replica of the users home directory on the computer we needed all of that extraneous information such as preferences and mailboxes that were stored in the Library file. When logging into the users accounts for testing and confirmation of a successful sync we realized that none of the Mail clients were properly setup and that no bookmarks or old email was transfered. Initially, we thought we could solve this problem simply by adding the directories to the sync list in workgroup manager and forcing a resync where the network would override the client settings. Unfortunately we couldn’t find a way to do this. Upon every subsequent log on the settings were not merged or override and instead were simply ignored by the syncing process.

The only solution that we have been able to find is to complete delete the mobile account created on the users notebook, and then rebuild the home directory from scratch. A very long and tedious process, but at least it solves the problem.
The second problem we came across we still don’t have any solution for. In order for a user to switch from Mobile to Networked accounts or visa versa they are forced to do a complete shutdown or reset of the machine. In other words if a user logs out of their network account at work, then take the notebook home they cannot log into the mobile accounts without first shutting down the computer. Its interesting to note that they can convert from/to a mobile account if they are logged into the computer when the change occurs, e.g., plugging into the network after originally logging into the computer while offline. We’ve made a little process into this problem, it used to require a restart between every logout/login even network to network but that problem seemed to solve itself giving us no clues as to the cause or solution.

Mac OS X: Mobile Accounts

Over this past week, spring break in my district, we prepared over 130 MacBooks for deployment in our two middle schools, Hinsdale Middle school and Clarendon Hills Middle School. The idea of course is to provide our teachers with the ability to utilize advanced technologies in the classroom while making it more convient for them to do the preperation and grading required to maintain that classroom. We made the decision to provide our elementary school teachers with an Intel iMac in the classroom (In addition to the 3 g3 iMacs, and 5 g4 ibooks for students), and the MacBooks for the Middle School teachers. I was not a part of this decision making process, it was before my time, but to me the purpose of providing the teachers with a MacBook instead of an iMac is to allow them to take there work home, or at least out of the classroom enviornment.

Management of Notebook accounts is a little more difficult then the typical user account, in order to create a managed enviornment for the user and maintain the integrity of your network you are faced with 3 options: Local User Accounts, Standard Managed Accounts, and Mobile Accounts.

Local User Accounts

The local user account option is the standard laptop setup that most people use. It consists of an account locally stored on the computer, with all the users data kept on the internal hard drive of the computer. This solution is far from ideal in a number of ways. First and foremost the user can only access their data from that particular laptop and not from any other computer on the network. Should some component of that laptop fail, like the hard disk, the user can easily lose all their information or at least lose access to in while the machine is being repaired. Of course the information can be backed up to an external source but unless that process is simple, and seemless to the end user you will likely not have much success. Either the user will fail to backup, or you and your staff will have to backup each computer personally.

The other downside to local user accounts is a loss of control over that system. By operating the computer completely seperate from your network you surrender a lot of control that you have over the security, integrity, and stability of the client. By not managing that account you are forced to either give that user administrative access or risk their inability to control vital functionality on their machine such as the ability to add access to their home printers.

Standard Managed Accounts

A standard managed account is what you will typically have for any user on your network be it students, teachers, employees, or clients. This is the layout where your user can log into their account from any computer on your network and access their files, and also allows you complete controls over the user experience limiting everything from the software they access to the system preferences they can modify. This system also has built in protection of the user's data by not tying it to any one machine or compontent that can fail. Unfortunatly for a notebook this limits the amount of portability. Of course if your intention is for the machine to only be used in your network, like a student machine for the library or classroom this may still work. However, in a situation where you want your user to be able to leave the confines of your network this leaves the machine either crippled or you have to create a local user account for use at home. Creating a local account for home use sort of defeats the purpose of the network accounts. Your users will eventually start using only the local accounts because that will work both on and off network again defeating the whole purpose of a managed account.

Mobile Accounts

A mobile account refers to an account is well...mobile. The account is fully managed offering all of the benefits above, but adds in the active syncing between both their local machines and the network. Setup is rather simple, just turn on the mobility features in workgroup manager. Then every time the user connects to your network the local and network accounts are synced automatically, providing both an automatic backup and the ideal mobility situation. You can still manage their accounts and control their access and privledges while still allowing them the ability to access their information off network. This functionality is built into Mac OS X 10.4 server, and I expect like everything else to see a major performance/functionality improvents in Leopard.

After much discussion our district chose the obvious option of mobile accounts, and we begin rolling them out tomorrow. I will be making followup posts discussing any problems or challenges that we face in the coming week.

Mac Browsers: Webkit vs. Safari

Browsing the web on the mac has always been a interesting endevour. The web has long been designed for the PC and specifically Internet Explorer 6. When Microsoft ended developement on IE5 for the Mac, we lost a valuable tool in our toolbox for compatability. Now, we mac users are routinely forced to surf with multiple web browsers switching from Safari's great user interface to Firefox for compatability, and Camino for speed. I'm not going to go into all of the different browsers here, instead I'll just point you to this article over at Macintalk with some benchmarks.

What I found most interesting in that article was that they were using the nightly builds of WebKit in substitution for the current Safari browser version 2.0.2. Safari is based off of the KHTML open source rendering engine, and in exchange for using the source Apple is obligated to release their changes to the open source community, and the open source project around Safari is WebKit. As the Macintalk articles shows, this nightly build is well ahead of the other browsers in speed which has been my biggest complaint about Safari.

Installing the nightly builds of WebKit is as easy as you would expect on the Mac, a simple drag and drop you your applications folder is all it takes. The first thing you'll notice is that the icon for WebKit is the familiar Safari compass with a darker dial and a gold rim which is nice for differentiating it in your dock from Safari. Upon opening WebKit you will see your homepage has been replaced by a WebKit launch page instructing you how to report bugs, contribute to the program, and notifys you if there is a new build of the browser. Don't worry, the launch page only shows up when you launch the program itself if you simply close the browser window and reopen throughout your daily use your regular Safari home page will appear, but this launch page is really useful for reminding you about a new build of the software if you wish to update.

Webkit itself looks just Safari, it even calls itself Safari in the Apple Menu. All of your Safari bookmarks and settings are automatically transfered into Webkit, and any changes will be shared with Safari. Really you see no difference between Safari and Webkit aside from the speed and compatability fixes though keep in mind these are nightly builds not final releases of a browser so you may find some stability problems some nights. If you aren't interested in actually testing and contributing to the webkit community you might simply find a good stable release and only update it every couple of weeks or so. (I'm running revision 20648)

If you are looking for an easy way to update WebKit every night, I'll point you to NightShift, a utility that will update the new version each night and keep the previous version in an archive just in case a new build is unstable.

All this begs the question, why hasn't Safari been updated in so long if WebKit is so far ahead? The short answer is Leopard. Apple wants to squeeze every performance increase it can out of the OS Update and holding a new version of Safari until then will provide a recognizeable boost for every average user. So download WebKit any enjoy a little piece of what Leopard has to offer.