Exchange changes
Microsoft is moving its Exchange platform into the companywide initiative called .Net. That means a new data store for Exchange, a renewed emphasis on it as an application development platform and a number of migration issues for current users. The transition to .Net also has larger implications for IT executives, including integration, security and licensing issues. At the recent Microsoft Exchange Conference Network World Senior Editor John Fontana sat down with Paul Flessner, Microsoft's senior vice president for .Net Enterprise Servers, to talk about:
Exchange administration
Exchange development
Yukon
Kodiak
Flessner's recurring 'better together' mantra
Virus attacks
Licensing
Wireless
Did you put a stake in the ground today about the transformation of Exchange into the .Net line of servers?
That is absolutely true.
Is the transformation 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 DBA 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.
So what am I doing from an enterprise perspective that steadies my infrastructure now so I am ready for this .Net world?
The Exchange 2000 deployment is important because it gets Active Directory established and gives the customer a lot of flexibility in terms of the platform they are going to build upon going forward. Education is a big part of it. Your development team has to be thought of as part of your infrastructure, not just your hardware. And learning the standards, how I think about protocols, synchronous and asynchronous transactions, reliable messaging - they are all things in terms of training. In terms of infrastructure in your shop, I don't see a big movement there outside of the move to Exchange 2000, Windows 2000. Consolidation is going on.
The move to Exchange 2000 is a big one. What is motivating users to do it?
They are digging Outlook Web Access (OWA). A lot of customers are saying 'We don't care, we have to go, we want OWA.' That pulls directory and the whole banana, and once they get into it they realize the directory is a good thing and it helps them. It makes their lives as administrators easier. An infrastructure sell like that is always hard because it is not easy to quantify the end-user benefit. People say, 'I don't give a darn about your new directory. Does it make my life easier?' But if you show them OWA, they say, 'Amen, brother. How soon can you get it in?'
How do I decide, if I want to migrate past 5.5, whether to wait for this next generation of Exchange or go to Exchange 2000?
You don't wait. It really is an Active Directory decision first. Service Packs are a great way to get you 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.
So will the Exchange developer today blossom into someone who can develop across the entire .Net platform?
Absolutely. That is a key. They want that, they are begging for it. They want to be mainstream. Line-of-business vendors want their apps to plug in, they want to use that calendaring. Lots of third-party vendors have their own calendaring built in - customers don't want that stuff. They know Exchange can do that. But there is not going to be this point of discontinuity, we are not going to throw all these guys away and say we want you to do this totally different thing. It would be suicide for us to do that.
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. We will get more crisp next summer as we start to hammer down. But I owed the Exchange users that talk [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. I didn't want to do that. You don't want to do that to your customers. You have to tell them why. It wasn't easy to get the Exchange storage team mixed with the SQL storage team. There was a big fear that the body would reject the organ. It was not clear it would succeed. A year later it is not only clear that it will succeed, it is clear that it will exceed expectations. It feels good - it didn't feel that good a year ago.
The Local Web Storage System was suppose 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 that runs on the server and a version that runs on the desktop. You saw SQL Server CE running today in a demo. That all moves into Exchange with the new data store.
So Exchange users won't see those features until at least 2003?
Probably not.
Is there an interim release between now and the 2003 release?
We are watching the market. Honestly, we just don't know.
Are you working on something called Kodiak, and what is it?
We don't want to talk about it yet. That name floats around, kind of a code name. We don't have enough definition to say what it is.
But it is on the Exchange side?
Yes. It's not something we have enough behind. Yukon is on the storage side, and on the Exchange side there is the Kodiak name. But again, both of those are pretty high-level.
With this data store, you are not talking about one huge store; you are talking about a common store that runs across all the .Net servers?
Yes. The power of SQL Server's distributed-query and scale-out partitioning is that we work to make it easy for users. There is a lot of opportunity, I get excited when I think about the potential.
What is it going to take to lay this object store across the .Net platform?
I didn't use the word 'object store,' but there will be lots of object programming models that customers will choose to put on it. What you get with a database is a strongly typed schema. What we will have is a strongly typed schema across the entire system. The ability to create your own object models should you choose. Or one that we may create and pull forward, but you can be guaranteed we will think hard on how the developer will interact with the system.
You always talk about "better together" in describing the .Net servers. What does that mean from an infrastructure prospective? How do you define that for IT?
If you install Windows and install one of our servers, we should do things that make that a better experience, not to the exclusion of any partner. A partner could do it as well; all the APIs are available to anybody. But I want to do the best job. I want to be the best citizen, the model citizen. I talked about integrated caching for higher performance, I talked about integrated diagnostics for better ability to diagnose problems; I talked about integrated management. With Exchange you have Active Directory and Outlook. Those are probably the two best "better together" examples going. The experience should get continually better. The development teams have really galvanized around that theme. So 'better together' is something I drive hard, if you come to any of my team meetings for the development teams, I pound on it every time.
From an IT perspective, do I have to run all the servers to get the best experience?
It's not like you have to have all the servers. It's not like things won't work if you don't have them plugged in. But if you use our solutions, again, the experience should be better. In Exchange, for example, if you use someone else's mail client you don't get the same experience we believe you get with Outlook. Again, I am not talking about anything that is exclusive in our platform. Everything is being engineered with open APIs so customers can plug in, even the cooperative caching and diagnostics that I talked about.
Diagnostics - we don't have it all the way thought through, but we will probably do something with SOAP and tag a timestamp on a thing. Every time you touch that thing you have to be a good citizen and stamp when you got it and when you got rid of it. So think about loosely coupled, trying to make things service-level in a loosely coupled environment. I might not even know you, and I am asking you for a service. Well, I might want to check your service level. If I am continually seeing you with a 4- or 5-second response time, then I am going to have to call you and say, 'Hey, I love your service, but you're out unless you can cut this down to subsecond.'
When you talk about deep XML integration in .Net servers, what does that mean?
It means different things to different products. SQL Server today has an XML layer above the engine. We are going to put an XML data type inside the engine. With BizTalk Server there is not much deeper it can go. It's native XML in and out anyway. With Exchange, think of it on a new store that is more native XML. Maybe the data model is easier around XML.
The point is, it's a broad statement - a purposely broad statement - because it means different things to different products, but also it is our intent and fundamental design point. You will start to see things come out of XML wrappers - that is how customers get into things and that is how we get into it. If it is a protocol thing, you use a wrapper first, and then as things solidify, you move them into the product. Look at our listener for HTTP that was in IIS for a long time - and now with Windows .Net, that goes into kernel mode and it becomes a fundamental service to the operating system.
When Exchange is connected into that common .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 harden 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 today. 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. Part of the problem is that when the fix is distributed people don't install it; they think they are isolated, and then they get killed.
The customer is asking for an interconnected world. In an interconnected world you have to figure out better ways of prevention. If you do have a problem, how do you partition it and stop its proliferation? When there is a problem you need a proactive way to get the software patches installed. We are going to be very aggressive around this concept of Windows Update. You may see a security area where customers may potentially sign up. If they sign up, we have a security fix, it goes in, we install it into their environment.
How will you license the next-generation Exchange? When you start to pull out calendaring features for use in another application, that's not a mailbox license?
As we go forward, 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.
Right now Exchange hosting is mailboxes, but is there a future scenario where Exchange hosting becomes hosting Exchange-based Web services?
Kevin McCuistion, group product manager of Exchange server marketing: That is a fascinating world. We are looking hard at that brave new partnering and customer world with services tied into it. We are doing creative licensing in the hosting space today to learn more about that. There is no question that hosting will be a part of .Net because it is about services.
Do you expect Exchange administrators to take the lead on Mobile Information Server? It seems that you are positioning it next to Exchange.
McCuistion: We are certainly starting there. We are starting with the killer app, which is mail. But it has to go beyond that because mobility is much more than base messaging and collaboration. It's very clear that what it does today is clearly aligned with Exchange.
How do you judge the competitive landscape for messaging?
Flessner: We think the competitor [Lotus] is not articulating a clear strategy. They are scaring customers. They don't have a good core messaging business. Their strength was their applications development environment, and now they are telling customers that that will be in WebSphere. It is like they are orphaning their customers and saying this is kind of a dead horse. That is not the case for Exchange.
Related Links
