We do certainly get asked the question a lot, what is Apple doing building servers? And we absolutely passionately believe that you can't deliver a great user experience on the desktop if you don't have a great server backing it up. There are areas where Apple can truly understand how to optimize to meet the needs of Mac users in areas where competitive servers will just never have that same degree of attention to detail or polish or focus. And we really believe the mission at Apple, hopefully you've heard time and time again this week, is to build the best possible personal computer. And in the 21st century and certainly in the Mac OS X era, that requires having an incredibly strong server platform.

So where are we going? Well, Apple Share IP for many, many, many years has been an unbelievably great product for us. It's been the number one server in the education market pretty much forever. It focuses on incredible ease of use with great general purpose services from file, print, web, mail services now with the current Apple Share IP product.

With Mac OS X, we're going to have an incredibly powerful platform. As you saw, hopefully, in the hardware keynote Tuesday morning, Mac OS X, from an infrastructure perspective, is capable of some incredibly great things. We're going to have an incredibly great file system, very modern network environment, and as was hinted in the keynote, an enablement of symmetric multiprocessing. All of these capabilities, when you add it to the wealth of services that Apple Share provides, leads us with an incredibly strong platform that is powerful, robust, scalable, and is easy to administer and manage.

Also add on top of that the innovative new capabilities that Mac OS X server provides. Netbooting, the easiest way to get a network, say a classroom in a lab, set up with almost zero administration. QuickTime streaming. QuickTime is transforming how people communicate over the web. You need a powerful engine, and we've delivered QuickTime streaming with the Mac OS X server product.

And then you take all of that with the context of open source. The fact that the Darwin layer, we ship the source code to the very foundation of the operating system, and it allows and enables certain opportunities to enhance the system, for you to take it in directions that maybe we haven't had the chance to prioritize. And it makes for a much more open and easy to work environment for certainly the developer community. You add all of that together, and you have what we believe, and we're very excited about it, is just an incredible, the best ever server that Apple has ever produced.

So let me just spend a couple minutes talking about some of the history and some of the lineage behind our current servers. And I'll focus on maybe just two key areas, one in K12 and then one very close to Apple. When Mac OS X Server was introduced last March, there's a number of very powerful capabilities, but one that was incredibly exciting, very bleeding edge in terms of a new technology introduction, was NetBoot.

And we consciously picked a number of test sites that we would be able to evaluate and test the technology. One of those was a K12 school district, Hacienda de la Puente. And the benefits of being able to take a server and configure it with a version of the Mac OS operating system that had the right set of extensions, the right set of preferences, the right applications, and literally just walk in with an iMac, connect up a network connection, hold down the N key, and that iMac would boot across the network off of that server. It's a very interesting technology.

and others have been involved in this. Thank you. I think it's important to note that the average service time for a school district is about two and a half days. It really has transformed the way that school district can deliver content. Students are free to roam from machine to machine to machine. Their work environment is always there. From an administration perspective, they are able to keep their network up-to-date with minimal investment.

It's been a highlight in terms of how the future of technology can really change the way that people teach and learn using computers as a tool. We've seen just incredible interest around the world in the NetBoot technology. It's actually expanded well beyond the K-12 market, even though that was our initial primary focus.

Another really amazing capability with Mac OS X Server in terms of its robustness and the WebObjects application server solution for which there are 18 tracks here at the conference this week, is just some of the incredible things you can do in terms of delivering web-based services in concert with all the other technologies that the server provides. A couple interesting little anecdotes about the power of Mac OS X Server in that environment.

The Apple Store is one of the leading e-commerce sites in the web, a pan market, not just the computer technology market. It is incredibly reliable. We basically, on an annualized rate, realize about a billion dollars worth of revenue that is sold through that store, and that is running completely on Mac OS X Server.

It's an incredible service. It's an amazing thing to put the trust of that much revenue in the hands of technology, but we believe incredibly strongly that you have to, these words have been used before, eat your own dog food. We use Mac OS X Server for the store. We use it to deploy a number of the iTools solutions. We're using it for internal networks. And it's been an absolutely amazing technology, and we're investing very, very heavily in it.

So let's walk through the basic architecture. Hopefully this is now in order. This is an old, boring slide, the definitive architecture roadmap of Mac OS X. Where we have the Darwin layer, it's the operating system plumbing, strong graphics architecture, a variety of application programming models, and obviously the user interface.

Well, how does the server fit into this? How do we map the key technologies and the architectures and the layers that a server platform would provide? Well, take that whole Mac OS X picture that you saw previously, and that's the Mac OS X layer at the bottom. bottom of our server services roadmap. The important message is that our server offerings start with the desktop product and then we add to it.

We have a number of services that I'll talk to in a moment, but there's two key bands below and above our individual services, and that's a common directory architecture and a common administration model. From the services perspective, File and Print remains the primary services that a workgroup network expects to be great and work well, especially in a Mac-oriented environment.

A wealth and portfolio of Internet services from Web through Mail and others. Comprehensive network services and network solutions. Desktop Management Services. Desktop management allows a K-12 school administrator to create all of the policies in order to effectively run a lab of student-driven machines. Are they allowed to access CD-ROMs? What preferences should be managed on their behalf? Which preferences are they allowed to manage themselves? And as I mentioned, a comprehensive administration architecture so that we have the ease of use and the simplicity of managing a diverse system. out of server services. So that's a very high level perspective on our approach, our architecture. I'd like to invite on stage Greg Burns. He will talk about the server solutions and the internet, and it's all yours. Thanks, Ken. Hi.

I'm going to talk to you a bit about what we're doing with additional services on top of the Mac OS X operating system. But before we get into that, I want to say one more thing about Mac OS X, the operating system itself. And you've all seen this diagram now, I think, several times. It has Darwin down at the bottom. And hopefully many of you have heard that Darwin is based in part on FreeBSD.

And FreeBSD is not a newcomer to the operating system world, and there's a lot of experience built into FreeBSD running as a server. Has anybody here ever heard of Yahoo? Everybody? You should all be raising your hands. How about Hotmail? Probably heard of that as well, Microsoft's Hotmail. Both of these are networks that run on FreeBSD.

So FreeBSD has a good pedigree as a server operating system, and as part of the core of Mac OS X, it provides a good foundation for providing a server. And as Ken said, we're not a big iron company, but for our customers, there is a strong foundation there for building services.

So in Mac OS X Server, we are providing some additional capabilities on top of the core operating system. The first one is the Directory Services and the Directory Architecture. And the goal here is that we want to have a common directory that underlies all of the services and applications using the network in Mac OS X.

And we do this in two parts: through an API that any application can use, and this allows any service, any application, whether it be on the client or the server, to access network resources. And because we recognize, even though we provide a directory with Mac OS X, we recognize there are other directories in the world, and perhaps you want to access NDS or Kerberos or some other directory. So this API provides for the ability to access other directories.

And in addition to accessing information in directories, you also want to be able to figure out whether or not somebody is authorized to use resources. John Smith may be in a directory, but you also want to know if the client is in fact John Smith and give him authorization to access certain resources. So the directory APIs include a central authentication authority to provide for that. And together with the network information and the central authentication authority, you can manage users centrally in your network.

And so how does it fit together? Well, the key piece here is that green band in the middle, the Directory Access API. This exists both on the Mac OS X desktop and on the server side. And our software, as well as your solutions, can sit on top of this. This is a public API. We have extensive documentation for it.

And it's very easy to use, very easy to get access to any directory service through this. And underneath there, you'll see that there are several plug-ins. There's an open plug-in architecture. And we use that ourselves. This is key. We use it ourselves for accessing NetInfo. So we're eating our own dog food here. And all of the accesses to NetInfo, our directory service, are done through this plug-in architecture. We also provide LDAP, as well. But in addition, if you have a directory, you can plug in there, as well.

The API, as I said, it exists on the desktop as well as the server. It's utilized by all of our services. In our current Mac OS 9 product, Apple Share IP, we have Directory Services in there, but they weren't universally utilized by all of our services, and that's something we wanted to fix for Mac OS X. So now in Mac OS X, all of the services are integrated with the core Directory architecture.

And as you saw, it is extensible. It's a runtime plugin architecture, so you can develop new directory plugins that allow applications to access new directories without having to touch the code or recompile those applications. And we ourselves will be delivering NetInfo and LDAP support as part of the core directory services in the desktop and on the server. On the server side, in addition to the APIs for accessing the directory, we're also providing the NetInfo Directory Service itself. This is Apple's distributed replicated directory service, and this provides the ability to manage users and resources on the network for a Mac OS X Server.

We recognize, again, that there will be clients that don't use NetInfo that want to access this directory, and so we will be providing LDAP server support as well to provide the same data in response to LDAP queries. In addition, we know that if we're using an external directory such as LDAP, for instance, if you want services in Mac OS X to be able to take advantage of this, we have a standard schema that you can enter into the LDAP directory to allow accounts in Mac OS X to log in and to utilize services through this LDAP directory. And so that is all well defined in the API.

So where's the opportunities for you in all this? Well, first and foremost, if you have a directory, if you're a systems developer, or perhaps you're working at a university, you have a proprietary directory, in particular to your site, we want your directory to work with Mac OS X. So develop a plug-in for your directory.

And secondly, if you're developing an application, whether it be a productivity application like email, calendars, et cetera, or a vertical application, if you're doing directory access, you'll want to use the Directory API. And finally, of course, managing directories is a complex activity, and so there is opportunity here as well to provide management utilities for directory services.

There is an additional session tomorrow that you'll want to be aware of if you're interested in learning more about the Directory APIs and developing to them, and that's going to be in this room tomorrow at the same time. And so if you're interested in this, please come back tomorrow and hear more about the Directory API and how to develop plug-ins and how to use the API for your applications.

Okay, so the directory, of course, sits on both the client and the server. Now we're going to talk specifically about some stuff that is part of the server and will be in the server version of the Mac OS X operating system. And I'll tell you a little bit about where we're going from a technology standpoint.

File Services, as Ken mentioned, is a core staple of a server offering. And so with File Services, we want to provide basic, high-performance, reliable services for any client. And in addition, because Sherlock is a core part of Apple's technology, we want to make sure that the indexing support for Sherlock is built into the File Services as well.

So again, how does this fit together? Well, if you look at this at the top, you see a variety of file services that we want to support in Mac OS X Server. And the key here is that these are all shared. A key goal of Mac OS X Server is to bring all these services together and to make the configuration and the privilege management integrated, sitting on top of the Mac OS X operating system and the Mac OS X file system and file system privileges. And of course, all of these services use the Directory Service for user access and authentication.

So as far as the services themselves, of course we have AFP. And with AFP we've introduced some changes to the protocol. So we have a new version, 3.0, that adds some more features for support of Mac OS X, the Mac OS X desktop. In addition, we have SMB support. That's something that is new to the upcoming version of Mac OS X Server.

Our SMB support is based on Samba. I'm sure a lot of you are familiar with that. It is the best third-party implementation of Windows File Support around. It's open source and it's been well tested. And so that's something that we are going to be providing in Mac OS X Server as well.

Mac OS X Server is UNIX, so underneath the hood in Darwin, there is UNIX down there, and so there is NFS in there as well. So that is additional service that will be provided for UNIX clients. And of course, FTP, if you have web browsers you want to download across the internet, FTP of course needs to be there as well.

And one of the shortcomings of the current version of Mac OS X Server that's shipping today is that there are some limitations in the servers on what file systems you can export. So we wanted to remove that. So services like AFP and SMB in the future will be able to work with the various file services that come inside of Mac OS X. So whether it's HFS or UFS, etc., you'll be able to manage both of those and export both of those through the various services.

And of course, as we saw in the picture, all of it is unified. A key part of our overall server offering is to make it very simple to use and unified in terms of the management. The performance is something that we've been working hard at to make sure that it is very fast.

And you've probably seen some of the demos around SMP, and you know we are working hard to make sure that in the future when SMP is available that we'll be able to take advantage of that. And of course, we leverage the reliability of the Mac OS X kernel as well. And in addition, we've put some work into making sure that there are watchdog services and other capabilities to keep the server up and running.

In terms of developer opportunities here, the first thing you should be aware of is that if you're an AFP developer on any platform, you should support AFP 3.0 to provide full support for Mac OS X. Secondly, if you're doing a directory plugin that requires more than just a username and password for authentication, then you'll want to know about custom user access methods that are part of the Apple Share client.

And this allows you to do complex authentication dialogues. Most cases you won't need this, but if you're doing something really fancy, it's something you should be aware of. And finally, there are some extension APIs and the capability to extend some of these services that you might be interested in as well. Print services is the other staple of a server offering.

And the key thing to be aware of about printing on Mac OS X is that there's a whole new print architecture. And so if you're involved in any way in printing or print services, this is something that you're going to want to learn a lot about. And there's a couple sessions about that coming up, and I'll point you to those in a minute.

But another thing as far as printing in Mac OS X Server is that we've layered all of our services on this print architecture. So in the past, in Mac OS 9, we had a completely separate print service, completely separate print architecture that couldn't leverage anything on the server side that had been done on the client side. And of course, that was a shortcoming, and we fixed this.

So now as a developer, if you have a driver for a particular type of printer, it will work on both the server and the desktop. So that's something that is good news, and you should be aware of that. In addition, the printers that we support right now, the printing protocols support PostScript. But if you want to do converters, for instance, that would take you to a raster printer on the back end for the desktop. That will also work on the server.

So printing. So we support clients, both Macintosh, Windows, and Unix. Again, the Windows support comes from Samba, so we get very robust support there. And the support for the queues, of course, right now is any Mac OS X PostScript printer. But again, as a developer, you have the opportunity to put in PostScript to raster converters and have those work on the server as well. And of course, because it's a server, you can manage the queues and manage the print jobs over the network as part of our integrated management utilities.

As far as print opportunities for you as a developer, first and foremost, if you have a solution for publishing that runs on Unix, you should port it to Mac OS X. So if you're doing print services, publishing workflow, reps, what have you, there is an opportunity here. It's very easy to port these services to X, and you should get started. And I know some people already have products running here, but if you don't, it's time to get started.

And the other thing here, which I mentioned, is that drivers for the client side will also work for the server. So it makes it very easy to support additional types of printers on the server side as well as the desktop. And of course, there is also the opportunity to add additional management tools to our server products as well.

Okay, so that covers File and Print. Now another key area of our service offering is Internet Services. And Internet Services, of course, any core piece of any server is web and email services. But we also have two technology areas that are very important to us here at Apple, and that's QuickTime and WebObjects. And you've probably heard a lot about those at the conference here so far.

On the web side, of course we want to have a web service that provides web site hosting, whether it be very simple, something you want to get up and running in minutes, to very sophisticated sites with virtual hosts. A service that has a full-featured web server with high performance. And of course we need it to be integrated with our management solution, and we need it to be able to support application development services like WebObjects or like server-side scripting.

And the way we do this, of course, is with standard Apache. Those of you who are familiar with the current Mac OS X Server know that it includes standard Apache. It is the standard Apache module. In fact, if you took the open source Apache and recompiled it and substituted it in, it would work just fine. So this is fully standard Apache with the dynamic module API. And to that, we've added server-side scripting. It's available through standard Apache modules.

Apache is well used throughout the internet. There's almost 9 million sites using Apache now. It's about 60% of the internet. But even though it's well used, it's not the highest performing server out there. And so we've put a lot of work into increasing the performance. And so that's an area where we're going to continue to work on to have a really high performance product. And in addition, some additional things that are coming in the product that we're looking into are, of course, increasing the capabilities as far as SSL and e-commerce, and also Sherlock indexing for the sites.

As a developer, of course, because it is standard Apache, it's very easy for you to come in and develop Apache modules to enhance the server, to add new capabilities, or to bring modules onto the Mac OS X platform. And of course, the opportunity for management tools exists as well. That's something that's very important in website management. The other area that we're looking at as far as core web services, obviously, is email services.

They're very widely used and very important. And of course, as part of Mac OS X, it needs to include an integrated and very easy to use email server. And of course, it needs to scale as well and be high performance. And because we have a lot of customers that run on sites that have intermittent connections to the internet, we need to be able to support message delivery remotely as well through intermittent connections. And the way we do this, of course, is that we will be providing an integrated mail server that includes SMTP for message delivery and routing, as well as POP and IMAP mailbox services.

Now, this server will work completely by itself independently, but because there are a lot of folks that want to do more advanced scripting of mail delivery and routing, we have the option to work with SendMail for delivery. Or for that matter, any other mail delivery agent can be configured to do the mail routing as well. And of course, like any mail server these days, it includes anti-spam and the message delivery capabilities that we talked about.

Another part of our mail server is that it's integrated with the directory. So whether you're using our own directory or whether you're using LDAP, you can code into the directory where the user's mailbox is located and what machine it's on. And routing can be set up for complex mail installations in that manner.

And finally, we have something that exists today in Apple Share IP which we'll carry forward, and that's our IMAP administration port, which for people wanting to do additional management utilities makes it very easy to go in through IMAP with an administrator account and have full access. So the entire mail store, all the accounts and all the messages for management reporting and what have you.

So in terms of developer opportunities, well, there's two sides here. One is if you have an application, for instance, a server-side application, say web-based email as an example, make sure it runs on 10. The other is if you have a client application, make sure it runs well in markets that are important to Mac customers.

A good example here is the K-12 market where the mail users don't have ownership of a particular machine and need to move from machine to machine to access their mail. On the management side, of course, there are a variety of management tools that can be built, including account management through IMAP, management of routing through SendMail, as well as log management or mail tracking.

So let's move on to two of the services that are core to us here at Apple. First one is QuickTime and QuickTime Streaming Server. Now, QuickTime Streaming Server, hopefully most of you have heard of this, but in case you haven't, it delivers live media or on-demand media through QuickTime movies across the internet to hundreds or thousands of customers.

So you can take an application that's broadcasting live media, say a radio show or a video, live video, and basically have the QuickTime Streaming Server deliver that to hundreds of customers, thousands of customers. Or you can take a QuickTime movie and hint it and put it up on the server, and that movie can be accessed on-demand and streamed to customers.

It's completely standards-based. It runs on the RTSP and RTP IETF protocols, so it is the only fully standards-based streaming solution out there. And in addition to being a server, you can also relay other broadcasts. So basically you can set up-- . a relay of a live broadcast, or you can set up multiple relays to scale up a very large configuration for thousands and thousands of customers.

Each server itself is highly scalable, so whether you want to support a 56k modem or a 288 modem or go to broadband, DSL, or cable, or even to Internet at megabits per second, the server is capable of handling that. And at modem speeds it can handle thousands of connections.

And the other thing it's capable of doing that's important is usually over the Internet most connections are done unicast. You take a connection from the server and you send data to the client, and that's a single connection, a single pipe. So if you have thousands of clients, you have thousands of connections. But the server itself is also capable of handling multicast. So if you're in an area of the Internet that can handle multicast, or if you're on an intranet where it's configured, you have the ability to reach a lot more clients with less network bandwidth.

The server itself also has web administration, something that we've been working on. And of course, if you haven't heard of it, hopefully you'll want to check it out because it's fully open source. Some of our competitors will charge about $50,000 for a product like this, but for us it's free.

And so you can go out and get the server, you can get the source today, check it out. It runs on multiple platforms in addition to Mac OS X Server. And so this is what we think is the most expandable streaming server around. Not only is it open source, you have full access to the source to do whatever you want, but it also has a module API, similar to Apache.

So different developers can come up and add new functions to the server without having to learn the whole source base or without having to get in each other's way. And this is important for you as a developer as an opportunity because it allows you to develop new features to the server. The streaming market is expanding rapidly.

It's a very rapidly growing market. And there's a real opportunity to get in here and add new features. But it allows you to add those new features not only as open source, but also as modules which can be shipped independently of the server. And you can sell those modules as binaries and sell them for money.

So there's an opportunity to go both ways here and certainly a good developer opportunity in building modules for the server. And of course, as with the rest of the service, there's additional options for management tools. Certainly in the streaming area, that's an area where a lot of management is needed. People want to know who's watched what for how long and when. So there's a lot of opportunity for management tools there to help out with QuickTime Streaming Server.

Our WebObjects services you may have heard a lot about if you've been going to some of the sessions, so I'm not going to cover too much here today. But just so you know, WebObjects is our application server that provides database content for web services at the back end of a web server.

It runs on a variety of platforms, including NTE and Solaris, as well as Mac OS X Server. And in addition to providing the application server itself, there's a lot of tools that allow you to develop the services as well as manage them. And there's also objects that are there as well that have been pre-written to help you get going quickly.

And, you know, here's a good picture that shows you sort of an example of how it all fits together. If you look in the upper right-hand corner there, you'll see the web browser basically going through the web server into WebObjects, which brokers access to data, whether the data is in a database or other data source. Or you can use the Java clients that Avi demoed on Monday to go into WebObjects directly to access the same data.

So, you know, the point here is that there's tremendous opportunity. And WebObjects and pretty much any web application you want to build on the server side, you can do it with WebObjects. You know, there's 18 sessions going on. We have one every time, every day. So if you have heard about WebObjects and you're interested, hopefully you've been to some of those sessions. And if you haven't, you should definitely check them out between now and Friday because there is a lot of opportunity here for you as developers.

Lastly, I want to talk just briefly about Network Services. Network Services are another piece of the offering that we have in Mac OS X Server, and that includes some of the lower layer networking capabilities that you use to set up a network and servers themselves. And these are things like DNS, which are used for setting up domain name servers, and of course there, as this is Unix, we're leveraging Bind. And we also have DHCP for address assignment, as well as SLP, which does dynamic name lookup. It's very similar to AppleTalk's dynamic name lookup, but it's a protocol that was designed specifically for TCP by a standards body.

And all of these are available, or will be available, through Mac OS X Server, and of course we have them integrated with the server offering themselves. So that gives you kind of an overview of where we're going with some of the Internet and the file and print services. And so now I want to bring up Bob Murphy. He's going to talk a bit more about our desktop management and the capabilities and technology there.

Okay, thank you, Greg. As you mentioned, my name is Bob Murphy. I manage an engineering group here at Apple that's responsible for Macintosh Manager and Network Assistant, two components of the server program, as well as multiple users, which is a component of Mac OS 9. Today we won't be talking about multiple users, but instead focusing on those pieces of the server product. are in the right direction here. As Greg mentioned, we'll talk about Desktop Management Services today. I'll also touch briefly on the administration piece before turning it back over to Ken for him to close.

So I'd like to thank you for this opportunity to get a chance to tell you about the things that my team and I work on at Apple. And these are some of the key pieces that we're involved with: Macintosh Manager, Network Assistant, and NetBoot. Just to kind of get an idea, how many of you are familiar or have worked with Macintosh Manager? Can I see a show of hands? So that makes me feel good. How about Network Assistant? Oh great, so we've got a lot of experience. And NetBoot, is anybody working with a NetBoot installation? Great. I'm feeling really good about this. Well, hopefully, hopefully it's not all as bad as you, you know, say it to be.

But... For those of you who aren't familiar with Macintosh Manager, just a brief overview. Macintosh Manager is a product that has a server component as well as a client component. It really provides what we like to think of as two key pieces of functionality. We talk about the virtual desktop, the ability to move preferences and bookmarks.

Ken mentioned them some in the success story where we have the ability to move things around to take advantage of people going to different machines. It also provides a piece of what we call resource policy, which restricts access to certain resources as defined by the administrator. For example, whether or not people can go to the chooser, what applications they can launch. So basically, kind of configure the experience that the user has on their desktop machines.

Network Assistant does not require a server, but it is bundled as part of the product because it is a very useful administrative tool. What Network Assistant does is there's an administrative workstation as well as a client component. And again, we can break Network Assistant down into two key pieces. One we like to think of as interaction. It gives you the ability to communicate with the user either through text chatting or through sharing screens or through controlling screens to large numbers of users.

The second piece we like to consider is an administrative maintenance component of the product, which allows the user to configure workstations similar to their own or to their own. So, this is a very useful tool. The third component, NetBoot, is a tool to help make administrators' life easier, basically around the management of the client OS.

What we do is we provide a server-based OS image that then remote clients can boot. So we have administration and management of the OS in one central location. So, we have a server-based OS image that then remote clients can boot. So, we have administration and management of the OS in one central location.

What I'd like to talk about are some of the goals that we have for Macintosh Manager in the future releases. And I think primarily to our efforts is simplification. What we found is there's a great increase in the number of desktop machines without a corresponding increase in administrators to manage and take care of those. So anything that we can do, any work that we can do to simplify that experience and make it easier for administrators to work with, we want to try to accomplish.

Macintosh Manager has been very closed. We had our own proprietary database. We didn't give access to the login screen. We need to work to make it more open and more available for developers to interact with the products. We need to start moving in that direction, and that's a goal of ours.

Does that take care of all the hisses? . Gosh, these are tough. Simplify the user experience. Just as for administrators we'd want to try to simplify it, we also need to simplify it for the users because when we simplify it for the users, we win all around. Prepare for Mac OS X.

Key initiative for all of us. Our server components are Mac OS X. They work on Mac OS X today. What we need to do is start moving our client components to Mac OS X. So we have some ability to provide Macintosh Manager functionality there also. Compatibility. Compatibility is also a big issue for us. We are very large in education. Education keeps a large amount of legacy hardware. Therefore, we have to provide support fairly far back in the client OS.

Greg talked about Directory Services. Well, we're going to take advantage of that. In the past, we had our own set of users and groups. We had our own passwords. All the administrators had to manage. We're now going to take advantage of Directory Services so there's a single user, user and group setting, and password administrator in one central location.

The other piece that we've been asked for consistently is a way to plug into our log-in screen and for authentication. Very popular in that arena has been Kerberos. So by taking advantage of the directory, we're going to be able to take advantage of Kerberos plugins as they're written to provide an alternative method of authentication.

I think I've got more claps than hisses now. Okay. Well, maybe not. Mac OS X User Home Directory. As I talked about preparing for Mac OS X, one of the things that we want to do is share the same storage space so that when a user is working on their 8 or 9 machine and they move to a Mac OS X machine, they still have access to their files. They're stored in the same home directory, which we see as part of moving our transition to Mac OS X.

In addition, we're also going to store application preferences in that home directory. So Carbon applications that are still using the old preference management methods of storing preferences in the preferences folder will get their preferences on Mac OS X machines. So we're starting to move to that direction in terms of the virtual desktop experience. The resource policy is not happening right away. As I mentioned earlier, our server process is on Mac OS X. We're now moving our admin application to Carbon, which will make it available on Mac OS X. And the support will still continue to support back to client 761.

Just a quick overview. Basically, you see in the center is the server. The Directory Services are below us. Mac Manager will still have a server process, as well as we'll work with the AFP server process. The Directory Database, Users and Groups, that'll be stored in one central location.

We will still plan on storing some information in our databases. We weren't able to do a full transition over in the near term. We do want to work on that longer term, so we no longer have this proprietary set of information to Mac Manager. So we'll be moving in that direction. So let's get off Mac Manager for a while.

Hopefully Network Assistant isn't as controversial. Just a few key things about Network Assistant. I think it could really all be summed up as, in the first point, is support for the future, and that means moving to Mac OS X. Again, the simplicity, make it easy to use as it is today, and continue to advance on that to make it easy to use, and again, support compatibility. The key detail, or the key thing that we're working on for the next release is to provide a full featured client for our Mac OS X machines.

So that's really the gist of what we're working on at this point. We will have a Mac OS X admin application, but we're also gonna, even as we move to X, we understand there's still lots of 8 and 9 machines out there, so we want to provide the administrator the ability to manage the machines, no matter whether they're 8, 9, or 10 machines. So that's kind of where we're headed there.

We don't support 761 right now. Yeah, it would. It's hard though. It's really hard for that piece. So that kind of covers those three components, or those two components. Now let's move on to NetBoot. I think NetBoot is really exciting. It's a really cool technology. I'm really excited about what's going to happen going forward.

But basically what it does, it kind of ties to that theme that I think that Ken mentioned, and Greg also, is to simplify. Is to make it easier for administrators to take care of things, because you've got all these client machines, and you're not getting any more administrators to take care of them. So what we do is we provide a single location on a server to manage the OS.

This makes it protected from user modification. They may be able to modify it during the course of their operations, but with a simple reboot, they're back to where they started. So you have a protected OS. Desktop OS has become trivial. And actually, in addition to that, some installation of software becomes trivial. You install it in one place, you restart your clients, you're installed.

So I think this is a real big win for administrators. It is our goal to work with standard, unmodified Mac OSs. Any Mac OS that is released should automatically support netbooting and be installable and usable in your network. And we understand that performance is important also, that it must be comparable to local disk.

So the users don't know that they're working on a netboot machine versus a local boot machine. Some of the details, some of the details that the NetBoot team is working on, they want to make it work in more robust networks. It's going to interact with standard DHCP servers.

This is exciting, especially in the situations where you have different languages. A machine may be used in a multilingual setting. You want to provide the ability to boot in French or German or Spanish or Japanese or any language that you would like. In addition, you could provide a modified OS.

It doesn't need to be language difference. It could be other things installed that you want to make available to the user. Okay, and it's going to be highly scalable. We're moving to make it more scalable. The clients will auto sense which server has the least activity and then it will go NetBoot from that machine.

I guess the key implication we can think of for developers around Netboot is you don't have a persistent OS. As soon as it's rebooted, it's gone. If Mac Manager is involved, you can still manage preferences and some of the system settings, but you have to assume that there is a non-persistent Mac OS. Simple diagram. Again, you see now with the addition of multiple servers, multiple Netboot servers, you can see in the bottom you have different subnets, Net1, Net2. The clients will interact and go ahead and just boot right off whatever server has the most availability.

So we think that that's a real win. We think that's a real opportunity. So I just wanna touch briefly on administration, the final block in our diagram before I turn it over to Ken. From an administration perspective, oops. The goals, I think the goals here again are similar.

It's simplicity, to make it easy to use, to make it easy for the administrator to get in and do the work that they need to do and get out. So simplicity. One of the goals for that is to move to one application, to not have to go look around for a whole bunch of applications.

We want to try to move that to one central place. Remote or local. We understand that everybody's mobile, right? So we need to be able to provide administration anywhere on the internet. That's critical also. And then the final point, very easy to use, just echoes that theme once again.

Some of the details: it will be a client server architecture, the administrative application, and what this provides is the second bullet there, the admin server will update the clients as needed. For example, if the server that you're trying to maintain has a component that you don't have the administrative piece for, it'll automatically provide that for you so you can go maintain that feature. First bullet: it'll be Carbon also, so Mac OS 9 and Mac OS X as well as Aqua. It'll be Aqua interfaced.

We'll support SL and SLP for locating servers as well as being able to administer multiple servers. And then the final piece, what we're trying to focus on is being able to do some limited set of web administration. So with that, I think I've completed the section, and I'd like to turn it back over to Ken to close. Thank you.

So to amplify a couple of points that Bob made in particular, how many people in the audience produce client-side applications that fit into the server environment?

You've heard that there's a variety of opportunities for developers in this server environment with the Mac OS X Server product. Certainly there's a wealth of plug-ins. Directory Service is central. It's essential to the integration, the interoperability of this technology. And we're going to focus on a small set. There's ample opportunity for a variety. A couple are mentioned here.

The whole notion of management and control of the server environment. People need to be able to understand how the technology is being used. From a scalability perspective, maybe you start with a small number of servers. Are you able to actually analyze how the technology is being used so you can most efficiently plan your next year investments in, do you focus on more bandwidth? Or do you need more scalability? There's a lot of scalability for the file server. So there's huge opportunities for producing administration, console utilities, log analysis, how the server has been used from a historical perspective. A variety of services for guaranteeing always-on availability of the server from an auto-restart and remote management perspective. Backup and restore is always an interesting and important opportunity.

The needs of backup scale from very, very large to very small. So there's a lot of scalability for the file server. So there's huge opportunities for producing administration, console utilities, log analysis, how the server has been used from a historical perspective. A variety of services for guaranteeing always-on availability of the server from an auto-restart and remote management perspective. Backup and restore is always an interesting and important opportunity.

The needs of backup scale from very, very large to very small. There's a lot of scalability for the file server. you know, very, very large enterprise grade environments where large customers have investments in a backup technology, all the way down to a much smaller, you know, single user, single administrator, you know, tape driver, peripheral model. So there's a wealth of opportunities in there as well.

On the web and application space, certainly Apache is just an incredible web server technology. The number of plug-ins that turn Apache into an unbelievably powerful platform is open for anybody to entertain and exercise with the Mac OS X server product. And we can't say WebObjects loudly enough more often. This is some of the greatest application server technology that the world has ever seen, and it creates some incredible opportunities for adding value-add application services on top of this very powerful platform.

In terms of additions and add-ons to the server, from a hardware perspective, obviously RAID solutions enables a greater degree of scalability and performance for the disk subsystem. Large storage arrays, et cetera, power management are all examples of how the server product can be enhanced beyond the confines of our desktop hardware design.

And in the creative professional markets, certainly there's incredible opportunities for very sophisticated, higher-end print management and workflow solutions. The print industry is obviously being transformed by the greater flexibilities and efficiencies that the Internet has enabled, and the publishing workflow is one that is ripe for incredible opportunities for adding value to the server product.