We are going to talk about your organization's first Macs. With me today will be Ian Kelly, Senior Systems Engineer, and we're also going to have a short demo on some things, but I want to ask a couple questions first. First off, how many people have never been to WWDC before? This is your first time. Excellent. You're in the right place. Secondly, how many of you have never administered Macs before? Good, you're in the right place. Welcome.

When we get started, we have some people that we want to talk to today. We want to talk about the Mac user in a Windows-dominated environment. We want to talk about the Mac support staff, the island of Mac people. And we want to speak to you, the Windows IT administrator who's now been handed the Mac support.

What are you going to learn? You're going to learn strategies for gaining acceptance and offering support for the Macs within your organization. We're going to talk about migration planning. We're going to talk about building acceptance for the Macs within your organization. And we're going to see with a couple of case studies how others have done this.

What we're not going to learn, this is not a full and complete deployment session. It's not a detailed integration session. That's not what it's about. It's not an imaging session. However, there are other sessions this week that I urge you to go to. You'll see them on the slides a little bit later on. For example, the Directory Services Troubleshooting session later on this week.

Excellent session and I urge you to go to that as well. We're not gonna talk about patch management and this isn't a quick and dirty shortcut way to do this. We wanna give you real solid strategies for supporting your Macs. So let's look at the Mac people. Who are they? Well, I'm one of them. You have a new Mac user. It's an executive, maybe a superior. They don't really have a technology background, but they have a Mac.

They may not speak all the Mac stuff yet. They may not call it a doc. They may not really understand it, but they've got it. The value is placed on the integration. And if you're the IT administrator, they don't care about your feelings. They write your check. Make my Mac work.

What they'll use? Mail, Safari, maybe iWork, maybe iLife, probably Microsoft Office, and they may have a Mac at home. And as we're going to see a little bit later on, if they have a Mac at home, they're probably a local administrator. and chances are in your Windows environment, you don't allow your Windows people to run as local administrators. Not a good idea. So there's a little bit of re-education that has to go on here. We'll talk about that.

The other set of Mac people are the Mac Island, right? It's a small group, maybe a graphic design group. They're self-managed, they're isolated from the corporate IT strategy. They just, they don't get any love from corporate IT. and the Mac IT staff. Maybe one person, right? Not supported by IT. They're forced into the back. At this time I'd like to bring up Ian Kelly.

and Ian's going to talk about the Windows side of things. Ian? Thanks. So how many people here before we start are actually current or former Windows administrators? Okay, good. So as Schoun said, I'm a systems engineer with Apple Canada. I cover the whole of Ontario up there. And in a previous life, I was a Microsoft guy. I spent my entire life doing NT to 2000, 2003 migrations, exchange migrations, probably more migrations than I can actually care to remember. And now I'm a system engineer at Apple. So it's a transition that can be made and can be made very successfully.

So what's the profile that we're looking at for the Windows administrator? Typically, you're looking at someone who is probably overworked and probably spends most of their time doing maintenance and or recovery rather than looking at ways to push the boundary, look at new technologies and look at ways of making the working environment for users better and more efficient.

A lot of time will be spent with things like making sure that antivirus is up to date, pushing out hot fixes and a lot of these will be happening out of hours typically. So you'll be doing your nine to five stuff and then working evenings and weekends to do stuff on the servers when you can actually have some downtime.

and then there's Vista. So what's the typical environment that the Windows IT admin is working in? We're looking at, obviously, nowadays, a large, complex Active Directory environment where things like group policies are pushed down to users, the desktop is managed, and applications that can or can't be launched and printers are set up and all that kind of stuff as well.

There are some probably very extensive security policies and guidelines about what you can do and can't do on the Internet, what you can do with email and what you can't do with email. And typically, you don't have much of a life. And certainly, for my part, towards the end of my career as a Microsoft guy, there was a lot of Mac envy, seeing the way that things could be done and seeing that maybe the grass was greener somewhere else.

So what are the kind of questions that IT management ask or obstacles they might raise and put in your path when you're looking at this kind of transition? Well, firstly, it's always kind of a financial human resources thing. Well, we can't afford to hire any more staff and you can't find these Mac guys.

Where do you find a Mac guy and how do they train them? There's no training for this. It's kind of a dark art thing. And certainly we can't afford to double our resources and have a whole bunch of Windows guys and a whole bunch of Mac guys at the same time.

So what are the important things to know? Well, as I said earlier, the skills are transferable. I spent seven or eight years as a Windows sysadmin and I made that transition to understanding how the Mac works pretty easily. I mean, the skills that you're understanding, the foundations, things like networking, are all completely the same on the Mac. So once the foundations are solid, the transition is quite easy.

I know a number of great Mac sysadmins who used to be Windows sysadmins. Especially anyone that's managing Unix right now, and particularly Solaris, they make fantastic Mac guys. And I have a customer of mine back in Toronto. He has been using Solaris for about 20 years. And I spent a day with him to show him just the little intricacies of how the Mac is slightly different to Solaris. And he's never bothered me with another question since.

To highlight this, I'm going to talk a little bit about a company based in Toronto called Core Feature Animation. They're an animation company and about two years ago they did an animated movie with Disney called The Wild. And they had a decision from the start that all of the 3D animation was going to happen on Linux machines, but everything else was going to be Mac. And it was the same kind of deal that Schoun spoke about earlier that basically the head of the company was a Mac guy and he loved Apple products and said we're going to be using them wherever it makes sense.

So they had around, it was a two to one ratio. They had 400 Linux machines for all of their 3D and everything else, all of the Final Cut editing, all of the shape compositing and all of the systems administration. By that I mean like the production scheduling and all that kind of stuff was handled on Macs.

And their headcount was basically one senior full-time admin for the Macs with a half-time junior and five senior Linux assistants. So they had around, it was a two to one ratio. They had 400 Linux machines for all of their 3D and everything else, all of the Final Cut editing, all of the shape compositing and all of the systems administration. admins and six full-time juniors. So really we're looking at a ratio of 2:1 on the machines with a ratio of around 11:1, or 11:1.5 on the actual overhead for managing them.

Talk about strategies. Now we're going to delve into some kind of finer-grain strategies, and I'm going to hand back to Schoun to talk about the first of those. Thank you, Ian. All right, so the strategy that we have, we have five reality distortion fields that are sometimes considered pain points. They're not really, and that's what we want to do. We want to dispel these myths. We want to give you strategies and offer you support techniques for this. First off, we have networking. Integration, Management, Deployment and Security.

Okay, so let's talk about networking first. The myth, our network is fine. We run dynamic DNS, file transfers are fast, we don't have any problem. Besides, the Macs need AppleTalk, I still hear this. Today, the Macs need AppleTalk, it's chatty. We use Cisco's VPN. What's Bonjour? How does that fit within my organization? Can I control it? I don't understand it. And maybe the Macs don't really network all that well. So let's talk about DNS.

Dynamic DNS, it's great, it's okay, works well. How many people run Dynamic DNS in their organizations now? Okay, how many people run Static DNS? Okay, you're probably a little happier. It's harder to manage, takes a little more skill, but Overall, it's a little bit better. With a Mac, straight out of the box, DHCP is fine.

You want to have DNS in order, especially if you're going to be running Mac OS X server. For example, if you're going to be using static addresses, you'll need pointer records, you'll need the reverse records. Dynamic DNS may not always set these up, you may have to go in and put them in there. File sizes.

A while ago, a few years ago, I went to a large company in Islip, New York. They had a NOC, Network Operations Center, about the size of a football field underground. It really, Star Trek-like Network Operations Center. They had a graphic department, they had a design department. And what happened was that the department was complaining file transfers were slow. And they had, at that time, a state-of-the-art server sitting down on the NOC. Everything was great.

But they had one switch for the graphics department. So you had about 24, 25 Macs that were all being piped through there. All we did was ask them to look at the average file transfer size. The Macs were 250, 300 megabyte Photoshop files, these really large files that were being transferred back and forth daily.

And the IT staff just didn't have any idea because all the other files and everything else were relatively small. And just like most organizations, those PowerPoint presentations were attached as email. There was no limit. Hey, let's send a 15 megabyte attachment to the person in the cubicle next door. Why? Because we can. So, When we showed them that the Macs generally, if they're in a design department, they use larger files.

They all had a direct line down to the server. Problem solved. It's also an excellent strategy for putting it on XServe. AppleTalk. Macs can do AppleTalk for discovery. It's been deprecated, yes. They can't talk AppleTalk specifically, but they can do it for discovery. And here's a little screenshot showing that you can actually check it and turn it on. And then we have the Apple filing protocol, which runs over port 548, all right? Windows servers, they just use AFP 2 old and busted. It's just services for Macintosh. Doesn't work anymore with the new Macs. You're gonna have problems with it.

It's AFP 3.new hotness, right? So there are a couple things that we can do if you wanna do file transfers this way. First off, you can turn to SMB. Mac OS X servers can be an SMB server. Macs can connect to SMBs. You can, if you need to, you can transfer your files over SMB. It's not a problem. There's no client access licenses.

You may have some file name excitement, right? If you've had Mac users that have been using Macs since the 1800s, chances are they probably put forward slashes for dates in the file names. We know that Windows can't do that. So sometimes you have to retrain the Mac users, don't do this anymore if you're going to be transferring these up to Windows machines, here are the illegal characters you can't use and so on and so forth.

Also, there's a product called ExtremeZIP from GroupLogic. It runs AFP on a Windows server. They do file and print services, they do clustered services. So if you can't get a Mac OS X server in your environment and you can't run file services in your environment, you can purchase ExtremeZIP and you can run AFP on your Windows box. And this is an excellent solution in certain cases where the IT staff just said, "Okay, fine, we'll put Mac OS X clients in here, but we are not going to put a Mac OS X server in here.

We're just not going to do it." With respect to overall networking on Mac OS X, networking is handled in the GUI, the Network Preference Pane. There is a command line tool called Network Setup. You can script it just like you can do any other command line tool and you can do everything from setting up a new interface to changing DNS and search domains and everything else.

As you'll learn later on this week, especially if you do a little digging and you learn about launch D, you can actually set up a launch D item to watch for certain changes. For example, let's say you have a launch D item that watches for maybe a DNS failure.

If it sees that a DNS server has gone down, it can trigger a shell script that runs network setup to actually redirect it to a second DNS or a third DNS. If a user goes home and it detects a different IP range, you can have it actually do automatic network changes for the user. Network setup is an excellent command line tool and I urge you to take a look at it.

We also have a plethora of troubleshooting utilities from network utility to ping to NS lookup to dig and all the rest of the command line stuff. Really, really good tool. Macs do run wireless, 802.11b, 802.x and Leap and TTLS and all the really good, neat stuff that we need for security. And Macs run VPN. So I want to tell you another story about another company in California.

They ran a proprietary VPN service and they paid client access licenses for all their clients. And life was okay, but they still had to pay this. They looked at Mac OS X server's VPN server. It can work with Windows users authenticating against the VPN server, but there's no client access licenses.

And in Leopard, you can do VPN load balancing. So I can have six VPN servers and I have 5,000 users. They're not all going to slam the same server. It'll do round robin load balancing. I can also purchase RSA or CryptoCard. They're both supported by Mac OS X right in the GUI. So if I need token-based authentication. This company basically changed over from using a third-party client access licensed VPN server to using a Mac OS X server as a VPN server. and there are no client access licenses. They realize their savings immediately.

Bonjour. Bonjour is based on zero-conf. It does four things. Apple has it doing three of them. First, automatic discovery of local resources. I have a printer, I have something else, I plug it in, boom, it shows up. Automatic Address Assignment. I get a 169.254 if I don't automatically get an IP address. All Macs have 169.254 in their routing table, even if they have an IP address.

In other words, I can have two Macs on the same subnet. One of the Macs could have a 172.16 address. Another Mac could have a 24-dot something IP address, totally not in the same subnet, on the same network, and they can transfer files. Why? Because the 169.254 route is in the routing table. It's hard coded in there. This is a tremendous advantage.

Secondly, automatic name resolution. So in other words, we can put a name in, just like Microsoft wins and NetBias. So we can do automatic name resolution. Behind the scenes, all the networking is handled by configd, that's the daemon that handles all the networking in Mac OS X. You can have multiple active interfaces by default.

I can have wireless active, I can have Ethernet active at the same time, can have two DHCP addresses at the same time, but I can have one static and one DHCP address. And the interfaces can be reprioritized without you losing connectivity. For example, if you have a VPN interface and you want all your traffic to go over VPN, you can simply drag that interface up to the top. It'll remain inactive as soon as you connect to VPN.

It'll move itself to the top and all the traffic will be pushed over the VPN connection. So what's the strategy with networking? We want to showcase the Macs networking extensibility. It is extremely extensible, extremely powerful, and very, very efficient. We want to provide solutions instead of workarounds. And if you're talking to the network IT staff, you want to be extremely concise about your topics.

So if you're a Mac person, if you're the Mac island, these are some excellent strategies for you to get your Macs onto the network. If you're the Windows IT administrator, You may need extreme ZIP. If you're not going to let a Mac OS X server do AFP on your site, look at extreme ZIP as a solution.

If you're running SMB and you don't have any problem, there's no real changes that you need. You don't really need to change your network. You do need to look at file transfer speeds. And It may force you to clean up your DNS, which is a good thing. At this time, I'd like to bring Ian Kelly back up to speak about integration.

Five years at Apple and I'm still talking about Windows. Yeah. Okay, so there's a lot of myths out there around how Macs work with Active Directory in a large environment. And there's also a lot of issues around Macs connecting to Exchange servers. And we're going to talk a lot about that. We've got a demo as well in this section to show you.

So typically when we go in and we speak to large enterprises, they're like, well, we're running Active Directory and we're always going to be running Active Directory and that's not going to change. And typically one of the first things they say is, and we're not changing Active Directory just to accommodate these 20 Macs down in that building. That ain't gonna happen.

And then we begin to talk to them and show how the Macs can integrate with Active Directory. And the Macs have integrated with Active Directory since the days of Panther and 10.3. And even before that, they could integrate with Active Directory, but there was no actual specific Active Directory plugin.

So what does the Active Directory plugin do? Well, it sits inside an application called Directory Access or Directory Utility, depending on whether you're running Tiger or Leopard. And there's a command line version of that GUI application as well called dsconfig-ad, which allows you to script everything that you can do in the GUI and actually push that out to multiple Macs at once so they can all be configured to bind into Active Directory.

Let's take a look at the plugin first in a little more detail. What we've got here is the first screen that you will see and basically you put in the domain that you want to connect into. It figures out what the forest is automatically from DNS and then you specify the actual computer record that you're going to use to bind into Active Directory with and that gets created in the computer's container.

We can specify a number of different options here at this screen as well. So working out what the home directory path is gonna be, if you're gonna be using SMB to do that, and things like the user shell, if you're gonna allow users terminal access and things like that.

On to the next thing, we can do specific mappings of Active Directory attributes into the Macs as well because we may not have those attributes. And so you can either do static maps here and there's also a place for dynamic maps as well. On the administration side, we can specifically state which domain we want to bind into, which servers we want to use. And we can also specify which Active Directory groups we want to allow to be admins on the Mac.

So if you have a specific Active Directory group that does desktop support or desktop management, you can add those Active Directory groups in here. And automatically when that user logs in, a part of that group, they will have full admin access on that local Mac. There's also a checkbox in there to allow authentication to any domain within the forest as well. So if you've got trust between domains, you can take advantage of that as well there.

What we're doing here is specifying a username with a password obviously that has privileges to create computer records in the Active Directory. And you can create a specific account for that or a specific group of users that are allowed to create computer accounts and use any of those records here.

Two little check boxes to allow you to specify the settings you're about to be used to be automatically put into the Mac. So for things like authentication, it'll automatically search the Active Directory that you've just bound into. And it'll also use that for contacts as well so that when you're doing lookups in address book, it'll automatically pull from Active Directory.

So what does that look like on the command line? Well, it's dsconfig-ad and we're using exactly the same example as you saw in the GUI here. So we're specifying the account is going to be Macbook, the username is winadmin, it's going into the computer's container in the Mac's OU for the domain virusland.org.

Under Leopard, we introduced some specific new options in DS Config AD that was specifically tied around some changes that Microsoft made in Windows Server 2003 around the way that security is handled. Beforehand in Windows 2000 Server, these were not specified security policies. In 2003, they became enabled by default. And so we can now do packet signing and packet encryption. These are both enabled by default, so really you only need to go in and worry about these if you're going to disable them or specify they have to be required as part of the bind.

We can also specify the namespace that we want to connect into. So if you have multiple domains within a single forest and you have the same username in two different domains, then we can specify which actual forest and domain we're connecting to with this user record so we actually log in as the right user.

and there's also password intervals. So if you wanna cycle the machine accounts, which Windows does with Windows machines by default, you can also specify this, synchronize the number of days on the cycle so that they're all tied up. Basically what I'm trying to say here is, is there's no reason why the Macs binding into Active Directory should be treated any differently to the Windows machines binding into Active Directory.

If you need anything more, right now there's one other option for you. So if you're using extensively DFS SharePoints, right now if you want to take advantage of those, you'll need to use a product called AdmitMac from Thursby Software, and they handle connection to DFS SharePoints as well. While we're on the whole directory services thing, binding into any other directory system, if it's any open LDAP derivative, there'll be no problem. And things like e-directory work just fine too.

Talk a little bit about Kerberos. Still to this day, I've been into Windows environments and spoken to Windows system administrators who say, "We don't run Kerberos. We have Active Directory." Sorry to point it out to you, but all of the cool features that you get with Windows machines when you bind to Active Directory and you can log into any SharePoint without supplying another username and password, that's Kerberos.

So the Macs now under Leopard run Kerberos, they run Kerberos on the client machines and obviously on Mac OS X server we run Kerberos as well. So open directory is Kerberos, it's open LDAP and it's a password server. Basically exactly the same as Active Directory. So the Macs can work well with any kind of Kerberos.

MIT Kerberos is obviously the default that we're using and Active Directory, Open Directory Kerberos works just fine as well. So anywhere where you want single sign-on, you want a user to be able to log in and then access SharePoints on servers across the network without supplying another username and password. Once you've bound in with the Active Directory plugin, it creates the Kerberos records for you and single sign-on is handled from there on.

Talk a little bit about Exchange Server. A lot of Exchange sysadmins work on the assumption that everyone connects via MAPI. Well, MAPI is Microsoft's messaging application programming interface and is specifically designed for connection into Exchange Server from Microsoft Outlook. And as long as your Windows environment is solely a Windows environment, it works really well.

Hard to argue with that. But as soon as you start looking at clients on other platforms wanting to connect to those Exchange Servers, the whole MAPI thing falls down because it's not available for any other platform other than Windows. Even Microsoft's Exchange client, if you like, as part of Microsoft Office on the Mac, doesn't use Mappy. It's not available on the Mac. So Microsoft Entourage uses WebDAV, LDAP, SMTP, IMAP, all the standard open protocols.

Having said that, Exchange 2007 now does not ship with MAPI included. It's a free download if you want to add that MAPI functionality back into Exchange server, but it looks like Microsoft are beginning to move away from MAPI as well. On the Exchange support side of things, outside of Microsoft Entourage right now, we don't have a lot, but as Bertrand mentioned yesterday, Snow Leopard does have support for Exchange connection, and I'd like to invite Brendan Langoulant up to talk to you a little bit about that now.

Good morning. Switch to the demo machine. I'm the engineering manager, I'm responsible for Exchange on the desktop. Today I'm going to show you a little bit of a demo of what actually is on the seed CD plus a little bit more. The way that typical users will get to exchange in environments is either to use entourage or to use our.

There we go. So what you see here is a representation of what's on the Exchange server as we speak. So what we've now got is, if I show you Address Book, this is a typical default setup. There's nothing in Address Book yet, so it's quite empty. The same goes for iCal. And then what we've got is a way to set up an account. So again, I'm launching mail at saying you need to set up before you can do anything.

And you'll notice much like we have for Gmail and other things, we have profiles. And so this profile is for that particular Exchange server. We support Exchange Server 2007. And you'll notice that we actually automatically will set up both Address Book and iCal for you. So now we've connected to the Exchange server. The Exchange server is running at Apple at the moment. And we've downloaded the same mail. So if I show you, there's the mail. They're my contacts. There's my mail. If I cycle through these.

Likewise, for Address Book, you can now see that the Address Book's been fully populated with all of my Exchange contacts, making it a lot easier to actually migrate into an Exchange environment. We can do global address list lookups. And it will return results as you would expect.

And then I guess finally, if I show you iCal. And so again, iCal, it's fully integrated. We've now got an Exchange account which it's reading using EWS, which is not to be confused with Hour. It's a different web service. And again, all the things you would expect of typical iCal integration. So I can move an event.

I'm clearly not going to make that 8 o'clock meeting today. If I go back to calendaring, and you can see the event's been updated. So hopefully, we're really going to make a lot of people's lives a lot easier. We think that we're going to make IT admin's lives a lot easier. And we're really going to make a lot of users that are inside Exchange-dominated environments a lot easier. So thank you.

That was pretty cool. I hadn't seen it until then, so first time for me too. Just to round off this slide, obviously we announced back in February the whole iPhone SDK program and obviously the licensing of ActiveSync allows us to do much the same kind of cool stuff that Brendan just shown, but using ActiveSync onto the phone to get pushed email, calendars and contacts from an exchange server down to the iPhone.

As a Canadian, I'd like to say that finally we now have, well, in four weeks we'll have the phone in Canada too. Not that I've been able to use any of this cool stuff, but now we will be able to. The other cool thing about this is obviously remote wipe as well. If the phone is stolen, the admin sat back in the office can remotely wipe all of the sensitive company information off that phone.

One last thing to talk about on the side of Windows and integrating with Windows is maybe the need to still run Windows once you've moved to the Mac. And there may be typically a single application, a custom application that was written that doesn't work on the Mac. The resources aren't there to port it to the Mac yet. So what do we do? Well, there are really three options, one of which may or may not work. So the first would be Boot Camp, obviously, included with Leopard.

And if an environment requires maybe a significant amount of time spent in Windows, that Boot Camp would be an option. Obviously, you'd have to boot in between different OSs to switch back and forth, which if you're flitting between different applications might not be a workable solution. On the virtualization side of things, there are two main solutions out there. There's Parallels Desktop from Parallels. I don't know how long went into the naming of that product. And Fusion from VMware. And both of these products allow you to run. a Windows operating system virtualized under OS X.

and they both do it in a really nice way so that it's pretty much seamless. You don't have to see the start bar and the pretty rolling fields and blue sky desktop backgrounds. You can basically have the applications fully integrated with the Mac desktop. So they appear in the doc. They appear in the recently used applications list. And so really all you see is that Windows application. You don't need any of the other background to it.

Another option might be to use a product called Crossover. And what Crossover allows you to do is just run a Windows application inside OS X. It doesn't work for all applications. It doesn't work for Microsoft Outlook, for example. But if there's one application, you just need to run that XE file to do something. Crossover may be a solution so you're not running a whole virtualized OS as well.

So our strategy here is really to show how well the Macs integrate with Active Directory, talk about the Active Directory plugin and the functionality that gives you to tie in. Look at the options and after yesterday, we got a whole bunch more options on ways of connecting to Exchange Server. and then where our options are around virtualizing Windows if there's those lingering applications that can't be rewritten or don't have an equivalent on the Mac.

So really there are not many changes required in terms of integrating with Active Directory. You're already going to have accounts that have the rights that the Active Directory plugin needs. Everything can be scripted so you don't need to go around and touch every single machine. You can just create it once and push it out to every machine. Kerberos is built in, single sign-on will work and you've got options for virtualizing. With that, I'd like to hand back to Schoun. He's going to talk a little bit about how Macs might be managed in the environment. Thank you, Ian.

All right. So let's talk about management for a moment. The myth is the Macs can't be managed. It's anarchy. Everybody has to be an administrator. We have no group policies in place. Updates are somewhat hard to manage and users download updates before testing them and oh no. So, First off, with administrators.

Mac users don't have to run as local administrators, right? If you do, you can create neutered administrators in a couple different ways. One of the easiest is to edit the Etsy sudoers file and take out the admin group and only put in the users that you want to run the sudo command. So in that case, they really can't get in there to run any commands as super user because you've edited the file. You can further edit the Etsy authorization file to change rights and rules so that only certain users have access to certain security policies.

A third option that you can do is actually put a second data store inside the local machine. If you do that, you can actually have administrators who don't show up in the system preferences who may have a home folder hidden somewhere inside private. And that's a really good way to have a hidden admin in there that's not really part of the original local directory data store or any connected data store like Active Directory or Open Directory.

Second, group policies. The Macs can be managed. Apple calls them managed preferences. Windows users call them group policies. It doesn't matter. It's account-based. We can do group policies based on user. We can do group policies based on group. We can do group policies based on computers. Or we can do group policies based on computer group.

And we can be extremely granular in the policy management that we do. And there are some excellent sessions. Again, we're going to show them to you at the end of today, but there are some excellent sessions this week that I really urge you to go to, especially centered around policy management.

We also have integrated management. In other words, we can have a Mac OS X server and we can have an Active Directory server. And this is also known maybe as the magic triangle. And basically what happens is that we have a Mac OS X server, we bind it to Active Directory, we create a group, we take all the users from Active Directory and we nest them inside of the Open Directory group.

We then do group policy management on the Open Directory group, but we don't touch the Active Directory users. The Active Directory schema has not been modified. We haven't had to make any changes. We just have a Mac OS X server in the middle doing all of our policy management for us.

So how do we update the Mac? Well, we probably don't want to let users update their own machines. Windows administrators certainly don't do this with Windows. They have a centralized server that they use for updating. And we want to thoroughly test these updates beforehand. And how do we track what updates have actually been applied? Well, there are a variety of ways that we can push out software updates.

Apple has a software update service that we're going to be talking about in just a couple slides. We can use Apple Remote Desktop to actually push out packages. And there are a plethora of third-party tools, Casper, LandRev, FileWave, Puppet, RadMine. Some of these are open source tools, some of these are pay-for tools, and this by no means is the only list. There are others.

So here's a screenshot of Apple's software update service and if you take a look at the screenshot, this is a Mac OS X server. It was connected to the internet. It went out to the internet and it downloaded every conceivable possible software update known to man over the past X number of days. It stores them on the server.

Then all we do is tell our managed Macs when they run software update to look at our server. This is great for education where you may have a fractional T1 line or a small connection to the internet and Apple releases an update on iLife or iWork and you have 200 Macs all going out to get the exact same update. Why not put a Mac West End server in the mix, have it hosted and have all that file traffic done locally, not saturating your internet line? Oh, and by the way, there's no client access fees for this.

You just buy the server and hook it up. Again, the scenario, if we visualize the scenario, we have the cloud, we have Apple's bank of software update servers, and we have our lone Apple software update server. It connects, goes out to the internet, and all of our Macs then receive the updates from our lone server.

So what's the strategy here with management? Use proper acronyms and synonyms. If you're trying to correlate group policies and very granular group policies on Windows, know the names on the Mac side. Don't get lost there. Second, create a matrix of supported management options. In other words, when users open up Safari, I don't want them to be able to do this and this and this and this. When users open up System Preferences, I don't want them to be able to click on the Network Preference pane at all. I just don't want them to be able to click on it.

OK, well, do you want that user-based? Do you want that computer-based? Do you want that based on a group? How do you want to manage that? So create a nice matrix. Decide which management settings that you want. Apple uses MCX, Machine Control XML language, to store these policies. And acceptance for the Macs in the environment often hinges on control. There is the myth that the Macs can't be controlled, that they run wild. And that's not true. They can be managed with a high level of granularity. Support. Set those policies. policies.

Second, make sure your users don't run as administrators. I know you don't do this in the Windows world. and third, the Mac OS X software updates can be handled easily. Again, no client access licenses. Buy Mac OS X server, get a next serve, connect it up to the internet, start it on a Friday night, it'll go out to Apple's server, suck down all 500 gigabytes of updates, not that much, but it'll pull them down and then you can decide which ones you want to enable and the users just get them when they run software update.

So I'm going to move on to deployment because management and deployment sort of go hand in hand. The myth for deployment? I must install stuff locally. I must walk around with my Microsoft DVD and install Office on all these machines. There's no ghost for Mac. Semantic doesn't have ghost for the Mac, right? And so when the Macs come in, sometimes the administrators look like Tweek from South Park. "Ah! A Mac!" So there's no ghost. What am I going to do? There's little understanding of imaging in Mac OS X. And maybe the Windows administrators know FireWire.

So let's talk about image creation. We tie the images to various hardware configurations for our Macs. Maybe we have one for portables, maybe we have one for desktops, maybe if Apple releases a new version with some specific hardware, we want to take a look at that one. And we test and test and retest. We launch all apps.

Not that you would ever do this, but a great testing scenario to your colleague at work. There's a command line tool that Apple has called Open. So if you open up the command line and you SSH into a computer that you're testing, and you type CDE space forward slash application, so you CDE in the applications folder, and then type open space star dot star and you watch the doc on that computer.

You'll get every app inside the applications folder and inside the utilities folder all just bouncing and going on at once. Number one, it's kind of fun to watch. Number two, it really puts a load on the system. That image that you created, you put an incredible load on that system.

Now while it's fun to do, you can still look at the logs a little bit later. You can look for certain applications that may have crashed, take a look at the response time, at the CPU cycles. It's a fun little command line tool, but it's really worthwhile when you're testing and you're working on images. Second, once we have our images created, how do we deploy them? Again, there's no ghost.

It's okay. I have a school district, bought 4,000 Macs, one-to-one initiative, some laptops, some desktops. They all came with Leopard. They spent two weeks testing the image, working on the image, They push it out to all the machines. There's no client access license. There's no license fee to push it out. The Macs already came with Leopard. They have legal license to use that copy of Leopard. All they're doing is re-imaging it and pushing it out. And it's free.

How can we push it out? We can use Netboot, Netinstall, Netrestore. Netboot allows us to boot Macs over a network. Netinstall allows us to actually install over a network. And Netrestore is a block file transfer. There are third-party tools that I can use. We'll also talk about packages here in a minute. The other thing that I want to focus on is something called multicast ASR.

I have a Mac OS X server and it's set up on a private network and I have 200 Macs and they all need the same image. I can have that Netboot server sitting there, all the Macs boot up off a tiny little image, and then I could have a 10 gigabyte image being pushed out, not over multicast, or not over unicast, but multicast. I can decide which method I want to use, so I can be incredibly efficient.

and if I use Multicast, that means all the machines don't have to be started at once, they just start getting the bits. If they missed them, they get retransmitted over and over. We could also use a third-party tool called Deploy Studio. We could use an open source tool called Puppet. RadMine does this. RadMine also will do rollback, so if I have a problem with something, I can go back to a previous version. These are open source free tools. There's no client access licenses.

Now what about packages? Apple changed the way packages work in 10.5 and it's really, really cool. For example, I could have Apple Remote Desktop in my organization and I need to install a security update for all the Macs. Maybe I don't have a software update service, maybe I only want to install them on certain machines to test.

I can download that one package from Apple and I can use ARD to send it out. Or I can set up a task server to do it over the weekend. Even better, if I don't wanna do that, if I have a Mac OS X server, I can set up net install and I can tell all the users, tomorrow morning when you come in, after you hear the chime, just hold down the N key, the letter N, just hold it down and go get a cup of coffee. It's not going to do a net install, but it will actually deploy the package that I created. And if necessary, reboot the system automatically. There's no fees for this. You bought the server.

So net install is a great way to deploy packages. And if you're a shell scripter and you have scripts that you need to do cleanup or something else, you can have what are called payload-free packages. These are packages that don't really have an item to deploy, but they run scripts for you. That's not too hard for me to go tell users, hold down the N key. You got five minutes, go get a cup of coffee. And we can use SSH to also do this. So what's our strategy? Mac deployment is unbelievably extremely efficient.

The support involves the creation of the image, the testing of the image, the deployment of the image, and as we saw in the previous section, the management of the image. So you're a Windows IT admin, how do you support it? You automate your image deployment. You pick one of the tools that we talked about. Play with it. Try it out.

There are other tools out there that you can use. Do your remote update planning carefully. Are you going to use ARD with a task server? Are you going to use net install with packages? We can build our own packages too. For example, I have an iMac and I've installed Microsoft Office on it. And I moved a few things around and that's how I want it to look for all the computers. But I already created my image. I took two weeks to create my image. Now am I going to have to create another image? No.

Because before I installed Microsoft Office, I ran Package Maker, Apple's free package creation tool, and it took a snapshot. of my hard drive. And then I installed Microsoft Office and I did a few things. and it took another snapshot and it created a package based on the differences and it collected all the files that had changed.

And then I can push that out. It's an excellent way to be able to do this. At this time, I'm going to turn it over to Ian Kelly again, and we're going to talk about the last reality distortion field, and that is security. Oh, and this is a big one.

So, yeah, there's a, as Schoun said, there's this overwhelming thing that Macs just kind of like run wild. I was actually speaking to Josh earlier and him and Joel go out and it used to be the cockroach thing that the Macs were kind of there lurking in the corners of the building and if anyone came over from IT and turned the lights on, they'd go scurrying away into the corner. But now they're kind of staying there in the light and staring right back at you.

So, a lot of places are beginning to ask, well, we're getting hit with viruses all the time and what do we do about the Macs? There's no antivirus for them. How do we control them? What do we do? So we're going to look at what the antivirus options are for the Mac.

What about malware, spyware, Trojans, those kinds of things? And then what about actually unauthorized access to the Mac and theft and actually securing the machines themselves? So first of all, I want to ask anyone, have they ever received any kind of compensation from their antivirus vendor for downtime or lost productivity as a result of viruses that they're supposed to be protecting against? Hands up.

So while there are very, very few viruses for the Mac right now, there have been a couple that are like proof of concept. There really are none in the wild. And Macs aren't affected by Windows viruses. They will quite happily pass that virus along. So if it's attached to, say, a Word document or an Excel document in an email and the Mac gets that email, it's not aware there's a virus in there, it'll pass it on.

That doesn't look good on the company having sent a virus out, even though the Mac wasn't even aware maybe that there was a virus in that message. So it's important to look at antivirus options for the Mac and realize that while the risk is low, it's important as just being a good net citizen that you should be running antivirus solutions on the Mac.

How do they work into the workflow? For example, I work a lot with the broadcast industry in Toronto and video editing is not somewhere where you're ever going to use antivirus because trying to do real-time Final Cut Pro work while having an antivirus chew away on the files as you're accessing them, it's not going to work.

So there's a lot of things to be taking into account as to where the Macs work, what kind of environment they're working in and whether antivirus is actually appropriate in those cases. In a lot of cases, it's more appropriate to deploy antivirus at the file server and the mail server and realize that you've got that barrier between those Macs that don't have it, for example.

So what are options out there for antivirus that work in exactly the same way as they do in the Windows world? Well, the first two are Windows primary antivirus solutions. I'm a Sophos user myself and primarily because I'm a Brit and they were founded in the UK. But both Sophos and Symantec have cross-platform antivirus solutions.

So you can manage the Macs from a central location, push out your antivirus updates and your definition files to all Macs at once on a schedule and have it automatically update the same as you can with Symantec. And so there's really no reason why the Macs should be treated any differently from an antivirus point of view. It's the way your Windows machines are treated.

One interesting thing to talk about is ClamAV, which is an open source antivirus solution. It's included on Mac OS X server as part of the antivirus for the mail server. And so it works really well for checking and going and outgoing email, but it can be very easily adapted to scan the file system for file viruses as well. And so that's something that a lot of people might want to look at as a free solution is to deploy ClamAV as their antivirus on a Mac OS X server, for example.

What about data theft? Well, FileVault was built into every Mac, which is encryption on the home directory. So that's one thing. The entire contents of the home directory is encrypted. So the desktop documents, every file the user creates and all of their preferences as well. We can also do things like encrypted disk images. So Disk Utility can create a disk image that you can dump files and folders into, and that can be encrypted at 256-bit AES encryption.

And then for things like data transfers, as Schoun touched on earlier, we've got the VPN built in. And obviously SSL, part of the Unix foundation of OS X, is included on every machine. So for things like SSL connections across networks or across the internet, you can use that as well.

There are also some full disk encryption options out there right now that are coming, seem to be kind of coming to market or very close to market. And so there are options there for those highly secure environments where you want the entire contents of the hard drive encrypted.

Let's talk a little bit about the keychain as well. So the keychain is really a central location for all of your passwords, and you can specify what passwords get stored there and what don't. And that's things like just connections to a file server. You can use it to store usernames and passwords on websites.

You can create secure notes inside the keychain as well. So if there's specific information you just store in there that you want kept secure, but you keep referring to it over and over again, you just need it reminded, you can use that in there. You have multiple keychains. You can push out keychains. the store of your certificate information. and I think they're kind of underused as well because they can be used a lot more effectively for things like pushing out VPN certificates and stuff like that.

So our strategy here is really to understand that the antivirus options for the Mac are really not a whole world of different from those for the Windows machines. We have things like FileVault and encrypted disk images to keep things secure. And basically, the world of security isn't too different as to how it is on the PC.

The Macs are built on a much more secure foundation. And things like spyware and malware are a lot harder to come by just because of the basis. If you're not running as an admin, a user isn't going to be able to install anything without supplying a user-level username and password.

The first time you launch an application, you're going to get a warning saying you downloaded this from this website on this date. Are you sure you want to open it? It's a Microsoft Office document from somewhere.ru that's 26K. Are you really sure you think this is Microsoft Office? I don't think so. So there's a lot more security built into the OS to prevent things like your Trojans and spyware.

Let's talk a little bit about migration, but really the focus here is going to be the case study that I'm talking about next because it illustrates the points in the next slide a lot better than me talking for 10 minutes about this. The key to a successful migration from Windows to the Mac is really based upon these factors. It's important that we get buy-in and buy-in is not just like a CEO or VP level, it's everything all the way down through IT and to the end users.

Any kind of strategy cannot involve data loss. You can't go in and say, well, okay, you've got that system, that's all well and good, but you're going to have to lose all that data or you're going to archive it and we'll just start from scratch on this new system over here. And the whole plan basically has to be adaptable, scalable, realizing that no matter what you think or where you think you're going to be in a year, the likelihood is that you're probably going to be a lot further than that.

And then reliability. There seems to be an overwhelming assumption that Macs, because they can do things more efficiently, that we don't need to do it in the same kind of way. So we're going to deploy Active Directory and we're going to have four domain controllers because we need that redundancy and reliability. But if we're going to move to the Mac, we're going to do Open Directory and we'll throw an old Power Mac G4 in the corner and that can be our server. It's really not the way to go.

Case study I want to use is the Ontario Government Ombudsman. What these guys are is the, they're the guys you go to to complain about the government. So as you can imagine, they're kind of busy. They get a lot of emails and a lot of phone calls and it's basically everything from, you know, the city came out and dug up the street and now got a pothole at the end of my driveway up to, you know, wrongful arrests.

They were a 100% Windows environment, only 120 users, and they had four full-time IT staff to manage those 120 users. And basically what happened is the ombudsman himself came in and said, "I'm a Mac user. I have my nice MacBook Pro 17-inch, and we are moving everything to the Mac.

I don't want to see another Windows machine in this building at the end of this project." As you can imagine, the IT staff were kind of freaked out by this. I mean, literally, I mean, the guys were nervous and worried. They're like, I don't know anything about the Mac, but we don't have a choice.

The guy said we've got to move and it's got to work. So what do they use? Well, they had this custom case management system. That's basically where every phone call and every email gets logged into. So it gets used a lot. It's kind of the most important thing they have, even above email. They use Microsoft Office extensively.

They do have a lot of email. It's not untypical to find users there with excess of 50,000 messages and mailboxes in excess of 10 or 15 gigabytes. There's no quotas. They were using Exchange Server, but they had nothing in place to limit users' access or use of Exchange Server. And they weren't using roaming profiles. So everyone was basically locked to the machine they had on their desktop. They couldn't get up and move anywhere else or use a different machine.

The strategy we used around migrating desktops was that, first of all, we need to get any user data that's on the client machines up to a server. We need to have this in a central location so that when we move these PCs off, we're not gonna end up with lost data. So that was a big job because although users were told to store stuff on the server, there was no real way of ensuring that they did.

The other thing that the company did was put the new iMacs on the desktop alongside the user's PCs way before they could ever use them. So they basically had this Mac sat on the desktop off, not doing a whole lot. And that was a really good strategy. I think they were just doing it to save space because they didn't have a whole lot of room in the IT area.

But the users began to say, like, when do we get to turn these machines on? And so it kind of was driving enthusiasm and anticipation way before things were ready to go. And the other thing they realized was that we can't do training as a kind of one-time thing. A lot of people, when they're doing training, they send all their users off for a day or half a day or whatever. And then that's really it done.

They realized that it would be a lot more effective to do small training sessions over a longer period of time to allow things to sink in and the users to begin to kind of come to grips with everything and then ask more questions at the next session. Thank you.

and the other thing they did was an on-floor walkabout. So when they actually went live, they had two of the trainers basically on the floor at all times, just walking around looking for someone to have a problem. And what that really helped with was that no one ever had to get up the phone and call IT or log something into their help desk and say, hey, this doesn't work.

There was someone basically with them within 30 seconds because typically the solution was maybe a 20 second, oh, you just need to click here or close this and open it this way. And that really, really helped the user's level of satisfaction with the system over the first two to three weeks.

So what they did was they picked key groups of users based on either the amount of usage or the level of knowledge and understanding and targeted key areas first they knew would drive excitement and enthusiasm throughout the rest of the organization. and they locked everything down way too much to start off with. They knew they wanted to lock things down and limit internet access, locations people could run.

And so they really went overboard from the start because it's a lot easier to back off and give someone way more freedom than it is to come down the road three months and say, okay, you can't do that anymore. You're not doing that. That's closed off and that's disappeared from the dock because then people start to get a little bit angry about that.

What we did was we took all of the users out of Active Directory using built-in tools from Windows Server to just dump a list of the users and groups, imported those users and groups into Open Directory. They hadn't been employing any kind of password policy, so every user had the same password that they had five years ago. So we figured it was probably about time for a password change anyway.

And then they chose Curio Mail Server as their new mail server. One of the reasons they did that was the built-in migration tool will suck all of the emails and calendaring information out of Exchange and put it into Curio. So there was absolutely no data loss. All their meetings and appointments came through, the global address list came through, and all their lists came through.

They made the decision to move the case management system off of SQL Server to FileMaker Server and write a custom front end based on a browser interface. We suggested they might just want to write a browser interface to SQL Server, but they were like, nope, we're not having any windows in the building.

So they worked with a local FileMaker developer to basically rewrite their entire case management system for FileMaker being cross-platform. So if they ever need to go, let's say the new ombudsman comes in in five years' time and he says, what's all this stuff? We're kicking it out. They can move FileMaker. FileMaker across. And they wanted that flexibility of not being tied to a specific platform.

So they managed to get rid of the access front end and replace it with a browser-based access. This is roughly what it looked like before. They had basically a mismatch of servers from different vendors, different tape drives and different storage arrays that were individually attached and everything was kind of split out and there was no real management to everything. Some of the storage arrays were completely full and some of them were half empty. and there were a mix of 70 to 50 on the desktop and laptop side things.

That's what it looked like afterwards, a little cleaner. So they moved to basically four XSERVs, one XSERV RAID that stored all of their mail, the case management system, and network home directories. They went to a tape backup using Fiber Channel and LTO4 and went to the 20 or 24-inch iMac and the 15, 17-inch MacBook Pros.

So as I said, they moved to a platform independent case management system. They moved to Microsoft Office 2008 on the Mac. They're using email way more than they ever were before. They're now doing way more with mailing lists as well. And they moved to network home directories, which means if a machine suffers a hardware failure, they just get up and move to another machine or IT can just drop a new machine on their desktop and they just turn it on and go.

They imaged every machine in the building in the space of one and a half days and they now have much greater flexibility than they ever had before. Previously, if a Windows machine died, they basically had to wait for a new machine to be built and put on their desktop. Now they can just go to a spare machine on the desk next to them if the person's on vacation, fire it up, log in and they're good to go.

The whole thing was basically once there was three to four months of planning and anticipation about this and once the decision was made it was basically eight months start to finish. It's handled by a local company called Digital Transitions and one consultant from that company handled the entire project on himself, on his own.

They've gone to one full-time Mac sysadmin, the other three are still there, they're just employed in different areas now. And he was formerly the senior Windows system administrator. He went on the training courses, he picked everything up. And he's actually smiling now. I didn't see him smile a whole lot beforehand.

So that's really good stuff there. And they're actually now even looking at buying another XServe. They're taking things and they just wanna spread out again. And this is way beyond the scope of what they originally thought they wanna do. They now start wanna looking at a whole bunch of other technologies, run their web services off of the Mac as well.

So the strategy really was around planning everything out properly from the start, making sure that communication was with every level of the organization. It's a tempting thing to just work with IT and forget everyone else, but they really wanted to keep everyone in the loop and understand what was going on with the project.

They had these great plans, but we encouraged them to start small. I figured you're moving to Leopard, you need to be very concise about what you want to do, and you need to understand that when you're on the leading edge and going with brand new technology, you need to make sure that all of the other software vendors that you're working with are also going to be up to date. So it's all well and good going to Leopard, but you need to make sure that Kirio are going to have a version of their mouse server that runs on Leopard before you do that.

There's a lot of ownership, so they invited all the key departments in to understand that this is how your new systems are going to work. Let's get your input on how it's going to work, how we're going to develop this, how do you need it to work for you, rather than just IT making those decisions and telling the end users what it was going to be.

Train them before migrating so that users can get to grips with a Mac before they're having to use it on a day-to-day basis and worry about their jobs. They can have a lot more fun on the training sessions. And that's really the key thing is to make sure that everyone is enjoying it because if it's any kind of a chore or hard work, that project isn't going to work.

With that, I'm going to hand back to Schoun to round up. Thank you, Ian. So the end result, don't fear the Macs. Embrace their oneness. Mac OS X, the simplicity, the manageability, and the customization really allow full integration. Strategic planning that's based around the Mac's clear advantages make first-time integration and migration much, much easier.

because the Macs are better. I might be biased. So here are the extra sessions that I really, really recommend that you attend. The portable home directories coming up very, very soon. You'll see the extending and directing or publishing directory services as well. So I would really recommend that you hit some of these sessions and some of these labs.