Friday, August 26, 2011

Exchange Server 2010 Design and Architecture document for upgrades

Creating a design document and explaining it is important to the customer is an integral part of planning an Exchange 2010 design. We are providing Exchange 2010 design document that you can us an upgrade checklist and you can decide which steps you need to take to have Exchange 2010 design that you and your customer can agree on.

Planning Phase

The planning phase enables the Exchange 2010 design consultant time to shade the detailed picture of what the end state of the upgrade will look like, and also to detail exactly how the network will evolve to this new state. The goal of the project are clear, what is in and what is out are documented, the resources requirement are defined, the timeline for the planning phase and an initial sketch of the risks are anticipated, and the budget is estimated.

Understanding the Existing Environment

Standard questionnaires are helpful to collect data on the different servers that will be affected by the upgrade. Normally, these all questionnaires are sent to the groups that mange the Exchange Server related system in various location as they have the best information on those system, including any issue they might have. First real look at the configuration of the existing hardware and network, if an organization has multiple exchange server in place, third-party add on application, multiple sites, security requirements , and it is essential to help to collect data on the different server that will be affected by the upgrade.

The discovery process typically starts with various interviews with the IT resources who are responsible for the different areas of the network and proceeds with a hands on review of the network configuration. External consultants often give the better result because they have extensive experience with different network setup.

You can check the network performance to assess at the same time to level of performance the end users whether they are accessing email, public folder, calendars from the company or home. This is also a good time getting the performance and bandwidth consumption and it is very important for new environment. You can also compare the previous performance data with new environment.

Existing network security policies might be affected by the upgrade, and should be reviewed. If AD is being implemented, group policies -- which define user and computer configurations and provide the ability to centralize logon scripts and printer access -- can be leveraged.

Anyone using Exchange Server is familiar with the challenges of effectively managing the data that builds up, and in grooming and maintaining these databases. The existing data-base structure should be reviewed at least briefly so the Exchange Server 2010 design consultant understands where the databases reside, how many there are and their respective sizes, and whether regular maintenance has been performed. Serious issues with the database(s) crashing in the past should be covered. Methods of backing up this data should also be reviewed.

Desktop configurations should be reviewed if the upgrade involves an upgrade to the Outlook client. If there are a variety of different desktop configurations, operating systems, and models, the testing phase might need to expand to include these.

Disaster recovery plans or SLAs can be vital to the IT department's ability to meet the needs of the user community, and should be available for review at this time.

Also review the remote and mobile connection to the messaging system; also check the OWA through secure channel (HTTPS)

To understand the messaging infrastructure in place as the foundation on which the upgrade will be built. New information might come to light in this process that will require modifications to the statement of the work document and always review the initial documentation at the end of a phase so that any changes can be fed back into the process, and you can determine if any tests need to be repeated as a result of the changes.

Understanding the Geographic Distribution of Resources

Exist Network diagrams should be reviewed to make sure they are up to date and contain enough information such as server name, roles, applications managed, switches, routers, firewalls, IP address information, gateway and so forth which are fully define the location and function of each device that plays a role in the upgrade. These diagrams can then be modified to show the end state of the project and also critical to these network diagrams is an understanding of not only the bandwidth rating of the connection, but also the average utilization. Connection latency also useful information for outlook 2007 and outlook 2010.

Existing utility servers -- such as bridgehead servers, front-end servers, domain name system (DNS) naming servers, and Dynamic Host Configuration Protocol (DHCP) or Windows Internet Naming Service (WINS) servers -- should be listed in these diagrams as well.

Companies with multiple sites bring added challenges to the table. As much as possible, the same level of information should be gathered on all the sites that will be involved in and affected by the messaging upgrade. Also, a centralized IT environment has different requirements from a distributed management model. It's important to fully understand these aspects of the environment to successfully plan for your upgrade.

If time permits, the number of support personnel in each location should be taken into account, as well as their ability to support the new environment. Some smaller sites might not have dedicated support staff and network monitoring, and management tools, such as System Center Operations Manager or System Center Configuration Manager might be required.

How is directory information replicated between sites, and what domain design is in place? If the company already has Active Directory in place, is a single domain with a simple organizational unit (OU) structure in place, or are there multiple domains with a complex OU structure? Global catalog placement should also be clarified. Did the existing Exchange Server environment span multiple administrative groups? Who managed what functions in each administrative group? Is this administrative model going to change in the new Exchange Server 2010 environment?

The answers to these questions directly shape the design of the solution, the testing phase, and the implementations process. Each decision made in the planning phase needs to support the orginal goals and object. When in doubt, always return to these goals and ask yourself if a particular decision is in line with those goals.

Planning Phase: Creating the Design Document

When the initial discovery work is complete, you can turn your attention to the Design document itself, which paints a detailed picture of the end state of the messaging system upgrade. In essence, this document expands on the Statement of Work document and summarizes the process that was followed and the decisions that were made along the way. When possible, include a little information on what the options were and why a particular decision was made. This helps other people to understand why decisions were made if they were not directly involved in the design process.

The second key deliverable in the planning phase is the Migration document, which tells the story of how the end state will be reached. Typically, these documents are separate, because the Design document gives the "what" and "why" information, and the Migration document gives the "how" and "when" information. This is a good example of writing documents slightly differently based on who the audience will be.

Collaboration Sessions: Making the Design Decisions

Just as the planning phase kicked off with discovery efforts and review of the networking environment, the design phase will start with more meetings with the stakeholders and the project team for collaborative design discussions. This process covers the new features that Exchange Server 2010 offers and how these could be beneficial to the organization as a whole and to specific departments or key users in support of the already defined goals.

The specifics of the upgrade should be discussed in depth, especially the role that each server will play in the upgrade. A diagram is typically created during this process (or an existing Visio diagram updated) that defines the locations and roles of all Exchange Server 2010 servers and any legacy Exchange servers that need to be kept in place. This includes plans for the number of mailbox servers, the number of client access servers needed to support the remote users, the placement of Edge Transport servers to allow for redundancy, and the placement of Hub Transport servers to ensure that mail can be routed efficiently.

The migration process should be discussed as well because it is likely to have the largest impact on the end users. This is the time to account for overlapping projects that might impact your Exchange Server 2010 rollout. Also pay careful attention to the availability of the resources you defined previously.

Disaster Recovery Options

Although a full disaster recovery assessment is most likely out of the scope of the messaging upgrade project, the topic should be covered at this phase in the project. Take this opportunity to review your existing disaster recovery plans for your existing environment and think about how it will need to change with the new design.

Most people would agree that the average organization would be severely affected if the messaging environment were to go offline for an extended period of time. Communications between employees would have to be in person or over the phone, document sharing would be more complex, communication with clients would be affected, and productivity of the remote workforce would suffer. Employees in the field rarely carry pagers any more, and some have even discarded their cell phones, so many employees would be hard to reach. This dependence on messaging makes it critical to adequately cover the topic of disaster recovery as it pertains to the Exchange Server messaging environment.

Existing SLAs should be reviewed and input gathered on the "real" level of disaster recovery planning and testing that has been completed. Few companies have spent the necessary time and energy to create plans of action for the different failures that could take place, such as power failures in one or more locations, Exchange Server database corruptions, or server failures. A complete disaster recovery plan should include offsite data and application access as well.

Design Document Structure

The Design document expands on the content created for the Statement of Work document defined previously, but goes into greater detail and provides historical information on the decisions that were made.

The following is a sample table of contents for the Exchange Server 2010 Design document:

Executive Summary

Goals and Objectives

Business Objectives

Departmental Goals


Overview of Process

Summary of Discovery Process

Exchange Server Design

Exchange Server 2010 Design Diagram

Exchange Mailbox Server Placement

Exchange Mailbox Replication

Exchange Client Access Server Placement

Exchange Edge Transport Server Placement

Exchange Hub Transport Server Placement

Exchange Unified Messaging Server Placement

Organization (definition of and number of Exchange Server organizations)

Mailbox Databases (definition of and number of)

Mixed Mode Versus Native Mode (choice and decision)

Global Catalog Placement (definition and placement)

Recipient Policies (definition and usage)

Server Specifications (recommendations and decisions, role for each server defined, redundancy, disaster recovery options discussed)

Virus Protection (selected product with configuration)

Administrative Model (options defined, and decisions made for level of admin)

System Policies (definition and decisions on which policies will be used)

Exchange Monitoring (product selection and features described)

Exchange Backup/Recovery (product selection and features described)

Budget Estimate

Hardware and Software Estimate

Some organizations choose to use the Design document to get competitive proposals from service providers, and having this information levels the playing field and results in proposals that promise the same end results.

For deep dive:

Orphaned Offline Address Book Recovery Process in Exchange 2010

In Exchange 2010, the generating server for your Offline Address Books (OAB) can change, under certain conditions, without any admin intervention. The process described here happens only on Exchange 2010.

An Offline Address Book (OAB) is a collection of address lists downloaded by Microsoft Outlook so users can access recipient information and select/resolve recipients when composing messages offline or in Cached Exchange Mode. Offline address book generation (OABGen) is the process by which Exchange creates and updates the OAB. OAB generation occurs during the scheduled time – daily between 5:00-5:15 AM by default. You can customize the schedule and specify the originating Mailbox server for each OAB. The originating Exchange server generates new OAB files, compresses the files and then places them on a local share for web distribution. See Understanding Offline Address Books for more details.

Orphaned OAB Recovery is part of OAB maintenance; the goal is to recover orphaned offline address books. Orphaned is defined as "at least 25 hours overdue for an update". This is calculated based on the LastTouchedTime and Schedule properties of the OAB.

A single Exchange 2010 Mailbox server is selected in the organization to perform the Orphaned OAB Recovery task, and all Exchange 2010 Mailbox servers know the selected server using the same algorithm:

All Exchange 2010 mailbox servers will log event ID 2001 in the Application event log, indicating that evaluation of OAB recovery has taken place:

Log Name: Application
Source: MSExchange OAB Maintenance
Event ID: 2001
Task Category: Orphaned OAB Recovery
Level: Information

The server responsible for performing the OAB recovery scan is .
Event ID 2002 is logged on all Exchange 2010 Mailbox servers that are not selected to do OAB recovery:

Log Name: Application
Source: MSExchange OAB Maintenance
Event ID: 2002
Task Category: Orphaned OAB Recovery
Level: Information
Because this server is not the one responsible for performing the OAB recovery scan, the task is exiting.
Events 2003 and 2004 are loggedOn the Exchange 2010 Mailbox server that is selected to perform OAB recovery:

Log Name: Application
Source: MSExchange OAB Maintenance
Event ID: 2003
Task Category: Orphaned OAB Recovery
Level: Information
 Orphaned OAB recovery scan has begun.

Log Name: Application
Source: MSExchange OAB Maintenance
Event ID: 2004
Task Category: Orphaned OAB Recovery
Level: Information

Orphaned OAB recovery scan has been completed.

Event ID 2005 is generated on selected server if no orphaned offline address books are detected:
Log Name: Application
Source: MSExchange OAB Maintenance
Event ID: 2005
Task Category: Orphaned OAB Recovery
Level: Information

No orphaned offline address books were found.

Event ID 2006 is generated on the selected Mailbox server when an orphaned OAB has been detected:
Log Name: Application
Source: MSExchange OAB Maintenance
Event ID: 2006
Task Category: Orphaned OAB Recovery
Level: Warning


orphaned offline address books were found. The OAB Maintenance Servicelet will attempt to move these offline address books to functioning servers.
 Then Recover Orphaned OAB Process is executed on the selected server and event ID 2007 is logged for each orphaned OAB detected:

Log Name: Application
Source: MSExchange OAB Maintenance
Event ID: 2007
Task Category: Orphaned OAB Recovery
Level: Information

The offline address book \Default Offline Address Book was successfully moved to server .
Tracking Offline Address Book Moves
To move the orphaned OAB to the selected Mailbox server, the process executes a Move-OfflineAddressBook command for each orphaned OAB using the system account [NT AUTHORITY\SYSTEM (Microsoft.Exchange.ServiceHost)"].

Note: You can also use the cmdlet to manually move the OAB generation process to another Mailbox server.
This command searches the admin audit log for all such moves between 1/5/2011 and 5/5/2011:

Search-AdminAuditLog -StartDate 01/05/2011 -EndDate 05/05/2011 -Cmdlets Move-OfflineAddressBook
RunspaceId : 34b7d8a3-5c29-4b94-9d9a-143b84a02416
ObjectModified : \ Default Offline Address Book
CmdletName : Move-OfflineAddressBook
CmdletParameters : {Identity, DomainController}
ModifiedProperties : {Server, LastTouchedTime}
Caller : NT AUTHORITY\SYSTEM (Microsoft.Exchange.ServiceHost)
Succeeded : True
Error : None
RunDate : 23/04/2011 13:21:00
OriginatingServer : (14.xx.xxxx.xx)
IsValid : True
Caller is "NT AUTHORITY\SYSTEM (Microsoft.Exchange.ServiceHost)"

In Exchange 2010, the Offline Address Book generating server can be changed with no admin action if specific OAB is deemed orphaned. Event ID 2006 [MSExchange OAB Maintenance] needs to be monitored.

Event ID 2007 [Source: MSExchange OAB Maintenance] will give us the information about what has changed as part of this process.

You can find the OAB recovery server by using the following steps:
Restart “Microsoft Exchange Service Host” service on one of mailbox servers

Check event ID 2001 logged by MSExchange OAB Maintenance in the Application event log:
Log Name: Application
Source: MSExchange OAB Maintenance
Event ID: 2001
Task Category: Orphaned OAB Recovery
Level: Information


The server responsible for performing the OAB recovery scan is .

Thursday, August 25, 2011

Exchange Server and Update Rollups Builds Numbers

Now you can track Exchange Server and Update Rolups Builds

you with a central resource for build numbers and release dates for versions of Microsoft Exchange. You can use the information in this topic to verify the version of Exchange that is running in your organization

Details are below:

Exchange Server 2010 Service Pack 2 (SP2)

Microsoft announces that in the second half of calendar year 2011 to be releasing Exchange Server 2010 Service Pack 2 (SP2). With SP2, the following new features and capabilities will be included:

1. Outlook Web App (OWA) Mini

2. Cross-Site Silent Redirection for Outlook Web App

3. Hybrid Configuration Wizard

4. Address Book Policies

5. Customer Requested Fixes

Details on “The Exchange Team Blog:

Update Rollup 5 For Exchange 2010 SP1 Released

Update Rollup 5 For Exchange 2010 SP1 Released…

Microsoft has released update rollup 5 for Exchange 2010 SP1, as promised by end of August.

Download the rollup here

Availability of this update on Microsoft Update is planned for late September. Update Rollup 6 for Exchange Server 2010 Service Pack 1 is currently scheduled to release in October 2011.

As always, disable forefront (fscutility /disable) before running the update rollup and enable it (fscutility /enable) afterwards. Otherwise, Microsoft Information Store and Transport service will not start after applying the rollup.