Friday, January 7, 2011

Getting Started With Exchange 2010

As most know Exchange 2010 is the latest version of Microsoft's email server.  I wanted to write a short description of the software and outline its features. 

Like its predecessor Exchange 2010 requires that you run it on an x64 platform.  32-bit processing is surely but slowly becoming a thing of the past.  In 2010 however you must also be running Windows 2008 SP2 or 2008 R2.  One of the major decisions you'll have to make is whether to select the standard or enterprise edition.  This basically boils down to how many stores you need.  Standard supports 5 stores per server as to where Enterprise you can do 50+.   As far as the client side CAL's are concerned you must purchase the 2008 enterprise CAL's if you wish to do unified messaging.  There is not however a limitation in the software.  It is simply a licensing issue.  Which means you'll still have the ability to access unified messaging but it will not be licensed correctly.   Another feature Microsoft has decided to keep is the JET EDB database.  It has been rumored in the past that Microsoft would start using SQL server to house the Exchange database.  This is not the case. 

If you ever worked with recovery storage groups in Exchange 2003 or 2007 you will no longer find those in 2010.  As well you will not be able to find routing groups.  All of the Exchange 2010's routing is done through active directory sites and services.  So you must make sure that you have properly configured your sites before moving forward with Exchange.  It is essential to Exchange 2010 functioning properly.  As with Exchange 2007 Microsoft still is trying to deemphasize public folders.  Their goal is to eventually replace these with their Sharepoint product. 

Another major feature of Exchange 2007 and 2010 is their ability to reject email at the gateway.  The Edge transport server allows you to configure ADAM and active directory lightweight services to query AD.  This allows you to get a list of valid email address and push them out to the border of your network.  If the edge server detects that someone is trying to send email to the inside of your organization and the user does not exist it is dropped immediately.  This saves on memory and processing power internally so that you don't have to deal with spam. 

Additionally with Exchange 2007 and 2010 you get the ability to create UNC direct file access paths.  This way in OWA when a user needs a file on a network share they can grab it without needing a cumbersome VPN client.  Outlook anywhere also remains widely the same in 2007 and 2010.  It basically encapsulates your RPC packets into https packets.  This allows you to traverse your firewall without opening any additional ports.  Therefore giving users access to their email from Outlook wherever they may travel. 

One of the greatest new features of Exchange 2010 in my opinion is database availability groups or DAG.  This is essentially the same thing as CCR in Exchange 2007.  Anyone who has tried to configure CCR, LCR, or SCR in Exchange 2007 knows that it can be quite the process.  Microsoft simplified this with DAG's in 2010.  It allows you to keep 16 copies of a users mailbox for redundancy and disaster recovery.  It does this through a process called log shipping.  Where 1MB files are created and then played into the database.  This allows you to keep a backup of your server at another physical location for disaster recovery or have two Exchange servers running next to each other.

Another nice feature in 2010 is the fact that the client access server or CAS redirects your client to their database server that houses their mailbox.  You no longer need to specify the location of your server in Outlook.  The CAS parses AD and redirects them automatically.  Therefore there is no hard coding.  This makes the transition for failover a lot easier. 

As most of you know who have used Exchange 2007 the GUI is simply a front end to Microsofts command line utility called EMS or Exchange Mangement Shell.  Anything you do in the GUI is converted to a command and executed against your server.  I would personally say you have about 90% functionality in the GUI as opposed to EMS.  However, EMS definitely makes the process a lot easier if you need to apply a setting to multiple objects at the same time. 

As with Exchange 2007 you still have the same five roles edge transport, hub transport, client access server, mailbox, and unified messaging.  Inside of these five roles only the edge transport server must be installed separately from the rest of the servers.  Everything else can be ran on one box.  Although this is not recommend for performance reasons.  The reason why the edge server is standalone is it was meant to sit in your DMZ or on the border of your network.  Absorbing the hits so your internal servers are not affected.  It has features such as safelist aggregation where Outlook client rules are brough outside to it so that it can apply those rules before the message ever enters your internal network. 

The hub server still is the same as Exchange 2007 it routes your messages internally and holds compliancy rules.  You can also run a command against it to install antispam featureset.  This way if you don't have an edge transport server you can use it to receive outside mail directly.  Although this is not recommended by Microsoft.

The CAS server or client access server is meant to interface with your internal and external clients.  As stated before it automatically redirects your Outlook clients so that you don't need to hardcode their mailbox server.  It also accepts connections from smart phones, OWA, etc.  It is basically your clients interface to your Exchange infrastructure.

If you wish to monitor your Exchange 2010 infrastructure Microsoft has made a plugin for their SCOM or system center operations manager.  This is Microsoft's MOM replacement that allows you to montior your servers.

In Exchange 2010 you will no longer see SCR, LCR, or CCR.  They have been superceded by DAG or database availability groups.  This makes configuring database replication a lot smoother.  DAG's also allow for your data to reside across multiple servers.  You can also have multiple DAG's.   This is a great feature because if half of your users are in one DAG group and it goes down the other half are not even affected.  Other benefits are reduced restore time since you're not restoring all of your users' data only the ones in that DAG.  You can also have separate exchange policies for different DAG's.  So if your management is in one and your regular users are in another you can change the rules that apply to them.  This is a great way to mitigate risk by distributing your load. 

As far as the enterprise and standard software go they are both installed from the same media.  It is just different license keys that you input that determine what version you are installing.  It is also upgradable.  You can go from trial to standard to enterprise.  However, you cannot downgrade backwards from enterprise to standard or standard to trial. 

In order to install Exchange 2010 your domain and forest functional level must be at 2003.  Also each site which contains Exchange 2010 must also contain a 2003SP2 domain controller or 2008 domain controller.  We recommend you have your domain running 2008R2 domain controllers however. 

Exchange still uses EAS or exchange active sync for mobile devices.  This way your contacts, calendar, email, etc. are all tightly integrated with your Windows mobile devices.

One common misconception that people have is Exchange enterprise must be installed on server enterprise software.  Or that server enterprise software cannot have Exchange standard installed on it.  Both of these are fallacies. 

When you begin your Exchange installation you should give serious consideration to how you configure your arrays.  Exchange is a very read/write intensive application.  Therefore you should separate your OS, log files, and database all on separate arrays.  If this is not possible it is then recommended that you at least put yoru OS and log files on one array and your database files on another.  The reason for this is simple.  The log files are write intensive and the database files are read intensive.  Separate these two out can speed up your disk I/O.

Memory requirements in Exchange 2010 have pretty much gone unchanged.  Start your server with 2GB of memory and then 5MB for every mailbox user.  I would also personally recommend to have a minimum of 4GB.  Memory is cheap enough these days that the benefit of having more of it outway the cost.

Although the databases in Exchange can grow very large we do not recommend that you go over 100GB.  This can become cumbersome to work with and decrease performance on your server.

If you wish to remotely manage your Exchange server you can install the management tools.  They will install on Vista SP2 and higher or server 2008 SP2 or higher.  This way you do not have to remotely login to your Exchange server to make all of your changes.

As far as your site layout goes you should also plan on having a global catalog server in every location that contains a mailbox server.  This is recommended by Microsoft and will reduce WAN traffic. 

Exchange has also setup a new permissions setup which they refer to as RBAC or role based access control.  From this you get 5 roles to manage your exchange infrastructure.  They are Organization management, view only organization management, recipient management, records management, and GAL synchronization management.

Another thing you should consider before installing Exchange 2010 is to make sure your domain is setup properly.  You can use tools such as NETDIAG and DCDIAG to verify this.  In order to install Exchange 2010 you're going to need to be a member of domain admins, enterprise admins, and schema admins.  You will also want to add connect.microsoft.com and download.microsoft.com to your trusted sites list in IE.  Other pieces of software that must be installed are .NET 3.5, Windows remote management 2.0, powershell v2, 2007 office converter microsoft filter packs.  If you are installing the mailbox role you must also have AD services remote management tools.

Before starting the install you must prepare your schema by running setup /ps if it fails delete the contents of c:\windows\temp, copy the files from your CD to yoru hard drive and rerun setup /ps.  You must then run setup /prepareAD /OrganizationName:MyCompany where "MyCompany" can be replaced by your organization name.

You must then prepare the prerequisites by running the following commands.

  • ServerManagerCMD -install RSAT-ADDS
  • ServerManagerCMD -install Web-Server
  • ServerManagerCMD -install Web-ISAPI-Ext
  • ServerManagerCMD -install Web-Metabase
  • ServerManagerCMD -install Web-Lgcy-Mgmt-Console
  • ServerManagerCMD -install Web-Basic-Auth
  • ServerManagerCMD -install Web-Digest-Auth
  • ServerManagerCMD -install Web-Windows-Auth
  • ServerManagerCMD -install Web-Dyn-Compression
  • ServerManagerCMD -install Net-http-Activation
  • ServerManagerCMD -install RPC-over-http-Proxy

    Once this is complete reboot your server.  You are now ready to run Setup.com /mode:install /roles:H,C,M the H,C,M install hub cas and mailbox roles.

    Once your install is complete run the Exchange BPA or best practice analyzer.

    In order to install the Edge server you'll want to make sure you're running 2008 standard with SP2.  You'll need .NET 3.5, remote management 2.0, powershell v2, AD LDS (can be installed via servermanagerCMD -i ADLDS).  For the edge server to work in a DMZ you'll need to open ports 50389-50636.  Then run new-EdgeSubscription -filename "c:\temp\EdgeSubscriptionInfo.xml"  Copy that generated file to your hub server you can import it in the GUI and run start-edgeSubscription from EMS.  You can test this once it is imported to verify it is working properly by using test-EdgeSubscription from EMS.

    I would personally recommend using a RBL provider to stop spam from entering your organization.  One example of this is SpamHaus.  This queries the connecting server to a black list of IP's and blocks communcation if it is found on the list.  This one feature can drastically cut down on spam.

    Another item you have to address is purchasing a SAN certificate for your Exchange server.  Exchange has moved to a secure by default mentality.  You will find connecting to OWA or using activesync become very painful if you try to issue your own SSL certificates.

    Another security improvement in Exchange 2007 and 2010 is that all intracommunication is secure and encrypted.  TLS is used for all server to server communication internally.  RPC is used for your Outlook clients to communicate with your servers.  SSL is configured for all external client communication including, OWA, activesync, etc.

    Opportunistic TLS is a new feature where your Exchange server will no long try to send via SMTP by default.  It will first send a STARTTLS command to use TLS to encrypt external SMTP communication with other servers.  If the other server however does not support this it will revert to unsecure communications.

    Still included in Exchange 2010 is the ability to use a journaling mailbox to track all of your emails.  This is required by some organizations.  Keep in mind that this feature can increase your processor and memory usage by 25%.  So you should make sure your server has plenty of resources before turning on this feature. 

    One of the requirements as previously stated is that Exchange 2010 must be running active directory 2003.  Even though 2008 is recommended if you are running Cisco Unified Messaging 4.2(1) or lower it is NOT compatible with active directory 2008. 

    When you upgrade your active directory infrastructure it is recommended that you create a virtual machine using Microsoft Hyper-v or Vmware.  Make the virtual machine an additional domain controller and make it a global catalog.  This way if your upgrade takes  turn for the worst you have data that is intact if you have to downgrade.  Do not forget to unplug it from the network before doing the upgrade.  If you need to revert back you can use NTDSUTIL to seize the roles.

    If for whatever reason you need to create a scratch installation of a domain you can always use the ADMT utility to move users, groups, computers, service accounts, and trusts.

    To migrate from 2003 Exchange to 2010 the overview is as follows.  First you must be running Exchange 2003 with service pack 2.  Your active directory domain and forest functional levels must be 2003 and at least one global catalog has to be 2003 server with SP2.  Instal AD LDIFDE tools on 2008 to upgrade your schema.  Upgrade your Exchange Schema.  Transfer OWA, activesync, and Outlook anywhere to the CAS server.  Install/upgrade hub server.  Transfer the mail flow to the hub transport server.  Install mailbox servers and DAG if required.  Move your public folder replicas using pfmigrat.wsf or PFRecursive.PS1.  Move your mailboxes.  Rehome OAB.  Rehome public folder heirarchy.  Transfer public folder replicas.  Delete 2003 public and private stores.  Delete routing group connectors.  Delete RUS using ADSIEdit.  Uninstall Exchange 2003.

    To migrate from 2007 Exchange to 2010 the process is a little less.  Make sure your Exchange 2007 server is running SP2.  Make sure your domain and forest is at 2003 functional level.  Global catalog server is at 2003 SP2.  Use AD LDIFDE tools to upgrade your schema.  Prepare schema.  CAS server.  Transfer OWA.  Install hub transport.  Transfer mail to hub transport.  Use AddReplicatoPFRecursive.Ps1 to move your public folder replications.  Move your mailboxes.  Rehome OAB.  Transfer public folder replica.  Delete public and private stores.  Uninstall Exchange 2007.

    With Exchange 2010 or 2007 you want to make your co-existance time as small as possible.  The longer you intermingle different versions the more problems you are asking for.

    If you are running Exchange 5.5 unfortunately there is no direct upgrade at this point.  You must first upgrade to Exchange 2003 SP2 then to 2010.  As far as Lotus Notes, Novell Groupwise, or Senmail goes the recommend path is to install a clean environment and then work on importing your data using tools.  There is no upgrade path.

    Database Availability Groups or DAG's are a very important new feature of Exchange 2010.  It gives you the ability to maintain 16 copies of users' mailboxes.  You can also set different databases to failover to different servers and specify in what priority.  The requirements for DAG are Windows Server 2008 enterprise, two nics in your mailboxes servers, Exchange 2010 Enterprise, a file share witness.  We recommend you put this on your hub transport server.  But technically it can be on any file server.  It is very easy to setup as you create a share and then Exchange manages and handles the permissions.

    Steps to create a DAG, Add members, and verify the DAG

    New-DatabaseAvailabilityGroup -Name ExchangeDAG -WitnessServer ExchangeHT -WitnessDirectory “c:\FSW” -DatabaseAvailabilityGroupIPAddresses 172.16.4.5 –Verbose

    Add-DatabaseAvailabilityGroupServer -Identity ExchangeDAG -MailboxServer ExchangeMB -Verbose

    Add-DatabaseAvailabilityGroupServer -Identity ExchangeDAG -MailboxServer ExchangeMB2 -Verbose

    Get-DatabaseAvailabilityGroup -Identity ExchangeDAG -Status

    To see your network settings run

    Get-DatabaseAvailabilityGroupNetwork -identity ExchangeDAG

    We can then add database copies by doing the following

    Add-MailboxDatabaseCopy -Identity ExchangeMB -MailboxServer ExchangeMB2

    Then check the status

    Get-MailboxDatabaseCopyStatus

    To test the health

    Test-ReplicationHealth

    Read more: http://www.articlesbase.com/information-technology-articles/getting-started-with-exchange-2010-1826490.html#ixzz1ALPAHg75
    Under Creative Commons License: Attribution

  • 0 comments

    Post a Comment