Migrating from Exchange 2007 to Exchange 2010

In my last blog post I covered the migration process from Exchange 2003 to Exchange 2010. In this post, I’m going to outline the sequence and provide tips, tricks, and best practices to look forward to in the migration process from Exchange 2007 to Exchange 2010.

Since Exchange 2010 is similar if not almost identical to Exchange 2007 in terms of server roles (CAS, Hub Transport, Mailbox, Edge), if you implemented Exchange 2007 in a manner that suits the needs of your organization, then your transition to Exchange 2010 will be pretty straight forward. Effectively, you would add Exchange 2010 server roles to mirror the Exchange 2007 server roles you have today (ie: if you have 2 CAS/2007 servers today, you’d likely build up 2 CAS/2010 servers in the Exchange 2010 environment, etc).

The sequence for a migration from Exchange 2007 to Exchange 2010 is as follows:

1. Upgrade all Exchange Servers to Exchange Server 2007 Service Pack 2.

2. Bring the AD forest and domains to Windows Server 2003 Functional (or higher) levels.

3. Upgrade at least one Global Catalog domain controller in each AD Site that will house Exchange Server to Windows Server 2003 SP2 or greater.

4. Prepare a Windows Server 2008 (RTM or R2) x64 edition server for the first Exchange 2010 server.

5. Install the AD LDIFDE tools on the new Exchange 2010 server (to upgrade the schema).

6. Install any necessary prerequisites (WWW for CAS server role).

7. Run setup on the Exchange 2010 server, upgrade the schema, and prepare the forest and domains. (Setup runs all in one step or separate at the command line.)

8. Install CAS server role servers and configure per 2010 design. Validate function-ality.

9. Transfer OWA, ActiveSync, and Outlook Anywhere traffic to new CAS servers.

10. Install Hub Transport role and configure per 2010 design.

11. Transfer inbound and outbound mail traffic to the 2010 HT servers.

12. Install Mailbox servers and configure Databases (DAG if needed).

13. Create public folder replicas on Exchange 2010 servers using AddReplicatoPFRe-cursive.ps1or Exchange 2010 Public Folder tool.

14. Move mailboxes to Exchange 2010 using Move Mailbox Wizard or Powershell.

15. Rehome the Offline Address Book (OAB) generation server to Exchange Server 2010.

16. Transfer all Public Folder Replicas to Exchange Server 2010 Public folder store(s).

17. Delete Public and Private Information Stores from Exchange 2007 server(s).

18. Uninstall all Exchange 2007 servers.

One of the areas of change that you’ll make with your transition to Exchange 2010 that is different than in your Exchange 2007 implementation is the high availability and disaster recovery functions of your Mailbox server role. Because the concepts of Single Copy Clusters, Cluster Continous Replication (CCR), and Standby Continous Replicaton (SCR) no longer exist in Exchange 2010, you’ll be transitioning your mailboxes off of Exchange 2007 that has these functions to Exchange 2010 that users Database Availability Groups (DAGs). Of course if you are just migrating to a single Exchange 2010 Mailbox server with no high availability or disaster recovery, then you will just have mailbox databases that you’ll be moving your mailboxes to. However for organizations implementing high availability and disaster recovery, the DAGs provide replication of mail (of up 16 copies) from server to server. When you setup your Exchange 2010 Mailbox servers to prepare them for the transition of mailboxes, setup your DAG replication and test your failover and failback of Exchange 2010 Mailbox servers, and then move your mailboxes to the DAG(s).

Another area of change between Exchange 2007 and Exchange 2010 is that ALL client connections go through the CAS server(s). Unlike Exchange 2007 and prior where OWA connections went through the CAS server but Outlook (2003/2007) connections actually communicated directly over MAPI to the backend Mailbox servers. However with Exchange 2010, client systems no longer communicate directly to the backend Mailbox servers. Instead, the client MAPI connections hit the CAS server(s) that then communicate with the Mailbox servers on the backend. So just like in the shift to Hub Transport servers in Exchange 2007 where all mail routes through the Hub Transport servers (incoming mail, outgoing mail, user to user mail between servers, and even user to user mail between users on the same server), with Exchange 2010, all clients go through the CAS server(s). As such, the CAS servers take on more of a performance load and need to be beefed up a little. Our recommendations for CAS to Mailbox in Exchange 2007 was 1 CAS servers for every 2 Mailbox servers. For Exchange 2010, our recommendation is now 3 CAS servers for every 4 Mailbox servers. Most organizations have at least 2 CAS servers in their environment for redundancy, and because you can virtualize the CAS role plus have 2000, 3000, even 5000 mailboxes on a single Mailbox server, we typically find this 3:4 CAS:MBX ratio hasn’t been a showstopper for organizations in terms of a design change.

Also important to note is that all 2007 server roles (CAS, Hub Transport, Mailbox) in Exchange 2007 need to remain until all users are migrated to Exchange 2010.  Exchange 2010 CAS, Hub Transport, and Mailbox servers are not backwards compatible with Exchange 2007, so in order for a user to access Outlook Web Access on Exchange 2007, they need to still hit the Exchange 2007 CAS servers to access their mailbox on the Exchange 2007 Mailbox server.  After their mailbox is migrated to Exchange 2010, then the user will hit the Exchange 2010 CAS server and access their mailbox on the Exchange 2010 Mailbox server.  Because Exchange 2010 has a proxy service on the CAS server, your external URL for OWA can point to the Exchange 2010 CAS server and if the user’s mailbox is still on Exchange 2007, the CAS/2010 server will automatically redirect the client connection to the CAS/2007 server for OWA.

Lastly, after moving mailboxes off of Exchange 2007 to Exchange 2010, leave the Exchange 2007 infrastructure in place for a couple (2) weeks.  By leaving the old Exchange 2007 server(s) in place, when an Outlook client tries to connect to the old Exchange 2007 server for its mail, the old Exchange 2007 server will notify the Outlook client software that the user’s mail has been moved to the Exchange 2010 server and will automatically update the user’s Outlook profile with the new destination server information.  Thereafter, when the Outlook client is launched, Outlook will access the user’s mailbox on the new Exchange 2010 server.  By leaving the old Exchange 2007 infrastructure in place for a couple weeks, pretty much all of your users will launch Outlook to have the profile automatically changed thus requiring no client system intervention during the migration process.  The only users you will likely need to manually reset their Outlook profile are users who are on extended leave and had not accessed their Outlook mail during the 2 week time that you had the Exchange 2007 environment still in place.

Hopefully these steps are helping in providing you guidance in your migration from Exchange 2007 to Exchange 2010.  I cover the migration process in much more detail (including specific steps and step by step processes for cutting over CAS, Hub Transport, and Mailbox server roles) in my book “Exchange 2010 Unleashed” from Sams Publishing.  The book was written from 2-yrs of early adopter experience working with Exchange 2010 and will hopefully provide more detailed guidance on the migration process from Exchange 2007 to Exchange 2010.

I’ve been ask to blog information about the new Hub Transport “Shadow Redundancy” process that provides fault tolerance to the routing of mail through Hub Transport servers, as well as I’ve been asked to blog about the new Exchange 2010 Unified Messaging (voicemail), so I’ll put together my thoughts on those areas upcoming…

Continue Reading »

Password Reset Feature in Exchange 2007 and 2010

In many organizations, creating new mailbox enabled users includes checking the "User must change password at next logon" box on the account. From a security perspective, that makes sound sense. However, if the user is a mobile user and only signs in to OWA, this has been a problem, as checking the box would prevent the user from being able to log in the first time. The same problem exists if a user's password expires before they change it. The resolution is a call to the Help Desk to have the account unlocked.

Microsoft recently added a feature that helps aleviate this issue. When enabled, users are allowed to change their password and then login - thus eliminating the call to the Help Desk.

In Exchange 2007, the feature was added in SP3, while in Exchange 2010, it was added inSP1. One important note is that the feature only works in Exchange servers running on Windows 2008 or later.

Enabling the feature is very easy, and takes only a minute. For either version of Exchange, go to the server(s) holding the Client Access Server role and open regedit.

Navigate toHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange OWA

Create a new DWORD (32-bit) value called ChangeExpiredPasswordEnabled

Assign the new DWORD a value of 1 as shown below.

Note: If the ChangeExpiredPasswordEnable registry key already exists, set its value to 1. Any value other than 1 will disable the feature.

Restart IIS by opening a cmd prompt and typing IISRESET /NOFORCE.

Repeat this process for all Client Access Servers. Once finished, when a user logs in with an expired password, they are prompted with a new screen as shown in both Exchange 2007 (left) and Exchange 2010 (right) below:

Once the user enters a valid new password, they are shown the following screen:

Once the user clicks on "OK", they are prompted to login with their new password. Enjoy!

Continue Reading »

Exchange 2007 mailbox size script V5

Maybe some of you now, Glen Scales has made a PowerShell script to view the mailbox sizes in an Exchange 2007 environment. You can download this script at his blog Script.

It’s a great script, to overview the current mailboxsizes, items, growth history, quota used. Watch the screenshot below, to see the great script of scripting guru Glen

Continue Reading »

ExInsight, free monitoring and statistics tool

ExInsight is a free monitoring and statistics tool for Exchange 2000/2003/2007 that provides a real-time view of the internals of Exchange Server transactions and allows you to evaluate individual user’s usage of Exchange Server.

This tool is especially useful for Exchange administrators and developers. By using this tool, you can gather real-time data about the users in an Exchange environment and learn more about the inner workings of MAPI, OWA, POP3, IMAP4, NNTP and other protocols.

ExInsight helps you to understand how individual users affect the performance of an Exchange Server, analyze application usage of Microsoft Exchange, and guide troubleshooting of applications that depend on Microsoft Exchange.

ExInsight consists of two tools: Activity Statistics and Transaction Monitor . These tools allow you to monitor users’ activity on multiple Exchange servers from any computer in the network.

Activity Statistics

This tool enables administrators to view statistics about individual users’ consumptions of Exchange Server resources and the users’ actual experiences. Shown on a user-by-user basis, this tool allows you to see the following information:

- Protocols used by the clients (MAPI, OWA, POP3, IMAP or NNTP)
- CPU usage (CPU time, CPU percentage)
- Number of messages sent, received or created
- IP addresses used by the clients (only for MAPI clients)
- Microsoft Office Outlook versions and mode, such as Cached Exchange Mode and the classic online mode

Transaction Monitor

This tool displays a continuous communication between any computer and Exchange Server, helping to guide troubleshooting of applications that depend on Exchange. You can view and log every Exchange Server transaction, applying filters and highlighting to pinpoint trouble areas.

Transaction Monitor shows accounts requesting the data, the names and locations of the objects queried in Exchange, timings and transaction results. This tool also provides simplified summaries and links with detailed diagnostic information for each transaction.

Continue Reading »

Exchange 2007 create new Storage Groups with Mailbox Database

After a default Exchange 2007 SP1 installation, there is one Storage Group with one Mailbox Database available and mounted. You have to change the logfile path and database path manually. If you use the following script, you can create one, two, three, four (or more) Storage Groups and Databases fully automatic. Let’s say you’ve installed a new Exchagne 2007 server with three partitions.

————————————————
# This script creates two storage groups named SG1 and SG2, with mailbox stores MB1 and MB2, and finally mounts them.
# C: – Operating System
# D: – Exchange Logfiles/Systemfiles
# E: – Exchange Databases

# Environment variables
$server = “srv-ex01″
$logfilepath = “D:\Log”
$mbxfilepath = “E:\Database”

# Creating the Storage Groups and Mailbox Stores
foreach (
$i in (1,2,3,4)
){
new-storagegroup -name SG$i -server $server -logfolderpath “$logfilepath\SG$i” -systemfolderpath “$logfilepath\SG$i”
}
foreach (
$i in (1,2,3,4)
){
new-mailboxdatabase -storagegroup $server\SG$i -name MB$i -edbfilepath “$mbxfilepath\MB$i\MB$i.edb”
mount-database MB$i
}
————————————————

Continue Reading »

Managing the Event Viewer with PowerShell

An easy way to manage your windows event viewer is to use PowerShell. With some simple commands you can open all the events. Let’s have a look on that….

Get-EventLog *
(gives an overview of all the available event sources)

Get-EventLog -LogName”DNS Server”
(gives all the event logs in the DNS server log)

Get-EventLog -LogName “DNS Server” -Newest 10
(gives the newest 10 event logs in the DNS server log)

When you put the following commands into a PS1 file and schedule it on a specific server, you’ll receive the event logs in an e-mail!
(in this example you’ll receive an e-mail from eventviewer@e2k10.local with the 10 newest event logs)

—————————————————————————
$body = Get-EventLog -LogName “dns server” -Newest 10 | out-string
$From = “eventviewer@e2k10.local”
$to = “administrator@e2k10.local”
$server = “srv-exc2010.e2k10.local”
$subject = “Event Viewer – srv-exc2010.e2k10.local”
$msg = new-object System.Net.Mail.MailMessage $From, $to, $subject, $body
$client = new-object System.Net.Mail.SmtpClient $Server
$Client.Send($msg)
—————————————————————————

Continue Reading »

How to: Hide Address Lists in Exchange 2010

When you have a Exchange 2010 (or 2007) environment and you have multiple Address Lists in your Exchange environment, there are maybe some users who don’t have to see all the available Address Lists.

You can fix this issueu to put some permissions on this Address Lists. Let’s have a look on that.

1.) Open the Exchange Management Console
2.) Create a new Address List
3.) Give up the filter settings (in this example it is based on the Active Directory field “Department“)
4.) Open ADSI Edit, adsiedit.msc
5.) Open Configuration,CN=Configuration,DC=E2K10.local,CN=Services,CN=E2K10,CN=Address Lists Container,CN=All Address Lists,<your Address Lists>
6.) Open the Properties, and click the Security tab, Advanced
7.) Disable “Include inheritable permissions from this object’s parent”
8.) Click Copy
9.) Remove the Authenticated Users
10.) Make a new Security Group in your Active Directory called for example “AL_ICT_Department”
11.) Place all the users of the ICT department in this Security Group
12.) Open the security settings again and at the group AL_ICT_Department
13.) Give this group the following permissions Read, Open Address List
14.) Login with a user that is member of the AL_ICT_Department. Make sure you see the Address List
15.) Login with a user that is not a member of the AL_ICT_Department. You didn’t see the Address List now.

Continue Reading »

Exchange Server 2007 File Structure

Exchange Server 2007 File Structure

Exchange Database Files:-

• E00.chk checkpoint file marks up to where database has been committed to the database files
• E00.log –the current log file with transactions waiting to be processed.
• E00res00001.jrs
• E00res00002.jrs
• E00000000A.log
• Mailbox Database.edb. EDB file is the one which stores all mailbox database information. The size of this file increases significantly since it stores rich text and attachement. .STM files are no longer in use.
• tmp.edb
• Enn000000000x.log logs that have already been processed (Max log file size is 1 MB, also maximum number of log files has been raised from 1 million to 2 billion)

http://www.techpeoples.net/

The other files are in the locations C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue are specified below:

• Trn.chk - The checkpoint file.
• Trn.log - The current transaction log file.
• Trntmp.log - The next provisioned transaction log file that is created in advance.
• Trnnnn.log - Other transaction log files that are created when Trn.log reaches its maximum size.
• Trnres00001.jrs - The Reserve log file.
• Trnres00002.jrs - The Second Reserve log file.
• Temp.edb – Temp DB used to verify database schema on start-up.

http://www.techpeoples.net/

Requirements of Installing Exchange Server 2007 on Windows Server 2003

Follow below steps to install Exchange Server 2007 on Windows Server 2003

1.       Administrative rights

2.       Window 2003 service pack 1 or later

3.       Install MMC.

4.       Install Net Framework2.0

5.       Power Shell (exchange command based tool….new feature)

6.       Install .Net Framework Update (74469)

7.       IIS

8.       Active Directory (Functional level-Native Mode)

9.       Run Exchange Setup

10.   Install Exchange Server Service Pack

Read more: http://www.articlesbase.com/online-education-articles/exchange-server-2007-file-structure-2300119.html#ixzz1ALRCYOKD
Under Creative Commons License: Attribution

Continue Reading »