Volume Number: 23 (2007)
Issue Number: 06
Column Tag: Network Administration

MCX: Client Wrangling 101

How to gain and keep control of your clients

By Ben Greisler

MCX is short for Managed Client for OS X. In a nutshell, it allows OS X clients (machines, users and groups) to be controlled (or managed) to a certain extent by OS X Server.

So what do you mean by managing my clients? What can I control? These are good questions and the easy way of answering that is to whip open a copy of Workgroup Manager (WGM) and peruse the options presented in the various tabs and windows. WGM shows us that we can manage three basic account levels: Users, Groups and Computers. Each of these has its own capabilities in terms of what can be managed. We will see that there are items that can be managed in each type of account while others are specific to the type of account.

For the scope of this article, we have to make some definitions. While MCX can be defined as controlling any aspect of a client which could include defining a location of a home directory or if they get a mail account, etc., but for this article we will consider the management choices based in the Preferences section of WGM.

If you are new to the world of directory services, a central repository of data, and want a quick rundown on it, here it is. If you want a really deep view of it, this article won't do it for you. How OS X uses LDAP (Lightweight Directory Access Protocol) can be its own series of articles and exceeds the scope of this article.

OS X uses a directory service called Open Directory. This is Apple's branding of their collection of directory services. There are a number of directory services out there including iPlanet (Sun's LDAP implementation), eDirectory (Novell's LDAP implementation), Active Directory (Microsoft), and NetInfo (NeXT/OS X). Apple's directory service is based on OpenLDAP, an open source LDAP implementation and was designed with a plug-in architecture for extending its capabilities.

The important piece of information that we want to understand about how Apple uses LDAP is that it stores information about users, groups, computers and a lot more. This information is stored in the OD Master and replicated to any OD Replicas. The information is made available to all computers that look towards OD for this information. The information is stored in a structure known as a schema. You can view the Apple schema located at:

/etc/openldap/schema 
(type in Terminal: "less /etc/openldap/schema/apple.schema" to view)

To view the information related to a single user, go to a Terminal window on your OD Master or Replica and type in:

dscl /LDAPv3/127.0.0.1 read /Users/joeuser

You will get a response that starts off looking like this:

nameserver:~ joeuser$ dscl /LDAPv3/127.0.0.1 ¬ 
read /Users/joeuser
apple-generateduid: C4BC70B7-9916-4C75-8088-594AFA3DC4DE¬ 

apple-mcxflags: <?xml version="1.0" encoding="UTF-8"?>¬ 

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"¬ 
 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">¬ 

<plist version="1.0">
<dict>
        <key>has_mcx_settings</key>
        <true/>
        <key>simultaneous_login_enabled</key>
        <true/>
</dict>
</plist>

The record will go on for a few pages with all the information related to that user. To view information regarding a workgroup, the same command is used but it will look something like this:

dscl /LDAPv3/127.0.0.1 read ¬ 
/Groups/workgroup

An interesting demonstration of how data is stored about a user, group or computer list, is to make a new entry, say a user, and run the dscl command on that user. Now go back and modify the users preferences (more info on how to do this later in the article) and run dscl again. You will see much more information being presented.

To allow MCX control of OS X clients, you need a server that is either an Open Directory Master or Replica. Of course, if there is an OD Replica, there is going to be an OD Master -- somewhere -- by default. There are many articles that show you how to set up an OD Master so we will not cover this directly in this article. That said, we need to review some very important aspects of an Open Directory based systems.

DNS is critical. Repeat 10 times and check it 11 times. In my experience, DNS issues account for the grand bulk of OD issues. Check forward and reverse resolution of the server's hostname at both the server and the client. If the clients refer to different DNS servers, make sure the records are the same on all of your DNS servers, or at least return the same information. Use dig early and often.

A solid network infrastructure is necessary. High latency and dropped packets can wreak havoc on MCX. Ping the server from the clients and check the results; you should have no dropped packets and latency times should be consistent and low.

While not absolutely necessary, a gigabit Ethernet connection is a plus. This is especially true if you are using network based home directories. If you are pushing out MCX via wireless networks, reconsider it. I know I will get a lot of flak for that comment, but my experience shows me that the bandwidth available in a wireless connection is barely enough to ensure that a client gets what it needs fast enough. You certainly aren't doing network based home directories wirelessly, but you may have mobile accounts with portable home directories. If you are having problems with your managed clients and you are connecting them wirelessly, try using a wired connection for testing and see if your problems go away.

There isn't much magic here except to join the client to the OD directory system via Directory Access. Do the tests listed above and make sure that the client can log into their OD account. A nice quick test to make sure the client machine is seeing the directory information once it is joined to OD is to go into Terminal and use the "id" command:

id joeuser

You should get a response such as:

uid=1025(joeuser) gid=20(staff) groups=20(staff), 1025(workgroup)

This shows you that the client machine is capable of communication with Open Directory.

Fig. 1 - Configuring Directory Access

Your primary tool for dealing with Open Directory and MCX is Workgroup Manager (WGM). It is used to make accounts, set up shares, define network views and view directories. WGM is installed as part of the server tools from the Admin Tools disk that comes with OS X Server or can be downloaded from:

http://www.apple.com/support/downloads/
serveradmintools1047.html

While the server admin tools are installed by default along with OS X Server, it is a good idea not to run them on the server. Pick a machine to be your admin station and run the tools from there. Also, make sure that you run the proper version of the admin tools, so that you use the 10.4 admin tools on 10.4 server. If you mix 10.3 admin tools on 10.4 server or vice versa, you are looking for trouble.

There are two basic ways to connect WGM to the directory. One is to connect directly to the server by using the "Connect" menu item. You enter the IP address or hostname of the server along with the directory admin's name and password. This is what you want to do when you need to see what disk shares are available on that machine. For any other purpose, I recommend skipping the "Connect" dialog and use the "View Directories" menu item. This needs to be done from a machine that is bound to the OD via Directory Access. The difference between the two methods is that, the "Connect" dialog method, gets you access to the directory and any machine specific options which are typically the disks or printers connected to that server and the "View Directories" only allows connection to the directory information. This is the preferred method if you don't need access to the machine specific items.

One item that I want to point out is the Inspector option. Under the Preferences options there is a choice for 'Show "All Records" tab and inspector.' Checking this box will activate an additional tab with a bull's-eye symbol in it alongside the tabs for Users, Groups and Computer Lists. It will also activate the "Inspector" tab in the informational panes in the account information section on the right of the application. Turn that on and you have unfettered access to the account records. This is a powerful tool and can be dangerous in the wrong hands; but, it can also allow greater understanding of the account information. Be careful with its use, but be glad it is there.

Fig. 2: Turn on the WGM preference for the inspector

Fig. 3: The inspector grants access to items the regular WGM choices don't

Fig. 4: This is the raw data available in the Inspector tab

Fig. 5: There is an Inspector tab available within the windows

There are four basic areas within the WGM window: the toolbar along the top, the directory bar just below it, the accounts list on the left and the account information on the right that shows all the record information for the accounts. The lower areas change when the Sharing, Network or Preferences button is chosen on the Toolbar. This reflects the specific uses of these buttons.

A very important, but sometimes confusing aspect of WGM is choosing the right directory to view. You choose the directory you wish to administer by using the not quite obvious pull-down menu right under the toolbar. It doesn't really look like a pull-down menu, but it is. There is a padlock symbol at the extreme right of the bar and it is used to authenticate to the directory that you want to administer. Even though locked, you can still see the records within the chosen directory, as most directories allow some level of anonymous browsing. On the left side, under the pull-down menu, you will get choices consisting of Local, Search Path, Other and any directories that WGM can see. Those would typically be the directories that the machine is bound to on which WGM is running. One interesting item of note is choosing the Local directory. This shows the contents of the NetInfo database on your local machine, and yes, you can manipulate your local accounts using WGM.

Fig. 6: The arrow next to the Dock icon shows they have been modified

Fig. 7: Workgroups have a similar structure to the Users

Fig. 8: Workgroup preferences look similar to the User and Computer List prefs.

The Accounts button is where many admins spend the most amount of time. This is where you set up users, workgroups and computer lists. The tabs in the left pane allow you to choose which of the three types of accounts you wish to administer. You can administer existing accounts or make new ones by clicking the choices in the toolbar. Apple has done a nice job making the administration of individual accounts a straightforward process and the choices in the right side account information panes are mostly easy to navigate through.

Computer lists are similar to users and workgroups in many ways being a type of account, but there are a few things to understand about them. As computer lists refer to the actual hardware, we need to define the hardware using MAC addresses, but this could be a real hassle if you don't want or need to manage your computer hardware. WGM handles this by having three default computer lists, Guest Computers, Windows Computers and All Computers. All machines that are not defined in an explicit computer list become a member of the Guest list. You can set the preferences of the Guest list the same way as any other list by clicking the Define button in the pane.

You can add specific machines to the computer list by either entering their MAC address manually, or using the browse button, which is the one with 3 dots on it. Keep in mind that you need to use the MAC address of the built-in Ethernet for the MCX to work properly.

Fig. 9: The computer lists can be built manually entering the MAC address or using the browse button

Fig. 10: Computer Lists have an additional preference available, the Energy Saver

Fig. 11: You need to specifically choose to define the preferences of all the Guest list computers

The information containing the preference records is stored in a cache on the client machines. This is so the preferences can still take effect even when off the network, say for Mobile Accounts. You can adjust the life of the cache from the default 17 days to whatever you feel is right for your environment. If you set the cache to 0, then no caching is done. You make these changes in the appropriate computer list under the Cache tab. You can also force an update by clicking the Update Cache button.

Fig. 12: You can define how often the MCX cache is updated

So how can I control my user's experience? That is a common question asked by most admins. With OS X Server the answer is MCX. Let's use a very basic example and control how a users Dock will appear. In WGM, we go to the users account, joeuser in this example, and click on their name to highlight it in the accounts list. We then click on the Preferences button in the toolbar. This gives us a display very similar to what we see when we click on System Preferences on any standard OS X install. To discover what we can modify, just click on any of the icons representing the preferences you wish to modify. We will click on the Dock icon. There are two tabs presented, Dock Items and Dock Display. In this example, I have clicked the Always button in the Manage bar. This means that every time a user logs in, this preference will be managed. The user may be able to change the preference during the time they are logged in, but the preference will revert to the way we have set it at each new login. The Once choice means that the user will be presented with the preferences I have set the first time they log in, but if they change the preference, their choice will over ride what I have set. This is handy if you want to allow the users freedom of choice, but want to present them with a certain defined environment as a starting point.

In the Dock Items tab, I have also clicked the "Add other folders: " buttons for My Applications and Documents. As we see in the picture, the two folders now show up in the users Dock. In the Dock Display tab, I have chosen 'Always' in the Manage bar and 'Right' for the position on screen. And as we can see from the picture, the Dock is indeed on the right.

Fig. 13: By picking "Always" the chosen preferences will be active at each login

Fig. 14: We have added items to the user's Dock

Fig. 15: This is the result of the user's modified Dock preferences

You can do similar preference settings in Groups and Computer Lists. The one thing to note is that not all the same choices are available in all types of accounts. For example, only Computer Lists allows you to make changes to the Energy Saver preferences. It isn't even an option in the Users or Groups tabs. Also, you can't modify the Scripts, Login Window or Options in the Login preferences for Groups. You need to check around and see what choices you have at what level. The items that have had changes made have an arrow next to their icon. It makes for a quick check as to what has been modified and what hasn't.

Fig. 16: Not all types of accounts can manage the same things

MCX Precedence Rules

So, a logical question to ask at this point is "What happens if I set the same preference in all three types of accounts?" You decide to get cute and set the Dock location on the right for a user account, the Dock on the bottom for groups and on the left for computer accounts. Which will win? In this case, the user preference wins, but how do you figure it out?

There are three levels of precedence in MCX: override, inherit and combine. Override precedence says the user preferences trump computer preferences and both of those trump group prefs. This is used when the preferences are set for two or more types of accounts that are active when a user logs in. A user with a Dock preference set may also be a member of a workgroup that has a Dock preference set and be working on a machine that is in a computer list that has a Dock preference set. In this case, the override rule prevails.

In the case of a user who is a member of a workgroup and logs into a machine that is part of a computer list and there are preferences set for each type of account, but when specific preferences don't overlap, the inherit mode kicks in. Say the user has their Dock preferences set, the workgroup has a Media Access preference set and the computer list has a Printer preference set, all three preferences become active.

The last situation is a combining of preferences. This is where the same preference is set on different types of accounts but they don't clash with each other. We might say that a certain folder should appear on a users Dock and another folder show up in a workgroups managed Dock. If the user is a member of the workgroup, both folders will show up on the Dock.

Clear as mud? Experiment and see what the results are first hand. It will help cement the concepts in your mind.

The Preference Manifesto

After looking around WGM for a while, you may notice that not everything can be managed by the available icons. We do have another chance at managing applications that aren't already part of WGM and this is done using the Preference Manifests. In general, any application that uses plists to control the preferences can be controlled by WGM and MCX.

You may have noticed in the Preferences pane a tab for Details and a listing of plists that grew as you added more managed preferences. These are the plists that get pushed out to the client machines. You can edit the plists in the editor or you can add a plist from an application that is not normally available in the Preferences panes, such as iTunes.

In the editor, you will be supplied with a parsed view of the XML format in which the plists stored. You will notice that the information will reside in high-level headings named, 'Once', 'Often' or 'Always'. 'Once' is a preference that is set but can be changed permanently. 'Often' is a preference that is set, but can be changed and will reset itself to the original value when the user logs back in. 'Always' is a preference that is set permanently and cannot be changed.

Troubleshooting

So, what do you do if you have an issue where the clients just don't seem to be responding to the MCX that you have set? The first step should be making sure that the client machine can see the server. Ping the server via the hostname or fully qualified domain name. Make sure the network connection is solid. Can you do an "id username" on the client machine and get an appropriate response? Have you restarted the machine? The server?

If all that looks proper, the MCX cache on the client machine might need to be deleted. This is done in Applications/Utilities/NetInfo Manager on the client machine. Open up NetInfo Manager and click the lock to authenticate with the client machines admin user name and password. There will be entries for mcx_cache and config/mcx_cache. Pick them and delete them. Restart the machine and try again. [Ed. Note: you can also manage this via a

shell using the MCXCacher utility located at /System/Library/CoreServices/mcxd.app/Contents/Resources. MCXCacher -d will dirty the cache, basically by deleting the contents of /Library/Managed Preferences/.]

Fig. 17: Remove the entire mcx_cache folder

"Managed Client for X" gives an administrator power to control their environment. You can combine this with Active Directory or any other directory service. In this article we have only scratched the surface of the power within MCX. There are many combinations to explore when it comes to controlling the client experience. The only way you will learn what works for you is to try it out in your environment.

There are many resources available to learn more about MCX. The first place to start is the Apple documentation for OS X Server. There is an entire PDF devoted to the topic and it drills down into deeper layers than we have room for here. There is also the WGM list that Apple hosts (http://lists.apple.com/).

Ben has been everything from a Mac user to CTO of one of the leading Macintosh professional services firms. Besides writing an occasional article for MacTech, you can find him presenting at Macworld or consulting with clients around the world. You can reach him at ben@greisler.org.