IntroductionYou
may have already heard Microsoft’s recent announcement that the next version of Exchange, currently dubbed E12, will ship as a 64-bit application only to run on x64 CPUs. This may have left you wondering what x64 is, how 64-bit technology is going to benefit Exchange, or what you should be looking for when purchasing hardware now, so when E12 ships you are ready.
What is x64?
Today, your typical server contains a 32-bit processor(s) which can use a maximum of 4GB RAM. Windows will split that into two, 2GB chunks, one for kernel mode and one for user mode. You can alter this, and Microsoft recommends you do so with Exchange servers that have more than 1GB ram, by adding the /3GB switch to your boot.ini file. This increases the amount of memory available to user mode applications, such as store.exe, to 3GB, leaving the other 1GB for the kernel. This still limits a 32-bit application to a maximum of 3GB RAM.
There are some ways a 32-bit application can overcome the 4GB memory limit, including Physical Address Extension (PAE) or Address Windowing Extensions (AWE). This does increase the amount of physical addressable memory, but it does not increase virtual memory addressing.
With the introduction of the x64 architecture come two major improvements that will increase performance in E12. The two major improvements provided to E12 by x64 are:
Increased physical and virtual memory addressing Increased number and width of internal registers The x64 architecture allows Windows to blow past the 32-bit memory limit of 4GB and allows 64-bit versions of Windows to access up to a whopping 1 terabyte (TB) or RAM. The /3GB switch will no longer be required as the kernel mode and user mode memory limits in Windows Server 2003 x64 editions is 8TB. Figure 1 outlines the memory limits for 64-bit versions of Windows.
How x64 will benefit E12?
There are numerous benefits to running E12 on the x64 hardware architecture, the biggest of which is scalability. Obviously, by having a server with more memory and faster performance will allow you to add more users to the Exchange server.
If you are running a medium to large Exchange organization you most likely forked out a large sum of money for a fast iSCSI or Fibre Channel (FC) Storage Area Network (SAN). During the planning stages you also probably ran tests to determine the minimum, maximum and average IOPS your SAN would need to support to provide the desired performance level to your deployment. While you probably will still need a SAN for storage, the increased memory available to E12 on the x64 architecture will reduce the disk IO dramatically. Early testing by Microsoft shows a reduction in IOPS of roughly 70% comparing Exchange 2003 to E12 on the same hardware.
The x64 architecture will also allow for larger numbers of storage groups and stores. Currently Exchange Enterprise editions support a maximum of 4 storage groups, each with 5 stores. E12 will expand this limit to 50 storage groups with 50 stores. That is a huge amount and really shows off the scalability of E12 on the x64 architecture.
32-bit versions of Exchange are also limited by the amount of memory in the kernel. In your typical Exchange environment, there are a number of connections made to the Exchange server. Each incoming and outgoing message can create a connection and Spam can easily create an enormous number of connections. Add to this web access via OWA or OMA, RPC over HTTPS and connections made with MAPI, POP3 and IMAP clients and memory exhaustion becomes a large problem. Each connection uses a bit of kernel memory and this limits the number of connections therefore limiting scalability dramatically. By effectively losing this limit, more connections will be supported, meaning more users per Exchange server.
IPSec also puts a strain on system resources. If you are running an Exchange front-end/back-end configuration, you may have implemented IPSec between the FE and BE server if the FE is in a DMZ. IPSec utilizes a fair amount of resources encrypting and decrypting data, by increasing the amount of registers and memory available to the system, this also becomes a lesser issue.
One other unplanned benefit is the ability to run Outlook on the Exchange server. Microsoft has always recommended that you do not install Outlook on an Exchange server. On an x64 system, 32-bit applications run in a similar manner that 16bit applications run in a 32-bit environment, via WOW. Since Outlook is a 32-bit application, it will run under WOW and not interfere with E12. This is something I know many Exchange administrators, including myself, have wanted for a long time. As a side note, E12 running on the x64 architecture will have no effect on 32-bit applications running on your client computers.
Hardware Considerations
If you have purchased any new hardware in the last 6 months, it most likely already is 64-bit capable. I migrated to an IBM based blade system in June 2005 and they all shipped with Intel EMT64 CPUs. X64 CPUs are even starting to show up on entry-level machines from HP, IBM and Dell. By the time E12 is expected to ship, x64 based servers will be commonplace.
The x64 architecture is a 64-bit x86 architecture, and CPUs built with this architecture currently include AMD Opteron and Athalon64 CPUs as well as Intel EMT64 CPUs. All these CPUs are backwards compatible with 32-bit operating systems and applications. Intel Itanium and IA64 CPUs are not backward compatible and will not be supported by E12.
Due to this backwards compatibility, you can ensure you are ready for E12 by purchasing new servers with any x64 CPU now. You can install and run 32-bit versions of the operating system along with the currently supported versions of Exchange server and when E12 ships you will be ready to migrate to 64-bit technology and E12 without a worry.
Conclusion
In a nutshell x64 will provide E12 organizations with better performance and scalability which will allow for:
- Larger volumes of messages
- Increased e-mail message size
- Increased size of attachments
- More users per server
- More mail clients connected (OWA, OMA, RPC, ActiveSync)
E12 and the x64 architecture will provide an increase in performance and scalability not seen in a long time. The increased memory capacity will allow more of the database to be held in RAM, reducing disk IO and the increased number of connections will allow you to add more users to your Exchange environment without the need for more servers.
Small Business Server administrators should also be aware that the next version of SBS, which should include E12, may also be 64-bit only allowing increased performance and scalability to the small business owner as well.
By planning your hardware purchases with this information in mind, you can be assured that the transition to 64-bit and E12 will be a painless one.
Credit by http://www.msexchange.org/articles_tutorials/exchange-server-2007/security-message-hygiene/
Thursday, November 15, 2007
Introduction to Exchange 2007 Server Roles
Introduction
Server roles allow an administrator to split the functions of an Exchange server and place each role, or a combination of roles, on different servers in the organization. This can be done for performance reasons, management reasons, or any other reason deemed necessary by the organization's policies.
With current Exchange servers you can make a server a Front-End server or a Back-End server and that is about it. Exchange 2007 introduces five roles to the Exchange organization.
- Edge Transport
- Hub Transport
- Client Access
- Mailbox
- Unified Messaging
The following graphic (Figure 1) shows the placement of each role in a typical organization
Edge Transport RoleThe Edge Transport role is installed on the edge of the network and therefore is installed on a standalone server that is not a member of the Active Directory domain. Because the server is not a member of the Active Directory domain, Active Directory Application Mode (ADAM) is used to sync AD with the Edge Transport server. ADAM and a component called EdgeSync are used to perform scheduled one-way synchronization of the configuration and recipient information from Active Directory. This allows the Edge Transport to perform recipient lookups and Spam filtering.
The Edge Transport role performs a number of functions including Anti-spam and Anti-virus protection. The Edge Transport uses connection filtering, content filtering, recipient filtering, SenderID, sender and IP reputation to reduce the amount of Spam delivered to the end users inbox. Mail tagged as Spam will sit in a Spam quarantine from which administrators can delete or allow messages tagged as Spam. One of the top features is the ability for Outlook 2003 and 2007 clients to merge their Spam settings (like white and black lists) to the Edge Transport server to increase the efficiency and accuracy of the filters. The built in VSAPI has been improved and the introduction of transport agents will allow third party AV applications to provide stronger AV filtering.
Edge Transport Rules are used to protect the Exchange organization by applying rules and, based on whether the message passes or fails, appropriate action is taken. Unlike the Anti-virus and Anti-Spam processing, Edge Transport rules are based on SMTP and MIME addresses, words in the subject or message body, and SCL rating. The Edge Transport role also handles address rewriting; in Exchange 2007 an administrator can modify the SMTP address on in or outbound mail.
The Edge Transport server is also responsible for all mail entering or leaving the Exchange organization. Mail travels inbound through the Edge Transport and once the Edge Transport Rules have been applied the message is passed on to the Hub Transport server. Because the Edge Transport is responsible for all in and outbound mail, you can configure multiple Edge Transport servers for redundancy and load balancing.
Hub Transport Role
The Hub Transport role is responsible for all internal mail flow. This role is similar to the bridgehead server in an Exchange 2000/2003 organization. In fact it originally was called the Bridgehead Role until it was changed.
The Hub Transport server, as well as the rest of the server roles, is installed on member server(s) in an Active Directory domain. There is no need for ADAM on this, or any other role aside from the Edge Transport. Because it is a member of an AD domain, all its configuration information is stored in AD and any other Hub Transport servers you install will get their configuration from AD.
Inbound mail is accepted from the Edge Transport and passed on to the user's mailbox and all outbound mail is relayed from the Hub Transport to the Edge Transport and out to the Internet. The Hub Transport and Edge Transport servers are very similar and in fact, one can forgo the Edge Transport server and configure the Hub Transport to accept mail from, and send mail to, the Internet. Hub Transport agents can also be deployed to enforce corporate message policies such as message retention, something that will come as good news to administrators attempting to comply with SarbOx rules.
The Anti-Spam and Anti-virus features of the Edge Transport can be configured on the Hub Transport in order to reduce the number of servers required. It is quite feasible that you may only have one server in your Exchange organization with all the roles installed on it. In this case you cannot have an Edge Transport and all those features will be passed on to the Hub Transport role.
Client Access Role
The Client Access Role is similar to the role a Front-End server would play in an Exchange 2000/2003 organization. The Client Access server is the server that users connect to with their mail client, mobile device, or web browser. The Client Access server handles all connections whether they come from an application such as Outlook 2003 or 2007, Outlook Express, or any other MAPI, POP3 or IMAP4 client. The Client Access server also handles connections made from mobile devices such as a Windows Mobile 5 Smartphone, or any other device using Exchange ActiveSync. Exchange ActiveSync in Exchange 2007 supports all devices with PocketPC 2002/2003 and Windows Mobile 5. Figure 2 shows how all the clients and roles connect to each other.
Unified Messaging Role
The last, and in my opinion, coolest role is the Unified Messaging Role. The Unified Messaging role is responsible for merging your VOIP infrastructure with your Exchange organization. What does this allow for?
combined voice, fax, and mail in one inbox access to voice, fax and mail via multiple interfacesNeed to check your voicemail but all you have is Internet access? No problem, connect to the Exchange server with OWA and you will find your voicemail as attachments in email messages. Running late for a meeting and no access to email or your calendar? Call the Exchange server and move the start of the appointment in your calendar and the attendees with get an email notifying them of the change.
Unified messaging will change the way user’s access voice, fax and email and they will love you for it. Now before you get too excited this will require some special hardware to interact with your phone system and more information will be released as Exchange 2007 gets closer to RTM.
Credit by http://www.msexchange.org/tutorials/Introduction-Exchange-2007-Server-Roles.html
Exchange 2007 Store Related Changes and Improvements
Exchange 2007 Store Related Changes and Improvements
Exchange 2007 – A True 64-bit Application
It shouldn’t come as a surprise for any of you that only the 64-bit version of Exchange 2007 will be supported in production environments. Because Exchange 2007 is real native 64-bit application, it can access much more memory which ensures high performance and reliability as mailbox sizes and the number of user accounts per server increase. The default mailbox as well as Public Folder size in Exchange 2007 is nothing less than 2GB
Exchange 2007 Storage Groups and Databases
A Storage Group is a grouping of Mailbox and/or Public Folder Databases, which shares a single backup schedule and a single set of Transaction log files. Storage Groups are managed using their separate server process and the idea behind splitting databases up in Storage Groups is primarily to reduce the overhead that results from multiple sets of transaction log files.
As most of you recall, Exchange Server 2003 Standard edition supported 1 Storage Group and 2 Stores – one Mailbox and one Public Folder Store (when excluding the Recovery Storage Group of course). Exchange Server 2003 Enterprise Edition supported a total of 4 Storage Groups each containing a maximum of 5 store databases. The limit of a database in Exchange Server 2003 Standard edition was 16 GB (although raised to 75 GB when Exchange 2003 Service Pack 2 was applied). There was no limit on a database when talking about Exchange Server 2003 Enterprise edition (well actually there is a 16 Terabyte limit but this limit is caused by hardware).
Exchange Server 2007 comes in two flavors, a standard edition and an enterprise edition, just like previous versions of Exchange. The Mailbox Server when talking about the Exchange Server 2007 Standard edition supports a total of 5 Storage Groups and 5 databases. Unlike Exchange 2003 and previous versions of Exchange there’s no longer a database storage limit in the standard edition. The Mailbox server in the Exchange 2007 Enterprise edition supports up to 50 Storage groups and a maximum of 50 databases per server. Exchange 2007 allows you to create up to 5 databases in each Storage Group as is the case with Exchange 2003, but best practice is to create 1 database per Storage Group. So why should you have a one to one relationship between storage groups and databases? Well primarily because you’ll be up and running a lot faster considering disaster recovery scenarios, etc.
Transaction Log File Size Changes
Another change in Exchange Server 2007 is that the transaction log files are now 1MB instead of 5MB as was the case in previous versions of Exchange.
So what’s the reason behind this decision? Well in previous versions of Exchange if a crash destroyed the last few log files that hadn’t been committed to the database yet, you would need to restore or repair the database to have it mounted again. Exchange Server 2007 introduces a new feature called Lost Log Resilience (or LLR in short) which will hold the last few log files in memory until the database is shut down. This means that you will never have a case where part of for example log file 5 has been written to the database, but part of log file 4 hasn’t. The benefit of this is that if you don’t have anything against losing the last few log files, you can tell Exchange to simply throw away the data and mount the database.
So the reason why the log files has been reduced to 1MB is to reduce LLR exposure. Now if you lose the last log, it costs up to 1MB of the most recent data instead of 5MB.
Another improvement worth mentioning is that the log file sequence numbers now can go above 1 million. As some of you might be aware previous versions of Exchange had a limit of 1 million, so if a database had been running long enough to generate a million logs, you had to shut it down and start over from log #1 ("reset the log sequence"). This would happen every few years for most databases. With the smaller log sizes and the increasing amount of messages passing through most databases, the Exchange Product group decided 4 billion would be a better maximum log number.
Credit by http://www.msexchange.org/tutorials/Exchange-2007-Store-Related-Changes-Improvements.html
Introduction
During the early stages of the development phase of Exchange Server 2007, rumors about changing the store to SQL circulated the Internet. But these plans were dropped relatively quickly and chances are we won’t see an Exchange product where the store is based on SQL before E15 (yes that’s the version after E14!). But this doesn’t mean that Exchange Server 2007 doesn’t introduce any store related changes and improvements, because although the Exchange still is based on a more or less unchanged ESE database a lot of work went into providing a much more scalable, reliable, and optimized product which performs better than was the case with previous versions of Exchange.
During the early stages of the development phase of Exchange Server 2007, rumors about changing the store to SQL circulated the Internet. But these plans were dropped relatively quickly and chances are we won’t see an Exchange product where the store is based on SQL before E15 (yes that’s the version after E14!). But this doesn’t mean that Exchange Server 2007 doesn’t introduce any store related changes and improvements, because although the Exchange still is based on a more or less unchanged ESE database a lot of work went into providing a much more scalable, reliable, and optimized product which performs better than was the case with previous versions of Exchange.
Exchange 2007 – A True 64-bit Application
It shouldn’t come as a surprise for any of you that only the 64-bit version of Exchange 2007 will be supported in production environments. Because Exchange 2007 is real native 64-bit application, it can access much more memory which ensures high performance and reliability as mailbox sizes and the number of user accounts per server increase. The default mailbox as well as Public Folder size in Exchange 2007 is nothing less than 2GB
Exchange 2007 Storage Groups and Databases
A Storage Group is a grouping of Mailbox and/or Public Folder Databases, which shares a single backup schedule and a single set of Transaction log files. Storage Groups are managed using their separate server process and the idea behind splitting databases up in Storage Groups is primarily to reduce the overhead that results from multiple sets of transaction log files.
As most of you recall, Exchange Server 2003 Standard edition supported 1 Storage Group and 2 Stores – one Mailbox and one Public Folder Store (when excluding the Recovery Storage Group of course). Exchange Server 2003 Enterprise Edition supported a total of 4 Storage Groups each containing a maximum of 5 store databases. The limit of a database in Exchange Server 2003 Standard edition was 16 GB (although raised to 75 GB when Exchange 2003 Service Pack 2 was applied). There was no limit on a database when talking about Exchange Server 2003 Enterprise edition (well actually there is a 16 Terabyte limit but this limit is caused by hardware).
Exchange Server 2007 comes in two flavors, a standard edition and an enterprise edition, just like previous versions of Exchange. The Mailbox Server when talking about the Exchange Server 2007 Standard edition supports a total of 5 Storage Groups and 5 databases. Unlike Exchange 2003 and previous versions of Exchange there’s no longer a database storage limit in the standard edition. The Mailbox server in the Exchange 2007 Enterprise edition supports up to 50 Storage groups and a maximum of 50 databases per server. Exchange 2007 allows you to create up to 5 databases in each Storage Group as is the case with Exchange 2003, but best practice is to create 1 database per Storage Group. So why should you have a one to one relationship between storage groups and databases? Well primarily because you’ll be up and running a lot faster considering disaster recovery scenarios, etc.
Transaction Log File Size Changes
Another change in Exchange Server 2007 is that the transaction log files are now 1MB instead of 5MB as was the case in previous versions of Exchange.
So what’s the reason behind this decision? Well in previous versions of Exchange if a crash destroyed the last few log files that hadn’t been committed to the database yet, you would need to restore or repair the database to have it mounted again. Exchange Server 2007 introduces a new feature called Lost Log Resilience (or LLR in short) which will hold the last few log files in memory until the database is shut down. This means that you will never have a case where part of for example log file 5 has been written to the database, but part of log file 4 hasn’t. The benefit of this is that if you don’t have anything against losing the last few log files, you can tell Exchange to simply throw away the data and mount the database.
So the reason why the log files has been reduced to 1MB is to reduce LLR exposure. Now if you lose the last log, it costs up to 1MB of the most recent data instead of 5MB.
Another improvement worth mentioning is that the log file sequence numbers now can go above 1 million. As some of you might be aware previous versions of Exchange had a limit of 1 million, so if a database had been running long enough to generate a million logs, you had to shut it down and start over from log #1 ("reset the log sequence"). This would happen every few years for most databases. With the smaller log sizes and the increasing amount of messages passing through most databases, the Exchange Product group decided 4 billion would be a better maximum log number.
Credit by http://www.msexchange.org/tutorials/Exchange-2007-Store-Related-Changes-Improvements.html
Subscribe to:
Posts (Atom)