Upgrade from Exchange 2007 Transport

When upgrading from Microsoft Exchange Server 2007 to Exchange Server 2010, there will be a period of time where both versions coexist in production. You can plan an upgrade path from Exchange 2007 to Exchange 2010 using the information in this topic, which includes overview information, technical information about message flow in a coexistence environment, and considerations when operating in a mixed version environment.

Important: If you deploy Exchange 2010 as a new organization, you can’t later install Exchange 2007 in the Exchange 2010 organization. This isn’t a supported scenario. If you anticipate requiring Exchange 2007 functionality in your organization in the future, you must first install an Exchange 2007 organization and maintain at least one Exchange 2007 server.

The most important point in an Exchange 2010 and Exchange 2007 coexistence scenario is that every Mailbox server needs a Hub Transport server with a matching Exchange version in the same Active Directory site. Due to the changes made to the Exchange Server Object (XSO) model in Exchange 2010, Exchange 2010 Hub Transport servers can’t pick up messages from and deliver messages to Exchange 2007 Mailbox servers. Similarly Exchange 2007 Hub Transport servers can’t communicate with Exchange 2010 Mailbox servers. Therefore, you need to maintain your Exchange 2007 Hub Transport servers in a specific Active Directory site until all Exchange 2007 Mailbox servers are removed from that site. For more details about how messages are routed in a coexistence environment, see “Message Routing Across Versions” later in this topic.

Note: In-place upgrades aren’t supported in Exchange 2010. You need to install new Exchange 2010 servers into your environment, and then phase out the Exchange 2007 servers. For the scope of this document, the phrase upgrade refers to generally upgrading the version of your Exchange deployment and not a specific server.

Upgrading your Exchange 2007 Hub Transport and Edge Transport servers should be part of your overall upgrade strategy. The recommended order is to upgrade your transport servers after your Client Access servers and before Unified Messaging and Mailbox servers. The Edge Transport servers need to be upgraded after the Hub Transport servers are upgraded.

Before you introduce Exchange 2010 Hub Transport or Edge Transport servers, make sure that all of your Exchange 2007 servers in that site are upgraded to Exchange 2007 Service Pack 2 (SP2). Exchange 2007 SP2 is required for Exchange 2010 and Exchange 2007 Hub Transport servers to coexist in a single Active Directory site. Exchange 2007 SP2 is also required so that the Microsoft Exchange EdgeSync service works across versions.

If you have Exchange 2007 deployed in multiple sites, you must upgrade your Internet-facing sites first. The order of upgrade for the remaining sites depends on your particular topology and your organization’s priorities.

The following process shows the recommended upgrade path for your transport servers in an Internet-facing site. (It is assumed that you are using Edge Transport servers with EdgeSync. If you are using a third-party smart host, you can omit steps 2-6.) The upgrade process is as follows:

  1. Introduce your first Exchange 2010 Hub Transport server to your site. As soon as the Exchange 2010 Hub Transport server is introduced to the site, it will take over edge synchronization. However, because the Edge Transport server is still running Exchange 2007 SP2, the Exchange 2010 Hub Transport server won’t perform incremental EdgeSync synchronization, but rather replicate full EdgeSync data, just like an Exchange 2007 Hub Transport server. For message delivery to the Internet, the Exchange 2010 Hub Transport server will go through the Exchange 2007 Hub Transport server, as shown in the following figure.
    Introducing Exchange 2010 Hub Transport server to existing Exchange 2007 site
    Transport server upgrade step 1
  2. Subscribe your Exchange 2007 Edge Transport server to your site again. This will add your Exchange 2010 Hub Transport server to the Edge Subscription as a source server, as shown in the following figure.
    Note:
    If you plan to add multiple Exchange 2010 Hub Transport servers to your Active Directory site, to save time, you can deploy all the new Hub Transport servers before subscribing your Edge Transport servers.
    Subscribing Exchange 2007 Edge Transport servers after introducing Exchange 2010 Hub Transport server
    Transport server upgrade step 2
  3. Introduce your first Exchange 2010 Edge Transport server to your perimeter network.
  4. Subscribe your Exchange 2010 Edge Transport server to your site. At this point, the Exchange 2010 Hub Transport server will start incremental updates to the Exchange 2010 Edge Transport server, as shown in the following figure.
    Subscribing Exchange 2010 Edge Transport server
    Transport server upgrade step 4
  5. Remove the Exchange 2007 Edge Subscription.
  6. Decommission your Exchange 2007 Edge Transport server, as shown in the following figure.
    Removing Exchange 2007 Edge Transport servers
    Transport server upgrade step 6
  7. After all of your mailboxes are on Exchange 2010 Mailbox servers, decommission your Exchange 2007 Hub Transport servers.

Message Routing Across Versions

Due to changes in the Exchange Server Object (XSO) model in Exchange 2010, Exchange 2010 Hub Transport servers can’t pick up messages from and deliver messages to Exchange 2007 Mailbox servers. Similarly Exchange 2007 Hub Transport servers can’t communicate with Exchange 2010 Mailbox servers. As a result, to have both Exchange 2010 and Exchange 2007 in the same Active Directory site, you must maintain both versions of Hub Transport servers in that site, as shown in the following figure. The versions of the servers in Site B aren’t shown in the figure, because the handling of intersite SMTP traffic is the same as it is in Exchange 2007. The Hub Transport server relays the messages to the Hub Transport server in the remote site for delivery.

Message flow between Exchange 2010 and Exchange 2007
Message flow with versioned routing

To enable message flow across versions, a feature called versioned routing is implemented in Exchange 2010. With versioned routing, the routing engine checks the version of a mailbox’s home server, along with its Active Directory site. If the version doesn’t match, the message is relayed to a Hub Transport server that has a matching version, as shown in the versioned routing workflow in the following figure. Routing is now dependent on both Active Directory sites and Exchange versions.

Versioned routing workflow
Versioned routing workflow

When an Exchange 2010 mailbox user sends a message to an Exchange 2007 mailbox user in the same site, the following occurs:

  1. The Exchange 2010 Mailbox server notifies the Exchange 2010 Hub Transport server of the new mail.
  2. The Exchange 2010 Hub Transport server picks up the message.
  3. The routing agent determines that the version of the Mailbox server that’s the home server of the destination mailbox doesn’t match its own version.
  4. The routing agent locates an Exchange 2007 Hub Transport server in the local site.
  5. The Exchange 2010 Hub Transport server relays the message to the Exchange 2007 Hub Transport server.
  6. The routing agent on the Exchange 2007 Hub Transport server determines that the target mailbox is on an Exchange 2007 Mailbox server in the local site.
  7. The Exchange 2007 Hub Transport server delivers the message to the Exchange 2007 Mailbox server.

Any messages sent from Exchange 2007 mailbox users to Exchange 2010 recipients follow a similar path.

Versioned routing was added to Exchange 2007 in SP2. To have both Exchange 2010 and Exchange 2007 coexist in the same Active Directory site, you must first upgrade your existing Exchange 2007 servers to SP2. When you have Exchange 2010 and Exchange 2007 SP2 in the same Active Directory site, each Hub Transport server handles messages for the Mailbox servers with matching versions. Versioned routing doesn’t change the way intrasite messages are routed.

Consider the following when you have Exchange 2010 and Exchange 2007 in the same site:

  • You can’t specify an incompatible Hub Transport server as the submission server override for a Mailbox server.
  • For a specific Mailbox server, if you don’t have a matching version Hub Transport server in the local site, any messages sent by users on that Mailbox server will remain on the Mailbox server.
  • For a specific Mailbox server, if you don’t have a matching version Hub Transport server in the local site, non-delivery reports (NDRs) will be issued for any messages sent to users on that Mailbox server.
  • Messages sent to mail-enabled public folders are handled the same way messages sent to mailboxes.

The edge synchronization process has been improved in Exchange 2010. In Exchange 2007, EdgeSync replicated all of the configuration and recipient information in its entirety. Especially in organizations with large number of recipients, this took a long time. Exchange 2010 introduces incremental updates for EdgeSync. When you first subscribe an Exchange 2010 Edge Transport server to a site, all the configuration information and recipient data is synchronized. In all subsequent updates, only the changes are replicated. Therefore, synchronization time and network utilization are substantially reduced.

Although Exchange 2007 Hub Transport servers can participate in EdgeSync with Exchange 2010 Edge Transport servers, incremental updates are only available between Exchange 2010 Hub Transport servers and Exchange 2010 Edge Transport servers. By default, when an Exchange 2010 Edge Transport server is subscribed to an Active Directory site that has Exchange 2010 Hub Transport servers, the Exchange 2010 Hub transport servers take over the EdgeSync process. You can fall back to Exchange 2007 Hub Transport servers by disabling the Microsoft Exchange EdgeSync service on the Exchange 2010 Hub Transport servers. However, when you do that, you go back to replicating all data with each EdgeSync update, instead of incremental updates.

If you already use transport rules or journaling in your Exchange 2007 organization, make sure that these features continue to function during the coexistence period, regardless of which Hub Transport server processes a specific message.

The following significant changes were made to transport and journaling rules in Exchange 2010, which have an impact when managing these features in a mixed environment:

  • Format changes Exchange 2010 transport rules support a series of new predicates and actions. To support these new predicates and actions, the format of how transport rules are stored in Active Directory has been modified. Exchange 2007 Hub Transport servers can’t process these new predicates and actions. For a complete list of predicates and actions available in Exchange 2010, see Transport Rule Predicates and Transport Rule Actions.
  • Storage location in Active Directory To prevent the Exchange 2007 Transport Rules agents from loading and attempting to process the rules created in Exchange 2010, the Exchange 2010 rules are stored in a separate Active Directory container. The same situation applies to journaling rules.

When installing Exchange 2010, if the Setup program detects the existence of Exchange 2007 transport rules, these legacy rules are automatically exported to a temporary location and subsequently imported to the Exchange 2010 transport rule container in Active Directory. This process happens automatically without any user interaction.

Note:
If there are any existing Exchange 2010 transport rules, Setup won’t migrate Exchange 2007 rules because the migration overwrites all existing Exchange 2010 transport rules.

Similarly, all Exchange 2007 journal rules are converted and copied to Exchange 2010 journal rules during setup.

The automatic import of rules to Exchange 2010 is only performed during initial setup. During the initial setup, the set of transport rules and journal rules for Exchange 2010 and Exchange 2007 will be synchronized. Going forward, if you make any changes to an existing rule, or create a rule, the rule will be changed in a single location based on the management tool you use. For example, in Exchange 2010, if you use the Exchange Management Shell to create a rule, only the Exchange 2010 rule container in Active Directory will be updated. Similarly if you use the Exchange Management Console (EMC) on an Exchange 2007 server to change an existing rule, only the Exchange 2007 version of that rule will be modified.

To ensure that your transport and journal rules remain consistent across versions, any changes you make must be made twice; once with Exchange 2010 management tools, and once with Exchange 2007 management tools.

In Exchange 2010, the internal and external DSN settings are configured for your entire Exchange organization. In Exchange 2007, these settings were configured on a per-server basis. As a result, these settings are stored in different configuration objects in Active Directory, and just like transport rules, need to be managed separately in a coexistence scenario.

Specifically, the following settings were moved from the Set-TransportServer cmdlet to the Set-TransportConfig cmdlet in Exchange 2010:

  • ExternalDelayDsnEnabled
  • ExternalDsnDefaultLanguage
  • ExternalDsnLanguageDetectionEnabled
  • ExternalDsnMaxMessageAttachSize
  • ExternalDsnReportingAuthority
  • ExternalDsnSendHtml
  • ExternalPostmasterAddress
  • InternalDelayDsnEnabled
  • InternalDsnDefaultLanguage
  • InternalDsnLanguageDetectionEnabled
  • InternalDsnMaxMessageAttachSize
  • InternalDsnReportingAuthority
  • InternalDsnSendHtml

If you need to change any of these settings in your organization, you must make the change once for the organization using the Set-TransportConfig cmdlet in the Exchange 2010 Shell and once for each Exchange 2007 Hub Transport server in the organization using the Set-TransportServer cmdlet in the Exchange 2007 Shell.

Message Tracking Across Versions

Exchange 2010 provides improved message tracking capabilities. End users, as well as administrators, can now track the messages they have sent using the Delivery Reports tool in Exchange Control Panel.

Delivery Reports enable end-to-end message tracking from a single location, providing detailed delivery information including when a message was marked as read. In Exchange 2010, a new message tracking remote procedure call (RPC) and Web service interface was implemented to support Delivery Reports. These interfaces don’t exist in Exchange 2007 and therefore the Delivery Reports feature doesn’t extend to the Exchange 2007 infrastructure in a coexistence scenario. However, it’s possible to use the message tracking tool in Exchange 2007 to track messages between versions.

The following table shows what to do when tracking messages in a mixed environment.

Tracking messages in a mixed environment

Sent from Sent to Tracking Tool

Exchange 2010 mailbox

Exchange 2010 mailbox

Use the Delivery Reports tool in Exchange Control Panel.

Exchange 2010 mailbox

Exchange 2007 mailbox

Use the Delivery Reports tool in Exchange Control Panel. The tool provides message tracking information to the point where the message is transferred to the Exchange 2007 server. No further tracking information will be available for that message.

Alternatively, you can use Tracking Log Explorer in Exchange 2010 or message tracking in Exchange 2007.

Exchange 2007 mailbox

Exchange 2007 or Exchange 2010 mailbox

Use Tracking Log Explorer in Exchange 2010 or message tracking in Exchange 2007.

For the most part, new transport features in Exchange 2010 only function within the realm of Exchange 2010. When to start using the new features depends on the needs of your organization. You can wait until the upgrade is complete, or start as soon as you introduce Exchange 2010 to your environment. To decide when to use the new features in a mixed environment, consider the following information.

Exchange 2010 introduces moderated recipients, so that messages sent to specific recipients can be subjected to an approval process. If you plan to use moderated recipients in a coexistence scenario, be aware of the following issues, which depend on the type of recipient:

  • Mailboxes You can only enable mailboxes on Exchange 2010 Mailbox servers for moderation. After you enable a mailbox for moderation, you must make sure that it isn’t moved back to an Exchange 2007 Mailbox server.
  • Distribution groups and dynamic distribution groups The messages to a moderated distribution group go through the approval process only when that distribution group is expanded on an Exchange 2010 Hub Transport server. Because the distribution group can be expanded on any server, we recommend waiting until all your Hub Transport servers are upgraded to Exchange 2010 before using moderated distribution groups.
  • Mail contacts and mail users Hub Transport servers route messages based on the external e-mail address specified for each mail user or mail contact. Because it isn’t possible to force messages for these recipient types to go through an Exchange 2010 Hub Transport server, you may not want to enable these recipient types for moderation in a mixed environment.

If you enable a recipient for moderation, make sure that the designated moderators use a client that can display the approve and reject options for an approval request. All moderators should use Microsoft Outlook 2010 or Microsoft Office Outlook Web App in Exchange 2010.

Shadow Redundancy

Exchange 2010 introduces shadow redundancy to provide redundancy for messages for the entire time they are in transit. The solution involves a technique similar to the transport dumpster. With shadow redundancy, the deletion of a message from the transport databases is delayed until the transport server verifies that all of the next hops for that message have completed delivery. If any of the next hops fail before reporting successful delivery, the message is resubmitted for delivery to that next hop.

Shadow redundancy is enabled by default on Exchange 2010, and it ensures that messages are redundant only while being transferred between Exchange 2010 servers. After that message is transferred to an Exchange 2007 server, it’s no longer redundant. Therefore, to ensure that a message that originates on an Exchange 2010 server stays redundant until it’s delivered, make sure that it doesn’t get transferred to an Exchange 2007 server. For example, if you are using a hub site that has Exchange 2007 servers, messages between two spokes won’t be redundant even if they both have Exchange 2010 servers.

Advertisements

New OWA features in Exchange Server 2010

When Microsoft released Exchange Server 2010, two aspects of OWA received a lot of attention. First, Microsoft rebranded Outlook Web Access as Outlook Web App, but still refers to the interface as OWA. Second, the Options section of OWA is now the Exchange Control Panel.

With all the fanfare surrounding these two changes, it’s easy to overlook some of the others. This tip introduces a few significant new OWA features.

Cross Web browser support

In Exchange Server 2007, the premium OWA client was designed for use with Internet Explorer 6.0 or higher. If you wanted to use an older version of IE or a non-Microsoft browser, you had to use OWA Light. Outlook Web App 2010 allows cross-browser support; the premium OWA client is compatible with Mozilla Firefox and Apple Safari. This finally gives Mac users the full OWA experience.

Conversation view

OWA can now display email conversations as conversation threads containing sent messages as well as received email, allowing users to keep track of responses (Figure 1). The entire thread can also be deleted or archived . Users also have the option to ignore the remainder of an ongoing conversation.

Messages can be displayed as threads in OWA
Figure 1. OWA displays messages as conversation threads.

Nickname cache

One of my favorite OWA improvements is the addition of a nickname cache. When you begin typing an email address, OWA automatically displays possible matches (Figure 2). This is great when sending email messages to recipients who are not listed in your contacts.

Nickname cache in OWA
Figure 2. OWA 2010’s nickname cache automatically displays possible email address matches.

Message tracking

Another great new feature in OWA is built-in message tracking. If a user wants to see if a message was delivered, they can go to their Sent Items folder, right-click on the message and choose the Open Delivery Report option. OWA will then display a delivery report for the message (Figure 3).

You can perform message tracking through OWA
Figure 3. Users can perform message tracking in Outlook Web App.

Advanced search

You can now perform searches by folder, sender/recipient, and message category (Figure 4). You also have the option of basing the results on either the message’s subject line or the entire message body.

OWA offers advanced search capabilities
Figure 4. OWA now offers advanced search capabilities.

Mail Tips

The Mail Tips feature displays important information about an email message before users click Send. For example, we’ve all encountered instances in which someone clicked Reply to All to a message they were blind copied on. OWA now warns users before they commit this common email blunder (Figure 5).

Mail tips can save OWA users from common mistakes
Figure 5. Mail Tips can save users from making common mistakes.

The Mail Tips feature can give users additional email message guidance. For example, it can inform the sender if the intended recipient has enabled Out of Office Assistant. It also alerts a user when he or she is about to send a message to a large number of recipients.

Message filtering

Message filtering gives users with large mailboxes the ability to view a subset of their messages. With this feature, users can filter mail to display only unread messages, or important messages or messages with attachments, for example (Figure 6).

Filter OWA messages to view a subset
Figure 6. Filtering in OWA lets users filter inboxes to only see specific messages.

Issues to watch for during an Exchange Server 2010 migration

When upgrading from Exchange Server 2007 to Exchange 2010, Microsoft requires that you perform a clean Exchange 2010 installation onto a separate server and then migrate mailbox and public folder content to the new server. You can no longer perform an in-place upgrade.

Because of this, Exchange 2007 and Exchange 2010 must coexist from a short period of time while data is being migrated, to as long as “indefinitely.” No matter how long the coexistence lasts, many Exchange organizations experience unexpected issues during that time. Here are a few problems you may encounter and their fixes.

Edge transport server issues

There appears to be some confusion as to how the edge transport server works in an Exchange 2007/Exchange Server 2010 coexistence situation. When you deploy an Exchange 2007 edge transport server, you must create an edge subscription on your hub transport server. The edge subscription links the edge transport server to Exchange Server 2007’s transport pipeline.

Like Exchange 2007, Exchange Server 2010 also includes both a hub transport server role and an edge transport server role. During coexistence, an Exchange 2007 hub transport server resides alongside an Exchange 2010 hub transport server without any problems. And you can continue to use an Exchange 2007 edge transport server indefinitely.

However, things get tricky when you begin to phase out your Exchange 2007 servers. Exchange 2007 doesn’t allow you to uninstall the hub transport server role without first deleting the edge subscriptions that are bound to that server. When you delete these subscriptions, it has an effect similar to orphaning your edge transport server.

If you’re trying to phase out your Exchange 2007 servers, the method is to deploy an Exchange 2010 edge transport server. Not only can this server peacefully exist with your edge transport servers, but you can load balance SMTP traffic across multiple edge transport servers.

When you deploy your first Exchange 2010 edge transport server, it must be subscribed to an Exchange 2010 hub transport server. You can’t subscribe an Exchange 2010 edge server to an Exchange 2007 hub transport server.

Once you have two parallel edge servers and two parallel hub transport servers in place, you can change the MX record to point to your Exchange 2010 edge transport server. After verifying that mail flow is working, you can remove the edge subscription from the Exchange 2007 hub transport server and decommission both the Exchange 2007 hub transport and edge transport servers.

Issues when managing distribution groups

A common complaint after migrating to Exchange 2010 is that the new server breaks distribution group management. When a user opens Outlook 2007 and attempts to manage his or her distribution groups, he receive the following error message:

Changes to the distribution list membership cannot be saved. You do not have sufficient permissions to perform this operation on this object.

By default, Microsoft designed Exchange Server 2010 so that users cannot manage their own distribution groups unless they have specific permissions to do so. To give users the ability to manage their distribution groups, go into the Exchange Control Panel and follow these steps:

  1. Choose the option to manage My Organization.

  2. Select the User Roles option, which is found in the Users and Groups section.

  3. Select the Default Role Assignment Policy and click the Details button.

  4. Check the My Distribution Groups box

By selecting the My Distribution Groups check box, you can allow users to manage their own groups in Exchange 2010.

BlackBerry BES Agents & Single Exchange Server lookup if mailbox gets moved from DB1 to DB2 within Same Exchange Server….. What caused BB handheld to

Moving Exchange users within the same Exchange server from DB to another DB will break handheld device and you will end up removing the user from BB server and adding it back again to get it working.

The reason why BB will end up not working is related the way how BES does scan to Exchange server. BES uses DN ( distinguish name of the Exchange server ) to scan mailboxes, hence moving users within same exchange server will end up causing BB agents to hose up and not working. ( DN is the same, BB agents will end up mapping to MB which they think the user is located on even you move the MB for same user to another DB within same exchange server.

It basically isn’t smart enough to identify new DB location for the same user, due to LDAP lookup starts with DN of the Exchange server which is not changing and stops there………..

So do we have to assign the static agent for the BB users before we move them within the same exchange server or afterwards? Here Jeff Bakin comes to rescue (-:

  • Got to put users on a static agent after you move their mailboxes
  • When you assign a static agent, it tells BES to do a MAPI rescan of the user, and thus finding the user in the new storage group. If you static agent the user before you move the MB, then the static agent will do the MAPI rescan, find the same mailbox location, then mailbox will get moved, and BES will break anyway.

To assign BlackBerry device users to a static mailbox agent, complete the following steps:

  1. In BlackBerry Manager, select a BlackBerry device user to be assigned to a static agent.
  2. Click Edit Properties.
  3. In the Properties screen, select Advanced.
  4. Set Enable Static Mailbox Agent to true.
  5. Set Mailbox Agent ID to a value between 200-399.

Of course if you are moving users within two different Exchange servers you don’t have to worry about this (-:

Exchange 2010 database recovery

This article explains the steps to restore an exchange database in Exchange 2010, Recovery Database for DAG.

1. Create 2 folders:

  • Database –> D:\Recovery\Database
  • Transaction Logs –> D:\Recovery\Logs

2. Now restore the database which is to be recovered and the subsequent logs exactly to the above location

3. Now follow steps 1-7 mentioned in the article and make the database in a clean shutdown :

Exchange Database Recovery – Using eseutil commands: http://msexchangeguru.com/2009/07/12/exchange-database-recovery-using-eseutil-commands

4. Once the database is in clean shutdown state, rename the original database file to “RecoverDB.edb”.

NOTE: Don’t copy the logs since ESEUTIL /R replayed them into the EDB and the database does not require any more logs to make it clean shutdown.

5. Use the Exchange management Shell to create a recovery database.

This example creates the Recovery Store “RecoverDB” on the server MSX-Exch using the defined path for the database file and transaction logs folder.

New-MailboxDatabase -Recovery -Name RecoverDB -Server MSX-Exch -EDBFilePath D:\Recovery\Database\RecoverDB.edb -LogFolderPath D:\Recovery\Logs

Important: If you have EMC Console open, you will need to restart it to see the newly created Recovery mailbox Store “RecoverDB“ under the Organization Configuration–> Mailbox –>Database Management and its state will be dismounted.

6. Now Right click on the newly created recovery Store and mount it.

7. Now open Shell and type the command as shown:

Get-MailboxStatistics -Database RecoverDB

This will show the list of mailboxes in that database.

8. This is the cmdlet to recover entire mailbox content for the mailbox UserA

Restore-Mailbox -Identity UserA -RecoveryDatabase RecoverDB

This will take time depending on the size of the mailbox.

9. This is the cmdlet to restore UserB mailbox content into UserA mailbox under the RecoverTest folder.

Restore-Mailbox –Identity UserA –RecoveryDatabase RecoverDB –RecoveryMailbox UserB –TargetFolder RecoverTest

10. This is the cmdlet to restore all mailboxes in the database mbx1 which are also present in the RecoverDB database. For every mailbox it will ask you to confirm the action, we do have an option “Yes to All”

Get-Mailbox –Database mbx1 | Restore-Mailbox –RecoveryDatabase RecoverDB

More to come on this!!!

Continuous Replication Block Mode (CRBM) and Continuous Replication File Mode (CRFM) with Exchange 2010 SP1 {beta}

CRBM and CRFM are 2 new feature’s in Exchange 2010 SP1.Exchange 2007/2010RTM relied on log shipping from an Active node to a Passive one which means, after a 1mb log file is committed onto the active database, it will get shipped to the passive copy.

With the release of SP1, Continuous Replication File Mode (CRFM) and Continuous Replication Block Mode (CRBM) are being introduced.

CRFM is the feature responsible for replicating the active database to the passive one by ensuring all logs are copied and upto date on the passive node. Once all logs are upto date, that’s when CRBM comes into picture. With CRBM or block mode, each update on an active database copy is also written onto the passive copy simultaneously. So in the event if the server holding the active database goes down, the passive copy will have all of the updated information to mount itself.

NOTE: CRBM will only be active if all logs are replicated to the passive copy and are upto date.

Exchange 2010 SP1 features and improvements

Let’s take a quick look at some of the new/improved features available with Exchange 2010 SP1 Beta release

1. Exchange 2010 Installation – While installing Exchange 2010, now we get a new option “Automatically install Windows Roles and Features required for Exchange Server” which will install all pre-requisites automatically

2. DAG goes cross sites – DAG or Database availability group in Exchange 2010 RTM version is indeed the most important highlight of the product. However, there was a concern with site resilience with stretched AD sites to have 2 mailbox servers in the primary site before we deploy DAG on a third server. With Exchange 2010 SP1 release Microsoft has made this possible to implement DAG with just 2 mailbox servers; each in one site. Having told that, you need to be aware of a major update on FSW (file share witness) which took a twist with this SP1 release. In RTM version, the FSW would just check for the presence or absence of the mailbox servers to see if the databases are mountable, but with SP1 release the mailbox servers checks the boot time of the FSW server as a cookie to see if the databases can be mounted or not.
So, DO NOT reboot both the FSW server (hub transport server commonly) and the Mailbox server at the same time because you will end up performing a disaster recovery as none of the servers will have the updated information to see if the databases can be mounted or not, so give the cmdlet RestoreDatabaseAvailabilityGroup and mount the databases. Again, the FSW’s preferred location remains to be on the HUB Transport role.

3. Archive mailbox – In RTM version, though we had an option to create an archive mailbox for a user it did not serve the actual purpose since the archive mailbox used to reside on the same mailbox database as the primary/original mailbox. With SP1 release now we have an option to point it to another database which could reside on a low cost storage system.
To do this – Right click on the user – Enable archive – Choose the Archive database where you want the archive mailbox to be pointed to.
So what’s the real point in doing this? Since archive mailbox is not accessed every now and then and not critical to everyday business, we could have a designated standalone server for this purpose on a low cost storage subsystem and the users won’t even know that their primary mailbox and archive mailbox are on different servers. Again, we can have a different backup strategy for these archive servers, maybe once in a week.

4. Retentions policies available within EMC – In RTM, it was a challenge to create retention policies through the shell. Now, if you look at the organization configuration – Mailbox – You will have 2 new tabs, Retention policy tags and Retention policies

5. OWA web app improvements– Themes are back with this SP1 release, click options and select the theme you want. Also we can select an attachment to be added to an email directly from a message.

6. Mailbox search – Log into to ECP (Exchange Control panel) and with administrator privileges you can now search own/other mailboxes. You now have more functionality like search estimate and the de-duplication of search results

7. MailboxExportRequest and MailboxImportRequest – With RTM, I don’t know why MS took off the Export-Mailbox and Import-Mailbox cmdlets. Now with SP1 release, it’s back with better functionality with an option to create a PST out of user mailboxes.
So, we don’t need outlook anymore and you also get an option to export the primary mailbox as well as the archive mailbox to a PST file.

To export an archive to a PST, use this cmdlet:
New-MailboxExportRequest -Mailbox ratish -FilePath “d:\PST\ratish.pst” –IsArchive

To import a PST file into the personal archive for ratish, use this cmdlet:
New-MailboxImportRequest -Mailbox ratish -IsArchive -FilePath “d:\PST\ratish.pst”

8. Certificates for Federation services – In RTM, we had to use a third party CA (Certification authority) like Verisign, Godaddy, Twate etc to issue a certificate so that you could enable Federation with another organization. With SP1, now we have an option to use a Self signed certificate created by a Windows CA in your own organization. If you would ask me, I would still go with Godaddy.

9. Exchange ActiveSync improvements – This is great. With SP1 release now we can do n number of Exchange Activesync administrative tasks from ECP (Exchange control panel). I am going to mention just a few since I personally think they will be of great use.

• List device partnerships for a user
• Delete mobile device partnerships
• Perform remote wipe requests to wipe devices
• List quarantined devices
• Manage EAS rules
• Create rules for all users with a specific mobile device type
• Synchronize SMS messages from mobile to Inbox

10. Store improvements – You can now detect and repair mailbox and database corruption issues with the cmdlet – New-MailboxRepairRequest.
Database Log Growth Troubleshooter, a new feature now allows you to troubleshoot issues with logfiles growing rapidly.
You can now manage Public folder client permissions within the Exchange management console
You no longer need to exit out from Outlook if a mailbox is moved from SP1 DB to another SP1 DB.

11. Auditing – Administrator and mailbox auditing logging improved

Windows Phone 7 !!

Windows Phone 7 is a latest Mobile Operating System( OS) from Microsoft
I had my hands on Windows Mobile OS from 5.0 and could say version 6.5 is the best. Again it requires high end device or the respose time will be “OK”

Microsoft identified this and has primarily worked on “Perfomance and response time” for new OS “Windows Mobile 7”. There is a Significant improvment in the touch screen accelaration.

This OS will have major impact in the mobile market, for more details and demo can be found here
Windows mobile emulator has always been a great tool for getting used with the new features an OS got to offer and for trouble shooting issues too. For people who had never worked on mobile emulator, there is a great step by step article by Ethan McConnell on MsExchangeteam which tought me “How to”. click Here

If you want to test this OS click Here