Good morning. My name is Armin Briegele. I'd like to welcome you to Managing Clients and Preferences with Mac OS X and Leopard Server. That's quite a mouthful. I wanted to call the session the joy of MCX. My name's Armin Briegele. I'm a solutions architect for Apple Education. And that means I get to travel around the country and sell my ideas. Other people's ideas as mine, which is always a good job. So why are we here? Why are you here? If you have to manage a lot of Macs, and personally I think a lot of Macs is anything beyond three.

If you find yourself re-imaging or reinstalling those regularly because the users mess them up and you just need to repair them, and the quickest way, instead of finding out what is actually wrong, is just to re-image them. If you use Remote Desktop a lot of the time, and I love Remote Desktop, but I think there's better tools in addition to Remote Desktop to use this.

And if you get these calls all the time, and I know you do because I've got them, the users accidentally messed up their settings and are lost and don't know what to do anymore. I once got the call of a very distressed user who said, I deleted the internet! And it took us a while to figure out what was going on, and in the end we found out that she had dragged the Safari icon off the dock. And couldn't find the internet anymore. Probably to admire the poof, I don't know. By the way, if you ever encounter this call, the correct answer is, oh, it was you.

So we'll talk about MCX. And in case you've been wondering what that means, MCX is Managed Client for Mac OS X. Another big mouthful, so I'll be using MCX all the time. We will also talk about launch restrictions and how you can limit applications to keep the users out of trouble. We will talk about preference manifests, what they are, how they help you, why they're a good thing, and why you have to file bugs to your favorite application for the developer to provide one.

And if we don't run out of time, we will show some actual applications and some neat use cases that hopefully go beyond what you find in the documentation. I will talk about control and restrictions and limiting the user a lot, because that's what managing clients is about. But before I do that, I want to give one caveat, and I use this as little as necessary.

The controls should support and guide the users, not hinder them. Build fences, not walls. I work in education, especially in education, people see that they can limit the students, and sometimes I think they go completely over the top. The idea of these controls is to build a consistent environment so that the users will find their way around wherever they are, no matter which machine they log into, no matter which version of the OS they log into, so they can't accidentally delete the internet.

Maintaining more controls also, very, very practically, means more work for us, the admins. You want to restrict that, so don't go over the top with that. You can introduce conflicts in your management, and tracking those down can be very tricky, though we will show you some tools today.

And don't try to use technology as the solution for what basically is a social problem. Again, especially in education with the students, but I think it's true everywhere. It might be more applicable and actually a better approach to deploy and enforce acceptable use policies, use a social solution to a social problem. That said, let's go and control the users.

So what is MCX? Managed Clients for OS X. I said that. Basically, it's the preferences, the preferences that each and every application uses on Mac OS X hosted in a central place on the server, a central point of administration for those. And it will be in the directory. And with those, you can override, complement, or preset the local preferences of a user.

If you're... Just a quick question in here. Who's coming? Who's new to the platform? Not that many. Who's familiar with the Windows world? Wonderful. Think group policies. They don't work the same. They're not exactly the same, but they have the same idea and the same goal. So mentally replace group policies with MCX.

The local preferences live in home library preferences, most of them at least. And they start in what we call the plist format. And they have the application domain name, which is basically internet URL turned around. For example, com.apple.doc. And then .plist, that's my file. If you look into that, there's an application called PList Editor, which you get with the developer tools to look at those. And you can see that this has a specific anatomy. I get a key value or key name, which has a type and a value. And I get a list of those. Some of these might be arrays and other things.

Actually, these are XML files. So if you open them in a text editor, you get to see this. And again, you see the list, you see the key value, and you see the actual value. Well, this is not quite true, to be honest. For performance reasons, I think ever since Panther, we've been storing plists in a binary format, so the access for them is faster. And to see the raw XML, you have to convert them first using the plutil command. And then you can open them in TextEdit or your favorite text application. Some third-party text editors do this step for you.

There's a command line tool that goes with this, and if you've been trawling Mac OS X hints or similar pages for hacks, then you've probably encountered the defaults command, which is a really useful tool for this. So there's a read command, defaults read, you give the application domain and the key name, and it will give you the value. And there's an equivalent, which is write.

Again, you give the application domain the key name, the type, and the value, and that way you can set the value without messing with the XML files. And a picture is worth more than a thousand words. A demo is certainly worth a lot more, and with that, I will ask Tony Graham to come up to the stage and show you this. Thanks.

So how many new to the platform? There was one person out there? Where are you? The rest of you probably know that preferences for applications are stored in your home folder. In this case, I'm the administrator. In my library folder, under Preferences, are most of the preference files for the applications I use. And typically, especially applications that use Mac OS X's Cocoa frameworks for reading and writing preferences.

I think after you see some of the stuff today discussed and demonstrated, you'll see why it's to your advantage as a user and administrator for your application developers to use that system. I have a simple application installed on this computer. It's called Manifestation. And if I launch it, it gives me a few settings, a few options for settings. So this is the kind of thing you probably find yourself setting a lot.

Serial numbers for applications, maybe a slider of some kind, and then perhaps turning off the feature. And then perhaps turning off the feature of an application to check for software updates automatically. These serial numbers generally are... Quite a bear to remember, so I'd like to keep them in a text file.

Let's enter the serial number now for manifestation. And the idea here is you don't want perhaps the user on first launch to be presented with this dialog, so let's set it, let's preset it. Let's set the volume slider to four, and we've already said I don't want to check for updates when it's launched.

So if we quit the application and look in my preferences folder sorted by date, you'll see now that my simple application has a preference file. And if I try and open that in TextEdit, which was my... Previous favorite way to do this. You'll see that that binary file is getting in the way of you editing those, although some of the strings will show up.

So let's close that and show you that some third-party text editors will do the right thing. Text Wrangler is one of them. BBEdit is another. So dragging these binary preferences to one of those text editors will let you see the format of the XML. And I can go through here and change this to, let's say, 5, for example. So editing the preference file while the application is not live is generally safe. I'll save that and quit. And if I relaunch Manifestation, it should have a volume setting of 5.

Armin mentioned the Property List Editor, and you'll get this if you install the developer tools on your system. And the beauty of using Property List Editor, which will open these by default if you have it, and if you double-click on it, is that you can walk the preference tree here using disclosure triangles. It's a little bit easier to read than your text editor, and you can edit preferences here as well.

So we'll save that change, quit, and relaunch manifestation, and sure enough, the volume is set to six. Now, for those of you who want to automate this or who prefer the command line, there are tools for that as well, and the defaults command is probably the most popular one.

Let's do com.your, you know what, I can never remember that, so let's just drag that guy in here. One of the things you're gonna need to remember is generally the .p list is left off of your defaults read commands. So by hitting that now, I can see what the setting is and I can... Play that with a write command. And let's set the volume to two.

There we go. All right. And then finally, Armin mentioned that for those of you who do prefer to use something like TextEdit to edit these files, there is a PLUtil command to do that. And it will modify that preference file, turn it into the old-style text format, and that will then allow you...

So working locally works great if you have a single Mac.

So I have my single Mac, I have my plist files on that for several things. But if I have more than one Mac, this gets really tedious. I mean, as a last fix, you could use something like Apple Remote Desktop to blast out a default command to fix something quickly. But imagine you have lots and lots of Macs and different flavors of Macs.

You probably want to manage the mobile Macs differently than the desktop Macs. And you probably have different user groups in your organization that you want to manage differently. And then keeping track of the plist files on the client is really, really tedious. So you need a central place to store all of these files. And you probably want a way to store different files for different groups of computers and groups of users. And in Mac OS X, that place is the directory service in Open Directory.

And because Open Directory is this great flexible framework, you could store it in a non-Apple directory service as well. I won't go into the detail for this. There are sessions that talk about directory services and how to integrate. There's one on Friday. And also, there's a lab that you can go to. And there are also great sessions on ADC from previous years, developers conferences, that you should look and learn about integrating. The tool you use to manipulate the preferences in the directory service is Workgroup Manager.

And we provide a UI to that. And you just saw plist editor to work with the local plist files. And surprise, it looks very similar. I have the same anatomy. I have my key name. I have my type. I have my value. And I have something new, which is the MCX domain, or the permanence of my setting in the directory. Because if you manage it centrally for a lot of users, you might want to do different things than just setting a value.

There are basically four things that you can do. The first one is do nothing, which is always good. So if you set the MCX domain to none or never, it will be unmanaged or never set. The user has full control over this particular value. You can set it to once, which means if the value is unset on the client, it will be preset with your value from the directory service, rather than the default value that the application developer thought was a smart thing.

Best example is Safari. Apple, of course, thinks the Apple start page is a good starting page. You might think differently. You want to set it to your organization's homepage or start page, so you can preset this. As soon as the user changes this, though... To his preferred start page, your setting gets overwritten.

The third setting is often, and this is not available in the graphical interface. This is only available in the plist style details view. And this is... For use with applications that kind of don't really work perfectly with this, some applications get really unhappy if they can't change the default while they're running. Once means it's set every time the user logs in.

Every time the user logs in, it gets reset to whatever you set in the directory service. Afterwards, the user can change it. Next time he logs in and out, it gets reset to what you think is great. That means often. And then finally, there's always, which this is set, the user can't change it.

It's forced from the directory service. And if the application reacts nicely to the information it can get from the directory service, it should gray out the control in the UI. And you can see down here, if you look in Workgroup Manager, you have the three choices, never once, no always.

And they go with three of these settings. Again, the preferences in the directory service are stored as XML data in attributes in the MCX settings attribute in the directory service. And you can go into the inspector and look at that. Before Leopard, we had to edit it in there, and that was really painful.

We also added commands to DSCL, which is the command line tool to interface with the directory service. And you can go in and read the raw XML. You can just go into the database, look for a user, and read the MCX settings attribute, and this will spew out tons of XML if you're managing this user. Again, the raw XML really isn't that much fun, so we added some command line tools.

There's an MCX read, which works like the default command. So I have a search path. I have to point the command to an object in the directory service. I have my application domain. I have my key name. And it will return me the MCX domain. In this case, this is managed always. And the value.

And same as the defaults command, I have an MCX set, which is the equivalent to defaults write. I have to work directly on the LDAP server in this case to get the right permission, and usually I would have to authenticate. I left that out in the slides. And again, I have the application domain, the key name, and the value. Note that setting the value to zero or false is different than unsetting the management.

And because you probably want to unset the management a lot, depending on what you do, that's something we use very frequently. There's a shortcut for that, so you can use MCX delete to unset the management. One really great tool that we've added is MCX Export. So if you're testing this, and please test this, not on the live users, these settings can get very complex.

And once you've got it set up on your test group and you want to migrate it to the production group, that used to be a very painful process. You had to basically either go and copy the raw XML or do it by hand. And there's now an MCX Export command that will basically export the XML into a file.

And then there's an equivalent MCX Import that will take a plist file and import it onto another object if you want to archive your settings and restore them. There's more MCX commands to DSCL, and there's an MCX Help command to list all of them. For some reason, they didn't make it into the man page in Leopard.

All of this command line hacking really makes you appreciate this. So you can see the graphical interface. We try to provide settings for the most common tasks in the graphical interface so you don't have to mess around with these. And again, I will ask Tony to show these.

So if we want to manage these preferences from a directory instead of on each local machine, we can stuff them in a place where the user can't modify them. Those preference files are in your local home folder, and you have read and write access to those, and you can change them.

But if you stuff them in a directory using something like Open Directory or another directory service, you can put them in a place, attach access controls to it, and prevent people from changing settings that you want to enforce. So in this open directory setup, let's go ahead and authenticate as the directory administrator.

I've got a number of users, as well as some groups, and the groups have users attached to them. I've got computers, and then I've also got lists of computers or computer groups. And I can go through and pick a user. Let's pick on Joel today and click on Preferences.

And at this point, WorkRoot Manager has a bunch of preset graphical options for things that you can control. I can, for example, go into the dock and say I always want to control Joel's dock experience, and I specifically do not want him to run dashboard, or at least not have dashboard on the dock.

So if we apply those settings, a bit of XML, which is essentially identical to what you saw in the preference file, got stuffed into a field in his user record. And you can see that user record by going into the Workgroup Manager's preferences and enabling this All Records tab and Inspector. It's not on by default, but when you turn it on, you'll get a warning, and then you'll see this bullseye.

And the bull's eye allows you to go and do things like, I want to select my users, and do you remember who I set? Was it Joel? So I can go into Joel's user record, and here is where his short name is, and password, not password, sort of short name, long name, his preferred shell, all of the things that describe his user account.

But in here also are the MCX settings, this field right here. If you double-click on it and do a select all... and copy that and paste it into a text editor. You'll see it's, in essence, a combination of all of these various preferences that would have ordinarily been on that local file system.

So we can go through and change all of these things through this interface if you like, or we can go, let's get Joel again, and preferences. If you look in the Details tab in WorkRootManager, you'll see the various settings that you've set, double-click on them, and as Armin said, you've got more of a disclosure triangle option to set it often.

Let's say you want this thing, every time he logs in, to be set a certain way, he can change it all he wants during his session, but as soon as he logs back in, it's reset to the way you like it, just stuff it in the often. We'll set it to always, and I can go through and change a number of settings here. This is the dock setting.

We're going to do some work with John here as soon as I can see him alphabetically. Found him, not alphabetically. And let's make a couple of changes to John's experience. Let's go to the doc. And if you know John like I know John, you know that the only thing he really does is play games.

And and do Unix, right? So let's let him have access to the chess application, right? And again, when I say access, I really mean just having it on the dock. For some people, that's the same thing. In John's case, All right, great. So we've got Terminal. We'll apply those settings.

And if I log in as John, We should see, oh, I forgot one thing. Did you guys see what I forgot? Notice that Chess and Terminal are in fact on the dock here, but so are all of the other things that John has been goofing around doing. So let's get back into Workgroup Manager.

And uncheck this box that says let the user have their own things too, right? So you're just going to take away that capability. So again, we can go through in Preferences and Details and see all those settings and double-click them here, and we can edit them in this user interface if we like.

Now, Apple has provided a number of these interfaces for you, but there are applications that you may want to manage that are not in here, and you can import those. So by clicking on the Details tab here and clicking Plus, I can go through to my, in this case, my home folder, under what library, right? And then Preferences.

And my application was called what? dot your company, right, dot manifestation dot plist. Now I'm gonna import this into the always section of John's user record. So now I can double-click on this setting and I can say, in John's case, I for sure want to have that serial number preset for him, but I also want to set the volume. Let's do that to 10.

Now, I can't go to 11. That's too loud. Right? So if we set that to 10 and go log in as John again, you know, I can already tell John's going to have trouble with this because I didn't put it in his doc, so we're going to have to find it.

It's in the Applications folder, right? So if I launch Manifestation, and let's try and drag it to the doc. No, it's not going to let me. All right, fine. But it will let me launch it, and sure enough, it did set it to 10. No, as you suggested, 11 is one louder, so let's take it all the way up.

And then, let's relaunch it. Oh, wait a second, no, it's not safe, right? 11 is not safe, it's one louder, it's just too loud. All right, so John's been forbidden from cranking the volume up. And what's nice about this is this is an application that wasn't designed by Apple, no UI was provided by Apple, but you were able to import those preferences and provide those.

And remember that you may use this to control someone's behavior, but you may also use it just to provide a base to start from. So you may use this to make sure that everyone's serial number is preset and the volume is where you wanna start from, but put it in the once setting. So they get that to begin with and then do let them change it to suit their tastes.

All right, so that's the UI. The command line options are nice as well. Let's take a look at, as Armin said, there's a DSCL MCX read option. So let's take a look and see what John's preferences look like. I'm gonna use DSCL. I'm going to point it at my Open Directory master, which happens to be this system right now.

I'm gonna tell it to use MCX read. I have to tell it which record I wanna read. In this case, it's John's user record. And then I want the particular application domain that I want to see. So if I hit that, you'll see, sure enough, he's set to 11 and the value is 1. And there's an equivalent set to that. So let's do that.

And here we're going to say check for updates. All right, did I have it set to zero before? Yeah, so that application is always gonna check for updates on the Internet. I'm gonna set it to zero. Put in my directory administrator password, and then pop open Workgroup Manager.

And if we go back into the inspector here, you should see that's now been set to false. So any way you like it, whether you script it, whether you go in through the GUI, it does the same thing. It stuffs those in the user records. You can do the same thing with groups. Stuff those in group records, stuff them in computer records. They tend to overlap at that point. You can, in some cases, run into conflicts. I think Armin's going to talk about that more in a little bit.

And then one other set of tools that you want to be aware of is the MCX import and export set. So let's see if we can-- dump John's preferences to a text file. And I think Armin showed you the syntax for this as well. As mcx export, we're gonna do an output file, and I'm gonna put that on my desktop, and I'm gonna call it johnsprefs.plist. And I specifically want just the settings for this one application.

So now I have a plist file on the desktop. When I double-click it, it should look familiar by now. All those same settings. So I now have a local copy of that, and the beauty of using MCX import to do that is I can then reverse that and say I want to... Let's import those settings to Joel's record from the file that I've saved on my desktop.

So if we go into Joel's record now, we should see the same settings set now for Joel. So if you have gone through and established a large number of managed client settings on an Open Directory master, and you want to migrate those to another server, for example, or back them up, you can use MCX import and export to dump all that stuff out, re-import it.

Or if you've attached, for example, let's say you picked a lab and you said, all of the computers in this room can print to these printers, and you want to do it again for another lab, you don't have to go through and check all those boxes, just dump it and re-import it. And I think that's it for now. Back to Armin.

So Tony has already mentioned that there's many places, many objects in the directory that you can store MCX settings in. You can store it in user groups. You can store it in computer groups, which is a new feature in Leopard. You can store it for individual computers and for individual users.

We demo with individual users because it's nice to make fun. You probably don't want to go to the individual records down too much. You probably will be working most of the time on the group level for the user groups and the computer groups. Another new feature in Leopard is that if a user is a member of multiple groups, and I guess most are, it will actually take the settings from multiple groups and try to merge them in a sensible way. Of course, once you start managing on different levels, you will run into conflicts.

And there's a hierarchy to these. So in general, the hierarchy goes from bottom to top in this case. So computer groups supersede user groups. Individual computers supersede computer groups. And the user settings will supersede everything else that will give you the complete priority. However, it's even more complicated than that.

We can nest groups as well, a feature we added in Tiger, which is great. It's really, really useful. That makes things so much more complicated. And on top of that, you can nest computer groups. Again, a very, very powerful tool, but it just makes the conflict settings. So much more confusing.

Within groups or computer groups, same thing, there's another hierarchy. And the hierarchy is that the children will supersede the parent settings, and they will supersede the grandparents if you have any. If the groups are on the same level, we will actually choose the alphabetical first group first. We had to do some choice.

If anything else fails, denies, will wins, over-allows. And all of this is different for those settings which aren't check marks or values, but which are lists, like the doc settings. Those will be concatenated and merged. So the one thing you have to take out of this is don't mess around too much with this. The rules are there, but the chances of messing up are really big.

So in case of, let's say, the doc settings, if I have different doc settings for different groups, say the chess club gets the chess application and the designers get Photoshop and Illustrator, and a user is a member of both, they will be merged, which is what you want to be, what you want to expect. And it will actually take all of the icons from all of the levels where I can manage and merge them into one preset combined doc.

Yeah, you want to debug this. You will have to debug this once you've set it up. And we actually provide a bunch of tools that will allow you to debug this. One of them, surprisingly, is System Profiler. In System Profiler, we have a new setting, which is called Manage Client, and you can actually go in there. It's a little hard to see here.

It will show you all the composited MCX settings out of the directory service, and it will show you the source from which object did this setting come from. If you're expecting that my account gets an auto-hide value of false from the group object, but you forgot that you once set it on the individual user object, you can actually see here where the information comes from.

There's also a command line tool, MCX Query, which basically does the same. MCX Query has one big advantage, though. It doesn't have to run for the current user or the current group or the current machine. You can enter any object or any combination of objects in the directory service tree and have the compositor run and give you the output without actually having to log in as the user to see how that's working. And again, by now you know how the output works, and it will also show you not only the value, but where it comes from, which object it comes from. And again, Tony will show that.

All right, so if we're in Workgroup Manager, you'll see that there are a number of settings. That are kind of either-or settings, and you'll see some settings that are additive. Let's start with some additive ones. So let's, for example, go to the groups and say, all engineers are going to have the following preferences. Let's, again, deal with the doc, and we'll always manage their preferences, and we'll say they're gonna get, what should the engineers get? Terminal? That's in the wrong place, all right, what else? Terminal and Console, okay, yeah, good. Those two are perfect.

If we apply these settings, anyone who's in the engineers group should get Terminal and Console on their dock. And to make things clear, I'm gonna uncheck this, allow them to have their own thing checkbox, just so you can see these things in action. If we also go into the field employees, for example, and manage them, What should field employees have? Careful now, what's that? Mail? Makes sense.

And chess, right? 'Cause we're working from home, so you really don't know what we're doing. Right. And at this point, if you're in the field employees group, you should just have those two applications. So let's take a look and see what John has. Now remember that this is additive, so he's got the things that I set on his user record and the things I set for his group record. And if we managed his computer in a pool, he'd also have those as well. So let's log out.

And if we go into John's record now, sorry, the groups, and take a look, there is an Employees group, and the Employees group consists of engineers and field employees. Let's go to the engineers, and let's add John to the engineers group. And take my word for it, if we log in as John, you're going to see engineers and field settings.

What we want to do, though, at this point is let's show the difference between additive stuff, like lists, and Boolean things. So if we go to Preferences for Engineers and go to Finder Settings, I can say under Commands, I want to always manage these commands, and I want to make sure that engineers cannot restart or shut down. That's cheating. And we'll go to the field employees.

and we'll allow them to restart and shut down. Now based on, this is the pop quiz, based on what Armin said, what would you expect John's account to have on a Boolean conflict like this between two groups? No restart, shutdown, raise your hands. Restart and shutdowns, raise your hands. Okay, we'll see what happens.

So is it what you expect? Yeah. But we can still log off. So let's do that and take a look at some tools. Actually, let's go back in there because Armin made a very astute observation, which is the Apple System Profiler can help you figure out why he got the settings that he got. If we go into About This Mac and choose More Info, and Apple System Profiler will launch. There's the Manage Client Setting.

And if we go down to, this one actually goes into the Login Window Settings, believe it or not. It'll actually tell you where you got the setting that you got. But that will only show you the settings for that user while they're logged in, and you probably don't have the time. to do that for each user as you're troubleshooting it. So there's a command line tool called MCX Query that can help you.

And let's take a look and see what that looks like. Let's dump John's settings. I can specify from the command line which user and which group I want and output that to a file. This one's gonna go on the desktop and it's gonna be called John D Management. I'll throw that away.

And this is actually more of a text file style, although you have some options to how this data is presented. Let's do the same thing for a user called Dave O., He has nothing because that particular group has no settings. So I'm gonna cheat and go into, Engineers, no, let's go into that user.

Okay, what can we do to Dave today? I know. No, no, no, this is even better. All the way down and position it on the right. There we go. All right. So now we've got Dave's settings. There's a text file showing those values that I just set. And Armin had a handy tip for comparing these. I mean, as you're comparing these text files and setting lots of settings, it's going to be difficult to see how they line up. There is a developer tool called File Merge that developers can use to see differences in code. You can actually route these.

See if I can find my... You guys see it? Second one? From the bottom. From the bottom, that one, thanks. So this one is going to take two files, and the OpenDiff command line tool will take two files and send them to the graphical file merge tool. So if I do that, You get, I mean, it's sort of cheating, but you get kind of a graphical display about the differences between these files, and differences are highlighted in blue, so you can see things like, you know, and you have to be able to decode these settings, obviously, but sort of a handy way to view the differences between those files. There we go. Back to Armin.

For most users, removing something from the dock is good enough to restrict them from launching it. However, we do have a more powerful way of doing that in Leopard now. And basically, application launch restrictions let you decide who gets to launch what. And to really enforce that, we now digitally sign applications. Most Apple applications that are installed in Leopard already have the signature.

But if you have a third-party application that you would like to control, and you just drag it into Workgroup Manager, Workgroup Manager will actually prompt you to add that signature. And it will add a file called Code Resources, which is a text list of all the files in the application's bundle with a digital signature for each of those files, to the bundle of that application. You're physically changing the application bundle on the disk.

That means, if you want this to take effect on all of your clients, you need to distribute this Code Resources file, this digital signature, somehow to all of your clients. If you want to use application launch restrictions, you have to think about this very, very early in your rollout process. Otherwise, it will be just a pain to take care of it later. You probably want to do this on the machine that you build your final image from.

If anything in the application bundle changes, the digital signature of that file won't match the digital signature in the list of all the digital signatures, and the launch permission for that application will be revoked. The user will get an information, you can't launch this application, it doesn't match the signature. And they will probably call you. So if you roll out updates, you need to re-sign the application and make sure that all of the updates that reach the customer or the user will get the same signature, the one that the directory services knows of.

Because this is a very complicated process, it's very secure, but also a very complicated process, we also added a different way of managing launch restrictions, and that is by folder. So you could generally say, I've got my image locked down, I have control over it, anything that's in the applications folder, the user can launch, which is our example down here.

But then you probably think about it and say, wait, there's some stuff in application utilities that I really don't want the user to launch. So we also have a blacklist or a disallow list, and you can say, well, applications folder is fine, but applications utility isn't, application server isn't.

And since most applications are folders, you can actually add individual applications into here, which works really great. And as all lists, you can manage this on different levels and different groups, and these will be merged. If you set one disallow folder, You have to set an allow folder, otherwise the user won't be able to launch anything.

As soon as you set anything in the launch restrictions, only those applications that you explicitly allow will be allowed to launch. If you use a mix of permissions by folder and digital signatures, applications that are signed and permitted to the user will be able to launch no matter where they are stored.

There's some applications that don't behave quite well. I will use Firefox as an example, though recent updates of Firefox have been working much better, and I have big hopes for Firefox 3. But they will actually modify the application bundle while they're running. So, And that will obviously invalidate their signature if you sign them. And that means you can't launch or use any signatures.

The way around this is to set the allow folder to the root of the application bundle, and then you also have to set the privileges correctly so the user can actually modify the files that he needs to modify so that the application can successfully run. But this opens a security hole, because if the user is really, really crafty, believe me, I work for K-12 educations, the students are really, really crafty, they will copy a third-party application, an unallowed application.

into that particular folder where they have write permissions and launch it from there. So if you set write permissions to any subfolder in an allowed launch folder, you will have to set that path to a disallow folder. So beware of traps there. If you want to use this to really lock down the experience, there's some traps.

A really useful tool once you've signed the bundles and you have to redistribute them is PackageMaker, because it can basically watch what changes and build a package of the changes and distribute that out. And Apple Remote Desktop, if you want to do it after the fact, or you do it on your original image, and then you distribute those out with your image.

Another great tool in this area are preference manifests. So we saw that the graphical interface is nice. That's something that's comfortable to use. But you will get to the limits of the graphical interface very, very quickly. Editing XML-- no, we don't want to do that. Really, a lot of problems can arise from there.

The detail view is a big help, but you still have to manage a lot of stuff individually. And basically, you have to guess. In unsupported applications, you have to guess what this setting means. Most keys are a little explanatory, but sometimes you have to set up combinations of keys to make things really work. Just changing one setting doesn't help. You have to change a group of settings to the right things.

And this is where preference manifests comes in. Preference manifests are provided by the developer, they're part of the application, and they are basically a list explaining the preference settings. And if a preference manifest is present in an application, Workgroup Manager will pick those up, and it will give you a list of preferences, as shown in this case, and tell you what they do, and what values make sense. And again, I'd ask Tony to actually show that.

Great. So the idea here is to get developers to include preference manifests with their application. I don't have one with the application that Armin wrote, so I guess I know who to talk to about that, right? I think I probably set it for John, so let's take a look at John in Preferences under Details. But what you'll see is that the preferences that are there, the variables were pretty well-defined. Check for updates, serial number, volume.

You don't have a guarantee that the developer is going to use such easy-to-read preference values, so a manifest can be kind of handy. And there are a number of applications that do have manifests. Let's see if we can see what happens. If we go to the library folder in Preferences and try and find my Safari preferences. I may not have them. There we go. There's the Safari plist. So if you recall, I imported a plist before for the manifestation application. Let's stick this in the often section. So I just did that again with Safari. Did I click the wrong one? There we go.

Right, address bar includes Google, true or false. Address bar preferences were converted, true or false. Some of these you're gonna mess with, some of them you're not going to mess with. There's one that looks good. Homepage preference, you can set that to your own. Apple's engineering team has actually included a number of preferences inside an application on your system in /system/library, and I think it's in core services.

And if you scroll through there, Look for the managed client application. This, among other things, has a bundle of preference manifests for a ton of applications that are included with the system. So rather than each application having the preference manifest, some of them are just all bundled in one place here. And if you import those now, you get more sensible descriptions for things. I can go in, for example, and say iTunes settings, always. Let's get a new key in there.

And let's restrict explicit content and set that to true. So this, if applied to a computer list, could set all of the computers in a computer lab, for example, to not use explicit content. And again, the beauty of this is, rather than going through when you're building an image and checking every conceivable checkbox and then saving that out to an image and deploying it and then realizing that you forgot that one checkbox, stick this in a directory server, bind your clients to the directory, and they will be able to use it. and they will pick those values out of there.

So there's some other handy ones in here. Did they talk about folder direction in the home directories session? Good. So this is kind of a handy thing. To be able to take a variable substitution for your home folder, rather than having that be in a user record, for example, you could embed that right within their managed preferences for a computer list or a group.

Setting screen savers, how many of you have set the QuickTime Pro key on more than one computer on this same network? Yeah, so these are the kinds of things you can look at as magnifying your power, checking a box in one place, and spreading it throughout all of your systems.

There's one other that I think Armin wanted me to show, and that was, was it in the Finder, Armin? Armin Briegel, Tony Graham And there it is right there, sidebar settings. So some of you have asked, for example, to, let's get a new key. Set up custom URLs or define how the finder shows, whether it shows network machines on your network and that sort of thing. Set those centrally and control all the machines on your network that way. I think that's it for now. Back to Arm.

As you saw in our small example, not all developers go to the effort to provide the manifest. So please, with your favorite applications, if you don't see that they provide the manifest, ask the developers, file bugs with them, say this will make our life so much easier and we have 3,000 licenses or whatever, so that they know about this. This is the link. You can read it yourself, but basically this is the link for the developers on how to provide manifests and why to provide manifests and why they're a good thing.

So we showed some neat tricks. The main starting point for this is to take the application and import it into Workgroup Manager. We put a bunch of these files into system library core services, manageclient.app, which will provide you a huge list of preferences that you can use and explore and play around with and preset. You can manage the finder sidebar. You can disable the automatic lookup so you see all the Macs in your lab. You can disable that.

You can preset certain volumes or file shares of certain locations in the sidebar. Basically, everything that's in the preference control in Finder sidebar, you can control through the details view. You can preset registration keys for QuickTime and iWork. So if you have a volume license for either of those, you can preset those through the directory service.

You can disable iTunes features, which is very valuable in education settings, where you want to use iTunes because of the podcasting functionality, but you don't want them browsing the iTunes store or sharing their libraries, because Heyman's second rule says that students will use every possible means to communicate with each other and turn it into a chat. We had one school where the students started changing their iTunes library names, and suddenly we had iTunes libraries like, the answer to question three is C.

So you can disable that. They found something else afterwards. We can do folder redirection. In Tiger, it requires login hooks, and it's now built into the MCX settings, and you can take the caches folder on a network home directory setting and redirect it to a local folder instead of moving all the small cache files over the network.

There are a lot of related sessions. There's the overview session, Managing Mac OS X with Netboot Managed Clients and Apple Remote Desktop, which talks how this works together with other tools that we provide for management. MCX is certainly not the only one. There is a session that talks about authorization services.

Sometimes the granularity of MCX isn't deep enough. Sometimes you want to control whether the user gets administrative privileges for a certain task. You control that through sudo and the authorization process. It's quite complicated. They will talk about that in this session. And then we have the Managed Client Lab on Thursday.

So MCX controls the Mac OS X preference model in a central database through the directory, and you can basically control everything that lives in a plist file, even if we don't provide a graphical interface for it. We have the details view and the command line tools that let you control everything that's in that file or in that folder.

If you want to use application launch restrictions and application signing, it's a very, very powerful tool, but you have to start planning about this very, very early in your deployment process and during the maintenance as well. And please ask all of your developers for manifests, and any developers that are here in this room, please provide manifests.