We're going to give you guys a little bit of detail about Apple Remote Desktop and I'm going to just do a brief intro. I'm the manager of the management and collaboration group which includes ARD. And in case you don't already know, ARD 3 is out. We've been working on this for a long time and it's great to have it out there, but it also, it being out there, gives us an opportunity at WWDC to kind of take a little different angle on it in terms of a presentation. So, just a little bit of a rah-rah, a little bit of cheerleading about ARD, some quotes about how it's being received out there in the market. This is a gentleman who's really, really happy that we spent a lot of time improving the file copy.

It's a simple little, it's a simple little, it's not a simple little task, but it's something that people do a lot, copying bits from A to B. We spent a lot of time on that and this guy seems to like it. Then we've got a very different customer, Pulitzer Prize winning photographer, Vincent something last name.

And again, he's sitting here using the remote access functionality. And what I like about these two quotes is that it shows something about ARD that we really serve a lot of different customers. Obviously an IT product, but a lot of different customers. different people get a lot of different value out of the product.

So, I'm going to give you guys a little brief history of the product. And then we're going to get into the real meat of the presentation with Mark Whitemore, the ARD engineering manager. This is going to be different because what we're going to do is we're going to get really under the hood of the product and show you how it all fits together. ARD 3 introduces the task server concept and that makes yet another process that's running as part of the whole ARD ecosystem. And we wanted to give you really good details about how that all works.

The other thing is, is we get a lot of, Creative feedback about how ARD is being used out there. And I think we got a lot of good advice and ideas about how you can use it even better. And we've got demos all over the place. So we're going to show you how we're using it, some fun ones and some great examples of how you can use ARD right.

So I'm not going to go into all the features that we've been doing since I got here about four years ago, but obviously we've done a lot of releases of ARD over the past four years. What I want you to look at is sort of that curve, the innovation curve there.

We started with the first release just getting it running under Mac OS X a bunch of years ago, and then we started adding more features, and we started adding more features. And then with ARD 3, Apple Remote Desktop 3, we added a bunch more features, the task server, remote drag and drop, automator support.

Obviously, we're done with the current release, but as we get to Q&A here at the end, I'm really interested to hear your feedback, how you like it, what you'd like to see in future releases as well, because we're going to keep on pushing this product. We're going to keep on adding more great features to it.

When you think about the product, I'm fond of calling ARD a Swiss Army knife. When you compare us to the different products out there in terms of these five or six buckets, you are often comparing to individual products out there. ARD is an all-in-one solution. It's a software distribution solution via the install package, the copy items tasks.

It's the asset management via the dizzying array of different reporting tools, reports that we have in there. It's the remote administration, the remote assistance, the feature that everyone can see where we allow admins and IT types, labs, lab IT types, teachers to help via remotely observing and controlling machines.

It's automation. With the automated support that you have in Apple Remote Desktop 3, we've given you a tool to build more tools. And that's one of the things I like about the product. Tools like Send Unix that really allow you to extend the functionality to adapt it to how you want to use it. And again, the setup. How you actually go and use the product, configure the product to get it working in large deployments.

I'd encourage you if you have more questions to go to the site and also give us great feedback at the end. But with that, I'd like to bring Mark Whitemore up who's going to give us some of the in-depth inside what's going on inside of ARD slides. Mark? Mark? Thank you, Michael. Good morning. Thanks for coming. Let's get started.

Let's get under the hood of Apple Remote Desktop here. So I'm going to talk about the processes that make up Remote Desktop, talk about what each of these processes do. We're going to take a look at the preferences. This is going to be interesting for those of you who are creating system images and deploying them because you might be wanting to tweak some stuff after you get your image deployed. I'm going to talk about how these processes communicate with one another so you know what UDP TCP ports you need to be aware of.

We're going to talk a little bit about network design because some people have issues with how their network is configured and how Remote Desktop behaves on their network. And so we're going to take a look at that and try to hopefully give you guys some ideas of how you can resolve any issues you have. And then lastly, we'll do a little demo with scanners, task server, and reporting so that when you guys use it, you can build it more successful in actually using those features.

First, let's talk a little bit about Apple Remote Desktop technology so that for those of you who are maybe not as familiar with others for the program, we'll all be on the same page as far as what I'm talking about here. So clients, these are the machines that you're actually managing with Remote Desktop and they're the ones you've got deployed throughout your organization. The administrator console is the program that you have RemoteDesktop.app running on and the machine from which you're controlling all these machines. And their task server is a lot like an administrator but it doesn't run the Remote Desktop.app program.

On the task server, it requires a license just like the administrator but this is the machine to which you can delegate tasks that you've set up on your administrator console like install package. So your administrator console can, you can do something else instead of hanging around waiting for your task to complete.

So this is how they all tie together. Basically, everything kind of communicates with everything else. You've got your administrator talks to your task server, your task server talks to your client, and your administrator talks to your client. We're going to get into more detail though about exactly what communication is going on here in just a moment.

So, let's talk about processes. What are the processes that are running on each type of computer and what are these processes doing? Because what you're going to see is that some of the process runs on each different type of computer, the administrator, the clients, the task server, but they serve very different roles on each of these machines.

So on the client, we have ARD Helper. This is what kind of kicks the whole thing off. In system preferences and sharing, when you turn on Remote Desktop, you're actually enabling the helper to start up. And when the helper starts up, when the machine starts up, that kicks off the ARD agent. The ARD agent on the client machine is responsible for actually performing the task. It's the workhorse for Remote Desktop. You do a send Unix command to a client.

This is the process that's actually running and executing it and sending the response back to an agent on the administrator. We'll get to that in a second. Mike Lopp, Mark Whittemore, Steve Hayman Apple VNC Server on a client. This is a separate process that when you do a control screen, is grabbing the screen contents and sending it back to the admin. And this gets launched by ARD agent startup.

On the administrator console, of course, the app that you are all familiar with is Apple Remote Desktop.app. This is the main GUI console. On the administrator side, if you don't have access turned on, what gets the agent launched is Remote Desktop itself. So when you launch that, the agent isn't already running.

If you don't have access turned on, it kicks up the agent. Now, on the administrator console, the agent has a slightly different role than it does on a client machine. It still does all the same things it does on the client, but in addition to that, it acts as a conduit for Remote Desktop.app.

So when I do that send unix command, it isn't the admin app that's directly communicating over the network to the client. It's actually going through the agent, and the agent is communicating to a similar agent on a client machine and saying, here's the send unix command, please perform this, and then it sends the status back.

Now, the Apple VNC server on the admin machine also has a slightly different role. Whereas on a client, it's grabbing the screen changes and sending them back to the admin. When you do a share screen on the admin, the VNC server there takes the admin, the screen contents, and sends them out to all the clients.

On the task server, so on the task server ARD Agent does the same thing that it does on a client, but in addition to that, it handles all the responsibilities of the task server. It handles the delegated tasks like install package. It stores all the files that are part of the install package task. It communicates with all the clients and distributes the files out. It accumulates the results and sends them back to the administrator when the administrator is online.

RMDB, that is our database in which we store all the system information, application usage, and user reporting information. It's a SQL database. It's PostgreSQL. You can set it up to communicate with it across the network if you want to. And the ARD helper and VNC server on the task server work the same way they do on the client.

Okay, preferences. What are the important preference files and what are these files contain? There's tons of preference files in Remote Desktop. In fact, I often forget how many there are and I have to dig around and rediscover them. But I'll go through what some of the important ones are and why it is you might be interested in knowing a little bit about them.

Okay, first one is the preference file for Remote Desktop.app itself. This lives in your own library preferences directory inside whatever account it is you're running Remote Desktop. And the reason you might want to know about this is because some of these things are things that you, if you want to transfer your preferences to another admin on another machine, if you've gone to the trouble of setting up lots of computers and lists and scanners and save tasks and you don't want to have to duplicate that work, you can take a look at this preference file, copy out the values assigned to some of these keys and move them over to the other machine.

Now, in the case of computers, your passwords are stored in the key chain. They're not going to follow with you when you bring that stuff over, so you're going to have to re-authenticate, but that you can do a multi-get info and type in the password as long as you don't have a different username and password for each machine.

Now, the main preference file for the agent is ardagent.plist. This is a global one. It lives in slash library preferences. Now, these particular preferences that I have up here are the ones that are specific to the agent when it is running in the role of the client. Because remember I said it runs on the admin, it runs on the task server, it runs on the client.

In each case, it has a different role. In this case, these preferences are for the client side. There are other preferences that the agent uses that are located in other places. Like, for instance, when it's acting as a task server, there's some root readers that are located in the client side. But it only preferences in another location.

Now, the one that is probably of, might be of greatest interest to most of you, well, actually, there's a couple that are pretty interesting here. But one is ardagent log level. And if you are trying to debug an issue with Remote Desktop, if things are just not behaving right and you'd want to get a little more information, you can set this log level higher. Right now, it's set to three. You can set it all the way up to seven, get maximum logging.

You restart the agent and you look in system.log and you'll see all kinds of stuff. And the cache policies, when you set up a reporting policy, on a client using the admin, an array of those policies is located inside of this file. So you can go and double check that everything looks good on that side if you want to. And it's also useful for debugging in a situation I'm going to talk about a little bit later.

Okay, hidden prefs. There aren't a lot of them, but some of them are going to be useful. I'm not going to talk about all of them here because I'm going to be at the 2 o'clock session this afternoon. So don't go ahead and try to write them all down right now. Come and see me. I'll have this stuff for you there and you can copy it down.

But basically, there's some prefs to control your transition and multi-observer if you want to play around with that. Show the short name instead of the long name inside of the computer list. And then there's some preferences that affect control screen, the VNC server part of it, as well as some things relating to file copying with multicast and so on.

Okay, lines of communication. So I'm going to talk about Who communicates with who and what they communicate? Or what protocols they're using, sorry. So here's the basic diagram for Apple Remote Desktop. You've got your administrator, your client, and your task server. And there's all kinds of communication going on constantly between them. I mean, not that it's chatty, but they're always communicating.

So with the administrator console, when it talks to the client, for instance, it communicates over UDP port 3283. Also on the task server, since that agent acts as a client as well, it communicates over 3283 UDP with that as well. But it also has a persistent connection, a TCP connection to the task server.

So when you launch your admin, your task server is out there on a separate machine, it's always connected. Now the task server also communicates with clients over port 3283 UDP. So it's not just a TCP and TCP. Whenever the client is in the middle of receiving information from the task server, like an install packet, it does that over a TCP connection.

Now when your Remote Desktop.app is doing a screen control, it communicates with the Apple VNC server on the client. It does so over TCP port 5900 and 21. Now 21 is the SSH port, and that's the one that's going to be used if you're doing an encrypted control screen. Now it's the case that always the command, the mouse gestures and the keyboard characters are always encrypted, but if you want to additionally encrypt the screen data, that's when port 21 gets used.

Now when you do a share screen, we share the screen in a multicast manner. And so that's done from the Apple VNC server on the admin machine to an application called ARD Force Viewer on the client machine. So that's actually an app that gets launched and is what displays the admin screen on each of the client machines.

And so that gets its communication over port 5900. So the reason this stuff is important to know is if you're going to be setting up firewalls, you want to make sure that you've got the right kinds of ports open. And we're going to talk a little bit about firewalls later.

Actually, we're coming up to it real soon here. So network design. What are the common issues and how should your network be configured? Now, when I talk about our kind of remote desktop's ideal network configuration, this may not be something that's going to be totally practical for in your organization, but at least it's going to give you an idea as to what ARG's basic network requirements are.

So common issues: firewalls, NAT routers, multi-homing and just multicast configuration. So starting with firewalls, you know, firewalls can be in lots of different places in your organization. They can be on your admin side, on the host side. It can be inside of your switch or your router or it can be on your client side.

So the thing to keep in mind is that when, if you do have issues, make sure that these ports and these other requirements are met so that on your switches, for instance, you allow broadcast. Broadcast is needed for upgrade client. If you turn off broadcast, you're not going to be able, you're not going to be successful at upgrading your clients over the network. Multicast is needed for file copying on the local network. It does that in order to reduce the amount of bandwidth that's used.

Ping, the scanner, the local scanner and the range scanners, the first thing they send out is an ICMP packet in order to try to find these machines. If it's successful, then it communicates with them in report 3283 to try to get more Apple Remote Desktop specific information. So if Ping is disabled, you're not going to be able to find them.

And one thing to keep in mind is that it's easy to accidentally disable Ping because in the network control panel or under sharing, I think under firewall, there's a stealth mode option. You turn that on, that actually turns off ICMP. It doesn't say that, but that's the net effect. So make sure that that's not turned on in your client machines. Thank you.

Also, your internet service provider may also have a firewall that's preventing certain traffic like UDP packets, for instance, from getting back and forth. Now, one of the symptoms that you might see if you've got a firewall issue and UDP, for instance, which is critical to Remote Desktop, is blocked, is that you may see a machine show up that just says VNC only or VNC on instead of actually seeing the nice blue computer with all the status that you're used to.

And the reason you see this is because when Remote Desktop app is trying to find these clients, the first thing it does is it tries to send out a packet of 3283 to communicate. And if that isn't successful, it tries to do a VNC connection on 5900 because for all it knows, it may be a PC that it's communicating with. So if you know that A or D, the agent is up and running on a client and you're seeing B and C, then think about checking your firewall settings and make sure you don't have an issue between your admin and your client.

So NAT routers. NAT routers are more or less a no-go for Remote Desktop because all the clients on the LAN side of your router show up as one address to Remote Desktop. So it's not going to be able to successfully administer all those machines. So in order to deal with that, there's a couple options.

One is port forwarding and one is VPN. If you want to go the port forwarding route, make sure you've forwarded all the necessary ports and do that to a machine that you're going to run a second copy of Apple Remote Desktop on. That way you can do a control session to Remote Desktop running from the WAN side into the LAN side and that RemoteDesktop.app can then see all the machines that are on the LAN side of the NAT.

And VPN will also work for you as well. If you can VPN into the LAN side of that NAT, that's going to give your administrator machine an IP address that's going to appear to be on that same network. Then you can use this remote desktop from your administrator console to see all these machines. This is how when I go home, I VPN into work and I'm on the same network as I would be if I was at Apple and I can control all the machines from home.

Okay, multi-homing. This is a mid-limitation of Apple Remote Desktop. It does not handle multi-homed clients very well, mainly if the two different networks or all the different networks that your interfaces are on can end up routing back to the same network that your client is on. And what happens from the client perspective is that the admin sends out a packet over 3283 and it doesn't know down at the networking level which interfaces it's going to go out of.

It's beyond its control. It's beyond the control of any network app what port this stuff is going to ultimately get out of if your app is written as a well-behaved network application. So it may be at one point that the client receives a UDP packet from what looks like 20.001.

And in another case, it'll receive maybe the next packet from 10.001. But the client, when the administrator authenticates to it, now has a session going with the administrator and it's expecting all packets to come from one address. It's not expecting this kind of flip-flopping of addresses as data is sent to it. And particularly for copy items, it's really bad. So if you're kind of getting sketchy status like, oh, I got status from the machine when I first started up, but then it kind of went away after a minute.

And you know that your machine has multiple interfaces going, you might want to consider turning off one of those interfaces or making sure that both those interfaces can't route back to the same network that your clients are on. And in this case, in this example, it's real easy to end up doing that because a lot of machines have both Ethernet and AirPort. And a lot of times when I'm at work, I'm plugged into both and I control a machine and I might have issues with it.

Okay, multicast configuration. Basically just make sure in order to support file copy on your local area network that if you've got switches, make sure that it's enabled. And in some cases, some switches or routers support bandwidth limiting, so just make sure that whatever bandwidth limiting you want to use, just make sure it's appropriate and relatively high in order to support efficient transfer of data when you're sending out copy items.

Okay, so basically in summary of all this, what we recommend is to have a nice switch network. So because we're using a lot of UDP, you don't end up with too many retransmissions. Make sure that your firewall settings are correct. If you're using multi-homing, make sure there aren't multiple, no routes between your multi-homed interfaces. Use smaller subnets and ideally an administrator console and task server per subnet.

But I know for some of you that's not particularly realistic. So in a larger kind of network environment, you could have a router, you can have an administrator, one single administrator that can then, on one subnet, that can then control an administrator on each of your other subnets.

And for instance, in copy items, if you've got dozens and dozens of subnets, if you, from let's say the administrator here, 1003.1, the guy at the top, if you do a copy items out to all the different machines on each, to those subnets, it's going to do it in a unicast manner. And so it's going to take a long time for that data to get out.

If instead you have an administrator on each of those networks, you can either do a control screen to each of those different administrators and from there kick off your copy items task and that'll do it in a multicast manner. Or through Apple script, you could actually script something that would allow you to send from your administrator the items that you want to copy to the administrator machine on each of those subnets.

And then from there, automatically kick off a second copy items task on each of those subnets that will then distribute the data to the rest of the machines. And so it can happen from your perspective relatively automatically, a fairly easy thing to do. Okay, so I'm going to bring up someone to assist me, Adam Eath, who's one of the engineers on Apple Remote Desktop, to help me demo some of these features and talk about basically how we think they should be used.

I think this works. Hello? All right. Okay. Let this Apple script run. Boy, that's speedy. There we go. So when you have a brand new Apple Remote Desktop and you launch it, after you get through the setup, the first thing that comes up is the scanner window here.

And so one of the things I want to point out is how does Apple Remote Desktop come up with the, you know, how does it fill in the computer name? The first thing it does is when it scans the network, it gets a response back from the machine. The only thing it knows about is the IP address, and that's the first thing that goes in the name field. Then a lot of stuff happens like in a split second, so you never actually get to see this going on.

But I'm going to tell you what happens behind the scenes. Next, it does a reverse lookup on the name and tries to get your DNS name. So if you have a really slow DNS server, which some people do, that can actually sort of bog this thing down. Once it gets the DNS name, simultaneously with that, it's also sending out the packet over 3283 to communicate with the clients.

And once it does that, it gets back to the computer sharing name. And that's what it ultimately puts or tries to put into the name field. I don't know if you could just... If you could just widen the screen a little bit more, I'm going to show them the network field.

Okay, so there's sometimes there's some confusion as to exactly what do these values mean inside of the network interface field. This is the network interface on your computer from which you are seeing these clients. So you see the one on the bottom, the ARD administrator machine says this computer because it's just looking through the loopback device and finding this machine. In the case of the other clients that it's seeing on that rack over there, it's communicating with all those via its built-in Ethernet.

And if you look up at the top where in the little search bubble it just says searching built-in Ethernet. And Adam, if you kind of go over that for just a second, there'll be a tool tip that'll come up and it'll tell you what the range is. So if you just hover over the where it says searching colon built-in Ethernet next to the local network. Got that.

So that tells you what Remote Desktop thinks is your local subnet range. Okay, so Adam selected several machines and dragged them to the all computers list and this brings down the add computer dialog. So when you add multiple machines, in fact when you add any machine, it's going to add them by IP address. Even though it shows you the DNS name for this first machine here, it's only going to store that for informational purposes only, but it's not going to use it in the future to try to resolve the machine.

And the reason is that, the reason we chose to do it this way is because a lot of people use DHCP. And so in that case, storing that DNS name as a way to forward look up the address to find the machine later on is generally not going to be very reliable. It's not going to be any more reliable than just storing the IP address. So we opt just to store the IP address in this case and just kind of skip the step of looking it up. So go ahead and add those machines.

So you can get info on one of these machines. Okay, so as I mentioned before, the primary lookup in this particular case is the IP address. Now, if you edit this and you clear out the IP address field and just hit done, that's going to then change how Remote Desktop looks up this machine. This says, okay, I really want to look this thing up by the DNS name.

So from this point on, what's going to happen is that when you launch Remote Desktop, the first thing it's going to try to do is it's going to use the last known IP address because it may get lucky the machine may still be there. If that doesn't work, it's going to resolve the DNS name and if it resolves to something different than the IP address that it was last known at, then it's going to try the new IP address and hopefully the machine will be found there.

So, a lot of people when they're setting up their network, they end up with a lot of different scanners. They set up scanners for each of their subnets because that's how they go find their machines and that's kind of where it ends. They then use those scanners from that point on to actually organize their machines and go to those lists and that's not the most effective way to use your remote desktop because you're doing a lot of unnecessary scanning of the network in that case.

So, we're going to talk about using lists for these machines in just a minute as the way that you really should be organizing your computers once you've found them. Now, another reason that people tend to stick with scanners is because they feel like they've kind of been burned with machines that have disappeared and they've got to keep on re-scanning for them in order to find them, so why not just keep on using the scanners? One particular instance of that is an IP address will go to 0000 and it's confusing as to why. And it's confusing as to why that happens.

But the reason that that happens is that especially in a case where you've got DHCP for your clients is that another machine on your network has actually taken the IP address of a previous machine, the machine that went to 0000. So, let's say machine A had an address but it went to 0. Some other machine, machine B for instance, comes up and has that address and remote desktop sees that. From its perspective, it knows for a fact. That A no longer has this address. So, it goes ahead and clears it out and that's why you see that.

Now, if your remote desktop that app is not running at the time when this address changes, that's what happens. And that's why if you are experiencing this problem, it's really a good idea to have a separate task server because in addition to taking the load off the admin as far as doing install package tasks, it also will constantly track DHCP changes on your clients. Or just to give you a little bit of a hint, if you're using a remote desktop that's not running at the time when this address changes, that's what happens.

And that's why if you are experiencing this problem, it's really a good idea to have a separate task server because in addition to taking the load off the admin as far as doing install package tasks, it also will constantly track DHCP changes on your clients. Or just when clients just move from one network to another, your clients know about the task server. And when they start up, the very first thing they do is they check in with the task server and they say, "Hey, here I am.

And by the way, here's my IP address." And the task server makes a note of that. And the next time your admin comes up, the first thing it does is it syncs with the task server to make sure that it knows what all the current addresses are as far as the task server is concerned.

And it's a really great way to avoid having a situation where machines are changing IP addresses and your administrators are all going to be doing the same thing. So if your administrator is offline, next time he goes up, someone else has stolen somebody else's address and Rope Desktop doesn't know what to do with the guy who used to have that address because he's not around anymore and he's not communicating with the admin.

Okay, so let's take a look at, assuming you've got yourself set up with a remote task server, what the best way is then to organize these machines and in my opinion is to use a feature called Smart Lists. And so let's say you have, let's say you have a remote task server and you're So, if you have a bunch of different subnets and you've got the machines named a certain way in each of the subnets or you've got an IP address range, you can set up your smart list to just filter down on those machines that match that criteria. So, if one subnet is 10.0.0 or in 10.0.1, you can set up a smart list that's going to have just those machines in it. In this case, Adam's doing it by name here.

And if you hit OK, There's no machines because they have no machines because we've got to change. We're going to go ahead and change the name on these machines so that they're going to match with the criteria for that smart list and they're going to show up in there. Bam. So now they show up inside that smart list.

All right, I think that's probably a good enough demo for basically the smart list. So let's review what it is, what we just talked about here. If we can switch back to this. So scanners primarily use them for finding machines and for adding them. Use your smart list, not your scanners, for organizing your clients after the fact. Use the task server to track IP address changes on your clients.

Client IPs change to zero for a reason, as I explained. And you really should be using scanners as a last resort to find machines that you've lost. Really the thing you should be doing is setting up a task server. But I certainly understand if you don't have that set up, scanners are a good way to fall back and try to relocate your machines again.

Okay, so let's do a little demo of the task server here. So in this case, we've got on this rack here a remote task server already set up. This is a machine that has a second Apple Remote Desktop license, and we're going to configure our admin to use that machine. I think it's just www.dc-ard-9. OK. WMDs.

Does that look good? That looks good. So in this case, it's asking for the username and password because we have to authenticate to it. Now, in addition to setting up, if you've already got your remote task server set up and you can do it at startup like that, you can also do it after the fact if you set up your task server later. If you go to preferences and go to the task server tab, you can see what your task server settings are. In this case, it shows you that we've got a remote task server set up here.

Okay, so we're going to go ahead and add a few more machines here. And so, let's see if there's anything else. So here, when we add these machines, The administrator is going to tell the task server about these machines so that it's going to be able to track all the changes for you.

And we're going to, I think we want to put maybe a couple of them to sleep to kind of demonstrate that when you're using the task server for a task, like install a package for instance, it doesn't matter whether or not the clients are asleep. This is one of the things that the task server is going to handle for you is making sure that the task gets done on those machines that are not online at the time the task is started.

So they can come on, they can start up later on, and then when they check in with the task server, the task server is going to tell them, hey, I've actually got something for you to do. I've got an install package for you to perform. So in this case, Adam's going to pick that package right there.

He's going to select using the remote task server. And we're going to put a little bandwidth limit here just to make the thing go a little bit slower. Now, when we kick this off, another thing too is that in addition to the task server communicating with the clients and syncing up with them, it also syncs up with the admin. So as soon as we kick off this task, once the package actually gets sent down to the task server, we can go ahead and quit the admin. We don't even have to hang around anymore. We could shut the machine down. So go ahead and do that.

And right now, it says that it's sending it over there. So now the package has actually got there. Adam can go ahead and quit remote desktop. And we can sort of just hang out for a moment here. And you can go ahead and fire up remote desktop again. And it'll either be in the middle of installing the package to those machines that were online or maybe have already succeeded. did.

Hope this works. So we're gonna go ahead and wake up those machines that were offline. And once they wake up, they're going to check in with the task server. And once they become available, the task server is going to go ahead and start installing the package on those machines. So as you can see, it's kicking off the install on those guys.

I'm not exactly sure what's up with number four and five there, but those are the guys that were online before? Yeah. Yeah, that's unusual. Why don't you try restarting those guys and see if... These are all Intel iMacs, so they should restart pretty quickly here. There we go.

So as I mentioned before, when they start up, they should be checking in with their task server. And hopefully the task server knows that they've got something to do. So right now you can see that in the current status column, they say that they're inactive once they start up. That should change. And hopefully if we're lucky here, hey, there we go. So it eventually figured out what it is that it needed to do.

Hooray! It works. It does work. Okay, so let's look at in summary what it is that we just saw there. So the task server requires its own license. When you set up the task server remote machine, launch Remote Desktop just once to configure access. There's a preference that says allow other machines to use this as a task server. You want to check that.

After that, you can quit the admin. You don't have to keep Remote Desktop, that app, running on your task server. You don't have to add the same machines that you're adding to your other admins to that machine. The admin that's using that task server is going to go ahead and take care of that for you.

The task server distributes its data in a unicast manner, so it does, for any task, up to 10 machines simultaneously, so it's not going to try to overload your network. And as machines finish, other machines are going to be started. The task server is going to keep retrying the job until it can get done.

So if the machine sleeps or crashes or gets shut down in the middle of an install, the task server will make sure that eventually it gets done. You can use bandwidth throttling to limit how fast you send stuff out. The bandwidth throttling applies everywhere. It applies to your administrator talking to your task server. It applies to your task server talking to your clients.

And the best use of the task server for install packages is when the machines are actually not online. If they're all online, and especially if they're local, it's probably better to not use the task server and just do the immediate mode because it's going to be faster for you, unless you really need to close the thing down and go do something else. Okay, so lastly, we're going to do a reporting demo. So basically we're going to set up our remote task server again. So this machine is going to receive all the caches from the clients. When they get generated, it's going to store those.

Okay, so when you're setting up a remote desktop for the first time, some of you have probably come across this setup pane here. And this is for setting a default reporting policy. This is a policy that's going to tell the clients what caches that you want built. And it gets applied to these machines as soon as you add the machines to your computer. This is not going to overwrite the policy of any existing machines that you've got out there.

When we set this up, we had a problem with the original remote desktop. We had a feeling that a lot of people didn't really get about setting up these report policies. And so we kind of put this in here to make sure that this was kind of right in your face and you saw it and you thought about it.

I think we've sort of got the converse problem now where everyone has reporting policies set up. And if you've got multiple administrators managing the same machines, every administrator is shoving their policy down this machine. So this was really kind of intended for the single-player. This is a real admin case where one administrator was managing a set of machines and not multiple. If you're in an environment where there are several administrators all managing the same machines, you probably don't really want this set up.

You should probably uncheck this and go ahead and just one person should be responsible for setting these policies or at least coordinate between people when you're setting up these reporting policies. And before when I was showing you the preferences for ARD Agent and I said, "Here you can look to see what reporting policies are set up." If you think you've got a situation where now that you've heard what I've said here about this, where several of your admins are all sending their reporting policies down. And keep in mind, these things do not overwrite each other.

They just get added on there because each one is a separate admin. You can check that preferences file and see whether or not that's actually the case because there'll be an entry for each that's keyed by the Ethernet zero address. And check in there and you'll be able to see whether or not you've got multiple admins putting these reporting policies down and you'll be able to hopefully relatively easy identify who it is in your organization that's putting these policies in there that you don't want because their EN zero address is in there. So okay, let's go ahead and kick this up here.

So go ahead and add some machines. So here we've got the checkbox that says apply default data upload schedule. So when you've got that checked, this is going to apply that schedule that we had set when we came in. Now, the times that are set for that are basically seven days a week at midnight. That's the default. You don't see that stuff, but that's what it's set to.

And we can go ahead and review that in just a minute. So we're going to add these guys here like this. Now, we're going to add a few more, but we're going to turn off that checkbox so we can see what it looks like when they're not set and then talk about how to add them manually.

Okay, so go ahead and do a get info on one of those machines. We'll take a look at the data settings here. So go ahead and click "Edit" here. So here's kind of the big pain where all of these settings are set for your cache policy. And so this is what a default one looks like. Now, for those of you who are upgrading from 2.0 and you already had your reporting policy set, one of the new things in Remote Desktop is app usage and user accounting.

Those things are not getting set by default. So you need to actually go and select all your machines, do a "Get Info" on all of them simultaneously, and you can edit the schedule information for all of them at once. And you want to turn on those top two, the ones that say "Collect Application Usage" and "Collect User Accounting." So in this case, Adam selected some that have kind of a mixed result. So if he were to check over those things, that's then going to go ahead and do that. And if he applies this now, it's going to push those down.

Now, another thing is when I talked about multiple administrators putting their cache policies on an agent, it's not enough just to go into that agent and manually edit the P-List and pull out the cache policies that you don't want. Because each time that agent is authenticated to by the admin, the admin re-pushes down its reporting policy.

So you really need to resolve the problem at the heart of it and go to the administrator. So you can go to the administrator console that may have one of these default policies set up and turn that off. If we can just go back to preferences, the main app preferences for just a second.

and go to the task server. So down at the bottom there, looking slightly different than that other pane, is this is the default information. This is where you would go to change that same default information that you got set up when you started up the program. So here's where you want to go to if you think you have another admin that's set up with this stuff and turn this stuff off. It's enough just to uncheck those check boxes on the front part. You don't have to go into here to do that.

Okay. So some folks have some problems with app usage and user accounting because they go and they, well, either because that stuff isn't set up and nothing has been collected or they just want to try it out and they've picked a machine, they know they've enabled this on it and they go and they launch an app and then they run the report and nothing shows up in the report. There's a couple of reasons that might happen.

One is that if you go ahead and bring up an app usage report there, you notice that the end date is the day before. It's not today. So that might be one reason why you're not seeing anything. The other is that... The app itself needs to have some kind of closing event on it.

So when you launch an application, nothing has been written yet to disk. We don't record that event as, okay, this app has launched. You have to switch out of it or quit it or log into another account and then we'll record that. And after that event happens, if you go ahead and run the report and you click rebuild data for report, you'll be able to see that event happen.

So I think we've got, yeah, okay, so we've got some of this stuff actually stored there now and you can see that we've got some of the amount of time that the app was front most, the total amount of time that it ran, who ran it and what state it's in, whether it's quit or in the case if it was running and being switched in and out, whether or not it's still running and what the processes are in the computer and so on. All right, I think you want to do a user accounting one real quick too, just to show that one off.

Okay, so we see which user is logged in, how long they're logged in, and from... and others have been involved in the development of Apple Remote Desktop. The latest version of Apple Remote Desktop is a powerful system management platform. Find out how to put these features to use in different environments. Find out how to put these features to use in different environments.

So the default policy, again, intended for a single administrator. You can change the policy on any client using Get Info. Those policies get sent back down again every time you authenticate. It also gets sent down at exactly that moment when you change it. And look in ARD Agent Preferences for the cache policies.

And upgrading, when you upgrade from 2x to 3o, that requires that you actually turn on that user accounting and reporting stuff. Next, we're going to actually have more demos, but these ones are fun demos, unlike these somewhat academic ones. And Steve Hayman is going to take care of that. Adam, thank you very much for your help with that. We appreciate it.

I'd like to say a special hi to all the Canadians in the crowd, all the Canadians in the crowd. Once again, WWDC is on a week when there was a Canadian holiday. Monday was, of course, Canadian Thanksgiving. It's coming a little earlier than it used to. Global warming.

Anyway, I... I was talking with the ARD engineers over here and I said I thought I had some fun demos and they claimed that ARD was not in fact a fun program. Well, of course it's a fun program because any application that has scripting is a fun program.

And any application that lets you do something stupid on not just your own computer but on nine other computers or perhaps 500 computers is by definition kind of a fun program. So I want to talk a little bit about the scripting and automator features that are in Remote Desktop.

One of the nice things about this is that I can dream up my own additional features now for Apple Remote Desktop and implement them myself and I don't have to bother these guys. So here is one simple example of something a lot of people would probably like. I've got a list of, can I say by the way how much fun it is to be sitting down there waiting for your demo watching the previous guy renaming the computers. You're going, oh my god.

So, crossing our fingers here. Here's a little Apple script. This is a remote desktop Apple script. If we look in script editor in the dictionary for remote desktop, You can see some of what's available. There's a whole suite here of different tasks you can create and different objects such as computers and computer lists and you can send them messages and you can make up your own tasks on the fly and create scripts and automated actions and Cocoa applications that tell Remote Desktop to go and do something.

So here's a simple example. This is a script that's going to tell Remote Desktop to look up the selected computers and then tell Terminal to launch an SSH session to each one. I'm a command line, terminal-oriented kind of guy here, so I would find it convenient, and in fact, this actually was a feature that I asked the team for.

Could we not have an easy way to let me start a new Terminal SSH session to the selected computers? Well, I don't need to wait for them. I can come over here and select a bunch of computers, and I've arranged to have this particular script in my script menu already.

I thought I had. Well, we'll just run it from here. If we run this, this will actually ask Terminal to open a new window with an SSH session to each of the nine computers. So I think for a lot of admins, this is a script they've already written.

Once they found that Remote Desktop had this ability to determine, to allow you to determine the selected computers, and knowing that Terminal has the ability to launch a new command to a new machine, you can combine these two things. Really interesting. Scripting is this sort of order N squared process where it gets much more interesting depending on how many more applications you can roll into the same script.

So that's a pretty easy one that I think a lot of administrators would find to be very handy. Now, because we've got scripting, we've also got the ability to create our own automator workflows that talk to Apple Remote Desktop. Remote Desktop ships with something like 30 automator actions. There are a bunch more you can get. If you go to automator.us. slash ARD, you can find another 30 actions. I think I've got all of those in here.

But there are simple actions that will get the currently selected computers, that will ask them all to open a particular application, or to empty the trash, or to restart. And you can build your own little mini applications in Automator like this right away. Let me start with find Remote Desktop items.

We're going to find, I've got a computer list called WWDC that's referring to those nine computers over there. And then I just want to be able to lock all the screens. So this is a very, very simple. Workflow. Find a computer list, lock all the screens with a particular message.

And if we run this little workflow, I can't see the screen, so I'm desperately hoping that they will all lock. Have they in fact locked.

That's a good one. Hang on. You know what I'm going to do? I had this idea here. I'm going to take the opportunity to have a drink of water right now before I get on the plane tomorrow. Yeah.

How are we doing over there, Bruce? We're back? They're booting. They're booting. That's great. Bruce is going to give them the big thumbs up over there. Bruce, you've got a speaker badge for this show just so you could, and all you're doing is basically sitting there and telling me what's on those screens, right? Okay. In fact, let me open a little multi-observe window here so we can all see what's on those nine computers.

Well, I want to show you a couple other variations on workflows and automator ideas. Here's one that-- actually is a sequence of several actions involving Keynote and Automator and Remote Desktop. What we're going to do here is build a new Keynote presentation on the fly. Keynote has some Automator actions that can create a new slide.

We're going to use an Automator action that talks to Remote Desktop that tells all nine of these machines to pop up a simple question and answer dialogue on the screen. The students from my class over here are going to vote on the questions. The data is going to flow into the final action, which is going to use Keynote to create a pie chart of the results.

Fingers crossed. Are you ready? Because I'm going to do this. Yep. Here we go. The interesting one is one I wrote down here in the middle. Ask a question and I will set it so that it shows the action when run. So what's your question? What is your favorite CFL team? Fingers crossed. Are you ready? Because I'm going to do this. Yep. Here we go.

The interesting one is one I wrote down here in the middle. Ask a question and I will set it so that it shows the action when run. So what's your question? What is your favorite CFL team? It is fun. See, Remote Desktop is fun. Here, it is fun. Except when you try to unlock the screen. So that part's not as much fun. Well, I want to do one last thing here.

Let me just cross my fingers here and hope that this is going to work. Give me one second here. I'm not always in front of my computer, but I have a cell phone. I have a cell phone with Bluetooth and I have Sol and Clicker on this cell phone. Sol and Clicker, there are a few tools like this. I like Sol and Clicker. It executes Apple scripts in response to phone events. And I have a menu on here that I've set up called ARD.

And in my ARD menu, I can ask all nine of those machines to display their IP address. Oh, I'll put up the big window. Yep. If you can't, I'll see it. Thank you, Bruce. I would like all nine of these machines, me clicking on the phone, to display their IP address.

How full is the disk? OK. Show me the host name. The machine name got changed, but not the host name. Show me the host name. And we spent an awful lot of money to have a mixer over here to take the audio output from these nine machines just so that I can do this. Say the host name.

Welcome to WWDC from WWDC ARD Summit. Hey! How much did that mixer cost just for this bit right here? This, what I'm doing here is kind of a commercial for a session we're doing tomorrow on automating Apple Remote Desktop at 9 o'clock. If you want to come to that session, I'll explain exactly what's going on here. But I think you'll find that a few simple little scripts can make Automator and Remote Desktop work together.

I got one more I just thought of. Dangerous. Well, you made the mistake of finishing early. That was your problem. You went too fast here. Let's just see here. Is there any reason this is not going to work? Let's see here. Yeah, there's a Sudoku puzzle on all nine computers.

Alright, that's just a brief look at what you can do with scripting. I'm so glad that they put that feature into Remote Desktop because that keeps, A, it keeps me off their case. B, it means I can go off and implement my own features, either as saved tasks, automated workflows, even custom Cocoa applications. So if you can, come to tomorrow morning's session and we'll go into great detail on how a lot of this is actually done.