Howdy Protectors,

It seems Microsoft has released another couple of updates for our beloved product:

2966012 - Update Rollup 7 for System Center 2012 Data Protection Manager SP1

http://support.microsoft.com/kb/2966012

2966014 - Update Rollup 3 for System Center 2012 R2 Data Protection Manager

http://support.microsoft.com/kb/2966014

Keep Safe!!!

Howdy,

Microsoft has released an important update to resolve some issues experienced when using the Hybrid Configuration Wizard to create  a new or manage an existing hybrid deployment with Microsoft Exchange Server 2013.

In order to know more about this including a FAQ section please follow the below link:

http://blogs.technet.com/b/exchange/archive/2014/07/30/important-update-available-for-exchange-server-2013-hybrid-deployments.aspx

Keep Safe!!!

Another great achievement on the Exchange Universe… Exchange Server 2007 Service Pack 3!!!!

I am very pleased to let you all know that Exchange Server 2007 SP3 is available for download. As we highlighted in Updates to the Exchange Supportability Matrix this past November, this third service pack for Exchange 2007 enables Exchange 2007 to be installed on the Windows Server 2008 R2 version of the operating system. We heard you loud and clear that this is enormously important to our Exchange 2007 customers, so we worked quickly to deliver SP3 in order to meet this requirement.

Download Exchange 2007 SP3 here…

Keep the feedback coming and for those of you evaluating all the good stuff packed into Exchange Server 2010, don't miss the beta of Exchange Server 2010 SP1. You can read about SP1 here…

Kevin Allison
General Manager - Exchange Customer Experience

It was recently published an amazing article about DPM licensing… So many customers come to me asking me all of these questions regarding licensing, and because on my role we don’t deal with that we always end up kind of passing the question to other people in Microsoft…

With this article from the so well known Jason Buffington my life and others is easier now on these tricky subjects…

A small summary is here, however if you want to know the full story please visit Jason’s Article:

If you already have ECAL, then you already have the Client licenses for DPM 2010 and can begin protecting your Windows client machines (and probably not have to renew whatever third-party backup software is currently backing up your workstations).

If you already have the System Center SMSE or SMSD suites, then you can protect your Windows application, file and virtualization servers because you already own Enterprise licenses for DPM. See money saving note above.

And if you are a midsized organization that has been excitedly looking forward to SC Essentials 2010, then you will soon be able to purchase the SC Essentials Plus suites for both your clients and your servers.

I hope this was helpful…

A database availability group (DAG) is a set of up to 16 Exchange Server 2010 Mailbox servers that provide automatic database-level recovery from a database, server, or network failure.  DAGs use continuous replication and a subset of Microsoft Windows failover clustering technologies to provide continuous mailbox availability.  Mailbox servers in a DAG monitor each other for failures.  When a Mailbox server is added to a DAG, it works with the other servers in the DAG to provide automatic, database-level recovery from database failures.

When we create a DAG, it will initially be empty, and a directory object is created in Active Directory Domain Services (AD DS) that represents the DAG.  The directory object is used to store relevant information about the DAG, such as server membership information.  When an administrator adds the first server to a DAG, a failover cluster is automatically created for the DAG.  In addition, the infrastructure that monitors the servers for network or server failures is initiated.  The failover cluster heartbeat mechanism and cluster database are then used to track and manage information about the DAG that can change quickly, such as database mount status, replication status, and last mounted location.

Database Availability Group Design & Cluster Continuous Replication Design

Exchange Server 2010 uses the same continuous replication technology found in Exchange Server 2007.  However, Exchange Server 2010 combines on-site data replication (CCR) and off-site data replication (SCR) into a single Structure known as a DAG.  Once servers have been added to a DAG, administrators can add replicated database copies (up to 16 in total), and Exchange Server 2010 switches between these copies automatically, as needed, to maintain availability.

This new high availability architecture also provides simplified recovery from a variety of failures (disk-level, server-level, and datacenter-level), and it can be deployed on a variety of storage types.

Architectural Changes to Continuous Replication from Exchange Server 2007

Exchange Server 2007 introduced a built-in data replication technology called continuous replication.  Continuous replication, which was available in three forms: LCR, CCR, and SCR, significantly reduced the cost of deploying a highly available Exchange infrastructure, and provided a much improved deployment and management experience over previous versions of Exchange.  Even with these cost savings and improvements, however, running a highly available Exchange Server 2007 infrastructure still required a great deal of time and expertise because the integration between Exchange and Windows failover clustering was not seamless.  In addition, customers wanted an easier way to replicate their e-mail data to a remote location, in order protect their Exchange environment against site-level disasters.

Unlike Exchange Server 2007, where clustered mailbox servers required dedicated hardware, Mailbox servers in a DAG can host other Exchange roles (Client Access, Hub Transport, Unified Messaging ), providing full redundancy of Exchange services and data with just two servers.

The underlying continuous replication technology previously found in CCR and SCR remains in Exchange Server 2010 and it has been further developed to support new high availability features such as database copies, database mobility, and database availability groups.  Some of these new architectural changes are briefly described below:

• Since storage groups have been removed from Exchange Server 2010, continuous replication now operates at the database level.  Exchange Server 2010 still uses an Extensible Storage Engine (ESE) database that produces transaction logs which are replicated to one or more other locations and replayed into one or more copies of a mailbox database.
• Log shipping and seeding no longer uses Server Message Block (SMB) for data transfer.  Exchange Server 2010 continuous replication uses a single administrator-defined TCP port for data transfer.  In addition, Exchange Server 2010 includes built-in options for network encryption and compression for the data stream.
• Database copies are for mailbox databases only.  For redundancy and high availability of public folder databases, we recommend that you use public folder replication.  Unlike CCR, where multiple copies of a public folder database could not exist in the same cluster, you can use public folder replication to replicate public folder databases between servers in a DAG.

Several concepts used in Exchange Server 2007 continuous replication also remain in Exchange Server 2010 .These include the concepts of failover management, divergence, the use of the auto database mount dial, and the use of replication and client access networks.

The Role of the Cluster Service in Exchange Server 2010

Exchange Server 2010 includes a new Active Manager component that provides functionality that replaces the resource model and failover management features provided by integration with the Cluster service in older versions of Exchange.  Exchange no longer uses the cluster resource model for high availability.  All Exchange cluster resources provided by exres.dll no longer exist, including the construct known as a clustered mailbox server.  A failover cluster is used by Exchange, but there are no cluster groups for Exchange, and there are no storage resources in the cluster.  Thus, if you examine the cluster using cluster management tools, you will see only the core cluster resources (Internet Protocol address and network name, and if needed, file share witness resource).  Cluster nodes and networks will also exist, but those are managed by Exchange and not cluster or cluster tools.

Active Manager runs on all Mailbox servers that are members of a DAG.  There are two Active Manager Roles: primary active manager (PAM) and standby active manager (SAM).  PAM is the Active Manager in a DAG that decides which copies will be active and passive.  PAM is responsible for getting topology change notifications and reacting to server failures.  The DAG member that holds the PAM role is always the member that currently owns the cluster quorum resource (default cluster group).  If the server that owns the cluster quorum resource fails, the PAM role automatically moves to a surviving server that takes ownership of the cluster quorum resource.  In addition, if you need to take the server that hosts the cluster quorum resource offline for maintenance or an upgrade, you must first move the PAM to another server in the DAG.  The PAM controls all movement of the active designations between a database’s copies (only one copy can be active at any given time, and that copy may be mounted or dismounted).  The PAM also performs the functions of the SAM role on the local system (detecting local database and local information store failures).

The SAM provides information on which server hosts the active copy of a mailbox database to other components of Exchange (e.g. remote procedure call RPC, Client Access service or Hub Transport).  The SAM detects failures of local databases and the local information store.  It reacts to failures by asking the PAM to initiate a failover (if the database is replicated).  A SAM does not determine the target of failover, nor does it update a database’s location state in the PAM.  It will access the active database copy location state to answer queries for the active copy of the database that it receives.

Active Manager (AM)

Active Manager (AM) manages the live relationship between mailbox databases and the Mailbox servers that have replicated copies of the databases. 

The AM has the following functionality:

Mount and dismount databases, Provide database availability information, Provide interface for administrative tasks, Monitor for failure and Maintain database and server state information.

Active Manager Roles

At any given point of time, AM assumes one of the following roles.

• Standalone – On a Mailbox server that is not part of a DAG, the role is always Standalone.  This role can only change if the server is added to a DAG.
• Secondary Active Manager (SAM) – When a Mailbox server is a member of a DAG but does not currently host the default cluster group for the DAG, the assumed role is SAM.  The server can assume the PAM role only if it becomes the host of the default cluster group.
• Primary Active Manager (PAM) – When a Mailbox server is a member of a DAG and currently hosts the default cluster group for the DAG, the assumed role is PAM.  The server can relinquish the PAM role and become a SAM if the default cluster group is moved to another server in the DAG.

The PAM role holder is responsible for making all decisions that affect database availability in a DAG.  Only one AM can operate as the PAM role holder at a time.  All other servers in the DAG operate as SAM role holders until conditions change.

Creating Database Availability Groups

A DAG can be created using the New Database Availability Group wizard in the Exchange Management Console, or by running the New-DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell. 

When you create a DAG, an empty object representing the DAG with the name you specified and an object class of msExchMDBAvailabilityGroup is created in AD DS.

After a DAG has been created, you can add server to or remove servers from the DAG by using the Manage Database Availability Group wizard in the Exchange Management Console, or by using the Add-DatabaseAvailabilityGroupServer or the Remove-DatabaseAvailabilityGroupServer cmdlets in the Exchange Management Shell.

If the Mailbox server being added to a DAG is running Microsoft Windows Server 2008 and does not have the failover clustering component installed, then you must run the Add-DatabaseAvailabilityGroupServer cmdlet or use the Manage Database Availability Group wizard locally on the server being added.  This is because the failover clustering component is installed on the Mailbox server when it is added to a DAG, and there is no way to install failover clustering remotely.

When the first Mailbox server is added to a DAG, the following occurs:

• The failover clustering component is installed, if it is not already installed.
• A failover cluster is created using the name of the DAG.
• A cluster network object (CNO) is created in the built-in computers organizational unit (OU).
• An IP address is assigned to the DAG.  This is done by using the DatabaseAvailablityGroupIpAddresses parameter of the Add-DatabaseAvailabilityGroupServer cmdlet or by omitting this parameter and allowing the DAG to obtain an IP address by using a Dynamic Host Configuration Protocol (DHCP) server on your network.
• The name and IP address of the DAG is registered as a Host (A) record in Domain Name System (DNS).

DAGs use a subset of failover cluster technologies, namely, the cluster heartbeat, cluster networks, and the cluster database (for storing data that changes or can change quickly, such as database state changes from active to passive or vice versa, or from mounted to dismounted and vice versa).

When creating a DAG, you will need to specify a name for the DAG no longer than 15 characters that is unique within the AD DS forest.  In addition, you will also need to provide a file share witness and witness directory for use by the DAG.  You do not need to create the directory ahead of time.  Exchange will automatically create and secure the directory for you on the file share witness you specify.  The directory should not be used for any purpose other than for the DAG witness.

The requirements for the file share witness are as follows:

• The file share witness cannot be a member of the DAG.
• The file share witness must be in the same forest as the DAG.
• The file share witness must be running Windows Server 2003 or Windows Server 2008.
• A single server can serve as a witness for multiple DAGs; however, each DAG requires its own directory.

We recommend that you use a Hub Transport server in the AD DS site containing the DAG.  This allows the file share witness and directory to remain under the control of an Exchange administrator.

When a DAG is formed, the failover cluster that is created will initially use the Node Majority quorum mode.  When the second Mailbox server is added to the DAG, the cluster quorum is automatically changes to the Node and File Share Majority quorum model.  When this change occurs, the DAG will begin using the specified Universal Naming Convention (UNC) path and directory for the cluster quorum.  If the witness directory does not exist, Exchange will automatically create it, and provision it with full control permissions for local administrators and the CNO computer account for the DAG.

Managing Database Availability Group Membership

When a server is added to a DAG, it works with the other servers in the DAG to provide automatic, database-level recovery from database, server, or network failures.  When a server is removed from a DAG, it is no longer automatically protected from failures. 

Before performing either procedure below, you must first verify that:

• A DAG has been created. 
• Because DAGs use failover clustering technology, all servers added to a DAG must be running Windows Server 2008 Enterprise or Windows Server 2008 Datacenter.
• All servers being added to the DAG must have at least two network interface cards.  Each network interface card must be on a different subnet.
• If the Windows Failover Clustering feature is not installed on the server being added to a DAG, then the following procedures cannot be performed remotely and must be performed locally on the Mailbox server that is being added to the DAG.
• You must remove all replicated database copies from a server before you can remove it from a DAG.
• When the first Mailbox server is added to the DAG, the DAG must be assigned an IP address.  The default behavior is to use DHCP to obtain an IP address for the DAG.  If DHCP is not available in your organization, or if you want to use a static IP address for the DAG, you can use the DatabaseAvailablityGroupIpAddresses parameter of the Add-DatabaseAvailabilityGroupServer cmdlet to specify an IP address for the DAG.  The IP address is needed only when adding the first Mailbox server to the DAG.

Using the Exchange Management Console to Manage DAG Membership

To perform this procedure, you must be assigned, either directly or using a universal security group, to the Organization Management Role Group.

1. In the console tree, expand Organization Configuration.

2. Select Mailbox, and then select the Database Availability Group tab.

3. Right-click the DAG you want to manage and then select Manage Database Availability Group Membership.

4. On the Manage Database Availability Group Membership page, you can either:

Click Add to add the local server to the DAG, select the local server, and then click OK.

Select a server from the list of members, and click the red X to remove the local server from the DAG.

5. Click Manage to perform the configured management action (adding or removing a server) on the DAG.

6. On the Completion page, the Summary states whether the operation was successful.  The summary also displays the Exchange Management Shell command that was used to perform this procedure.

7. Click Finish

Using the Exchange Management Shell to Manage DAG Membership

To perform this procedure, you must be assigned, either directly or using a universal security group, to the Organization Management Role Group.

In this example, a Mailbox server named CONSEAMB2 is added to a DAG named CONDAG1.  The DatabaseAvailablityGroupIpAddresses parameter is not used when the DAG already has been assigned IP addresses, or when you want the DAG to use DHCP to obtain an IP address.

Add-DatabaseAvailabilityGroupServer -Identity CONDAG1 -MailboxServer CONSEAMB2

In this example, a Mailbox server named CONSEAMB2 is added to a DAG named CONDAG1.  CONDAG1is configured with an IP address of 10.0.0.20.

Add-DatabaseAvailabilityGroupServer -Identity CONDAG1 -MailboxServer CONSEAMB2 -DatabaseAvailablityGroupIpAddresses 10.0.0.20

In this example, a Mailbox server named CONSEAMB2 is removed from a DAG named CONDAG1.  Before running this command, you must ensure that no replicated databases exist on the Mailbox server.

Remove-DatabaseAvailabilityGroupServer -Identity CONDAG1 -MailboxServer CONSEAMB2

Configuring Database Availability Group Properties

You can use the Exchange Management Console or the Exchange Management Shell to configure the properties of a DAG, including the file share witness and directory used by the DAG.

Configurable properties include:

• File Share Witness – The name of the server that you want to host the file share for the file share witness.  Microsoft recommends that specify a Hub Transport server outside the DAG as the file share witness.  This enables the system to automatically configure, secure and use the share, as needed.
• Witness Directory – The name of a directory that will be used to store file share witness data.  This directory will automatically be created by the system on the specified file share witness.

The Exchange Management Shell enables you to configure DAG properties that are not available in the Exchange Management Console, such as encryption and compression settings, network discovery, the Transmission Control Protocol (TCP) port used for replication, alternate file share witness settings, and datacenter activation mode.

Quorum Model

Exchange 2010 uses only two of the four quorum models available in Windows 2008 Failover Clustering:

• Node Majority – Each node that is available and in communication can vote. 
• Node and File Share Majority – Each node plus a designated file share (the “file share witness”) can vote, whenever they are available and in communication.

Using these two models, the DAG cluster provides automatic monitoring and failover only when there is a majority of votes, that is, more than half of the voters are functioning.

The quorum model used by Exchange depends on the number of mailbox servers in the DAG and is automatically updated as servers are added or removed from the DAG.  When the first mailbox server is joined to the DAG cluster, the Node Majority quorum model is used.  When a second server is added, the quorum model is changed to Node and File Share Majority.  If a third server is added, the quorum model is changed back to Node Majority.  This process continues as servers are added or removed from the DAG cluster so that the following rules emerge:

• Odd Number of Servers – The DAG uses the Node Majority quorum model.
• Even Number of Servers – The DAG uses the Node and File Share Majority quorum model.

Notice that each model results in an odd number of voters.  This ensures that in all cases that the cluster is able to maintain functionality as long as a majority of voters are functioning.  In the case where there is an even number of servers in the DAG, if it were not for the vote of the file share witness, a failure of half of the DAG members would result in a failure of the cluster.

Database Availability Group Network Encryption

DAG networks support the use of encryption by leveraging the encryption capabilities of the Windows Server operating system.  DAG networks use Kerberos authentication between Exchange servers.  Microsoft Kerberos SSP’s Encrypt Message/Decrypt Message APIs handle encryption of DAG network traffic.  Microsoft Kerberos security support provider (SSP) supports multiple encryption algorithms.  The Kerberos authentication handshake picks the strongest encryption protocol supported in the list: typically Advanced Encryption Standard (AES) 256-bit, potentially with a Secure Hash Algorithm (SHA) Hash Message Authentication Code (HMAC) to maintain integrity of the data.

Encryption Settings for DAG Network Communications

You can configure DAG network encryption by using the Set-DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell.  The possible encryption settings for DAG network communications are detailed in the following table.

Database Availability Group Network Compression

DAG networks also support built-in compression.  When compression is enabled, DAG network communication uses XPRESS, which is Microsoft’s implementation of the LZ77 algorithm. 

You can configure DAG network compression by using the Set-DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell.  The possible compression settings for DAG network communications are detailed in the following table.

Compression Settings for DAG Network Communications

The Exchange Management Shell enables you to configure DAG encryption and compression settings that are not available in the Exchange Management Console.

Page Patching

Microsoft Exchange Server 2010 high availability introduces a new Extensible Storage Engine mechanism known as page patching.  When database corruption is caused by minor disk faults, Exchange Server 2010 page patching automatically repairs the corrupted database, using one of the database copies configured for high availability. 

Exchange Server 2007 incremental reseed provided the ability to correct divergences in the transaction log stream between a source and target storage group, but did not provide a means to correct divergences in the passive copy of a database after divergent logs had been replayed.  This functionality forced the need for a complete reseed of the database copy. 

Exchange Server 2010 incremental reseed automatically corrects divergences in database copies using a new Extensible Storage Engine (ESE) mechanism known as Page Patching. 

Using Database Availability Group Networks

You can create multiple networks in a DAG, and dedicate them to client access or for replication purposes.

You can use the Exchange Management Console or the Exchange Management Shell to configure the properties of a DAG, including the file share witness share and directory used by the DAG, network encryption and compression settings, and the TCP port on each DAG network that is used for replication.

The Exchange Management Shell enables you to configure DAG properties that are not available in the Exchange Management Console, such as network discovery, the TCP port used for replication, alternate file share witness settings, and datacenter activation mode.

Creating a Database Availability Group Network

This section provides instructions for creating a DAG network using two different methods; using the Exchange Management Console and the Exchange Management Shell.

Using the Exchange Management Console to Create a Database Availability Group Network

To perform this procedure, you must be assigned, either directly or using a universal security group, to the Organization Management Role Group.

1. In the console tree, expand Organization Configuration.

2. Select Mailbox, and then select the Database Availability Group tab.

3. Right-click the DAG for which you want to create the new network, and then select New Database Availability Group Network.

4. On the New Database Availability Group Network page, provide configuration information for the new DAG network:

• Network Name – Provide a unique name for the DAG network of up to 128 characters.
• Network Description – Provide an optional description for the DAG network of up to 256 characters.
• Database Availability Group Network Subnets – Click Add to add each network subnet to the DAG network.  Subnets should be entered using a format of IP Address/Bitmask (for example, 192.168.1.0/24).  If you add a subnet that is currently associated with another DAG network, the subnet will be removed from the other DAG network and associated with the network being created.
• Enable Replication - Leave the check box selected to enable the DAG network for use by replication.  When a DAG network is enabled for replication, MAPI traffic is restricted on that network.  Clear the check box to prevent replication from using the DAG network, and to enable MAPI traffic on that network.

5. Click New to create the DAG network. On the Completion page, the Summary states whether the operation was successful.  The summary also displays the Exchange Management Shell command that was used to perform this procedure.

6. Click Finish to exit the wizard.

Using the Exchange Management Shell to Create a Database Availability Group Network

To perform this procedure, you must be assigned, either directly or using a universal security group, to the Organization Management Role Group.

In the following example, a network named DAGNetwork01 is being created with a subnet of 10.0.0.0 and a bitmask of 8 in a DAG named CONDAG1.  Replication is enabled for the network, and an optional description of the network is also being added.

New-DatabaseAvailabilityGroupNetwork -DatabaseAvailabilityGroup CONDAG1 -Name DAGNetwork01 -Subnets 10.0.0.0/8 -ReplicationEnabled:$True

Configuring Database Availability Group Network Properties

Each DAG network has several properties that you can configure, including the name of the DAG network, a description field for the DAG network, a list of subnets that are used by the DAG network, and whether or not the DAG network is enabled for replication.

This section provides instructions for configuring DAG network properties using two different methods: by using the Exchange Management Console, and by using the Exchange Management Shell.

Using the Exchange Management Console to Configure DAG Network Properties

To perform this procedure, you must be assigned, either directly or using a universal security group, to the Organization Management Role Group.

1. In the console tree, navigate to Organization Configuration -> Mailbox.

2. In the result pane, on the Database Availability Group tab, select the DAG you want.

3. In the work pane, on the Networks tab, right-click the DAG network you want, and then click Properties.

4. Use the General tab to configure DAG network properties as follows:

• DAG Network Name – Each DAG network name must be unique and cannot contain more than 128 characters.
• Network Description – Use this box to provide an optional description of up to 256 characters for the DAG network.
• DAG Network Subnets – Each DAG network must contain at least one subnet.  Subnets should be added using a format of IP Address/Bitmask (for example, 192.168.1.0/24).
• Enable Replication – Leave this check box selected to enable the DAG network for use by replication.  When a DAG network is enabled for replication, MAPI traffic is restricted on that network.  Clear this check box to prevent replication from using the DAG network and to enable MAPI traffic on that network.

5. Click OK

Using the Exchange Management Shell to Configure DAG Network Properties

To perform this procedure, you must be assigned, either directly or using a universal security group, to the Organization Management Role Group.

In this example, a DAG network in a DAG named CONDAG1 is being renamed from its default network of DAGNetwork01 to a new name of RepNet.

Set-DatabaseAvailabilityGroupNetwork -Name RepNet -Identity CONDAG1\DAGNetwork01

In this example, a subnet of 10.0.0.0 and subnet mask of 255.0.0.0 is being added to a DAG network named RepNet in a DAG named CONDAG1.

Set-DatabaseAvailabilityGroupNetwork -Subnets 10.0.0.0/8 -Identity CONDAG1\RepNet

Database Availability Network CmdLets

The following new CmdLets are available for use in configuring DAG networks:

Set-DatabaseAvailabilityGroupNetwork

Use the Set-DatabaseAvailabilityGroupNetwork cmdlet to configure a network for a DAG.  You can configure a variety of network properties, such as:

• Name for the network
• Description for the network
• List of one or more subnets that comprise the network
• Whether the network can be used for replication activity (log shipping and seeding)

Get-DatabaseAvailabilityGroupNetwork

Use the Get-DatabaseAvailabilityGroupNetwork cmdlet to display configuration and state information for a DAG network.  State information is returned for subnets and for network interfaces

New-DatabaseAvailabilityGroupNetwork

Use the New-DatabaseAvailabilityGroupNetwork cmdlet to manually create a network for a DAG.  After you create DAG networks, you can use them for log shipping and seeding for mailbox databases hosted on servers in the DAG, or use them for client access to mailbox databases in the DAG.

Remove-DatabaseAvailabilityGroupNetwork

Use the Remove-DatabaseAvailabilityGroupNetwork cmdlet to remove a network from a DAG.

I’d like to express a HUGE thanks to Niyaz Mohamed for compiling content and providing screenshots, which hopefully will help loads of people on DAGs.

First of all a HUGE THANKS to Yuval Sinay for putting this information together.

The following article will provide a summary on common issues in Exchange 2010 deployment in the Enterprise. The information in this article consists of my own experience and official Microsoft knowledgebase articles. Due to the fact that your Exchange environment may vary, please read the information carefully and test the suggestions from this article - in a lab that can demonstrate the current Exchange infrastructure.

The article is divided to the following chapters:

1. General issues in Exchange 2010 deployment.

2. Best practices in Exchange 2010 deployment.

3. Common issues in Exchange 2007 migration to Exchange 2010.

4. Common issues in Exchange 2003 migration to Exchange 2010.

Common issues in Exchange 2007 migration to Exchange 2010

• Strange errors may appear during OWA/Outlook Anywhere, Offline Address book management (e.g. Event ID 9519 "Error 0x80004005" in Application event log, etc.).
  • Event ID 9519 "Error 0x80004005" is logged in the Application log when you try to mount a database in Exchange Server 2010 or in Exchange Server 2007
  • In rare situations, you may need to apply the solution from the link above, to “Exchange Enterprise Servers” group (e.g. Give the group the user right to”Manage auditing and security log” in the domain controllers GPO) – I saw this issue when the Exchange 2007 server was installed in the past on domain controller.
• After creating a new Exchange 2010 database, the new database wouldn’t mount and the following error may appear: “Active Directory operation failed on <<DOMAIN CONTROLLER NAME>>. This error is not retrievable. Additional information: The name reference is invalid. This may be caused by replication latency between Active Directory domain controllers. Active directory response: 000020B5: AtrErr: DSID-03152392, #1: 0: 000020B5: DSID-03152392, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 200f4 (homeMDB)”
  • You cannot create a new Exchange Server 2010 Mailbox database in a multiple domain environment
  • Due the fact that the issue appear in customer with a single domain, I recommended to review the steps bellow.
    • Use the following method to create a new Exchange 2010 database:
      • Create a new Exchange 2010 database without mount it.
      • Use the power shell command to force the Exchange 2010 to use a preferred domain controller: "Set-ADServerSettings –PreferredServer mydomaincontrollername.domainname.local"
      • Mount the database by using the following power shell command: "Mount-Database -Identity "Second Mailbox Store" -DomainController mydomaincontrollername.domainname.local"

First of all a HUGE THANKS to Yuval Sinay for putting this information together.

The following article will provide a summary on common issues in Exchange 2010 deployment in the Enterprise. The information in this article consists of my own experience and official Microsoft knowledgebase articles. Due to the fact that your Exchange environment may vary, please read the information carefully and test the suggestions from this article - in a lab that can demonstrate the current Exchange infrastructure.

The article is divided to the following chapters:

1. General issues in Exchange 2010 deployment.

2. Best practices in Exchange 2010 deployment.

3. Common issues in Exchange 2007 migration to Exchange 2010.

4. Common issues in Exchange 2003 migration to Exchange 2010.

Common issues in Exchange 2003 migration to Exchange 2010.

• During mailbox movement, the following error may appear: “Active Directory operation failed on DC. This error is not retriable. Additional information: Insufficient access rights to perform the operation. Active directory response: 00002098: SecErr: DSID-03150A45, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0"
  • Use Remove-MoveRequest command to cancel the mailbox movement.
  • Verify that the account that is used has permissions to access the mailboxes in the Exchange 2003 server.
• During access to user mailboxes that reside on Exchange 2003 from Exchange 2010 management tool, the following error may appear: "Property Expression “User name” isn’t valid. Valid values are : Strings that includes ‘@’, where ‘@’ cannot be the last character."
  • Use ADSIEdit and fixed the following users attributes that may contain a space in the beginning: “User Alias” and “Username”.
  • Error message occurs when you move a mailbox from an Exchange Server 2003 server to an Exchange Server 2007 or Exchange Server 2010 server
• The following error may appear during Exchange 2003 migration: “Event ID 1036 is logged on an Exchange 2007 server that is running the CAS role when mobile devices connect to the Exchange 2007 server to access mailboxes on an Exchange 2003 back-end server.”
  • Event ID 1036 is logged on an Exchange 2007 server that is running the CAS role when mobile devices connect to the Exchange 2007 server to access mailboxes on an Exchange 2003 back-end server
  • Install Update for Exchange 2003 (KB 922817) on each Exchange 2003 server.
  • Review the instructions in http://support.microsoft.com/kb/937031.
  • Move the user mailboxes to the Exchange 2010 server.

Hopefully you have already heard about this and have change your deployment plans, otherwise here it goes. Recently it was compared the performance of the Exchange 2010 Client Access role supporting Outlook Anywhere users on both Windows 2008 SP2 and Windows 2008 R2, and found that the improvements the Windows Team has made in R2 more than doubles the number of concurrent users a given server can support, assuming CPU is the limiting resource.

For more information refer to the Microsoft Messaging Team Blog…

These results will be included in an upcoming TechNet whitepaper on Exchange 2010 CAS Guidance.

Imagine a scenario where we would have an Exchange Server 2007 CCR on Windows Server 2008. In this setup we only have two network cards.

Initially our thoughts would go to that it’s a best practice to configure the private/heartbeat NIC as the primary one to be used for log shipping and seeding and thus to move that traffic away from the public/MAPI NIC, as per Tim McMichael’s blog.

So the main question here would be if we could use such configuration. Unfortunately there's no support statement on this, just best practices. But we can't configure log traffic on a network that doesn't support client traffic, so a purely private network would be restricted from log shipping anyway.

As per the above blog instructions the heartbeat NIC needs to be set to mixed as well which bring us to our initial question again:

Exchange 2007 SP1 CCR (Cluster Continuous Replication) – Two Network Ports

When using a cluster continuous replication cluster with two network ports, your options are limited.  Consider the following design:

• First port set to “allow the cluster to use this network” and “allow clients to connect through this network”.

• Second port set to “allow the cluster to use this network” and “allow clients to connect through this network”.

You’ll noticed that in this configuration both networks are set to “allow clients to connect through this network”.  This is necessary in order to establish the private network for use with log shipping functions.

To establish this network for log shipping functions, refer to the enable-continuousreplicationhostnames cmdlet:

• http://technet.microsoft.com/en-us/library/bb690985.aspx
• http://technet.microsoft.com/en-us/library/bb629629.aspx

If used the replication service will first prefer to perform log shipping functions over the “private” network.  Should the private network be unavailable the replication service will resume log shipping functions over the public network.

However in the above case, if we didn't enable both cluster and client connectivity for both networks, we'd have at least one single point of failure again. That's something to avoid in a two-port configuration. I believe Tim McMichael’s blog generally recommends a minimum of three ports for CCR systems, with two networks set for public and private and one for private only.

Last but definitely not least, for Windows Server 2008 clusters there really is no such thing as a dedicated private network anymore. As soon as you enable the network for client use, you have to enable it for cluster use, you can’t enable it for client use until you have set it for cluster use. Additionally there is no way to control the priority of the networks for cluster use, the failover cluster adapter determines the routing paths for that. Also, apparently “the allow clients to connect through this network” option is only used for automating and/or controlling the wizards for configuring services and applications, this setting tells the wizards which networks to create the service IPs on. So it actually no longer matters if you don’t have a dedicated heartbeat network, even ExBPA has been updated to not fire the “Dedicated heartbeat network not found” warning for Windows 2008 Failover Clusters. The key thing is that the networks must be on different subnets, and therefore client traffic would never go over the cluster/log shipping network.

The main reason we wanted dedicated private networks in Windows Server 2003 was because we were not very tolerant of missed heartbeats, in Windows Server 2008 we are certainly far more tolerant of missed heartbeats with the new network heartbeat improvements, especially when using a Majority Node Set with File Share Witness (no bus resets to rely on, with buggy disk drivers and firmware). But if you are wanting to be extra, extra safe then go with three networks.

While searching on Internet about this piece of information couldn’t really find a place where we had it all together as so I have decided to blog it… mostly because a team mate asked me… :)

DPM2007 Server Services

Protected Server Services

Imagine the scenario where you want to to set an execution policy for a specific user on a machine. The per-user setting is nothing more than a key in the registry, something like:

[HKEY_USERS\S-1-5-21-REST-OF-SID\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell]

"ExecutionPolicy"="RemoteSigned"

So all you have to do is grab your users’ SIDs (easy enough with AD cmdlets or ADSI I suppose) and modify the registry directly (as long as you have admin rights).

The proper way of doing this, of course, would be using Group Policy, see Set-ExecutionPolicy for details on that.

You can alter who is affected by the statement by using the –scope option.  The setting will be persistent though. You shouldn’t need to run it each time PS is started up.

Best Practices Analyzer (BPA) is a server management tool that is available in Windows Server 2008 R2. BPA reports best practice violations to the administrator after BPA scans the roles that are installed on Windows Server 2008 R2. Administrators can filter out unnecessary information or exclude results from BPA reports. Administrators can also perform BPA tasks with either the Server Manager GUI, or Windows PowerShell cmdlets. For more information about Best Practices Analyzer and scans, see the Best Practices Analyzer Help.

When you select the entry for Hyper-V under the Roles node you should see a new section called Best Practice Analyzer:

Here you can select to scan the Hyper-V role and see how you are going against common best practices. One other neat feature of the Best Practice Analyzer is the ability to exclude results.  This way you can remove best practices that you do not believe apply to your environment – so you will not have to deal with a large number of unnecessary errors / warnings.

Imagine the following scenario where you have your Exchange Organization split in three major sites, where each site has their own domain, for instance EMEA, APAC and AMERICAS.

In each site we have CCR clusters, Hub Transport and CAS servers, all in Service Pack 1. Service Pack 2 meanwhile is released and we end up with a major doubt regarding how should we act in terms of such upgrade.

The doubt generally resides between:

• Upgrade each site, every single role, to Service Pack 2 and only then upgrade the other sites, one by one;
• Upgrade all the CAS servers followed by the Hub Transport servers in every single site to Service Pack 2 and only then upgrade the CCR clusters;

The answer for this is quite simple, long maybe as we need to reassure some stuff around it, but definitely it is not hard as it may initially seem.

It doesn’t matter which choice we take, as long as we upgrade first the CAS servers, especially if we are using CAS-CAS proxy. We can have servers with Service Pack 1 and others with Service Pack 2, as long as the CAS is greater (or equal) to the mailbox. In terms of delays, as in timeframe for the patching operation between the first and last patches, that doesn’t really matter, as far as the versions are supported and in this case Service Pack 1  is still supported!

Another thing to take as a recommendation is that two CAS servers can have different versions as far as we do not have them in NLB or even in a CAS Array as in that case the RPC Client Access attribute in the databases will just be a virtual name, as so everything within that virtual name (NLB or CAS Array) need to be consistent in terms of versions… This exclude the time that takes the update of all servers in the NLB or CAS Array obviously.

This apply to all builds, or at least to all the Release Updates and Service Packs supported at the moment. Obviously the CAS servers on the internet facing site must always be the first servers to upgrade, otherwise you definitely break the OWA.

Finally if you upgrade a whole site first, if it is the internet-facing site, there is no issue in having the others sites with lower versions.

As we heard on the 19th of April we finally released DPM 2010 RTM, however customer wise it will only be available in June…

For our customers which have already in place previous versions of DPM the main question will be how can they migrate their system.

A great utility we came up with was the DPM 2010 Upgrade Advisor. It is an Excel spreadsheet where you can fill in what version that you are coming from and what version that you want to go to as well as what you are using for Disaster Recovery, Tape Library Sharing, etc. And it outputs a checklist to walk you through the upgrade process.

And finally it is out… The “kind of” expected element to allow Exchange Server 2010 (including BPOS) to coexist with Lotus Notes… The Quest Solution!

As you probably are aware already there is no support from Microsoft to make both environments to coexist, and as far as I am aware, there won’t be, obviously on a native Exchange Server 2010 organization, as so Quest will provide that service… If you want to do it using Microsoft products only you will need to have an Exchange Server 2007 as a bridge to the Lotus Connector… however Exchange Server 2007 needs to be there before the Exchange Server 2010 boxes… :)

“Quest Software is one of Dimension Data’s premier partners for our Microsoft Solutions line of business. We are pleased to partner with Quest to combine our specialist services with their best-of-breed Lotus Notes to Microsoft Exchange migration tools and coexistence solutions. Together, we have helped our clients enable high performance workplaces by improving competitiveness, increasing return on IT assets and providing better regulatory compliance. ”

Phil Aldrich, Practice Director of Microsoft Solutions, Dimension Data

“A Lotus Notes transition to Microsoft Exchange Server can be a complex project with considerable risk.  To ensure business continuity and minimal user impact, organizations need a tool that keeps end users collaborating together throughout the coexistence period. With the new functionality of Quest Coexistence Manager for Notes, we enable organizations to establish interoperability between Notes e-mail and applications and Exchange/Outlook by ensuring the accuracy of mail and calendar data.”

Bill Evans, Vice President and General Manager, SharePoint and Notes Transition, Quest Software

There has been one too many conversations about Data Protection Manager and The Cloud… Some of them correct and others eventually a little bit less correct, so I decide to write this post in order to clear things a bit and hopefully help someone with it.

So apart from being able to protect to disk, tape and disk to disk to tape we can actually protect our information online, now how can we do that?

We have basically two great partners who have been with us on this, and they are Iron Mountain who provide us CloudRecovery solution and I365 who provide us a brilliant solution called EVault (DPM):

CloudRecovery

The new release of Iron Mountain, CloudRecovery, will provide support for DPM 2010 in addition to continued support for DPM 2007 with Service Pack 1. To support rapid corporate data growth, the solution also provides increased scalability – protecting multi-terabyte servers.

“We need to have systems that are always on, and always available.  This is especially true when it comes to the backup and recovery needs of our Microsoft applications – including Exchange, SQL, and SharePoint,” said Alan Bourassa, CIO, Empire CLS. “The seamless integration between Microsoft DPM and Iron Mountain CloudRecovery is ideal for addressing these requirements and we are looking forward to taking advantage of the new features that will be available with the new release.”

EVault (DPM)

EVault (DPM) is an all-in-one backup and recovery appliance for Microsoft centric, mixed computing environments. And besides that believe-it or not even to non Microsoft Platforms… all in the same box!!!

It integrates with your Microsoft business applications and offers the most up-to-date protection for your Microsoft systems. You also gain broad non-Microsoft system protection; optimized cloud connectivity for fast, secure, affordable offsite disaster recovery; and the simple deployment and maintenance of an all-in-one appliance.

Jason Buffington, recently blogged about the DPM 2010 release and the i365 partnership.

So basically these are the solutions we have with these two brilliant partners, and that should be what is considered to be recommended, any further information until today’s date may not be absolutely true…

If you are concerned on knowing exactly what you need to do in order to migrate your current Exchange environment to Exchange Server 2010, whatever reason it is (multiple firewall rules, multiple certificates, multiple external URLs/ports for clients) don’t be as there is good news. We completely understand that this complexity means there is opportunity for making mistakes, which causes deployments to stall-not to mention a lot of frustration.

The solution is Exchange Server 2010 Deployment Assistant!!!

It will allows you to create Exchange Server 2010 On-Premises deployment instructions that are customized to your environment and all of your specific situations. It starts by collecting some information from you, and based on a your answers, it provides a finite set of instructions that are designed to get you up and running on Exchange Server 2010.

Main idea is to avoid the infinite information you can find in Internet specially in Exchange Server 2010 library and go straight to what you need to do.

Here is a screenshot from the tool, after the initial set of questions were answered and instructions generated.

Happy Exchange Server 2010 Migration!!!

Overview

Exchange Server 2010 help organizations guard their messaging with built-in protective technologies; offers anywhere access to email, voice mail, calendars, and contacts; and enables new levels of operational efficiency. Help develop your expertise in this advanced messaging system with state-of-the-art training from Exchange Server 2010 product specialists. Choose a certification path that is relevant to your current job role or one that prepares you for your next career step.

Microsoft Certified Technology Specialist certification

Whether you are new to Microsoft Certification or a Microsoft Certified Professional (MCP) certified on Microsoft Exchange Server 2003, consider earning the Microsoft Certified Technology Specialist (MCTS): Microsoft Exchange Server 2010 – Configuration certification. This certification highlight your area of expertise and help validate the knowledge and skills that are required to deploy and administer an enterprise messaging environment by using Exchange Server.

Exam 70-662 – TS: Exchange Server 2010, Configuring

Microsoft Certified IT Professional certification

The Microsoft Certified IT Professional (MCITP): Enterprise Messaging Administrator certification is also appropriate for MCPs who are certified on Microsoft Exchange Server 2003 as well as IT professionals who are new to Microsoft Certification. This certification helps demonstrate your professional expertise in using Microsoft Exchange Server 2010 to excel in a specific job role, such as the lead engineer for messaging solutions within an enterprise organization.

Exam 70-662 – TS: Microsoft Exchange Server 2010, Configuring

Exam 70-663 – Pro: Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

Microsoft Certified Master program

Differentiate yourself as the technical expert. The Microsoft Certified Master (MCM) program helps the best professionals in the IT industry become even better. Whether you want to enhance and help validate your advanced skills or take your career to the next level, achieving a Microsoft Certified Master certification will help differentiate you from others in the competitive ranks of senior IT professionals.

This unique program consists of three weeks of mandatory, hands-on training led by experts, and extensive written and lab-based testing. Candidates' practical product knowledge, technical acumen, knowledge of best practices, personal and professional stamina, and communication skills are constantly challenged as they work toward attaining this premier Microsoft technical certification.

MCM Certification

Microsoft Certified Architect certification

Validate your capability to translate business problems into technology solutions. When you earn the Microsoft Certified Architect (MCA) certification, you can be recognized by Microsoft and the IT industry worldwide as an expert who holds the highest level of professional certification from Microsoft.

MCA Certification

Data Protection Manager

As this blog main technologies are Exchange and Data Protection Manager I could miss the Data Protection Manager exams information:

Exam 70-658 – TS: System Center Data Protection Manager 2010, Configuring

This is a case study of a customer who wanted to perform a migration from Exchange Server 2000 / 2003 to Exchange Server 2007 whilst consolidating a number of remote sites to a centralised hub site. The main premise of this engagement was to ascertain Microsoft’s best practice methodologies for migrating very large mailboxes and moving large amounts of data with the least amount of risk of data loss, and the consolidation of globally dispersed messaging environments.

I’d like to send from here a HUGE THANKS to my peer, Ray Khan for putting all of this information together, as he was the one involved on the project and who kindly present to us this awesome case study which hopefully will encourage some other customers!

Problem Statement

This customer had a need to migrate all of their regional site data into a centralised site in UK with the least amount of downtime. They had users with very large mailboxes in China and Japan of up to 40 GB per mailbox, however there were only 30 to 40 users at each of these sites. There was a total of around 600 GB of mailbox data that would be required to be migrated from the regional sites to UK.

The objective was to archive most of the data from these mailboxes onto a new Enterprise Vault platform, so once on Exchange Server 2007 they would only have around two gigabytes of "online" mail.

They had reviewed several migration approaches but wanted our advice on these approaches and any others that have been proven in other environments.

As part of their upgrade project they were also investigating all other messaging platforms including Microsoft’s BPOS solution as well as partner’s and other third party solutions and also considering carrying on running On Premise. This aspect was out scope for this engagement.

Infrastructure before Upgrade

The company has just under a couple of thousand employees. Over 75% of their staff are located in UK and Switzerland the other 25% are located around the major financial centres around the world including China, Japan, and US.

Their Exchange server organization exists inside a single Active Directory Forest running Exchange Server 2003 SP2 in native mode. However there were several Exchange 2000 SP3 mailbox servers situated at some of their key branch offices such as China, Japan, UAE, Canada and Uruguay.

Exchange Estate Summary

• 31 servers globally, 11 routing groups and 6 administrative groups;
• they employ a single ended Exchange topology and do not use any front-end servers;
• 4,128 mailboxes (including resource mailboxes but some are dormant or on disabled accounts);
• 5.1 TB personal mailbox data and approximately 650 GB of Public Folder data (PF's mostly in UK and Switzerland);
• The global organisation sends around 850,000 messages a week and receives around 1,000,000 messages a week;

Exchange 2003 Integrations

• 17 Enterprise Vault 6.x and 7.x archiving servers hosting around 7.5TB of archive data (but not all regions have archiving);
• 10 Blackberry Enterprise Servers servicing around 800 Blackberry handsets globally;
• OCS 2007 R1 transitioning to R2;

Many of their users have very large mailboxes, averaging 2 to 4 GB, but in some regions where no archiving exists we have users with up to 40GB mailboxes

Our client estate is based on Windows XP SP3 and Outlook 2003 with SP3 (new workstations with 2GB RAM).

Networks (Global MPLS WAN)

• 100 Mbps (between UK and Switzerland);
• 45 Mbps (between UK, China, Japan and US);
• 2 Mbps (high latency links between UK, UAE, Uruguay, Canada, Singapore, etc.);

Target Architecture

They planned to transition their entire organization to Exchange Server 2007 SP2 into a consolidated and centralised architecture hosted in our new Global Data Centre in UK. This network will be facilitated by Cisco WAN Accelerators, situated at all of their branch offices.

They were also planning to consolidate and centralise their archiving and BES estate into the UK Global Data Centre.

They were in the planning/design phase of this programme and were scheduled to commence deployment in beginning of 2010 for completion by end of summer of 2010.

Proposed Solution

This customer designed a number of solutions to address the problem statements listed above. They decided to go for the following approach to migrate the Exchange Server 2000 / 2003 users with very large mailboxes and archive their data to the centralised site using SCR data replication technologies... Please refer to the steps below for more detail.

Migration Steps

1. Install and configure the entire centralised Exchange Server 2007 SP2 infrastructure, EV and BES infrastructure into the Global Data Centre (GDC). Install WAN Accelerators;
2. Install an Exchange Server 2007 staging mailbox server in the GDC (to receive gross branch office mailboxes);
3. Install an Exchange Server 2007 MBX/HT as swing server at the remote site (on the same LAN);
4. Configure staging server in the GDC as an SCR target of the swing box Exchange Server 2007;
5. Run Move-Mailbox command from Exchange Server 2000 (at the branch office) to Exchange Server 2007 swing box server (move entire existing mailbox over – swing box becomes the production MBX/HT for the branch office users);
6. Allow SCR to seed the staging server over a period of up to 2 to 3 weeks (however long it is expected to take – after testing) – using SMB 2.0 as both servers will be Windows Server 2008 SP2;
7. Once all data is migrated across – perform VSS backup of the SCR target – run ESEUtil /G to check database - invoke SCR disaster recovery process and switch the active mailbox node to the staging server in the GDC;
8. Move BES account to GDC BES server;
9. Enable EV archiving policy and groom the mailboxes (that are in the staging server) to 1 GB in size – all inside the GDC site (SAN to SAN);
10. Once complete run Move-Mailbox to migrate the 1 GB mailboxes to the production CCR cluster (SAN to SAN);
11. Once all data is validated delete the staging server databases used to eliminate white space;
12. Move Exchange Server 2007 swing box server to the next branch office;
13. Remove and re-install Exchange MBX/HT in the next branch office site (also rename the swing server);

Summary

This customer decided to migrate to Exchange Server 2007 and to continue managing their infrastructure to On Premise using the above approach. They have managed to migrate their remote site data using the strategy outlined above. They are continuing with us from a support perspective and will be booking further proactive engagements looking forward to migrating to Exchange Server 2010.

SSL certificates are issued for periods of spanning a number of years (typically in multiples for example one, two or more years, however eventually they do expire and need to be renewed).

The renewal process involves generating a fresh CSR (Certificate Signing Request) on one of your Exchange Client Access servers. This is then sent to a root certification authority (e.g. VeriSign) for processing into a valid SSL certificate (essentially they sign the request).

Creating a Certificate

In order to generate a CSR file on the Client Access Server and Windows Server 2008 open the Exchange Management Shell and type the following command:

New-ExchangeCertificate -GenerateRequest -Path c:\myReq.csr -KeySize 1024 -SubjectName “c=GB, s=Middx, i=MyCompany, ou=IT, cn=mail.mydomain.com” -PrivateKeyExportable $True

The string that you provide after the -SubjectName switch is very important and it is made up of the following values:

• c – This is the country of origin.
• s – This is the state we are in.
• i – This is the company that you work for, or indeed the SSL certificate will be assigned to. You should note that if you have purchased SSL certificates before it is worth ensuring that the company naming convention is consistent throughout all certificates that you have purchased.
• ou – This is the organisation unit that the section of the company which will take charge of the certificate.
• cn – This should be set to the DNS FQDN of the Client Access Server which will be using the certificate.

This will produce a file in the root of C drive on the CAS server called myReq.csr. This should be sent to our root certification authority.

When the CSR has been generated you will be provided with a CRF (Certificate Response File) which looks like the following (this will be returned to you via email):

-----BEGIN CERTIFICATE-----JJkbbssCCAuucgAwIBAgIQcyE6jZgwnFgAq0d7onjMFzANBgkqhkiG9w0BAQUFADCBzj

EEWNNNEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du

MR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv

biBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhhd3RlIFByZW1pdW0gU2VydmVyIENB

MSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNlcnZlckB0aGF3dGUuY29tMB4XDTA4MDcxMTE2M

DU0OFoXDTEwMDcyNjE1NTcxN1owgYYxCzAJBgNVBAYTADDDDDDjujjjjjw87666cvNxMJkeDE

PMA0GA1UEBxMGTG9uZG9uMSswKQYDVQQKEyJMb25kb24gQm9yb3VnaCBvZiBIb3Vuc2xvdyBD

b3VuY2lsMQswCQYDVQQLEwJJVDEcMBoGA1UEAxMTb3dhLmhvdW5zbG93Lmdvdi51azCBnzANB

gkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAolvn0lT1W+cdRFjqOn56tPwHNULjq7LDA/G4ZAIVf9

cl7y4jLKR/6/3x2O/1st8OEcFDFKElmn8dzoA3pG14JL8ZmBTh0RLxtGRw9fHB2ARuYplagoD

LqgA5mzEPo3a3wCKboTaEwKwoeQ9dAp2bGcvs4lMPptI48eoSDhFs/u0CAwEAAaOBpjCBozAd

BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwQAYDVR0fBDkwNzA1oDOgMYYvaHR0cDovL

2NybC50aGF3dGUuY29tL1RoYXd0ZVByZW1pdW1TZXJ2ZXJDQS5jcmwwMgYIKwYBBQUHAQEE

JjAkMCIGCCsGAQUFBzABhhZodHRwOi8vpgthennn/ss88877a222129tMAwGA1UdEwE

B/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAuYSyeOUx53TkjCfol2psVY3E9uzMb6P6nrgs2U

uG8BBQlshPkv+te8G2JpaaaaCmcrCV8J0WQN8mRm5443vbdasafJTBxB2PAZfl3GSWEgDIH

q/lg3IOxG43YK4qDWYTu3j/Ngymq8g/d+0VrqkF/AmXWnGMGIQmE3GUnUDXeZKOR8SM=

-----END CERTIFICATE-----

You should copy the CRF (including the Begin Certificate and End Certificate) into a text file called owa.txt and then rename the file owa.cer. You should then copy this file up to a drive on the CAS server where you are working.

Installing a Certificate (CAS)

Firstly you need to remove the existing (expired) SSL certificate from your Client Access Server. In order to accomplish this you need to open the Exchange Management Shell and then type in the following command:

Get-ExchangeCertificate | fl | out-file –filePath c:\certs.txt

This will create a text file in the root of C drive called certs.txt which contains the details of every certificate install on the server. The output should look like the following:

The key property that will identify the certificate that you wish to replace is the Not After field. As this is essentially the expiry date and should have already expired or indeed be very close to expiring. Make a note of the thumbprint (the long number at the bottom after the Thumbprint field) and then type in the following command:

Remove-ExchangeCertificate –thumbprint <thumbprint that you noted down>

As a tip here is to copy the thumbprint from the text file above and then paste it into the PowerShell Window. When you have typed the command and pressed enter you will be presented with the confirmation message:

Are you sure you want to perform this action?

Remove certificate with thumbprint 138B6EC5AAE868F495ECCBDA05C1F011B08A7CD3?

[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help(default is “Y”):

Confirm the action by entering A and then press ENTER. You are now ready to import the new certificate onto the Client Access Server. In order to do this type in the following command within the PowerShell window (ensure that the path you specify to the certificate file matches the location where you placed the new certificate in the earlier steps):

Import-ExchangeCertificate -path e:\certificates\owa.cer –FriendlyName “owa.mydomain.com”

You should then be presented with the following output (again here you will need to make a note of the thumbprint):

Thumbprint Services Subject

———- ——– ——-

B52842F7408772B7151FF74FDAE914EA7B59B53A ….. CN=owa.mydomain.com,…

Now that the certificate has been imported into the certificates repository you need to enable it for OWA. In order to do this run the following command in the PowerShell window:

Enable-ExchangeCertificate -Thumbprint B52842F7408772B7151FF74FDAE914EA7B59B53A -Services IIS

The new certificate should now be installed you can confirm this by running the following command:

Get-ExchangeCertificate

The output of which should be:

Thumbprint Services Subject

———- ——– ——-

B52842F7408772B7151FF74FDAE914EA7B59B53A …W. CN=owa.mydomain.com,…

The key thing here to note is the W under services (this signifies that the cert has been enabled for OWA) and that the thumbprint matched what you have typed in previously.

In this post I will try to bring you the way that all Recipient Lists, such as Address Lists or Distribution Lists behave in Exchange Server 2007 and what should we do with our old ones from Exchange Server 2003 and a few advices to some possible issues you may experience.

Distribution Lists Types

 Most of the distribution lists types that you can get in Exchange Server 2007 are familiar if you have been dealing with Exchange Server 2003 as we can see below:

• Universal Distribution Group: This is the primary type of distribution group you will use for sending messages to large groups of recipients. You cannot assign permissions to this type of group.
• Universal Security Group: You can use this type of group to assign permissions to a group of recipients access permissions to resources in Active Directory and to send messages to all the recipients in the group.
• Non Universal Group: These are groups created in Exchange Server 2003. You will have limited access to them. You should change the scope of the group or create a new one with universal scope so they can become a universal group.
• Dynamic Distribution Group: This type of group doesn’t have a static list of recipients. It uses recipient filters to generate its membership when a message is sent to the group. Every time you will send a message to this group Exchange will query Active Directory. These groups are useful but should be used carefully. Every time a message is sent to these groups you should expect increased processor/disk/network activity.

Many thanks to Mark Sewell for this information.

Experience from the field has shown that the following best practices, hints and tips are useful in using JetStress to determine appropriate requirements and configuration. The download location for JetStress and other tools for Exchange 2007 can be found on this page: http://technet.microsoft.com/en-us/exchange/bb330849.aspx.

1. Follow the installed and online JetStress documentation carefully, paying particular attention to the storage subsystem requirements and configuration. Any design for carving out LUNs will need to balance the requirements for performance, recovery time and administrative costs (complexity). Use the Storage Requirements calculator provided:
• List of JetStress updates: http://msexchangeteam.com/archive/2007/07/05/445802.aspx
• Updated blog post: http://msexchangeteam.com/archive/2007/01/15/432207.aspx
• Updated download: http://msexchangeteam.com/files/12/attachments/entry438481.aspx
2. Storage Calculator assumes IOPS values for 80% disk capacity. Latest version makes this explicit. Performance will be less for stripes towards the spindle.
3. Ensure multipathing is in use, if at all possible, in preference to Active-Passive/Concurrent or static routes through the SAN fabric. Check that the multipath software has an active licence if required. Have the customer engage the storage vendor to ensure that there are no bottlenecks through the SAN fabric. There are different algorithms available for multipathing and the vendor can determine which is best for load balancing in the customer's environment.
4. The StorPort driver, introduced in Windows Server 2003, is much preferred over the older iSCSI and can deliver significantly better performance in hardware RAID and SAN environments.
5. Remove anti-virus software and all other non-essential applications, as far as is practical, so that you can take a baseline of JetStress performance. Then you can incrementally add back in required applications and see their effect on JetStress. It is not sufficient to simply disable AV software as the filter drivers will still be in place and could still block or delay file I/O. Management or monitoring software could cause a conflict. Hardware vendors who assist customers in setting up their environment often install such management or monitoring suites. The customer's own OS support team may also install these applications.
6. Also remove any third-party video drivers and verify that only the default VGA driver is installed (which can save a significant number of System PTEs) or use the /BASEVIDEO boot.ini switch.
7. JetStress threads are applied on a per storage group basis. The more storage groups you have, the more I/O you will have with a constant thread count. Use autotuning initially to arrive at an approximate thread count and then fine tune manually to hit the target IOPS for a given number of storage groups. Setting a fixed thread count is not going to provide an exact IOPS value but we are aiming for the actual IOPS to be within 5% of the target. Start with fewer threads and increase them over different tests, using the JetStress reports and Performance Monitor data to confirm that the server and storage are handling the target load. In this way you should arrive at an optimal thread count tuning that provides the best basis consistent JetStress results.
8. Need to view the report in conjunction with the Performance Monitor logs in order to determine that the I/O JetStress is generating is as expected (in terms of I/O sizes, ratios, burstiness, etc.). For example, performance graphs ramping up with time have been seen when using AMD Opteron servers. These turned out to be a missing boot.ini file /usepmtimer switch as per http://support.microsoft.com/kb/895980.

One addition the IO generation in JetStress is linked to the SGs due to the way the IO generation works in the tool. So if you need to add more threads this will generate more IO and spread it over the SGs. It does not mean that the tool gives you the amount of SGs you need! The more SGs you have the better in the Real World!

We’ve just published a new whitepaper on helping organizations choose Exchange as their voicemail system.  This whitepaper details the value that Exchange 2010's Unified Messaging capabilities offer to empower users, reduce cost and manage risk by replacing a previous voicemail system.

Here are the short and long URLs.  Please use the short one for most scenarios including tweeting or posting:

http://bit.ly/crRISt

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=70cfd1f1-fb01-4abb-a260-41b21ece5839

There are three versions (DOCX, PDF, XPS) available on the site for customers that haven’t quite made the switch to Office 2007/2010 yet.

The main reason this guidance was developed was due to customers requesting that CAS be placed in a perimeter network.  See http://msexchangeteam.com/archive/2009/10/21/452929.aspx for more information on why that is not supported.  This same guidance, as the article indicates, is true for the other server roles, with the exception of Edge Transport as it was designed from a usage scenario to only communicate from the perimeter network to the internal network via SMTP and to allow connections (LDAP and SMTP) from the internal network.

As for what customers can do - If their plan is to open up all the defined ports between the Exchange and AD servers in Site A and all Exchange and AD servers in Site B, then this would be supported since one could argue that there isn't really a "firewall" between the two sets of servers anymore.  They will be able to get support  after deploying like that. And if an issue comes and then, while helping them debug it, its found that there was network traffic blocking going on which breaks some aspect of Exchange communications with other server roles in the AD Sites, then they would be helped at least help them get into a supported state (without traffic limitations between the Exchange servers and DCs).

Yes this adds complexity.  Yes it could break things.  Yes customers have reasons to do it.

Awesome news as the so much waited SP1 on Exchange Server 2010 will be out, hopefully soon… And the good news continue as these should be some of the improvements:

• Archiving and Discovery Enhancements;
• All the Mobility all the time;
• New Management UI;
• Outlook Web App better than ever;

http://msexchangeteam.com/archive/2010/04/05/454533.aspx