Friday 4 March 2016

Migrate from Exchange 2010 SP3 to Exchange 2013 CU11


- 8gb RAM

- 4 processors
- 2012 R2 - With updates
- Exchange 2010 SP3 CU 12 
- net framework 4.5 (do not install's a guide on how to remove it if it's installed)
- check location of arbitration mailboxes
- recreate them if need be

Open Powershell as administrator:

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

then restart

Next, install the following software in this order.

  1. Unified Communications Managed API 4.0 Runtime
  2. Microsoft Office 2010 Filter Pack 64 bit
  3. Microsoft Office 2010 Filter Pack SP1 64 bit


Open powershell as administrator

Install-WindowsFeature RSAT-ADDS

Then complete Windows Updates and make sure it's fully patched before installation.

Open file and extract it to folder.

Copy Command Prompt into the folder, open Command Prompt as Administrator

setup /PrepareAD /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms

setup.exe /Mode:Install /Roles:ClientAccess,Mailbox /IAcceptExchangeServerLicenseTerms

While going through select the following roles for installation

Finally: Set-ClientAccessServer -Identity LJD-E1501 -AutoDiscoverServiceInternalURI   ---------------------------

Exporting the certificate as PFX format from Exchange 2010

Because we will move the same HTTPS name from Exchange 2010 to Exchange 2013 we can re-use the same SSL certificate by exporting it from the existing Exchange server.
To perform this step, log in to the Exchange 2010 server and launch the Exchange Admin Console. Navigate to Server Configuration in the Exchange Management Console, select the valid SSL certificate with the correct name, then select Export Exchange Certificate from the Actions pane on the right hand side.
Figure 17: Exporting the SSL certificate
The Export Exchange Certificate wizard should open. Select a location to save the Personal Information Exchange(PFX) file and an appropriate strong password, then choose Export:
Figure 18: Selecting a path and password for the PFX file
Make a note of this location, as we’ll use it in the next step.

Importing the Certificate PFX File

Back over on the Exchange 2013 server, open the Exchange Admin Center and navigate to Servers>Certificates. Within the more (…) menu choose Import Exchange Certificate:
Figure 19: Importing the Exchange 2010 SAN certificate
In the Import Exchange Certificate wizard we’ll now need to enter a full UNC path to the location of the exported PFX file, along with the correct password used when exporting the certificate from Exchange 2010:
Figure 20: Specifying a UNC path to the PFX location
After entering the location and password, we’ll then choose Add (+) to select our Exchange 2013 server, LJD-E1501, as the server to apply this certificate to. We’ll then choose Finish to import the certificate:
Figure 21: Specifying the Exchange 2013 server as a target for the PFX import

Assigning the SSL certificate to services

Although we now have the SAN SSL certificate installed on the Exchange 2013 server it’s not automatically used by services. We’ll need to specify which services we want to allow it to be used with.
To perform this step, within Certificates select the certificate and then choose Edit (Pencil icon):
Figure 22: Choosing properties for the SSL certificate
Next, choose the Services tab in the Exchange Certificate window and select the same services chosen for Exchange 2010, typically Internet Information Services (IIS):

Post-Installation Configuration Changes

Configuring Exchange URLs using the Exchange Management Shell

The Exchange Management Shell also provides the functionality to change the Exchange URLs for each virtual directory, however unless you know the syntax it can be a little intimidating - and even if you do know the relevant syntax, typing each URL can be a little time consuming too.
We can use a PowerShell script to make this process simpler.
The first two lines of the script are used to specify the name of the Exchange 2013 server, in the $Server variable, and the HTTPS name used across all services in the $HTTPS_FQDN variable.
The subsequent lines use this information to correctly set the Internal and External URLs for each virtual directory:
$Server = "LJD-E1501" 
Get-OWAVirtualDirectory -Server $Server | Set-OWAVirtualDirectory -InternalURLhttps://$($HTTPS_FQDN)/owa -ExternalURL "https://$($HTTPS_FQDN)/owa"
Get-ECPVirtualDirectory -Server $Server | Set-ECPVirtualDirectory -InternalURL "https://$($HTTPS_FQDN)/ecp" -ExternalURL "https://$($HTTPS_FQDN)/ecp"
Get-OABVirtualDirectory -Server $Server | Set-OABVirtualDirectory -InternalURL "https://$($HTTPS_FQDN)/oab" -ExternalURL "https://$($HTTPS_FQDN)/oab"
Get-ActiveSyncVirtualDirectory -Server $Server | Set-ActiveSyncVirtualDirectory -InternalURLhttps://$($HTTPS_FQDN)/Microsoft-Server-ActiveSync -ExternalURL "https://$($HTTPS_FQDN)/Microsoft-Server-ActiveSync"
Get-WebServicesVirtualDirectory -Server $Server | Set-WebServicesVirtualDirectory -InternalURL "https://$($HTTPS_FQDN)/EWS/Exchange.asmx" -ExternalURLhttps://$($HTTPS_FQDN)/EWS/Exchange.asmx
In the example below, we've specified both our server name LJD-E1501 and HTTPS name then updated each Virtual Directory accordingly:
Figure 1: Updating Internal and External URL values

Configuring Outlook Anywhere

After updating the Virtual Directories for Exchange, we'll also update the HTTPS name and authentication method specified for Outlook Anywhere.
As Outlook Anywhere is the protocol Outlook clients will use by default to communicate with Exchange Server 2013, replacing MAPI/RPC within the LAN, it's important that these settings are correct - even if you are not publishing Outlook Anywhere externally.
During co-existence it's also important to ensure that the default Authentication Method, Negotiate, is updated to NTLMto ensure client compatibility when Exchange 2013 proxies Outlook Anywhere connections to the Exchange 2010 server.
To update these values, navigate to Servers and then choose Edit (Pencil icon) against the Exchange 2013 server:
Figure 2: Editing the server properties
 In the Exchange Server properties window choose the Outlook Anywhere tab. Update the External Host Name,Internal Host Name and Authentication Method as shown below:
Figure 3: Updating settings for Outlook Anywhere
Naturally you can also accomplish this with PowerShell, however it's just as quick to use the Exchange Admin Center for a single server.
With these settings configured, along with the obligatory iisreset /noforce to ensure configured is re-loaded into IIS we could in theory move client access across from Exchange 2010 to Exchange 2013. Before we do that we will first make some additional configuration changes.

Configuring Receive Connectors

We’ll need to ensure that the same settings are applied to Receive Connectors on Exchange 2013 as per our Exchange 2010 staging server. Default and Client connectors are already created and do not typically need to be altered. The defaults for Exchange Server 2013 allow email from the internet or spam filter to be delivered without adding an additional permission.
Many organizations do allow users to relay mail through Exchange from application servers, so we will use this as an example to illustrate how the process is slightly different when compared to Exchange 2010.
To begin, launch the Exchange Admin Center and navigate to Mail Flow>Receive Connectors and after selecting the Exchange 2013 server from the list, then choose Add (+) to create a new Receive Connector:
Figure 4: Viewing and creating new Receive Connectors
On the first page of the wizard, enter the name for the receive connector. For consistency we’ve specified the server name after entering Anonymous Relay. Select Frontend Transport as the role and choose Custom as the type:
Figure 5: Creating a new Anonymous Relay connector
On the next page, we'll be provided with the opportunity to specify Network Adapter Bindings - the IP address and TCP/IP port that the receive connector will listen on. Our example receive connector will listen on the standard port for SMTP, port 25:
Figure 6: Selecting TCP/IP IP listener and port bindings
On the final page of the wizard, we'll choose which IP addresses that the receive connector will accept mail for.
This allows multiple receive connectors to listen on the same TCP/IP port and IP address and swing into action depending on the remote IP address of a client. As an example, if our anonymous connector on Exchange 2010 only allowed mail relay from the IP addresses, we'll specify that range here:
Figure 7: Specifying a range of IP addresses that will be able to connect to this connector
After completing the wizard, we will then open the new Receive Connector’s properties page by selecting it from the list, then choosing Edit, as shown below:
Figure 8: Editing properties for the new Receive Connector
In the Exchange Receive Connector window, select the Security tab. Then within the Authentication section selectExternally secured to indicate our anonymous relay is from secure IPs; then under Permission Groups, chooseExchange Servers and Anonymous users:
Figure 9: Updating settings to allow relay

Moving Default Mailbox Databases

We will move the initial database created by Exchange Server 2013 setup and make it our first Mailbox Database.
To perform this action we will perform a two-step process using the Exchange Management Shell.
First, launch the Exchange Management Shell and use the following command to rename the database to DB01:
Get-MailboxDatabase -Server <Server> | Set-MailboxDatabase -Name DB01
Figure 10: Renaming the existing Database
In the example above you'll see that by executing the Get-MailboxDatabase cmdlet before making the change we see its default name – “Mailbox Database” with a random suffix. After making the change, the name is changed to something more appropriate.
With the database name changed, it still remains in the same location. Move both the Database file and the associated log files to their respective final destinations using the Move-DatabasePath cmdlet with the -EdbFilePath and -LogFolderPath parameters:
Move-DatabasePath -Identity DB01 -EdbFilePath C:\ExchangeDatabases\DB01\DB01.EDB -LogFolderPath C:\ExchangeDatabases\DB01_Log  
Figure 11: Moving the existing database
When moving the database it will be dismounted. The files will then be moved to the new location and the database and log locations updated in Active Directory. Finally the database will be re-mounted.

Creating Additional Mailbox Databases

Next, create additional Mailbox Databases to match our design specifications. We can create the mailbox databases using either the Exchange Admin Center or the Exchange Management Shell.
In this example we will use the Exchange Management Shell, which for a larger number of databases will be faster and more accurate.
The cmdlets used are New-MailboxDatabaseRestart-ServiceGet-MailboxDatabase and Mount-Database.
In the example shown below we will use the first cmdlet to create the databases, restart the Information Store to ensure it allocates the correct amount of RAM, then after retrieving a list of all databases we will ensure they are mounted:
New-MailboxDatabase -Name DB02 -Server <Server> -EdbFilePath C:\ExchangeDatabases\DB02\DB02.EDB -LogFolderPath C:\ExchangeDatabases\DB02_Log
New-MailboxDatabase -Name DB03 -Server <Server> -EdbFilePath C:\ExchangeDatabases\DB03\DB03.EDB -LogFolderPath C:\ExchangeDatabases\DB03_Log
New-MailboxDatabase -Name DB04 -Server <Server> -EdbFilePath C:\ExchangeDatabases\DB04\DB04.EDB -LogFolderPath C:\ExchangeDatabases\DB04_Log
New-MailboxDatabase -Name DB05 -Server <Server> -EdbFilePath C:\ExchangeDatabases\DB05\DB05.EDB -LogFolderPath C:\ExchangeDatabases\DB05_Log
Restart-Service MSExchangeIS
Get-MailboxDatabase -Server <Server>| Mount-Database  
Figure 12: Creating new databases and mounting databases using PowerShell

Configuring Mailbox Database Settings

After we have moved our first Mailbox Database and created our additional mailbox databases, we will now need to configure each database with the correct limits.
The limits chosen for our example environment are shown below, along with retention settings for mailboxes:
Warning Limit
Prohibit Send Limit
Prohibit Send/Receive Limit
Keep Deleted Items for (days)
Keep Deleted Mailboxes for (days)
It’s possible to configure this using the Exchange Admin Center, but for multiple databases, use Exchange Management Shell to ensure consistency. Using a combination of the Get-MailboxDatabase cmdlet and Set-MailboxDatabase cmdlet make the changes, using the values from the table above:
Get-MailboxDatabase -Server <Server> | Set-MailboxDatabase -IssueWarningQuota 9.8GB -ProhibitSendQuota 9.9GB -ProhibitSendReceiveQuota 10GB -OfflineAddressBook "Default Offline Address Book (Ex2013)" -DeletedItemRetention "14:00:00" -MailboxRetention "30:00:00"

Figure 13: Using PowerShell to modify all new databases

Preparing for Exchange 2013 Migration

Testing base functionality

Before we can move namespaces and mailboxes across to Exchange Server 2013 we need to test that the new server is fully functional.
We'll start by creating a test mailbox to use on Exchange 2013. To do this, navigate to the Exchange Admin Center and within Recipients choose Add, then User Mailbox:
Figure 14: Creating a test mailbox using the Exchange Admin Center
There is no prescriptive name for a basic test account, so enter suitable unique and identifiable details:
Figure 15: Example settings for a new test account
After creating our test mailbox we’ll now need to test that they are functional from a client perspective.
Navigate to OWA via the server’s name. As a minimum test mail flow works correctly between our new Exchange 2013 test user and existing Exchange 2010 users.
Figure 16: Verifying OWA functionality

Updating Exchange 2010 Virtual Directory URLs

Exchange 2013 supports acting as a proxy for Exchange 2010 services. This means that it is easy to allow Exchange 2010 and Exchange 2013 to co-exist using the same URLs.
We decided earlier in this guide that we would use the same names for both Exchange 2013 and 2010.
It is now time to move the and names across from Exchange 2010 to Exchange 2013.
This, along with the respective DNS / firewall changes, will result in HTTPS client traffic for Exchange 2010 going via the Exchange 2013 server.
We will update our core URLs for Exchange 2010 to remove the ExternalURL value. We'll also enable Outlook Anywhere, configuring it with the HTTPS name that will move to Exchange 2013.
To do this we will login to the Exchange 2010 server and launch the Exchange Management Shell. Enter the following PowerShell commands, substituting the $Server and $HTTPS_FQDN variables for appropriate values.
$Server = "LJD-E1401" 
Get-OWAVirtualDirectory -Server $Server | Set-OWAVirtualDirectory -ExternalURL $null
Get-ECPVirtualDirectory -Server $Server | Set-ECPVirtualDirectory -ExternalURL $null
Get-OABVirtualDirectory -Server $Server | Set-OABVirtualDirectory -ExternalURL $null
Get-ActiveSyncVirtualDirectory -Server $Server | Set-ActiveSyncVirtualDirectory-ExternalURL $null
Get-WebServicesVirtualDirectory -Server $Server | Set-WebServicesVirtualDirectory-ExternalURL $null
Enable-OutlookAnywhere -Server $Server -ClientAuthenticationMethod Basic -SSLOffloading $False -ExternalHostName $HTTPS_FQDN -IISAuthenticationMethods NTLM, Basic
Figure 17: Reconfiguration of Exchange 2010 virtual directories
From a client perspective this should not have any immediate effect. The Exchange 2013 server will provide External URL values via Autodiscover, but in the meantime client traffic will still be directed at the Exchange 2010 staging server.

Updating Internal DNS records and switching external HTTPS connectivity

To direct traffic internally at the Exchange 2013 server we need to change internal DNS records so that both the Autodiscover name and HTTPS namespace (in our case, are configured with the IP address of the new Exchange 2013 server.
On a server with access to DNS Manager, such as an Active Directory domain controller, update both records from the IP address of the Exchange 2010 server to the Exchange 2013 server:
Figure 18: Updating internal DNS records
Clients will not be immediately redirected to use the Exchange 2013 server as the proxy for client access, and instead will do so once their cached records expire. As soon as clients can access the server retry login and client access to ensure no issues exist.

If internal access works without issue, update the external HTTPS publishing - which in our example organization is a NAT rule configured via the router.

Preparing for Exchange 2013 Migration

Updating Inbound Mail Routing

We have tested that our Exchange 2013 server can receive mail and deliver it to Exchange 2010 users. By default, Exchange 2013 is already configured to receive email from the Internet using Anonymous permissions on the default receive connector.
If this hasn’t been changed from the defaults, update either firewall rules to direct traffic on SMTP port 25 to the Exchange 2013 server, or update your spam filter appliance.
Once this change has been applied ensure that inbound mail flow is not interrupted before moving on to migrating outbound mail flow.

Updating Outbound Mail Routing

Now that incoming mail is now flowing through Exchange 2013, our next step is to make the changes required to allow and then reconfigure Exchange Server 2013 to be responsible for outbound mail flow rather than via the Exchange 2010 server.
In our example environment our mail flow is directed to the Internet, but in your organization you might use a spam filter appliance. Therefore make sure if you use a smart host for relay, ensure the IP address of the new Exchange 2013 server is added as a server allowed to relay outbound messages.
Likewise, if you email direct to recipients then ensure the Firewall rules allow the Exchange 2013 server IP address to initiate connections to Internet hosts on TCP port 25 without tampering (such as SMTP Fixup).
After ensuring that the Exchange 2013 server is allowed to relay outbound mail, we’re ready to update the Send Connector. To perform this step, open the Exchange Admin Center and navigate to Mail Flow and then choose SendConnectors. You should see the Send Connector used for outbound mail flow within the list:
Figure 1: Navigating to the Send Connector configuration within Exchange 2013
Open the properties for the Send Connector used for outbound mail flow - in our case the Outbound Mail (New)connector created earlier in this series.
Navigate to the Scoping tab and locate the Source server section. The Exchange 2010 server should be listed. Choose Add (+) and select the Exchange 2013 server, then select the Exchange 2010 and choose Remove (-); leaving only the Exchange 2013 server within the server list:
Figure 2: Updating the source server used for outbound mail flow
After verifying both the server IP address is listed as able to relay, and that the correct Exchange 2013 server has been selected, choose Save to apply the configuration.
As with updating inbound mail routing, ensure you test outbound mail flow is unaffected before continuing.

Migrating Mailboxes to Exchange 2013

Migrating the Pilot Group

Before migrating mailboxes en-mass to Exchange 2013, it’s important to validate that you’ve had an opportunity to identify any issues that using and moving test mailboxes didn’t expose.
Therefore select a pilot group of users to migrate to Exchange 2013 that will provide feedback on any issues they encounter, and will represent a cross-section of end-users; for example users that are heavy mobile users, those that are primarily external users and those that regularly use features like shared calendars and delegation.
Many smaller organizations will find most pilot candidates within the IT department, but if you have users who are keen to be early adopters outside of IT, then you’ll get a better representation of real issues.

Migrating Mailboxes

When migrating mailboxes from Exchange 2010 to Exchange 2013, we’ve got a number of methods that can be used to migrate mailboxes in large numbers.
The first method applies if you have created equivalent databases to match your source Exchange 2010 environment. For each database, you can queue up mailbox moved using the following command:
Get-Mailbox -Database <Database> | New-MoveRequest -TargetDatabase <Database_E15> -BatchName   <Database>  
Figure 3: Migrating mailboxes on a per-database level
If you are using traditional backups on your Exchange 2013 server then take into account the impact of log file usage when determining the batch sizes.
When a mailbox is moved, log files consuming the same amount of space as the mailbox itself are generated. This means that you can only move as many mailboxes as log space allows in between regular backup jobs.
You can mitigate against this by either performing additional incremental backups during mailbox migrations; or temporarily turning on circular logging.
The second method is to use Distribution Groups to co-ordinate migrations of mailboxes. This works well because you can use the Distribution Groups to communicate with users as well as use it to initiate mailbox moves.
You’ll see in the example below we use the Get-DistributionGroupMember cmdlet to get a list of mailboxes within a distribution group, then pipe it to the New-MoveRequest cmdlet, with the BatchName specified to help us identify this set of users, and leaving the Target Database blank to distribute the users randomly across databases:
Get-DistributionGroupMember "Marketing" | New-MoveRequest -BatchName "Marketing"  
Figure 4: Beginning mailbox migration using the distribution groups
We can keep track of the migrations using the Exchange Management Shell by calling the Get-MoveRequest cmdlet, again specifying the BatchName; then piping the output to Get-MoveRequestStatistics to gain a detailed insight into our current batch of migrations:
Get-MoveRequest -BatchName "Marketing" | Get-MoveRequestStatistics  
Figure 5: Monitoring migration status using the Exchange Management Shell
If you’d prefer to use the Exchange Admin Center rather than PowerShell to co-ordinate migration, then consider using the migration batches, as shown during our test mailbox moves. Use the New Migration Batch wizard to select mailboxes from the Global Address List, as shown below:
Figure 6: Creating a Migration Batch using the EAC
After creating and starting a migration batch via the Exchange Admin Center, we can examine the progress of those moves by selecting the migration batch from the list, and then choosing View Details:
Figure 7: Monitoring progress of a new migration batch within the EAC
We’ll then be presented with a list of all mailboxes within the batch, each of which can be selected and the full status available for detailed examination:
Figure 8: Monitoring individual move progress using the EAC
Either of these two methods is equally effective, and whichever you use is down to which ever method makes most sense within your organization.
After performing migrations of end users you can verify that no additional mailboxes remain on Exchange 2010, using the following command at the Exchange 2013 Management Shell:
Get-Mailbox -Server <Server>  
If any mailboxes do remain, then pipe the results of the command to the New-MoveRequest cmdlet as a new migration batch, for example:
Get-Mailbox -Server <Server> | New-MoveRequest -BatchName "Remaining Mailboxes"
We’ll also need to move the system mailboxes from Exchange 2010. We’ll find these by using the Get-Mailbox cmdlet with the –Arbitration parameter:
Get-Mailbox -Server <Server> -Arbitration
You’ll expect to see a couple. Move them to Exchange 2013 using the New-MoveRequest cmdlet again:
Get-Mailbox -Server   <Server>   -Arbitration |   New-MoveRequest
Figure 9: Moving Arbitration Mailboxes
After all mailbox moves from the Exchange 2010 server are complete, remove the mailbox move requests from Exchange 2013.
To remove successfully completed move requests, use the Remove-MoveRequest cmdlet in combination with the output of Get-MoveRequest:
Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest
Figure 10: Removing Move Requests

Decommissioning Exchange 2010

Getting ready to decommission Exchange 2010

By this point, we should be safe to remove Exchange 2010 from the environment. Earlier in the series we moved inbound and outbound mail flow to Exchange 2013, moved client access across; and we have just completed migrating all Mailboxes over to Exchange 2013.
Before removing the staging server, it’s important to verify that these servers are definitely no longer used. For example, if you have devices that use the Exchange 2010 server for SMTP relay, double check that all these devices have been updated to use the Exchange 2013 server.
Also double check you’ve implemented and migrated mail flow. We’ll need to verify that both Inbound and Outbound mail (via Receive and Send Connectors respectively) is configured to flow via Exchange 2013 only.
After checking that mailflow should no longer be configured to flow through the Exchange 2010 infrastructure, we should be ready to remove Exchange 2010 completely. To ensure that this is definitely the case, shut down the Exchange 2010 server and leave switched off for a reasonable period of time (for example, a week) to ensure that should anything have been missed the Exchange 2010 server can be started up and anything that wasn’t originally identified migrated.

Removing unused Offline Address Books

We'll start off with a relatively simple task, removing the old default Offline Address Book.
As part of the installation of Exchange 2013, a new Offline Address Book was created and set as the default.
We'll remove the old Exchange 2010 one by opening the Exchange Management Console and navigating toOrganization Configuration>Mailbox and then within the Offline Address Book tab selecting the original address book, with the Generation Server specified as the old Exchange 2010 server. Simply choose Remove:
Figure 11: Removing an unused Offline Address Book

Removing Databases

In our example organization we do not use Public Folders, therefore we only have one type of Database we need to remove from our Exchange 2010 - Mailbox Databases.
Before we press ahead and remove the databases, we'll need to double check that all mailboxes have been moved to Exchange 2013.
To verify all mailboxes have been removed from our Exchange 2010 server, we'll use the following commands:
Get-Mailbox -Server <ServerName>
Get-Mailbox -Server <ServerName> -Arbitration
Get-Mailbox -Server <ServerName> -Archive

Figure 12: Verification no Mailboxes exist on Exchange 2010
After verifying that no mailboxes exist on the server, we're ready to remove the databases. As part of this process Exchange 2010 will double check that no mailboxes exist. It will not allow the removal of databases that contain mailboxes.
We’ll use the following PowerShell command from our Exchange 2010 server to first get a list of the databases:
Get-MailboxDatabase –Server <ServerName>
After confirming that the command is showing the correct databases, remove the Mailbox Databases using the following command;
Get-MailboxDatabase –Server <ServerName> | Remove-MailboxDatabase
Figure 13: Removing Mailbox Databases

Uninstalling Exchange 2010

With Mailbox Database configuration removed we can now uninstall Exchange Server 2010.
To do this, navigate to Programs and Features, within the Control Panel and choose Uninstall after selecting Microsoft Exchange Server 2010 from the list of installed applications:
Figure 14: Locating and uninstalling Exchange 2010
The Exchange Setup application is used for the uninstallation process, much like it was used for the original installation. When prompted, we'll therefore unselect each Exchange Role installed, for example Client Access, Hub Transport and Mailbox.
Additionally we'll choose to uninstall the Management Tools - which includes the Exchange Management Console and Exchange Management Shell:
Figure 15: Uninstalling Exchange 2010 components
After choosing Next, Exchange Server Setup will perform checks to ensure that we're actually ready to uninstall. After moving Send Connectors earlier in this series and performing the tasks in this article, we'll expect each readiness test to complete successfully, allowing us to choose Uninstall:
Figure 16: Verification Exchange 2010 is ready to uninstall
After choosing Uninstall we'll expect the setup program to continue with removal of Exchange 2010. After it completes successfully the server can be decommissioned, and the server removed from the domain.


In this series we’ve migrated from Exchange 2010 to 2013. When considering your upgrade, ensure you also consider your backup technologies and testing the infrastructure using JetStress before moving mailboxes across. What we have shown is that a migration from Exchange 2010 to a new version of Exchange is potentially the simplest Exchange migration in recent history, and should be considered.

1 comment:

  1. SysInspire EDB to PST Converter Software keeps up all mail properties, for instance, to, bcc, send and get subjects and etc. Convert NSF to PST document programming will empower customers to recoup NSF email messages, contacts, calendar and all deleted folder things.
    Read more: