All right. Oh, that's loud. Thank you, everybody, for showing up. And my name is Juussi-Pekka Mantere. I'm the Engineering Manager for Managed Client and Managed Desktop and System Imaging. And let's see, there are still people walking in, so people, find your spots. Oh, these are the Apple people who are waiting for the overflow. So here's the agenda for today. But before I go into that, so how many people were at the server overview session yesterday? Yay! So I have just two words for you: command-line utilities. Yay! And thank you. So we're done.

So the agenda for today is we'll discuss managed desktop. The key features that we're adding for that and application loss restrictions is first. And then-- oh my gosh-- Hierarchical Groups. So this is basically nested management of groups. Then we have reporting tools for that. And we have external accounts, which is an extension for Portable Home Directories. And-- oh my god. Thank you. And system imaging, we have simplified image creation.

Automator Actions for System Image Utility and Command-Line Image Creation for System Image Utility.

What we had for Tiger, we had a preference manifest which is a way for developers to add descriptions on their preferences into their application bundles so that they're easier manageable through Workgroup Manager. And portable home directories which was an extension to the cached accounts feature and then that became portable home directories.

And then for developer documentation, so if you're a developer, not a system administrator or IT staff, we had a session last year on the managed desktop and specifically about using CF preference and some of the best practices on how you'd use your applications in a network environment. Let's say if your application is run on a net booted system or if your user's home directory would be on a networked home directory.

So we have documentation on the developer site. So here's the URL. So if you get the slides after this presentation, if you go to that and look at the best practices that we have, so that covers basically what we had in Tiger. But we're here to talk about new technologies that are delivered in Leopard. So here's what we're doing. The focus on Leopard for managed desktop is improved security. And this is through application loss restrictions, actually make them work, fix it, forget it, be done with that. And better manageability and specifically this is about hierarchical groups.

So you could actually have workgroups that are nested so you could actually layer your preferences in some logical shape and not have to have individual users in individual workgroups and then figure out how they pick and choose amongst those. So this is more mobility. So this is extension of cached accounts in Jaguar, excuse me, in Panther and then portable home directories in Tiger and now external accounts in Mac OS X Leopard. So let me first go into application loss restrictions. So we've received feedback that there are some things that we could improve with application loss restrictions, specifically that people are able to go around them.

There are not so much restrictions, but when we look at the history of that, this feature was a legacy carryover from Macintosh Manager. So what we had in Macintosh Manager is basically application identities. You had resource IDs and we had a whitelist, blacklist of applications that are allowed to run or not allowed to run. And the way we find it, this should say tiger weaknesses, Leopard will have no weaknesses. The bundle IDs can be easily changed.

So previously you had to have at least some advanced tools like Resedit. Resedit on Mac OS 9, 9, 8, 7, whatever. You have to go and edit the application creator code. Well, today you can use TextEdit to do the same thing. Go into the Info.plist and make the application look like it's something else and you're done.

And other thing for application launch restrictions is that we don't have any support for widget management. So if you have a dashboard as an allied application, then any widget that the user might have access to actually is allowed to run. So we're addressing that in Leopard as well.

So, the leverage solution that we have for Application Launch Restrictions is a kernel-based mechanism. So, kernel is the lowest level we can go to. Like, after that it's bare metal. We're not doing a TPM. We could do a TPM something on the hardware, but we thought that was maybe too much. So, on the kernel we have a mechanism called KAUTH. This is something that's shipped in Mac OS and Tiger. So, on top of the KAUTH mechanism, which basically traps Unix system calls.

So, when a application launches, it goes through an execution mechanism and we can actually trap that mechanism inside the kernel. So, we built a enforcement kernel extension that then does the restrictions per user. And to manage the restrictions on a user, we have a launch policy or application launch policy that's another agent that talks to the kernel level of kernel extension.

And then we have an application identification piece as well that then talks to the enforcement So, the only way you could actually get around this in Leopard would be if you had root access to the system. So, if you can install a KEXT and delete a KEXT, well, your system is compromised. So, there shouldn't be any user level access to any of these modules now. So, editing an Info.plist file, that wouldn't really do anyone any good anymore.

And the implementation we have right now is path-based. So that means that if we want to restrict somebody from running Safari, we basically tell the policy module that this user named Joe can launch application at this location slash applications, slash Safari.app, slash contents, slash Mac OS, Safari. And that's it.

So we trust that the file system permissions haven't been munched with in such a way that ordinary users would be able to install applications there. So if somebody has access to the file system and can change files from the file system, then, well, they can install what applications they can. But if it's an administered system, then we trust that anything under slash applications is under administration control, and we can trust the file system permissions to be of some level of integrity that we won't have to worry about that.

And in the future, we might look into, we are looking into code signing. So instead of, instead of using just path-based policies, we would use code signing and maybe even some dynamic permission granting so that when the kernel extension that we have the user agent, when it does a check for the permissions for the application launch, it would actually go to some external module, and that could be some RPC call, IPC call, and then the grant would happen dynamically.

So if you have family controls or parental controls on the desktop client, you are using managed desktop and you're using Application Launch Restrictions. So it's not if you're a developer and think, well, I don't have to worry about that because this is a K through 12 or enterprise or education feature. Well, it's not really. If your application is used at home or anywhere else where somebody might be able to use or might want to use parental controls, then the Application Launch Restriction feature in parental controls sits on top of the Application Launch Restriction side of managed desktop.

And now let's go to a demo. So if we could have the demo slides up please. And demo guards please. Yeah, demo guys, because I have to look over there. I have a screen here that I don't use. So this is going to be interesting. I'll go to System B first.

And System B. Do we get System B up on the screen? This is demo restriction. Thank you. So we have now demo A, and now I'm going to demo B. - Okay, I can log on to the administrator. - Yeah. I'm just gonna... - Just refresh the screen.

and Figaro Tone. Yay! It's coming back. Oh, let me try. Thank you. So we had some issues with the displays here before, so please bear with us. So let me show you how things work in Tiger. So right now I'm on a Tiger system. So if you look at this, this is Mac OS 10.4.6. Actually, I should do the demo from there.

So I'm gonna log on a user. So I'm going to call this leadhackser and password something. Oh, because this is not an O, it's a zero. So my user now logs on. And OK, so I have some applications here. So let's see if I go back to system A.

Okay. Excuse me if I peer over this monitor because I'm not really happy with this resolution, so I'll make this 10, 20. Can you tell if we had a little bit rush getting this demo set up when we came on stage? Okay, that works. Now it's actually readable from here. And did we -- okay. So let me just verify that all our demo systems are now up and running.

Oh, I will log out, excellent. So now I'm supposed to be at demo three. Okay, so this is now demo C, and we have no video from that either. - Dun dun dun. Yeah, what about that Leopard Application Launch Restriction feature? So, should we just reboot that? So there's no computer scene.

Did I try them again? Okay. So while we reboot, Yeah, the problem with this demo is that we brought our own servers thinking that this was the safer way. And apparently that was not such a good option. Okay. So we'll get that system up. That's the fun with doing servers. So we wanted to be on isolated networks. We have our own router. We have our own server.

We have our own We're not connected to the demo setup here except for the monitors and unfortunately the monitors that we're using, we have a dual DVI output so we're doing screen mirroring and our servers are Mac Minis. So those are very portable but we don't have dual DVI out on the Mac Minis yet. And probably don't think we're planning to but that's the demo setup we thought we'd go with. Okay, so that should be coming up shortly now. Okay, thank you.

So when the system is actually booted, here we go. Oh, temporary refresh. Can I touch it now? Okay, my mouse is moving. I'm at System C now and I'm supposed to get a There we go. So let me just change this resolution to something more readable as well.

This place. We have step four. Okay, so here we go. So let me just launch a instance of Record Manager. So I'll be needing that too. and shortly, please don't beach ball. Okay. As soon as the beach ball is finished, then I'll show you what's going on. Excuse the intermission and Soon we'll have our mighty Mac Mini Server on Workgroup Manager.

It's coming up. It's the first instance launch of this particular build. Yay! So, now we have all our demos set up. Let me just see some users first. Please. We do have users here. We do have groups. So we're managing the server and we are waiting for the user list to appear. And soon that's going to be-- no, actually we're at 28.8 something here. So our serial connection isn't so hot right now.

So let me bring up a terminal and see if we can actually talk to the server in any other way. This is a preview of upcoming demo. So CDL.play3 Server Auth Admin. Oops, actually, Dear Admin. So, looks like my directory server is actually up and running. Except the Workgroup Manager doesn't see anything. Okay, so let me just have that sit there in the background and go back to my demo B system.

So, okay, so what we have here is this is a Tiger client. So in Workgroup Manager, I have set this user on Application Launch Restrictions so that this user has only access to two applications. So the user can launch chess, Yay, because we want people to be cerebrally entertained during school. And for some reason, this user also has access to Terminal, which is probably a bad thing.

So there goes all your application launch restrictions right there on Tiger. But the thing is that if I try to launch Safari, for example, I'm not able to launch Safari. So in effect, I have just two applications that I granted for this user. So on Tiger, if the user has copied a version of Safari onto their desktop, well, if the Safari application is the same as the system version, then that will not launch.

But because this user has access to their home directory, they can copy whatever files onto their home directory they can. So let's imagine that this copy of Safari came over on a FireWire drive or USB stick. And then this particular user has a neat script that they changed the bundle ID of Safari. And now this copy of Safari-- that's the system copy in applications-- does not launch.

But here, the desktop copy suddenly became launchable. So this is the Tiger Behavior Application Launch Rest rictions. Apparently, it's not so strong. So let's quit that. Let me go to our demo A system. So now if I log in this same user, so we are now running 10.5, so this is a Leopard client.

and on Leopard System, I have network accounts, that's good. If I log on my LeetHackSource, and go and try to run the same demo or try to do the same trick as in getting access to my home directory and then trying to launch an application there that I had modified. As soon as my network logging works. - And restricted. - Yes, our network home directories were protected at the same time. This user. Okay. Reboot the server. Yeah. So the problem is that I think my network accounts are available.

So, here, yeah, Bruce, if we can reboot the, kill that, kill the clients, and then start up the server. Okay, if we can go back to the slides, please. So back to the slides, please. There are no slides. If I walk over here, do I have slides? Let's touch on the slides. Yay! At least something works. Maybe we should have done the demos from the slides.

There's a slight glitch with our demo, if you haven't been able to tell. Our network doesn't seem to be quite up and running the way we had hoped. So, what you would have seen in the demo before, so when we use the Thai Leopard Application Launch Restrictions, the client on the Leopard side, even if we modify the local copy of Safari, the K-auth mechanism and the kernel extension that we have on top of that would have prevented that copy of Safari from running.

So, only the legitimate copy of Safari, oh sorry, only the legitimate applications, Jess and Terminal, would be able to run. Even if you edit the application, no matter where it resides in the file system, that wouldn't make the application able to run. That's the demo. So let's move on to hierarchical groups. And guys, are we having any luck with the server? No. We're not? Okay.

and then pull the plug on this and then I have to reboot that. So the server is rebooting and now, and wait, wait a second for the server to reboot. Bruce? So wait for this to come up. So hierarchical groups, and we have a demo of this as well, so let's hope that actually works.

So for hierarchical groups, what this allows you to do is to have granular management. So this is basically a way of attaching users to not just top-level workgroups and having the user to choose between multiple workgroups and essentially getting just one set of preferences through that workgroup selection.

So we can have nested groups and we inherit some of the preferences through the nesting. So you can have user belong to group A and if that group A belongs to group B, then the user gets all the preferences that are in that chain. And we are also using the member D functionality that was part of Mac OS X Tiger. So this is the way we do ACLs. So any group memberships are resolved through member D and that basically gives us the nested group mechanism. And we are also using computer groups.

So today, you can only have single computer list per computer. Single computer can belong only to a single computer list. So if you wanted to have computer-level nesting, that wouldn't be possible today using the computer list construct. So we are migrating the computer lists mechanism into a computer group. So a computer can belong to multiple computer groups and computer groups can be nested themselves. Thank you.

There is a legacy computer, so if you have mixed clients both running Mac OS X Panther or Tiger, so using 10.4, 10.3, and then have some leopard systems appear on the site, there is a way to map between the computer lists into the computer groups. Here's an example of how we'd use the computer list.

Let's say we have a couple of different scenarios we want to set up. Imagine you are doing software update and login window and energy saver and try to do the same settings for another set of machines and yet another set of machines. You'd have to basically narrow down the unique collections of preferences and then create computer lists for those.

and yeah, that's bad. But here, if we have the same set of machines and we want to set up, for example, now Energy Saver, we can create the Energy Saver group for never sleep for some systems and then another group for systems that are allowed to sleep. And then if we have login window preferences, we can have login window settings that then overlap those same machines. And then on top of that all, we just have one software update group that all the systems belong to.

So we basically overlay all these different settings on top of one another, and you can logically construct the most, I'd say rational, but most understandable way of grouping the computers into their particular settings.

and... Okay. Here we go again. What did I do? Okay, we go to demo. Excellent.

So if I can go to this screen and now we are looking at demo one and I should be at demo two. And that would be my system C here. So let's see if that came up. Did this system come up again? Demo C? It has power. We're not locked down again.

That's what Reboot did to us. There's going to be a sleep on these machines. That's on C. So that's the system. Okay. This is C. Do you see better? Yeah. C is here. You're done with that? Yeah. Okay. The only way we can bring this up is if we do this. Okay. So I'll do that. That's all right. While we're doing this, no actually I shouldn't touch this. So this is now on computer C. We need both systems for your demo as well.

Let's do some emergency shuffling then. We'll go through hierarchical groups and then We still need to get demo C up before we go to Bruce's section. So let's just get something on the screen from this system. Just now rebooting. Let me do this again. Okay, so System C is rebooting now again, so if you can see if that comes up. Yeah, we have it switched on, thanks. Yes, okay, we're coming up, thanks.

So what do I do next? OK. So if this system comes up and I can log on with a user, then we're good to go. Bruce, now let's do a demo. So we're going back to demo A and Bruce. Okay, so if we can switch back to the slides please. Back to slides please. So meanwhile, while we wait for the demos to come up, we'll have Bruce Gaya come up and do a demo of external accounts. Okay. All right. Thanks.

How's my microphone on? Okay, great. So, external counts, next slide. and And we actually do a demo. So let's do a demo. Okay, first of all, let's go to Demo A. Can we go back to the demo slides, please? Demo A. Let's hope it works. Yes. Okay. So, I've created an external account. It's on this Firewire drive here.

I seem to have lost my microphone. What external account is, is a PhD, everything you need, all on an external disk. Now, let's go to Demo C, which I'll do here. Okay, we're not going to do demo C. Back to demo A. Okay, well I'm going to plug this back in. Here's the cable. Okay, so I'm just going to plug this back in here. Like this. Leave it alone. Check to make sure it's spinning up. Looks good.

Okay, so now I'm going to log in using my normal password. and Okay, great. So now this is my total home, right? I've got all my files here, everything. If I go to look at the home here in the finder, you see that? It's right here on this FireWire drive. Okay? An external account is also a mobile account and also a PhD. So I can synchronize, synchronize back to the server. Though I won't do that right now. And I'm going to go through with this and make a quick change here. And then I'll log out.

and if the server was up it would re-sync. Ah! What do you know? There we go. And so what it's doing is synchronizing its hard drive back to the server. So now, Back to login window. I can take this out again, put this in my pocket, go to another machine, and do the same thing. That's the demo. Didn't see that.

Okay, so I'm going to talk about external accounts here. Let me head back to the slides. Okay, so what are external accounts? Next, evolution in managed mobility. In Panther, we had mobile accounts. That was essentially a network cached account plus credentials and also a local home directory. In Tiger, latest release, we had portable home directories.

That's a mobile account so you have a cached network account plus cached credentials plus home synchronization. So your network home and your local home on your portable computer are synchronized. So you can go basically take your account, work offline, come back, resynchronize, you're back, everything's all nice. Now here we are in Leopard. We're going to introduce external accounts. So what are external accounts? They're the total portable home directory implementation plus everything is going to be cached right on the disk. Okay, now I have to explain how this works. So for external accounts, two situations. You're inside the firewall.

What I mean by this is you're on your own network. You know, you have a network server, network file server, LDAP, network authentication server, it's all sitting there. So when you take an account and present it to one of these machines, what happens is the account information and the password information actually all go right from the server. Okay, they're not coming from the cache on this disk. So it's perfectly, well, it's as secure as a network login. All you're doing is you're presenting a name and a password and a home directory and logging in.

If you go outside the firewall, that is on some of these machines, you know, just connected at home or whatever, or just on a different network, You present your disk. What you need now is you need not only your account name and password, but you're also going to need

Computer Administrator Authorization. Now, we remember this so that if you come back to the same machine again, you don't have to go through the same process.

Okay, external accounts. They enhance OS X Server networks. I said external accounts as a PhD, so what do you get with a PhD? You get local disk performance with a network account, all the network manageability, network password. It enables data backup. Now, what does a PhD do? A PhD provides a mirror between your local disk and your network home, or local home and your network home.

If you have backup on your server, let's say Time Machine, you can actually recover all your old versions and it forms a complete backup system. So all you need to do is backup your servers and your images and you basically have all your portable home directories, all your external accounts backed up.

Okay, where external accounts are going to be good is in computer labs. You set up labs all over. Your employees or students can go from lab to lab, take your disk with them. You really don't need any synchronization in this case except for backup. You can go campus to campus to home. It's nice, one campus, another campus not connected to that campus. Still take your stuff with you. If you're a network administrator, this might be fun. Go home.

And also, it also kind of enables a multi-user workstation. What I mean by that is if you have a machine which is specially configured, let's say scanners, what not, video hardware, what not. You can take your data with you, log in, take your whole account with you, log into that machine.

You can take it out and some other user can come with their account, go to that machine and use all the hardware in that machine. So it's kind of nice for that. So how should you manage? Leopard Workgroup Manager. That's where you manage it. First thing is in Leopard, you can require that file vault be turned on at all portable home directories and all external accounts.

Okay, you can limit which computers allow external accounts, so maybe it's appropriate for this lab, not appropriate for some other lab. External accounts retain all their MCX Managed Settings. They can retain their user and their group settings. So wherever they go, they can still be managed. Okay, talk about hardware briefly.

Okay, best hardware is going to be a portable firewire, portable disk, or USB disk. This is because they're generally hardened for vibration or drops. I was looking at this one firewire drive, and it said that it could be dropped from 30 inches onto concrete without damage. That's pretty good.

You can also use desktop disks, but they're not going to have that kind of mobility aspect of them, you know. And also, if you're considering deployment, you might need to have some extra power available for people who bring desktop disks or have external accounts on desktop disks. And finally, I have to say that flash-based devices are not recommended.

Okay, security, use FireVault. Yeah, FileVault, not FireVault. Use FileVault, or basically, when you have an external device connected to an unmanaged computer, you can touch and read every bit of data on that. So if you want security, we recommend that you turn on FileVault for all external accounts.

So that's the end of external accounts. There was some other stuff I didn't get to show today because of various reasons. If you're on the developer site, we'd like to give feedback. You know, if you get a seed, let us know. We're continuing to develop this as we move to Leopard. Thanks.

Okay, so thank you, Bruce. Let's see where we are with our slides. So can we go to the demo slides, please? and see if we have anything up. So I need to resync. Oh my gosh. This is good. So this is good. Thank you, the tech guys. These guys rock. The WWDC tech crew rocks.

So now let me just show you where I'm at. So running back-- so this was 10 minutes ago, where you talked about application loss restrictions and how Leopard clients, they have now different means of preventing people from running applications. So here I am running on a Leopard client. And let me log on our lead hacksaw who probably should be doing tech support for me. And now this user is logging on. And as you notice, here is a copy of Safari on the desktop.

So if we have the user try to do the same thing, like go to terminal and run the hack type scripts, well, they still can't launch Safari from here. So it's still denied. And now the desktop version is denied as well. So this is now the modified copy of Safari. The user has brought this on their FireWire drive or on a USB stick. And has full write access to that. Just mucking with the application no longer makes it runnable on Leopard. So that is the new application loss rejection feature. Yay.

Thank you. And if I now go to our second demo system. So if this syncs up. See, Workgroup Manager is up and running. - Thank God, thank God! So, I'm gonna show you, if you would go back again in time. So this is a time machine, we're using time machine here. I'm gonna run back 10 minutes again, and I'm gonna show you nested groups.

So if you remember on our nested groups demo, we had a user that belonged to multiple groups, but we didn't want to create multiple work groups with just monolithic settings for them. So, what I'm gonna do now is create a hierarchical management view for this particular user. So, what I'm gonna do is go to the groups view, and I will create a preference setting. Actually, sorry, I need to create my group first. So, create a new group, and I'm gonna go all this doc, oops, doc default apps. So, doc default applications, great.

So, I'm gonna save that, and then we're gonna assign some applications to it. So, I'll go into the doc and say manage always, and I don't really like any of these applications, so let me remove these, and let me add some applications that are supposed to be the doc items for any user. And let's do chess again, and let's add, let's say, automator as well. And we really like teams directory, so let me add teams directory here as well.

So, now I have my basic applications that all the users should have. And apply now, so now I have my default applications. And if I go back to accounts, I will create a new group for another set of preferences for the doc as well. And I'm gonna call this the doc admin apps.

So, here I have the administration applications, and I'll go into preferences again, and change the doc settings, and manage it always. So, I'll remove all these applications. And what I want to do is add the server administration application. So, I want to have, let's say, server admin, yes. I want to have system image filter, yes. And record manager. So, I'll add these three applications. So, apply now. So, I now have two kind of work groups. But in the Tiger days, this would have been unique, so you couldn't pick both at the same time.

So, now if I go back to accounts and set the inheritance of this. So, I have... the default applications group but I'll also make a member of this default applications group, the admin applications. So now they are nested and click on save and if I now go into the administration applications and add users to that, so let's say Jane Smith is one of our admins, so now Jane Smith belongs to the admin applications group. So when Jane logs on, Jane should get the admin application preferences as well as the default application preferences in her dock. So, excuse me, that's it. And if I now go back to my client here and log out lead hacker, yes, and Lugon Chan-Smith.

Jane Smith And now the doc should be the default applications and the admin applications. So effectively, I got all the different preferences combined. So Jane now has the Teams directory, Chess, Automator items that came from the default applications group for everyone. And then these administration applications came from the admin group. And Jane just belongs to one group.

So Jane doesn't belong to the default applications groups explicitly. She belongs to that through inheritance. So one way to tell this is if I now go to System Profiler, and click on More Info. So you'll see that we have a new section for Managed Client. So here, if I click on any of this... Thank you.

So you can tell that these application hints come from two groups. And, oh, we have a bug here. So this doesn't really display what they're supposed to be, so let me use a command-line version of this. So I can use, let's see, ID, who am I? I'm Jane Smith, so if I use MCX query, and user is Jane Smith, and my group was, that I logged on, is docadminapps.

Ooh, now that looks kind of awful. But here, essentially you can tell that these two groups were combined. So we have the Duck Administration applications, and we have the Duck Default applications. And these preferences were inherited from that. And this is kind of readable, sort of, kind of.

And if you want to display these preferences in a, let's say, repurposable way, we can say Format XML. And this creates your PList. So now we can actually tell that, oh, yeah, OK, these keys came from Application Server, Workgroup Manager, whatnot. These keys were inherited from the Duck Admin Applications group and Duck Default Applications group. OK? So that's reporting.

And if I now go back to my demo setup. So that's reporting and client-side features and we go back here. So now if I go to terminal and so we mentioned that there was a Director Services Utility extension or DSCL extension to MCX or MCX has an extension to Director Services command-line tool. So if I use DSCL, let me get my cheat sheet here. So I'm going to auth into the LDAP node that is my LDAP server. So server.wcnet and do a Dear Admin auth.

And I guess this is the password. Yes, OK. So if you're familiar with the DSCL, so I can change my working directory just by navigating through the hierarchy, and I know that, OK, I created the dot admin applications group. So I can now use the reporting extension inside the DSCL command line by just saying mcx read and dot. And these are my settings for this particular mcx object for the managed client settings for this group.

So I can see that there are some settings here. But now, if I go back to the users and try to look what's there for Jane-- so if I use mcx read dot, Jane doesn't have any preferences. And that's evident if I go back to the accounts. And try to click on Jane as a user here. And if I look at the preferences, Jane doesn't have any preferences, which is fine.

But if I wanted to do some preference editing from the command line tool, what I'd do is call mcx set. And for this particular record, and say I know that the application is called doc. And the preference I want to set is orientation, and we have a-- refresh problem. Let's do that again. mcx set dot com apple doc. and do not make any typing errors orientation and make it an always preference and it's a string and it's called left.

There. So now if I do MCX read, this particular node, I've just set an MCX preference. So this is managed desktop from the command line tool. And where could this be useful? If you have, let's say, webfronts into your user base, and you'd want to set some login options or whatnot through Ruby on Rails or whatnot.

I don't even know what you'd use this for. The options are endless, right? You have the power. I could create an automator action or a automator workflow and embed MCX settings or managed client settings in that. So now you have full access to the internals of MCX on managed client and use that.

And let me just go back to Jane here and actually show that this works. So now my dock is at the bottom, as you can tell. And let's quit out of that. No more system profiler even. And log out Jane. And then we go into James Smith again. James Smith. and log her in. And without touching Workgroup Manager, mysteriously her duck appears on the left. So this works.

Okay, now I'll take a sip of water. So, all the demos rolled up into one. Where do we go next? Okay, so this was hierarchical groups using Managed Client 10 and using command-line tools, using System Profiler. And there are options to use this with computer groups now as well.

So in future releases or future seed releases of Leopard, we have all this stuff working. Right now on the developer seat that you have, there are stubs here and there, so you might actually see some of this, but all of that hasn't been vetted from end to end, so you might see some interesting interaction, but wait for the next seed, and then please give us feedback as what works for you, what doesn't. So that is the Managed Desktop demo, and next we'll go on to... Slides and Nick, do you want to set up your demo here?

So now I know where we are.

So Time Machine doesn't actually give you future predictions, so that's too bad. External accounts, so we did external accounts. And this was Managed Desktop. So for Managed Desktop features, we also are looking at plugins. So there are new features in Workgroup Manager, of course, to keep up with Leopard Client. There are no controls over application loss restrictions. There are controls over Dashboard. And for mobility, of course, we did-- Go back.

Popul Mobility. So we have account expiration. So if you wanted to have a cart of MacBooks and have portable home directories created on those accounts or have them expire automatically, now we have expiration control for that. We can restrict how many accounts are created on a machine. We have external accounts, of course, part of that, and controls in Workgroup Manager for that.

And we have options of turning off or disabling internet sharing. So if your site doesn't really want to have rogue DHCP servers on the network, we can enforce that policy as well. And we have options of allowing disk images to be restricted as a unique data type, as opposed to just removable media.

And we have also under the hood controls for some application level settings. For example, for iChat, if you were at the server overview yesterday, the simple server setup where clients actually get their configurations from their team server or their server setup, that is using the managed desktop feature set for preference controls. And there will be others as we develop other features, maybe for backup or things of that nature. So this concludes the managed desktop part. So let me then move on to system imaging.

So system imaging, we wanted to take the next step in system imaging. So bring the platform forward. And the two things we found that we wanted to make it easier to use, and that is through an image assistant. So there is almost one-click image creation process now. And then we wanted to make it easier to redo your workflows. So if you're creating similar images repeatedly, then we'd probably want to use something like Automator to re-execute the workflows.

So also under the hood, you'd want to have control over how these images are created. So in addition to making it easy to use, we also want to expose some of the internals of how system imaging actually works and give you the option of creating exactly the kind of deployment sets that you want to create. And this is also available through command line tools again. So not just using SIU as a Cocoa app. we can now create system images from terminal.

So, command-line tool and Automator Workflow. So, we decided that probably the best way to expose all the things that happen when we are creating system images, either creating net boot images or net install images, is to create an Automator action for corresponding items that we do internally. So, this is like the Erector set or for Europeans that are Meccano set. And this is just giving us the building blocks as well. So, we now have a very modular design of the System Image Utility where individual elements can be called independently from one another.

It's not just a monolithic like stove pile application. You can take pieces what you need and basically build different kinds of workflows or methodologies of creating images through this. So, it is modular by design. And what Automator gives us as well is that we can reuse these workflows. We can save the workflows and apply them to new images. So, let's say we get a eight core Intel Xenon, who knows what.

And you get the latest Mac OS X Leopard version, 9K1234. So, you probably know that that's not something that you can just swipe on any system. So, you want to bring your system images forward. And to recreate that system, you can just apply a workflow against that system and get all your other settings automatically applied so you don't have to maintain, 15 different versions of systems. You can just use this workflow and apply it on multiple systems.

So hopefully that's going to be, yeah, resume from System Image Utility and from command-line. Here we go. And... This is kind of self-evident now. So you can also use the command-line utility to bring up some parameters as to like call in the image that you're creating on a different name.

So passing variables that are particular to that one image and pass those on as arguments into the workflows so that you don't have to go back into System Image Utility and edit the workflow just to touch up on some image ID or the image name or some other parameters there. And now Nick, who is the lead engineer now on System Image Utility, he will give a demo of the system image utility.

Hi. Can you hear me? Hello. I'll give you a short glimpse at the new system image utility, which is at the moment completely work in progress, so you won't find it on the seed CD. But just have a look and take a look in the next seed, so you'll probably find it there.

So let's just say Leopard came out and you want to deploy it as fast as you can. You probably want to use our new assistant. You just drag the DVD over here, select assistant, and instantly, in the matter of a few clicks, you can just create a new net install image.

Everything gets filled out for you, pre-filled. And at this point, you're already set and you can create your image. I skipped this here, otherwise we would, well, have no Q&A at all. At next I will show you how to make your own workflow. Let's say the same scenario. Take your Leopard CD, take it over.

Now we have here our image selection action where you can choose whether a net install or net boot or what source you want. Add some image data. Give it a name. Say we're making NetBoot. Netboot of Leopard. Leopard, give it some index and we serve it remotely, locally. And because it's a netboot, we have to add a user. So I want to add myself here. Nick and some password. And also at this point we already could start creating the image. But I just want to save it here.

We have already one workflow. Well, OK. So at this point, I want to show you how to reuse an image and a workflow that was saved. Take it over. And so we have the same workflow we just created over here, and now we can go completely crazy with all the actions we have.

We can add another user. What is it? Oh, add packages, sorry. Took the wrong one. Of course, you can add packages. Nothing interesting here, so I'll skip this. Add another -- huh? Oh, I think I found another. Oh, yeah, okay. There we go. Make it a bit bigger.

and some admin user here. Don't care about passwords. One of the very cool features I think many of you requested is the per-image MAC address filtering. We have some issues here with the scrolling. Where does it go? Make address filtering. Make address filtering. Here we go. Sorry. We can now filter the Mac addresses per image and not on the server as it was before. So just enter here some fancy Mac addresses you want to allow or deny for a specific image. We could also, of course, customize our selections of packages. As it was used in the old network image utility, go away.

As is a mighty mouse. And... Hey, see I'm not the only one who has problems with this. and and customize your selection here or do model filtering as I have to fix this one and say we will only get it out to our new Intel systems so we can really force the Yeah, I know the new Mac Pro is missing. Sorry for this one.

Tyed into a directory service, of course this is still in. And one of the things I think you all were waiting for is the remote image restore. We can now hook directly into an ASR multicast stream and restore ASR images.

I think we will add several more actions for the next seats and on the next seats this too will be included. So yeah, we hope to get your feedback for this. So I hand over to Juussi again.

So, thank you Nick. Isn't that cool? Yes. Back to the slides please. So that was the demo of Automator. So this will be a Leopard-only feature. To use the 10.5 tools, you require 10.5 OS. So if you need to create a tiger, jaguar, panther, whatever images, you'll need to use the previous tools from either Tiger or earlier. But you can still serve the images, any images on a Leopard Server, and the Leopard-created images can be served on other previous systems as well.

And in summary, before we go into QA, so what did we cover? Managed desktop. So the top three items we have, application launch restrictions, so fix it and forget it. Users should not be able to go and circumvent the application launch policies anymore. Adding dashboard support for that. Hierarchical groups, so we can now have nested groups and workgroups that inherit preferences from other workgroups, including reporting tools.

So we have system profile integration, and we have a command line tool, and we have command line tools for setting managed client preferences. And external accounts, so next generation of portable home directories and mobility, so you can actually carry your home directory on a external drive. And then for system imaging, so simplified image creation, and we have automated workflows, and you can all do this from the command line.