|
Saturday, August 30, 2008
Things that can be missed in Exchange 2007 migration planning...
Let's be honest - Exchange 2007 is a beast of a product, and indeed potentially a bigger leap in redesign than the jump from Exchange 5.5 to 2000. From a management perspective it has forced many Exchange Administrators to rethink their administration policies and learn new technologies which prior to Exchange 2007 they would perhaps not considered being part of their skills arsenal. For example; In Exchange versions 2000 to 2003 - Exchange admins did not necessarily need to be a scripting guru in order to do his/her job. However in Exchange 2007 the integration of the Exchange Management Shell (based upon Powershell) and the amount of configuration options that the Management Shell controls which are not in the Exchange Management Console an Exchange administrator needs to develop at the very least, an understanding of basic scripting techniques - even if this is at the single command level. In the case of Exchange admins whom run larger Exchange 2007 installations (or indeed consultants and architects) the skill with the Management Shell need to be "ramped up" in order for them to achieve their deployment goals - and indeed get the very best out of the product - this can (in some cases not all) move Exchange Admins out of a "comfort zone" and into a world where they are almost part Exchange Systems Admin and part developer (a hybrid). Of course the changes are not just limited to mere scripting - the major Architectural changes that Exchange 2007 has brought with in - for example the move to x64 Hardware being the only supported production platform. In previous migrations between Exchange versions we were all safe in the knowledge that we had the option of "in place" upgrades on the same hardware (if it was up to the job) - in many cases now companies are in the position of having to purchase new hardware to meet or indeed supplement the the demands of Exchange 2007. Closely linked with the above is the inception of "Exchange Server Roles". Roles are not only just a big conceptual change, but have a significant impact on the specification of your Hardware and topological layout. People whom are embarking upon a migration path to Exchange 2007 need to work through the processes of sizing (specifying their hardware according to the role that it will be performing - examples of good sizing articles on the Web are: If you spend time looking through the above you will see that there is a significant increase in the amount of work that is required to correctly size your Exchange installation - there are of course other choices that need to be made - for example: - Do you cluster?
- If you cluster - which clustering technology do you use (CCR, SCC?)
- If you are not using clustering do you place all the compatible roles on a single server?
- If you wish to split the roles out do you choose to have dedicated mailbox servers with HT and CAS running on another server?
- Do you use the Edge Transport Role?
All of the above can (and should) take weeks - perhaps months to correctly ascertain - and remember all of this is before you even place the DVD in the drive. At this stage you might be tempted to overlook the sizing requirements of Exchange 2007 in favour of taking a "Best Guess" - however I urge you not to, Although the sizing calculators and advice look intimidating your should not underestimate the revised Disk I/O and Memory requirements for Exchange - these tools and articles are there to ensure that you do not run into issue later on down the line with the specifications that you have determined. To add to the complexity of migrating to Exchange 2007 you also need to ensure that your existing Exchange and Active Directory environment meets the recommended specifications and that you are ready for the added administrative overhead that occurs during the co-existence phase of your migration - it is worth reviewing the following articles before you install Exchange 2007 into your environment: Exchange 2007 System Requirements Planning for Co-Existence Managing Exchange 2003 Settings in a Co-Existence Environment By reviewing the above articles you will reduce the risk of problems during the Schema, Domain and Exchange setup processes however there are some other things that you should take into consideration before you begin: - If possible in your Organisation institute a "Lock Down" policy on Active Directory for the period of the Exchange installations - essentially ban any account modifications and directory structure modifications - this will make the process of a restore much simpler should you need to.
- Take backups of ALL FSMO role holders BEFORE you begin the Schema / Domain preparation processes
- If you are extra cautious and your schema master is a separate role holder from all the other domain controllers you can perform the Schema updates "offline" so to speak by either disabling replication via RepAdmin tool. This will prevent the changes from being sent to the other directory databases until you have verified that the Schema has been updated properly
- You should disable local Anti Virus during any Exchange installation process
- When installing the first Hub Transport into your environment it will create a routing group which ensures mail flow between Exchange 2003(2) and Exchange 2007 - you should take an Active Directory backup prior to the installation of the HT role - this will help you roll back should anything go wrong during the process (for example I had a support call where a person had not opted to create the Routing Group and then tried to manually create it - potentially it would have been quicker to restore from backup considering the amount of time that we spent troubleshooting it)
The above are just some of the many things that need to be considered on the road of the upgrading to Exchange 2007 - however to conclude this article the following are a number of other commonly overlooked or indeed misunderstood concepts when migrating: - Store Based Anti Virus Programs are not updated
If your existing Exchange 2003 servers make use of VSAPI based checkers (for example McAfee Group Shield, GFI or Norton) you will almost certainly need to upgrade them for Exchange 2007 - this might represent additional costs for your migration if you do not have Framework licensing for your products.
- Backup Tools and Agents
Significant changes have been made to Exchange 2007 at the store level to allow for both streaming (being depreciated and not in Windows 2008) and VSS based backups. You should check that your existing backup product supports Exchange 2007 - and if you have installed Exchange on Windows 2008 you will need to upgrade your backup so that is knows that Streaming has been removed and VSS is the primary backup system.
- Archival Products
If you make use of a commercial Compliance product such as Enterprise Vault you will need to ensure that it supports Exchange 2007 - and also that any integration features (for example with OWA) are also fully supported.
- Windows 2008
Many people whom are embarking on Exchange 2007 SP 1 migrations will almost certainly be tempted to use Windows 2008 as their Operating System platform (and so they should) - however remember that Windows 2008 is a pretty large departure from Windows 2003 (certainly in terms of IIS and clustering). You should also consider any product that uses an Agent to communicate with Exchange (for example Enterprise Vault) is supported on the Operating System.
- Depreciated Support for MAPI and CDO 1.2.1 and ASP Database based applications
MAPI / CDO is no longer supplied as part of the default Exchange 2007 install - therefore you should note that if you have an application which resides on your Exchange servers which makes use of CDO it may cease to function - you can download the components from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=E17E7F31-079A-43A9-BFF2-0A110307611E&displaylang=en.
Additionally if you make use of a ASP based solution which communicates with a Database you need to know that it could experience issues on a x64 platform (you will need to check that there is x64 ODBC driver support).
- Remember your Accounts Team
For larger organisations it is possible that you have a dedicated accounts management team. Exchange 2007 re-adopted the Exchange 5.5 administrator model whereby accounts can be created in Active Directory Users and Computers - however the mailboxes need to be created via the Exchange Management Console or Indeed the Exchange management shell.
Again like Exchange 5.5 from the Exchange 2007 Management tools you CAN create both the Active Directory account and the Mailbox - however if you need to add the user to groups and configure Terminal Services profile settings for example you will need to go back to ADUC to finish the job.
What I recommend is that you get your Accounts People to work with the account in ADUC and then supply them with a Powershell script which will configure the mailbox settings as required - all they will then need is a copy of the Exchange Management Tools and Powershell on the machine with the required permissions.
- Consider your permissions model
Linked to the above you should give careful thought to the permissions and roles that you assign to people - there is a good article here which will provide you with help in making these choices: http://technet.microsoft.com/en-us/library/aa996881(EXCHG.80).aspx
- SSL, the Client Access Server and the Auto Discover Service
If you look at the Exchange server forums which litter the Internet you will find hundreds of posts which deal with the above. The AutoDiscover service is perhaps one of the most complex things to get to the bottom of (as it is linked very closely with correctly configuring SSL, the configuration of Outlook 2007 clients).
Before you deploy users to your 2007 organisation ensure that you FULLY understand Auto Discover and SSL on CAS servers - the following are some very good links which will help:
Whitepaper - Exchange 2007 Autodiscover Service
Exchange Genie - Exchange 2007 Autodiscover Service Part 1
- Exchange Analysis Tools
If you make use of any Exchange Analysis or Monitoring tools (for example Mailscape, OmniAnalyser, MOM 2005) ensure that they are compatible with Exchange 2007 - and upgrade them if they are not. Well I think that I have rambled enough for this particular article - and I hope that it has given you some good pointers and food for thought before you embark upon your own personal migrations. Labels: Exchange 2007, Exchange Migration, Exchange Support, Exchange Tips
Anomalies when using the BPA with Exchange 2007 CCR Cluster on Windows 2008
Reproduced with Permission from: http://telnetport25.wordpres.com Like many Exchange Administrators whom have embarked upon a few recent Exchange 2007 migrations and deployments, I have chosen to use Windows 2008 as the host operating system and make use of Exchange 2007 CCR clustering capabilities in my overall system. Although Windows 2008 and Exchange 2007 CCR clusters still make use of the MNS (Majority Node Set) cluster type - there has been significant changes to the underlying management and indeed architecture of the clustering service within Windows 2008. Before I proceed if you are interested in (and I recommend having a look at) the following link: http://www.microsoft.com/downloads/details.aspx?FamilyID=75566F16-627D-4DD3-97CB-83909D3C722B&displaylang=en Essentially it contains a number of word documents that give you a good overview of the changes and possible configurations of clustering within Windows 2008 - I especially recommend the following documents: - Windows Server 2008 Failover Clustering Architecture Overview.doc
- Overview of Failover Clustering with Windows Server 2008.doc
Now that you have had a chance to look over the possible clustering scenarios (or indeed know you cookies already) I can get back to the article - Like many Exchange Architects before I deploy real life users (and to be honest at many stages throughout an Exchange deployment) I will run a Health Check of the entire environment using the Exchange 2007 Best Practices Analyser tool. This is located in the Exchange 2007 Management Console - [ START -> Programs -> Microsoft Exchange Server -> Exchange Management Console ] and then navigating to (within the Console) [ Toolbox -> Exchange Best Practices Analyser ] - another quick tip to launch the Exchange BPA on a Windows 2008 Exchange 2007 server is to [ START -> RUN ] and then type “EXBPA” and click on “OK“ NOTE: It is important to ensure that your copy of the Exchange BPA is using the most current XML definitions supplied by Microsoft. Microsoft updates them frequently with the latest data from their support groups - and indeed corrects “issues” with the BPA via this means. Many of you will already know how to use the BPA and indeed how to execute a “Health Check” but for readers whom are not as familiar it is as follows: Execute the Exchange BPA on one of the Exchange 2007 servers within your environment which contains the CCR cluster(s) (using the method above). When the BPA has loaded (and you have moved past the BPA update screen) you will be asked to either “Select Options for a New Scan” or “Select a Best Practices scan to view” - choose the latter - see below: 
You will then be prompted for a Domain Controller to connect to - enter in the details of a suitable DC and then choose the “Connect to the Active Directory Server“ 
Permissions and network connectivity to your domain controller will be verified when successful you will then be prompted with the “Start a new Best Practices Scan” option - provide a name for your scan - then choose the Exchange servers that you would like evaluated (for the purposes of this article make sure you choose a Windows 2008 based Exchange CCR cluster) and ensure that you have selected “Health Check” option. Verify the speed of your network and then choose the “Start Scanning Option“ The BPA will then go away and verify your Infrastructure. Now when the scan has finished you will be asked to view the report of the Best Practices Scan - confirm this option and you will be presented with a view that looks like the following: 
Now here you should address all issues which appear under the “Critical Issues” view - but for the purposes of this article we are interested in the Results for your CCR clusters which appear under the “All Issues” tab of the report - click on the “All Issues” entry. Here you might find two issues which look like the following: 
When you expand the definitions of the above entries you will see the following: Dedicated Heartbeat Priority: 
The full BPA definition of the above is available here: http://technet.microsoft.com/en-gb/library/aa997088.aspx Quorum log too small:
 The full BPA definition of the above is available here: http://technet.microsoft.com/en-gb/library/aa995830.aspx Now the point of this article is not the usage of the BPA tool itself - but the oddity that produces the above messages. Upon further investigation of the above entries I have found that they either do not exist or indeed are set to the correct values as specified in the articles that have been suggested by the BPA. I have searched many articles on the Internet and have found nothing that can explain as to why these values appear (under Windows 2008 clustering) as issues within the BPA (especially when they are either not needed, do not apply or exist already) so therefore the only conclusion that I could draw from this was that it is a “Feature” within the BPA itself. As this was bugging me I contacted a friend in Microsoft whom confirmed to me that the above is indeed an oversight between versions of Windows 2003 and 2008 of with the current version of the BPA and that they intend to correct it very soon. Therefore if you are running Exchange 2007 SP1 on a Windows 2008 CCR based cluster and are getting the above entries in the BPA Health Check report you can ignore them - but ensure that you update you definitions regularly to allow for the issues to be corrected. Labels: Clustering, EXBPA, Exchange 2007, Windows 2008
|
