Is the transformation of Exchange into .Net going to change the way administrators manage the box, the way developers develop on top of it?
It will be Exchange - that is what everyone needs to understand. We will do everything to make it a comfortable environment for the people who are managing Exchange today. It is not going to be this thing that is going to need a database administrator to deal with it. This is an application. We can set up the database tuned for that application. So from the administrator's perspective, it will be a very similar experience.
How do I decide if I wait for this next generation of Exchange or go to Exchange 2000?
You don't wait. It really is an Active Directory decision first [AD and Exchange are now integrated]. Service packs are a great way to get you new technology in the meantime.
You have marketed Exchange as a development environment, but there is the common belief that Exchange is messaging and there is not a lot of development on top of it. Why do you think that changes with .Net?
The cool thing is that developers are already there. They are already developing on a database, using ASP pages. Development is growing and it's mostly focused on Exchange features like the workflow engine. But think of the next version of Exchange built on this new data store. For example, it can be plugged into BizTalk Server and Exchange services can be exposed to go out beyond the enterprise.
What about popular Exchange form-based applications? What happens with them? Is there a way to convert them?
You are not going to be able to pin me down on how each migration will work or what forms will work; we just don't know. We are early in this thing; the development of the new Exchange store has been going on for almost a year. We are still in the early stages of development. The first beta will come some time next year.
You're talking about the store based on the next version of SQL Server called Yukon?
Some of it is linked to that. But I owed it to the Exchange users in my keynote [to clarify where Exchange was headed] because I scared a lot of people last year when I killed development of the Local Web Storage System. There was a lot of confusion. You have to tell them why.
The Local Web Storage System was supposed to provide replication and offline use of applications. How do those features make it back into Exchange?
If you think about the SQL Server store there is a version of SQL that runs on the server and a version that runs on the desktop. You saw SQL Server CE running [at the conference] in a demo. That all moves into Exchange with the new data store.
When Exchange is connected into a .Net infrastructure, what are the implications during a virus attack? When you start to integrate servers underneath your line-of-business apps you expose yourself to a much deeper attack. How do you protect that system?
It is serious. We will have a set of announcements soon about what we are going to do to step up and help customers with this. I don't have specifics now. We will get smarter about the virus scanning. We'll get smarter about partitioning. We'll get smarter about trying to corral things off when they go bad. We are going to get much smarter about proactively distributing the fix.
How will you license the next-generation Exchange? When you start to pull out calendaring features to use in another application, that's not a mailbox licence?
As Web services branch out, we may have to look at our licensing model and adjust it. We do per CPU today with SQL Server and other servers. There is a possibility of that, we are not committing to that, we have to look at it. This stuff takes a little time, we have to talk to customers. The last thing we want to do is to make customers angry about licensing. We'll never make everyone happy.
