vijayjain347

A topnotch WordPress.com site


Leave a comment

Cloud Services

Cloud Services

Create highly‐available, infinitely scalable applications and API’s

Quickly deploy and manage powerful applications and services with Windows Azure Cloud Services. Simply upload your application and Windows Azure handles the deployment details – from provisioning and load balancing to health monitoring for continuous availability. Your application is backed by an industry leading 99.95% monthly SLA. You just focus on the application and not the infrastructure. It’s that good.

Use Cloud Services to:

Focus on your application, not the infrastructure

Never worry about patching, hardware failures, or network issues again. Windows Azure Cloud Services is designed to let you build applications that are continuously available even during system upgrades and hardware failures. Now you can just work on the code – the part that matters.

Develop internet‐scale API’s for a world of devices

Every new mobile application needs a powerful set of server side services to power it. With Windows Azure Cloud Services you have everything you need to build the most robust, scalable APIs you can dream up. Take advantage of instant access to infinite scale so you can handle huge success without having to write any new code.
Build modern, cloud architectures

Windows Azure Cloud Services provides the most effective application environment for building the most modern, distributed, computing applications on the planet. Your customers will benefit from apps that respond faster and never go down.
Monitor, alert and auto scale (preview)

Windows Azure provides a number of capabilities that help you better understand the health of your applications. You can monitor the health and availability of your applications using the health metrics dashboard and set up alert rules to be notified when your service availability is degraded. You can also define an event of interest, be notified in real-time when the event occurs, and perform actions based on the events. Windows Azure allows you to configure your application to automatically scale up or down to match the current demands while minimizing costs with auto scale rules. Health and availability monitoring, auto scaling, and alerting are available at no additional cost while in preview.

When you create an application and run it in Windows Azure, the code and configuration together are called a Windows Azure cloud service (known as a hosted service in earlier Windows Azure releases).

By creating a cloud service, you can deploy a multi-tier application in Windows Azure, defining multiple roles to distribute processing and allow flexible scaling of your application. A cloud service consists of one or more web roles and/or worker roles, each with its own application files and configuration.

For a cloud service, Windows Azure maintains the infrastructure for you, performing routine maintenance, patching the operating systems, and attempting to recover from service and hardware failures. If you define at least two instances of every role, most maintenance, as well as your own service upgrades, can be performed without any interruption in service. A cloud service must have at least two instances of every role to qualify for the Windows Azure Service Level Agreement, which guarantees external connectivity to your Internet-facing roles at least 99.95 of the time.

Each cloud service has two environments to which you can deploy your service package and configuration. You can deploy a cloud service to the staging environment to test it before you promote it to production. Promoting a staged cloud service to production is a simple matter of swapping the virtual IP addresses (VIPs) that are associated with the two environments.

CONCEPTS

Cloud service role: A cloud service role is comprised of application files and a configuration. A cloud service can have two types of role

Role instance: A role instance is a virtual machine on which the application code and role configuration run. A role can have multiple instances, defined in the service configuration file.

Guest operating system: The guest operating system for a cloud service is the operating system installed on the role instances (virtual machines) on which your application code runs.

Cloud service components: Three components are required in order to deploy an application as a cloud service in Windows Azure

Cloud service deployment: A cloud service deployment is an instance of a cloud service deployed to the Windows Azure staging or production environment. You can maintain deployments in both staging and production.

Deployment environments: Windows Azure offers two deployment environments for cloud services: a staging environment in which you can test your deployment before you promote it to the production environment. The two environments are distinguished only by the virtual IP addresses (VIPs) by which the cloud service is accessed. In the staging environment, the cloud service’s globally unique identifier (GUID) identifies it in URLs (GUID.cloudapp.net). In the production environment, the URL is based on the friendlier DNS prefix assigned to the cloud service (for example, myservice.cloudapp.net).

Swap deployments: To promote a deployment in the Windows Azure staging environment to the production environment, you can “swap” the deployments by switching the VIPs by which the two deployments are accessed. After the deployment, the DNS name for the cloud service points to the deployment that had been in the staging environment.

Minimal vs. verbose monitoring: Minimal monitoring, which is configured by default for a cloud service, uses performance counters gathered from the host operating systems for role instances (virtual machines). Verbose monitoring gathers additional metrics based on performance data within the role instances to enable closer analysis of issues that occur during application processing.

Windows Azure Diagnostics: Windows Azure Diagnostics is the API that enables you to collect diagnostic data from applications running in Windows Azure. Windows Azure Diagnostics must be enabled for cloud service roles in order for verbose monitoring to be turned on.

Link a resource: To show your cloud service’s dependencies on other resources, such as a Windows Azure SQL Database instance, you can “link” the resource to the cloud service. In the Preview Management Portal, you can view linked resources on the Linked Resources page, view their status on the dashboard, and scale a linked SQL Database instance along with the service roles on the Scale page. Linking a resource in this sense does not connect the resource to the application; you must configure the connections in the application code.

Scale a cloud service: A cloud service is scaled out by increasing the number of role instances (virtual machines) deployed for a role. A cloud service is scaled in by decreasing role instances. In the Preview Management Portal, you can also scale a linked SQL Database instance, by changing the SQL Database edition and the maximum database size, when you scale your service roles.

Windows Azure Service Level Agreement (SLA): The Windows Azure Compute SLA guarantees that, when you deploy two or more role instances for every role, access to your cloud service will be maintained at least 99.95 percent of the time. Also, detection and corrective action will be initiated 99.9 percent of the time when a role instance’s process is not running.

Advertisements


Leave a comment

55 Reasons to Choose Exchange over Gmail for hosted messaging!

1) Email Rights Management: Microsoft Yes. Google NO!
Gmail does not support secure and controlled distribution of e-mail (such as limiting forwarding, preventing saving, and requiring expiration).
2) File-Level Manipulation of Messages (attach mail threads to new mail for reference) Microsoft Yes. Google NO!
Gmail items are not files, so there is no item-level control for cut-and-paste or archiving. Outlook messages (.msg files) can be attached to other e-mails, put in folders, copied to desktop, cut and pasted, etc.
3) Unified and Multiple Views: Microsoft Yes. Google NO!
Gmail has only a conversation view for mail. Outlook has multiple views including AutoPreview. Outlook also provides one unified view of all user data (e-mail, calendar, etc.).
4) Right Click and Multiple Select: Microsoft Yes. Google NO!
In Gmail, simple actions, like “mark as unread,” require extra clicks and user actions because of the use of check boxes and buttons, decreasing user productivity. Much more difficult with a large number of items.
5) MailTips: Microsoft Yes. Google NO!
Outlook 2010 offers automated guidance to avoid e-mail mistakes and be more effective, such as notifying the user when the recipient is out of office (before the message is sent), or warning the user that he or she is sending to a large distribution list.
6) Clean-Up: Microsoft Yes. Gmail NO!
Outlook 2010 offers advanced and automated capabilities to cleanup the user’s e-mail account, such as AutoArchive, and Mail Cleanup.
7) Social Connector: Microsoft Yes. Google NO!
Outlook 2010 shows communication history, status updates, and social networking service updates from LinkedIn and Microsoft Windows Live™, in people-centric views.
8) QuickSteps: Microsoft Yes. Google NO!
Save time by automating common information worker e-mail needs; reply to all meeting attendees, reply to manager, reply and delete, and more.
9) Unified Communication (voice mail, SMS/text, instant messaging, RSS feeds, etc.): Microsoft Yes. Google NO!
Google offers no inbox management of communication other than e-mail.
10) Instant Messaging/Presence Integration: Microsoft Yes. Gmail partial!
Gmail does not provide integrated presence capabilities within mail messages. Users must use the application sidebar or open the secondary application to search for a user.

Outlook interoperability with Gmail vs Exchange Online
11) Attachments and Rich Formatting: Microsoft Yes. Google NO!
Rich formatting in e-mail results in layout problems. Attachments and rich formatting cannot be added to Gmail calendar items or contacts.
12) Permissions and Delegation: Microsoft Yes. Google NO!
In Gmail the user cannot share mail or contact folders, or calendars, and cannot delegate permissions and access to others, such as administrative assistants.
13) E-mail Rules (includes Out of Office settings): Microsoft Yes. Google NO!
Client-side rules only. For example, no Out of Office/Vacation responder support.
14) Encrypted Mail (message vs transport): Microsoft Yes. Google NO!
Not supported as a feature in Outlook if using Gmail back end; prevents mail from being sent with an ambiguous “unexpected error.”
15) Mail Tracking and Receipts: Microsoft Yes. Google NO!
Delivery receipts do not work with Gmail back end, but read receipts do.
16) Shared User Calendars: Microsoft Yes. Google NO!
Outlook users cannot share their calendars if using a Google Apps back end, and cannot delegate permissions for others to manage their calendars, such as administrative assistants.
17) Meeting Attendees and Responses: Microsoft Yes. Google NO!
Attendees can be required only, not optional. Responses can be accept or decline only, not tentative. The user cannot delete attendees from exceptions to recurring events.
18) Distribution Lists and Groups: Microsoft Yes. Google NO!
No GAL support for groups or distribution lists with Google Apps mail.
19) Tasks and Reminders: Microsoft Yes. Google partial!
To-do flags and reminders work and can be set locally in Outlook. However, voting buttons and tasks cannot be sent to other Gmail users.
20) Folder Organization: Microsoft Yes. Google partial!
Folders work for e-mail in Outlook, but multiple contact folders sync to the cloud as one set of contacts.
21) Calendar Free/Busy Information: Microsoft Yes. Google partial!
Busy/Free requires deployment of GAL Generator and provides no support for Out of Office status. GAL Generator must be run everytime users are added/deleted or emails addresses edited.
22) Synchronized Group Calendars: Microsoft Yes. Google partial!
Google Apps does not provide as complete a collaboration solution, like SharePoint, for group calendaring that can be synchronized to Outlook for tracking project meetings, timelines, etc.
23) Company Directory: Microsoft Yes. Google partial!
Global Address List (GAL) is missing phone number, company name, business unit, work office location, manager, and other key metadata fields to help identify unique users. In addition IT must deploy the GALSYNC tool for the limited functionality.

IT Administration and Support (Service Level Agreements)
24) Configurable Storage and Quotas: Microsoft Yes. Google NO!
GAPE gives all users 25 GB; quotas cannot be set. Only the Microsoft offering allows smaller mailboxes for deskless, non-information-worker employees.
25) Software Add-ons and Client Installs: Microsoft Yes. Google NO!
Google requires add-ons and plug-ins not covered by the Google Apps SLA. This is especially true for offline access requiring Google Gears and Google Apps Sync, which need to be installed on each client machine that requires support for Outlook.
26) IT Architecture Flexibility: Microsoft Yes. Google NO!
Exchange can be configured for on-premises, off-premises, or hybrid configurations to coexist with the cloud. Google Apps supports only hosted model for all users.
27) Hosted BlackBerry Support (BES): Microsoft Yes. Google NO!
Exchange Online provides hosting for BlackBerry Enterprise Server (BES) to support BlackBerry users. Google, requires customers to run their own BES on-premises to support their BlackBerry community.
28) Data Center Locations: Microsoft Yes. Google NO!
Exchange Online provides services based out of known locations, with options for dedicated servers. Google stores data in multiple locations and will not track where the data resides.
29) Directory Integration: Microsoft Yes. Google partial!
Active Directory support with Google Apps is a separate download/utility. Limited GAL support in Gmail, with groups and distribution lists not supported.
30) Service Levels and Uptime: Microsoft Yes. Google partial!
Exchange has a 99.9 percent financially backed uptime guarantee. Google does not cover outages of less than 10 minutes, even if consecutive, and offers only service extension as compensation.

Migrating from On-Premise email – IT Administration and Support (Service Level Agreements)
31) Group Policy: Microsoft Yes. Google No!
Not supported with Google Apps.
32) User Data Migration (automated tools): Microsoft Yes. Google No!
Much of the user’s existing data (including archived mail, contacts, tasks, recurring calendar items, etc.) will not migrate over to Google Apps or will require unsupported manual tools or costly third-party applications to complete the migration. In order to migrate users locally archived messages to Google, tools must be run on each users machine.
33) Mail and Calendaring Coexistence During Transition: Microsoft Yes. Google No!
BPOS provides gateways that correctly translate complex message types and calendar invitations so they are delivered intact to the migrated users now running Outlook/Exchange. Google, however, does not provide these gateways, so links, rich text formatting, and attachments are stripped from mail and calendar items being sent by Lotus Notes users.
34) Directory Coexistence During Lotus Notes Transition: Microsoft Yes. Google No!
BPOS provides full directory synchronization during the transition for Lotus Notes users, so mail and calendar requests can be used without interruption. Google does not provide this service, thereby forcing users to manually type the e-mail addresses of colleagues in order to send messages and calendar items.
35) Mail-Enabled Workflow Application Support: Microsoft Yes. Google No!
Google does not support the translation of workflow messages, including doc links, for Lotus Notes applications. These applications will need to be rewritten to utilize different notification methods, which can be extremely costly for IT support groups. BPOS provides a utility that does perform the message translation, so workflow items can be acted on by users who have migrated to the hosted environment without issues.
36) User Data Migration (automated tools): Microsoft Yes. Google No!
Both BPOS and Google provide automated tools to transition users data from Exchange to their hosted environments. However, Google does not migrate distribution lists or recurring calendar items. With Outlook front end to Google Apps, IT department must deploy, configure, and maintain Google Apps Sync for every PC with Outlook.
37) Mail and Calendaring Coexistence During Transition: Microsoft Yes. Google No!
Exchange Online offers full compatibility for e-mail and calendar requests during the transition. Googlewill not transfer items, such as rich text formatting and attachments for calendar invitations (meeting agendas, etc.), Google Apps GAL with Outlook as a front end requires a registry entry to be updated on each user machine.
38) Directory Coexistence During Exchange On-Premise Transition: Microsoft Yes. Google No!
Both Exchange Online and Google provide directory synchronization during the transition; however, Google restricts synchronization to basic fields (first name, last name, e-mail address), Exchange Online synchronizes additional fields to provide valuable identity information (phone number, office location, manager, business unit, etc.).
39) End-User Support and Impact: Microsoft Yes. Google No!
Prior to the migration, extensive end-user communication is needed to explain the data transfer and conversion implications, as well as the features differences. The BPOS team has standardized communication and change-management plans built into its migration project model. Plus, it provides access to customized “How To” and “FAQ” documents for all transitioned users. Google, on the other hand, sends out only a single e-mail notification before the migration and pushes all first-line support, communications, change management, and training to the customer.

Mobility
40) Mobile Directories: Microsoft Yes. Google No!
Exchange has mobile GAL support for all Windows Mobile 6.0 devices. There is no mobile directory support for Gmail, except on BlackBerry, with the Google Apps Connector for BlackBerry Server installed.
41) Synchronization: Microsoft Yes. Google No!
E-mail is synchronized similarly across both on all devices. Google supports only one-way calendar sync for the BlackBerry. Contact sync on most devices other than Windows Mobile requires Google Sync App install. Exchange ActiveSync supports full over-the-air sync of contacts, calendars, and e-mail.
42) BlackBerry Support: Microsoft Yes. Google partial!
Google requires customers to support an on-premises BES for every 500 users, whereas the Exchange offering can support up to 2,000 users per server and can be hosted off-premises. Google supports server-to-device calendar sync only.
43) iPhone Support: Microsoft Yes. Google partial!
Google sync support for iPhone is a Beta environment. Limitations include sync issues with recurring events. In addition, actions in Gmail may have different results, e.g., archiving messages moved to the trash and attendee status for messages not clearly defined (yes/no/maybe not available; only check mark as a hint will appear). No way to reply to calendar event with a message via the iPhone.

Offline Access
44) Software Add-ons and Client Installs: Microsoft Yes. Google NO!
Offline access with Google requires the download and installation of Google Gears (unsupported by Service Level Agreement). Exchange requires no such installation, as all offline features are supported by the Outlook client.
45) Corporate Directory Access: Microsoft Yes. Google NO!
Exchange has offline GAL support. There is no offline directory support for Gmail.
46) Edit/Create Personal Contacts: Microsoft Yes. Google NO!
Users cannot create or edit existing personal contacts when offline.
47) Overall Disconnected Experience: Microsoft Yes. Google NO!
While offline, Google users cannot spell check, edit, or create contacts, nor edit or create meetings in the calendar, etc. No Google Labs features are available offline.
48) Offline Attachments: Microsoft Yes. Google partial!
If a Google Apps user receives a Microsoft Office document while offline, the user must convert it to HTML, with most formatting lost, in order to view it.

Security
49) Information Rights Management: Microsoft Yes. Google NO!
Information Rights Management (IRM) allows individuals and administrators to specify access permissions to documents, workbooks, and presentations. This helps prevent sensitive information from being printed, forwarded, or copied by unauthorized people. Google does not support IRM.
50) SSL: Microsoft Yes. Google partial!
Microsoft provides SSL, a “by default approach” to help ensure security. .Google SSL support varies by service and is available for e-mail, chat, calendar, docs, and sites. SSL access is not available for the Google Apps Start Page, Google Video for Business, and the Google Talk desktop client. Forcing HTTPS can make Gmail a little slower, and if you enable SSL, you will not be able to see your mail in the Gmail gadget on the Google Apps Start Page, since it is not served over SSL.
51) Encrypted Mail Support: Microsoft Yes. Google partial!
Encrypted mail is extra fee for Postini with Gmail.
52) Offline Security: Microsoft Yes. Google partial!
Cross-site scripting has been shown to be able to compromise the security of Google Gears, which uses client-side JavaScript to manipulate local data. Local data are stored in an unencrypted state and based on the physical and access security of the users machine.

Pricing and Options
53) Mail-Only Offering: Microsoft Yes. Google NO!
Both Microsoft and Google offer standard hosted e-mail services. Google’s standard service supports corporate domains and is free, but it is an unmanaged solution and ad-funded. Microsoft’s Exchange Deskless offer costs $2 per month but is a managed service offering technical assistance and support for corporate domains.
54) Hybrid Services (interoperated on-premises and off-premises offerings): Microsoft Yes. Google NO!
Microsoft offers the ability to have on-premises users supported by a physical infrastructure, hosted users supported by Microsoft data centers, or any combination of the two. The two environments can be integrated to allow for shared directories, IM/presence, etc. Google has only a hosted option.
55) Enhanced E-mail Services: Microsoft Yes. Google partial!
Both Microsoft and Google offer enhanced hosted e-mail services. GAPE offers support for corporate domains, an uptime SLA, and anti-virus and anti-spam. It costs $50 per year, per user. Microsoft offers the same services with a monthly payment option of $5 per month or $6O per year.
You also have the ability to localize your data into one hosted server. This guarantees that you know the location of your data. Google cannot offer this service. (Microsoft puts dedicated servers in place to BPOS versus the consumer offering of Hotmail.) Google has consumer and business GAPE users on the same infrastructure.


Leave a comment

Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure

Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure

In this articles series, steps necessary to deploy an Exchange 2013 hybrid lab based on Windows Azure virtual machines.
http://www.msexchange.org/articles-tutorials/office-365/exchange-online/deploying-exchange-2013-hybrid-lab-environment-windows-azure-part1.html
http://www.msexchange.org/articles-tutorials/office-365/exchange-online/deploying-exchange-2013-hybrid-lab-environment-windows-azure-part2.html
http://www.msexchange.org/articles-tutorials/office-365/exchange-online/deploying-exchange-2013-hybrid-lab-environment-windows-azure-part3.html
http://www.msexchange.org/articles-tutorials/office-365/exchange-online/deploying-exchange-2013-hybrid-lab-environment-windows-azure-part4.html
http://www.msexchange.org/articles-tutorials/office-365/exchange-online/deploying-exchange-2013-hybrid-lab-environment-windows-azure-part5.html
http://www.msexchange.org/articles-tutorials/office-365/exchange-online/deploying-exchange-2013-hybrid-lab-environment-windows-azure-part6.html
http://www.msexchange.org/articles-tutorials/office-365/exchange-online/deploying-exchange-2013-hybrid-lab-environment-windows-azure-part7.html
http://www.msexchange.org/articles-tutorials/office-365/exchange-online/deploying-exchange-2013-hybrid-lab-environment-windows-azure-part8.html
http://www.msexchange.org/articles-tutorials/office-365/exchange-online/deploying-exchange-2013-hybrid-lab-environment-windows-azure-part9.html
http://www.msexchange.org/articles-tutorials/office-365/exchange-online/deploying-exchange-2013-hybrid-lab-environment-windows-azure-part10.html
http://www.msexchange.org/articles-tutorials/office-365/exchange-online/deploying-exchange-2013-hybrid-lab-environment-windows-azure-part11.html


Leave a comment

How to migrate from Exchange 2007 CCR to Exchange 2010 DAG on existing hardware

How to migrate from Exchange 2007 CCR to Exchange 2010 DAG on existing hardware

Introduction
If you are currently running an Exchange Server 2007 Organization with high availability configuration in a Cluster Continuous Replication Setup and you are planning to upgrade to Exchange Server 2010 SP1, you are often considering a way to move without changing your hardware. The reason for this might be that the hardware is only 1-2 years old or has been leased for five years.
In these series of articles we will discuss the way to move to Exchange 2010 SP1 DAG (Database Availability Group) setup without having to buy new hardware. The plan implicates that you are losing high availability over a short period of time but if you are planning the migration on a straight-forward project, the time window you are running with no high availability can be calculated and is quite short.

Preparations
As one of the first steps before you start your project plan to move to Exchange 2010 SP1 you should check if your existing hardware is suitable for Windows Server 2008 R2. In general one of the preparation steps is to flash your servers ROM to the newest available release to make sure that Windows Server 2008 R2 is supported.
After being successful with your hardware compatibility the next step is to update your Exchange Server 2007 environment to be prepared for Exchange Server 2010 SP1. The easiest way to do this is updating your current messaging infrastructure (all servers in your Exchange Server 2007 environment) to Exchange Server 2007 SP3. The way to update is starting on your servers with the Client Access Role, moving to those ones that hold the Hub Transport Role and finally moving to the Mailbox Server Role.
Also you need to make sure to update your CCR environment as described below in order to make everything work properly after the update.

Updating Exchange Server 2007 CCR to Service Pack 3
Basically Exchange Server 2007 supports rolling Service Pack Updates, you only need to make sure that you are always upgrading the passive cluster node.

The straight forward method can be run as follows:
1. Move all cluster resource group to Node A
2. Stop performance counter Services and System Center Operations Manager Services (if installed)
3. Restart the Remote Registry Service
4. Open a Command prompt and navigate to the Exchange Server 2007 SP3 installation files logged on as Exchange Organization administrative Group member
5. Run the following command:

SETUP /m:upgradeSetup
6. Restart Node B after Setup has completed
7. After having finished the passive Node B is running SP3
8. Now you need to run the Stop-ClusteredMailboxServer cmdlet to stop the clustered mailbox server using the following syntax:

Stop-ClusteredMailboxServer -StopReason “Upgrade to SP2”
9. Now we need to move the clustered mailbox server to Node B using

Move-ClusteredMailboxServer -TargetMachine
-MoveComment “Upgrade to SP2”
10. At a Command Prompt navigate to the Exchange 2007 SP3 installation files
11. Run the following command to upgrade your CCR Cluster:

Setup /upgradecmsSetup
12. Setup upgrades the CCR server and brings it back online again
13. Now we need to stop any services that have open handles to performance counters and System Center Operations Manager Service on Node A
14. Restart the Remote Registry service
15. Open a Command Prompt and then navigate to the Exchange 2007 SP3 installation files
16. Run the following command on Node A to upgrade it to Exchange 2007 SP3:

Setup /m:upgradeSetup
17. Restart Node A to finish the upgrade to Exchange Server 2007 SP3 completely
18. Use Exchange Best Practice Analyzer to check whether further configuration changes need to be done before the update

Update Active Directory Schema to Exchange Server 2010 SP1
As a next step we will need to import the Exchange Server 2010 SP1 schema to your Windows Server 2008 based Active Directory environment.
The easiest way to do this is as follows:
1. Logon as member of the Active Directory Groups of Enterprise Administrators and Schema Administrators on one of your existing Exchange Servers.
2. At first we need to make sure that non Exchange Server 2007 or 2010 servers can run properly in the new security model:

setup /PrepareLegacyExchangePermissions or setup /pl

If no Exchange Server 2003 or earlier versions are part of your Exchange Organization you can successfully skip this command.
3. Afterwards we need to import the new schema entries to your Active Directory Schema Master using this command:

setup /PrepareSchema or setup /ps
4. Now we need to automatically create some security groups and further settings for Exchange Server 2010 SP1:

setup /PrepareAD or setup /p
5. Finally we need to make sure that all security groups are properly filled in using:

setup /PrepareAllDomains or setup /pad

The easiest way is to run this properly for all existing domains in one step. If you do not want to do this, you can run

setup /PrepareDomain or setup /pd
After having finished this procedure you should make sure that Active Directory replication took place and has finished successfully. You can check this using the Event Log on your Domain Controllers.

Decommissioning your passive Exchange Server 2007 SP3 Node
Now after having finished all necessary steps we can start over with the migration to Exchange Server 2010 SP1 DAG by decommissioning your passive Exchange Server 2007 SP3 node. When starting this task, you will lose redundancy temporary.
The steps for this procedure are as follows:
1. Make sure that all Databases are running on the active node
2. Move responsibility of OAB-Generation to the active node
3. Uninstall Exchange Server 2007 SP3 from your passive cluster node using:

Setup /mode:uninstall
4. Evict the formerly passive node from Failover Clustering
5. Disjoin the machine from Active Directory and shutdown the computer
Finally we have finished freeing up server hardware to prepare the rollout of Exchange Server 2010 SP1 on this machine in the future.

After having discussed the way to prepare the Exchange Server 2010 Service Pack 1 deployment in your Exchange 2007 CCR based deployment in the first part of this article, we now need to discuss how to go on with further steps and finish the deployment.
Install Exchange 2010 Mailbox Server Role
At first we need to install Windows Server 2008 R2 on the former Exchange Server 2007 server. After this we will install Exchange Server 2010 SP1 with the following roles on the machine:
• Mailbox Server Role
• Client Access Server Role
• Hub Transport Role
The roles “Client Access” and “Hub Transport” need to be moved after the decommissioning of the Exchange 2007 server environment. Then the existing Hub Transport and Client Access servers based on Exchange Server 2007 are not needed anymore and can be removed from the organization.

Configure Client Access and Hub Transport
To make sure that the new mailbox server can be contacted from the clients and that routing is impossible, we now need to transfer the Exchange 2007 Client Access and Hub Transport Server configuration to their Exchange Server 2010 pendant.
Moving Mailboxes
After having all mailboxes moved from Exchange 2007 to Exchange 2010 SP1 to Exchange Server 2007 including the internal Exchange mailboxes, we can uninstall the last Exchange 2007 Mailbox CCR node and finally uninstall the existing Exchange Servers with the Client Access Role and the Hub Transport role.
This means we now have a native Exchange 2010 Service Pack 1 Organization, but need to make sure that no fragments of Exchange Server 2007 are left in Active Directory. This can be done by manually researching the “Configuration Partition” of Active Directory for entries that include the old Exchange Server 2007 names. Before deleting them manually, which is the only way to get rid of them, you should create a System State Backup of the Server to have a roll back if things are missing because of having deleted false entries.
Installing the second DAG member
After a clean installation of Windows Server 2008 R2 Enterprise Edition on the formerly existing Exchange 2007 box, we need to install Exchange Server 2010 SP1 Mailbox Server Role in the corresponding version that already exists as the first Exchange 2010 Server.
Now we need to join this server to the existing DAG, this can be done quite easily using the DAG container in the Organization Configuration of the Exchange Server 2010 System Manager. Afterwards, we need to prepare the most time consuming task of creating the mailbox database copies from DAG Server 1 to DAG Server 2. Depending on the size of the mailboxes and the server and network performance this tasks may take from some hours to some days. You may find out that there are some databases in your Environment that do not have proper database states. If this is the case, you will need to check this using the well-known recovery tasks of Exchange. In the case the database copy task of some mailboxes does not finish successfully, you have a way to copy the database files, log files and checkpoint files manually from one server to another with stopped Exchange Information Store services on the source Exchange Server.

Transferring the Client Access and Hub Transport Server Role
After decommissioning the last Exchange 2007 mailbox server, we do not need the Hub Transport and Client Access Server anymore. So we can uninstall and reinstall them with Windows Server 2008 R2 and the corresponding Exchange Server 2010 server roles. Due to the configuration lives in Active Directory, we only have to transfer some of the settings to the new role members. Now, having Exchange Server 2010 based dedicated Hub Transport and Client Access Server roles, we need to uninstall the hub transport and client access server role from the first DAG member, where it has been installed for the migration time.
Finalizing the deployment
Finally you should check every connector and configuration for entries that point to the old servers. You should delete these entries as to get rid of them totally.
After a successful integration of the second DAG member, you should define a time window when you check if high availability is working properly, this means the following tasks should then be checked:
1. Active Directory Replication took place properly.
2. One database goes to shutdown state è this should result in switching over to the passive Database node copy.
3. The database goes online again è this should result in do not creating a fall back solution, because this is by-design.