Subtitles of the Movie

The architecture of Exchange 2010 hasn't really changed that much down at the foundational level, but there are some things you need to be aware of as an administrator, especially if you're coming into the Exchange world kind of new and I want you to understand this. First of all, we're still using the Extensible Storage Engine database. Now in prior versions, if you worked on Exchange back at the 5.5 version back in the 90s or even the 2000 version, the ESE was almost kind of used in the same manner as profanity and anytime you talked about the Extensible Storage Engine you would usually hear profanity kind of melded in there with it. This thing was incredibly reliable at some times and then just incredibly, incredibly fragile at other times. This has improved dramatically. Now one of the things you need to understand is we're still not using SQL Server in the Exchange environment. This is one of the big topics out there. Every time a new version of Exchange gets closer and closer to release there's a lot of people out there who would really like to see this go to a SQL Server database structure because there's so much SQL knowledge out there in place and people have all kind of ideas as how they could use the data and how much easier it would be to utilize it if it was in a SQL Server environment, but it's not there. What you do need to understand is Microsoft has made some considerable changes to the architecture and operation of the Extensible Storage Engine database technology and it is much, much faster. It is much, much more stable than it was before and, as a matter of fact, as you use this you're going to think or feel like you're working on a SQL Server database. It really is much better now. Now I sound like a used car salesman, but trust me, you're going to like what you see here. One thing I want you to understand is, is that the database that's being used by Exchange Server, one of the things that makes it so stable is it really is functioning as a single user database. Your Exchange Server that is connected to the database is the only connection that's ever being made and since that is happening Microsoft has really tuned this database to store hierarchical data and, of course, we're talking about mailbox information, calendar information, and all that sort of stuff. Now let me give you just a real quick animation here, and especially for those of you who are coming into Exchange new. If you can get this in your brain it's going to help you in all the administrative aspects and to help you to begin to troubleshoot at a high level what possibly is going wrong or what is impacting the service levels you're getting from Exchange. First of all, an end user out there sends an email message to another mailbox and so what's going to happen is they are going to obviously pass that message via Outlook or Outlook Web Application, or whatever they're using - their iPhone, their mobile phone, whatever - they're going to send a message and it's going to be delivered to the Exchange Server organization that's represented by the single server here. In reality, this Exchange Server organization is most likely going to be, especially in large corporate environments, multiple Exchange Servers running different roles - Mailbox Server Roles, Client Access Server Roles - and what's really going to happen in reality is this message is going to be delivered to a Client Access Server that is then going to hand this off and depending how we're configured here, it could be coming through Hub Transport and so forth, but the bottom line is, it is going to make its way to the appropriate Exchange Server where the mailbox is housed, where we need to deliver this message. Now what happens at that point is interesting and I'll kind of really simplistically go through it here. The first thing that happens is that message is written into the memory of the Exchange Server, so that tells you something. The more memory the better on the Exchange Server as far as functionality and speed and efficiency goes. Outside of your control, from time to time, Exchange is going to take all the messages that are residing in memory and it is going to write them into the Transaction Log. If you don't understand Transaction Logs and how databases work I'll give you a clue here, it'll dramatically help you in your effectiveness as an Exchange administrator to go out there and just read up on databases transaction logs, how they work, because the real bottom line here is Exchange Server really is a database server. It is simply storing your mail information, your contacts, your calendaring information, your voice messages, and so forth in a database and then allowing you to access them based on permissions and so forth. So we're going to write into memory first and then that memory is going to basically be dumped or written down into the Transaction Logs. We can use these for backup, we can use them for Failover capabilities - we do all kind of cool stuff. And then from the Transaction Log these things are later actually moved into the databases that exist on the Exchange Server and we're going to talk about databases, database availability groups and how we manage these things a fair amount later on. That's the very simplistic version. Let me add one more thing to this that I didn't want to do that would confuse you. In reality, back up at this step here when the data is written to the Transaction Logs it is also at that point simultaneously written to the Exchange database. So rather than truly going this way into the Transaction Log and then into the database it is more or less simultaneously written into the database and into the Transaction Logs. But again, the bottom line there is you can quickly see the amount of available memory on your Exchange Server needs to be sufficient to allow it to write the volume of messages into memory so that it can catalog them, store them, do whatever magic it's doing and then, of course, by putting the Transaction Logs and the Exchange database on separate physical spindles then we can do simultaneous writes on those and get a much faster read-write situation. But this is the basics. Get this basic functionality in your mind and then as you learn more about how Exchange is working this will help you to really understand what's going on, where your service may be suffering, why you need to add more memory and all that sort of stuff. That's just a real brief architectural overview of what's happening in Exchange and what you need to be aware of to kind of help you get kick started and get underway as an Exchange administrator.