Posts Tagged ‘Exchange 2003’

Introduction

Domain Names are a critical part of your Windows Environment.  The DNS (Domain Name System) is a foundation upon which Active Directories and Resources rely upon.  It can be a real problem if you need to go back and change your Domain Name.

So, before building your Windows domain it is important to choose the “correct” domain name.  Wherever possible you need to try and plan ahead, of course you cannot plan for company name changes or, a take over in years to come, because you simply don’t know about them. But….we can plan to be flexible, and we must consider technical and ownership issues at the same time.

Choosing your domain name

Whilst most people believe that the internal windows domain name needs to be something.local this isn’t strictly true.  While it is often easier if the suffix is .local, strictly speaking, it doesn’t have to be.  Let’s consider that point…

Some of the largest enterprises in the world use their external domain name on their internal network.  The most important consideration is that if you use domainname.com that you actually own domainname.com.

Why is this important? One of the main reasons that this is becoming a problem in recent days is because of 3rd Party SSL Certificates that are used to secure Small Business Server and/or Exchange 2007/2010. One of the default requirements for these systems is using the internal fully qualified domain name of your Exchange Server.

So by way of example let’s say you have an internal domain name of virtualdomain.com and your external domain name is abc.com.

When setting up an Exchange 2007/2010 server you would need to request an SSL Certificate that contained the following names:

  • Autodiscover.abc.com
  • owa.abc.com
  • exchangeserver.virtualdomain.com

When you request a certificate with these names in the first thing the Certificate Authority (CA) will do is perform a WHOIS lookup on the names you have requested. Anything .abc.com will show as your company owning the registration.

However when the CA performs a WHOIS lookup on exchangserver.virtualdomain.com they find that the registrant of this domain is a different company and therefore send them a request to authorise the name. Worse, if they don’t find a registrant for the domain then it is removed from the certificate request.

Can you see the problem?  If you own virtualdomain.com then by all means use it in your internal domain name.  If you don’t own it then don’t use it.

This is why most consultants will opt to use the .local suffix on internal domains.  Because when the CA receives a request .local they know it’s not an internet suffix and they will authorise it.

Now what about the dreaded company rename?…..Another common misconception is that when setting up a Windows Domain you must use the domain name for which you want to receive email for.  This is completely untrue.

You can configure Small Business Server and all versions of Microsoft Exchange Server to receive emails for any domain name, regardless of your internal domain name.  So let us now consider calling your internal domain name mydomain.local?

  • It is not linked to a specific company name
  • it will allow you to receive emails for your abc.com email domain
  • if you change your company name you don’t need to worry about trying to change the domain name so the new owner (or existing one) doesn’t have to see the old company name day in day out?
  • because it has a .local suffix you will never run in to problems in the future with SSL Certificates

Conclusion

With wider use of SSL certificates and a few common misconceptions created by the industry, it is important to deliberate over your internal domain name selection.  It’s also important to think ahead.

What might be a good idea or even a bit of a laugh now, could come back to bite you in the rear in a few year’s time.  So, be careful and conservative when choosing your name.

I personally like to give my domains something non-descript, because I do a lot of work for small businesses which can and often do get taken over.  I had one company that was bought out twice within the space of 3 years. I also had one company that split in to 2 companies and then both renamed themselves.

It can get messy and especially with Small Business Server where the internal domain name cannot be renamed, it can be impractical to use company specific domain names.

Of course there is always the case where the owner wants this but it’s our job as consultants to advise them why this isn’t a good idea.  And if they still want it then get it in writing 🙂

This guide is intended to provide step by step instructions on how to migrate from Small Business Server 2003 to Windows 2008 R2 with Exchange 2010.

For this migration to work you will need the following software:

Steps required:

  1. Health Checks on Small Business Server 2003
  2. Join new Windows 2008 Server to the domain as a member server
  3. Prepare Active Directory for Windows 2008 R2 Server
  4. Make Windows 2008 R2 Server a Domain Controller of the Existing Small Business Server 2003 Domain
  5. Transfer DHCP Service
  6. Install Exchange 2010
  7. Installing Exchange 2010 SSL Certificate
  8. Migrate Exchange Data
  9. Migrate SharePoint Services
  10. Migrate shared user data
  11. Uninstall Exchange 2003 from Small Business Server 2003
  12. Transfer all 5 FSMO roles to Windows 2008 Domain Controller
  13. DCPROMO SBS 2003 server so it is no longer a domain controller and remove from network

It’s important that the steps are followed in order as different stages make different changes to the way in which your server operates.  For example you MUST make the 2008 server a domain controller before you install Exchange.

Step 1 – Health Checks on Small Business Server 2003

The absolute first thing you need to do is take a SYSTEM STATE backup of your Small Business Server as well as a full system backup.  There is little chance of the data getting lost but the SYSTEM STATE backup backs up Active Directory so that if it all goes wrong we can recover it if needed.

What you then need to do on the SBS 2003 server is to make sure you have all the latest available updates.  This means you should at a minimum have:

  • Windows 2003 Service Pack 2
  • Windows Small Business Server Service Pack 1
  • Microsoft Exchange 2003 Service Pack 2

Once you have installed all of the above, run Windows Update and make sure you select the option in the blue banner bar across the top for Microsoft Update.  Microsoft Update will then allow you to update all Microsoft products installed on the server providing a more comprehensive update solution.  Keep running the check and installing all updates until there are no more available.

Check the health of your Active Directory by running DCDIAG, if there is anything reported as an error fix it before moving on.

Run the Small Business Server 2003 Best Practices Analyser from here:  http://www.microsoft.com/downloads/details.aspx?familyid=3874527A-DE19-49BB-800F-352F3B6F2922&displaylang=en

Make sure you fix any problems the analyser identifies. If you cannot, then why not raise a question on Experts Exchange to have the Experts there help you?

A common problem that can cause this migration to fail is that the SBS 2003 server does not have its own IP address listed for DNS in the network properties under TCP/IP.  If this is the case, update it so that it does (do not use the loopback 127.0.0.1 address).

Step 2 – Join new Windows 2008 Server to the domain as a member server

To join a Windows 2008 Server to the Small Business Server domain we need to first ensure that it is receiving a correct IP Address

Allow the Windows 2008 Server to receive a DHCP Address from your Small Business Server.  Run an IPCONFIG /ALL to check this.  The DNS Server entry is probably the most important. This should be configured to use the IP Address of your Small Business Server for DNS.

To test, it might be worth just pinging the SBS 2003 server from a command prompt just to check the name can be resolved by doing the following:

  • Click Start > Run > type CMD and then click OK
  • type PING SBS2003SERVERNAME

If you get a good response then we can try and join the 2008 server to the domain.

To Join the Server to the Domain, do the following:

  • Click Start and right click on Computer and select properties
  • From the screen that opens under the section called Computer name, domain, and workgroup settings click Change settings.  Then click on Change
  • At this point if you haven’t already specified the name of your new server you can do so
  • Check the radio button next to where it says Domain and enter the domain name that the Small Business Server 2003  belongs to
  • Click OK
  • At which point you will be prompted for a username and password for a user that has permissions to add the computer to the domain
  • Once you have added your credentials and click OK you will then be informed the server requires restarting.  Please restart to resume the migration

Step 3 – Prepare Active Directory for Windows 2008 R2 Server

The first step of this process is to raise the Functional Levels of the SBS 2003 server.  This involves raising the domain and forest functional level of Active Directory and the Operational mode of Exchange Server.

To raise the Domain Functional Level do the following:

  • Click Start > Administrative Tools > Active Directory Users and Computers
  • Right click on the domain name and select Raise Domain Functional Level
  • In the drop down box select Windows Server 2003 and click OK (if this has already been done don’t worry)

To raise the Forest Functional Level do the following:

  • Click Start > Administrative Tools > Active Directory Domains and Trusts
  • Right click where it says Active Directory Domains and Trusts and select Raise Forest Functional Level.

And we also need to raise the Exchange Operational Mode.  To do this, you need to do the following:

  • Click Start > All Programs > Microsoft Exchange > System Manager
  • Right click on the Organisation name right at the top of the list and select properties
  • In the dialogue box check the Operational Mode, if it says Mixed Mode click the Change Mode button and say yes to the dialogue box asking if you want to change to native mode

Before we can add the Windows 2008 Server as a domain controller to the SBS 2003 domain, we need to prepare Active Directory.

To do this use the following procedure whilst working on the Small Business Server

  • Insert the Windows 2008 DVD in to the Small Business Server.  Ignore the autorun message that appears telling you this version is incompatible by clicking OK
  • Open a command prompt (Start > Run > CMD) and run the commands below

NOTE: X: refers to the drive letter that has been assigned to your DVD Drive.

  • X:\support\adprep\adprep32  /forestprep

After the above command you will be prompted to confirm you wish to proceed by typing the letter C and pressing Enter

  • X:\support\adprep\adprep32  /domainprep
  • X:\support\adprep\adprep32  /domainprep /gpprep
  • X:\support\adprep\adprep32  /rodcprep

Step 4 – Make Windows 2008 R2 Server a Domain Controller of the Existing Small Business Server 2003 Domain

To make the Windows 2008 Server a Domain Controller is fairly straight forward, we simply click Start > Run  and type DCPROMO click OK.

This will check that the Active Directory Services Binaries are installed and if they are not, it will install them.  It will then start the Active Directory Domain Services Installation Wizard.

On the first screen, there is no need to check the ‘Use Advanced mode Installation’ check box, just simply click next.  On the operating System Compatibility screen click next.

On the ‘Choose a Deployment Configuration’ screen, select the radio box for Existing Forest and Add a domain controller to an existing domain.  Then Click next.

On the ‘Network credentials’ screen, the name of the domain should have been detected automatically.  Check this is correct.  If you are logged in as a user that has domain admin privileges then you can use the My Current logged on credentials option.  If not, click the set button and add the username and password that has domain admin privileges as shown in the screen above.  Click Next.

The following screen will give you the results of a domain search and ask you which domain you want to add this domain controller to.  As you are upgrading Small Business Server there should only be one.  Click Next.

The next screen will give you an option to select the site for the new domain controller.  If you have more than one Active Directory Site ensure that you select the correct one if it hasn’t been done by default.  Click next.

On the ‘Additional Domain Controller Options’ screen, make sure that both the DNS Server and the Global Catalog options are both checked.  Click Next.  The error message regarding DNS Delegation can safely be ignored.  Click Yes on this dialog to continue.

If you have separate folders where you want to store your log files, SYSVOL share and the Active Directory database then these can be specified on the next screen.  To be honest I keep them all as defaults.  Once done, click Next.

On the following screen, you are asked to set a password for Directory Services Restore Mode Administrator (DSRM).  Please note this is NOT the Domain Administrator password.  This password is used to boot the Domain Controller into Directory Services Restore Mode which is used for recovering corrupt/deleted/failed Domain Controllers.  Make a note of this password and keep it somewhere safe (in a fire safe for example).

Click Next on the following 2 screens.  The wizard will then start the promotion of the server to a domain controller (I always check the box on this screen to reboot on completion – This way you can leave it and come back to it knowing that it will be ready to continue).

Once rebooted your new server will be a domain controller, DNS server and Global Catalog server in your Small Business Server Domain.

Step 5 – Transfer DHCP Service

By default the Small Business Server will be the DHCP Server (if it isn’t and you’re using something else for DHCP, then you will simply need to update the DNS configuration this device is giving out so that it points to the 2008 Server instead of the 2003 Server) we will need to transfer this to the new server.

We can start this process by installing the DHCP Service.

To install DHCP, open up Server Manager and under Roles, click Add Role. From the list, select DHCP Server and click Next then next on the Introduction to DHCP Server screen.

On the network Connection Bindings screen you should have your primary IP address listed.  As you will be installing Exchange on this server it’s not recommended to have a multi-homed server but if you do make sure the LAN card and IP is the only one selected.  Click next.

NOTE: A multi-homed server is a server that has multiple IP addresses assigned to multiple Network Interface Cards.  Normally these types of servers would be used as routers.  Whilst Exchange can be made to work in this environment, it’s not recommended.

On the Specify IPv4 DNS Server Settings check the following settings:

  • Check the parent domain name is correct
  • Make sure that the IP Address listed for Preferred DNS server IPv4 Address is the address of the new Windows 2008 Server
  • Remove any entry in the Alternate DNS Server IPv4 Settings as these will not be required
  • Click next

Click next accepting the default settings on the WINS screen.

On the Add or Edit DHCP Scopes screen, click Add.  This will present you with the Add Scope dialog box.

On this screen enter the following details:

  • scope name
  • the start IP address
  • the end IP address

(This should be the same as the DHCP Scope you have configured on the Small Business Server).

  • Uncheck the box that says Activate this scope (we don’t want it just yet)
  • The subnet mask should have been calculated automatically but if it isn’t correct then please change it to ensure it is
  • Enter the default gateway; this will be the router on your network

On the Specify IPv4 DNS Server Settings check the following settings:

  • Check the parent domain name is correct
  • Make sure that the IP Address listed for Preferred DNS server IPv4 Address is the address of the new Windows 2008 Server
  • Remove any entry in the Alternate DNS Server IPv4 Settings as these will not be required
  • Click next

Click next accepting the default settings on the WINS screen.

On the Add or Edit DHCP Scopes screen, click Add.  This will present you with the Add Scope dialog box.

On this screen enter the following details:

  • scope name
  • the start IP address
  • the end IP address

(This should be the same as the DHCP Scope you have configured on the Small Business Server).

  • Uncheck the box that says Activate this scope (we don’t want it just yet)
  • The subnet mask should have been calculated automatically but if it isn’t correct then please change it to ensure it is
  • Enter the default gateway; this will be the router on your network

You will notice in the scope I am creating, I have started from 192.168.10.15 this is so that I have 15 addresses that I can assign to fixed addresses.  My Small Business Server and Windows 2003 server will have an address below 192.168.10.15 but I might also have printers, photocopiers, and wireless access points that also need fixed IP addresses.  I have also left 192.168.10.254 available to use for my router.

Once you have completed all the details, click OK and then Next.

Accept the default setting on the ‘Configure DHCPv6 Stateless Mode’ and the Specify IPv6 DNS Server Settings.

On the ‘Authorize DHCP Server’ screen, select to use the current credentials and click Next, then Install on the confirmation screen.

The DHCP Server service is now installed on the Windows 2008 server.

Before we can switch over, we need to make some changes to the Small Business Server DHCP settings.  Whilst we can just turn one off and turn the other on this will cause you to have to release and renew the settings on the client machines manually for them to pick up the new DHCP Service.  The alternative is to wait the 4 days before your client machines request an IP address renewal.

To make the required changes, do the following on the Small Business Server:

  • Navigate to Start > Administrative Tools > DHCP this will open the DHCP snap-in
  • Right click on the Scope listed under your Small Business Server and select properties

In the section titled ‘Lease duration for DHCP clients’ we are going to change it to 2 hours from the default of 8 days.  Click OK

Then under Address Leases, highlight all DHCP Leases, right click and select delete.  NOTE:  If you have any reserved addresses make sure they are not highlighted otherwise they will be deleted also.

This action will cause all DHCP clients to renew their addresses and gain an address that has a 2 hour lease.  Check the Address Leases and refresh until you are happy that all the clients now have an IP address. (You might want to leave this overnight just to make absolutely sure)

Once you are happy that all the clients have now got a 2 hour lease from the Windows 2008 server do the following:

  • Navigate to Start > Administrative Tools > DHCP
  • Expand the Windows 2008 servername and IPv4 then right click on the scope listed
  • Select Activate

This will start the DHCP Service on the 2008 server and deactivate the service on the Small Business Server (this will happen automatically because when Small Business Server detects another DHCP server on the network it shuts its own down).

You will now find that in approximately 1 to 2 hours time, all your clients will start picking up IP addresses from the Windows 2008 Server.

You can now disable the DHCP Server service on the Small Business Server.  DO NOT disable the DHCP Client service, as this plays a part in DNS registration.

Now that all the clients are using the new Windows 2008 Server for DHCP and DNS, we need to make sure that the Small Business Server is also using the Windows 2008 Server for DNS.  To do this modify the TCP/IP properties of the network card and change the Primary DNS servers IP address to that of the Windows 2008 Server.  Do not enter anything in the Secondary DNS server.

Once you have done this restart the NETLOGON service so that the DNS entries are added to the Windows 2008 DNS.

Step 6 – Install Exchange 2010

Because we performed all the diagnostic checks at the start, the installation of Exchange 2010 should be fairly straight forward.  Please note that even though the installation of any version of Exchange Server on a domain controller is supported by Microsoft, it is not a recommended configuration.  But since we are migrating from Small Business Server the chances are you still want to stick with a single server configuration.

The first step is to install the pre-requisites on Windows 2008 to allow the Exchange 2010 installation to complete.  This can be done very easily using the Windows PowerShell.

To do this, please use the following steps:

  • Click Start > All Programs > Accessories > Windows PowerShell

Once the PowerShell is opened run the following commands:

  • Import-Module ServerManager

There is no notification this has completed you will just see a flashing cursor waiting for input.  This command will allow us to add server roles and features via the PowerShell command.

  • Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy –Restart

This command will install all the pre-requisites for the Mailbox, Hub Transport and Client Access roles on to the Windows 2008 Server.  This will replicate what you currently have on the Small Business Server.
Once the server has restarted after the above command, launch the Windows Powershell again and run the following command:

  • Set-Service NetTcpPortSharing -StartupType Automatic

This will set the Net.Tcp Port Sharing Service to Automatic instead of Manual

Install the Microsoft Office Filter Pack (which you should have downloaded earlier from the top list of required software).

Once we have done this, we need to prepare Active Directory for the Exchange 2010 installation.

Unlike previous versions, Exchange 2010 will detect if the schema updates have been done and do them if not, I prefer to see this happen.

To prepare Active Directory for Exchange 2010 we need to do the following:

  • Insert the Exchange 2010 DVD in to the Windows 2008 Server
  • Open a command prompt (Start > Run > CMD)
  • Run D:\setup /PrepareLegacyExchangePermissions
  • Run D:\setup /PrepareSchema
  • There is an additional command which is: setup /PrepareAD /OrganizationName: but I am going to let the Exchange Server installation do this part

Start the Exchange installation from the DVD.  On the initial splash screen that opens, click Step 3: Choose Exchange Language Options, select the appropriate option then click Step 4: Install Microsoft Exchange.  The Exchange Installation Wizard will then start.

The first screen you see is the Introduction screen, click Next.  Read, agree to and accept the license agreement screen.

This screen allows us to choose the type of installation.  As it’s assumed the Exchange 2010 server is a direct replacement for Small Business Server and all roles will be installed on a single server, we simply select Typical Exchange Server Installation and Click next.

If we were separating our roles out on to different servers we would select Custom Exchange Server Installation and then click next.

This screen allows us to specify what URL will be used for accessing our Outlook Web App from outside of the network.  Whatever you put in here you will need to make sure you have a DNS A record for it in your EXTERNAL DNS server.  In the later steps you will also need to use this name in your SSL Certificate Request. (CSR)

Check the box ‘The Client Access role server will be internet-facing’ and then specify the URL you will use, do not add https:// or anything at the end i.e. /owa.  Click next.

This screen is asking us to specify the Exchange 2003 server that the installation will create a routing group connector for.  This is essential for mailflow between the servers.  Click Browse, the list should be generated automatically and you will be able to select the Small Business Server from the list.  Click OK and then next.

Choose on the next screen if you wish to participate in the Customer Improvement program and then click next.  At this point the readiness checks will be performed to ensure your infrastructure is ready for Exchange 2010.

The results of the readiness check should show a warning on the Organisation Prerequisites, this is normal and it’s because we didn’t run the setup /PrepareAD /OrganizationName: command earlier on.  This can safely be ignored as the setup will perform this task for us.

The other cautionary warning you will see on my screen capture is simply because I haven’t installed the Office Filter Pack so you will only see this if you didn’t follow the step earlier.  Once you click install, the wizard will Install Exchange Server 2010.  And we are looking for the screen below.  All green.

Now that Exchange is installed, using the Exchange Management Console, navigate to Server Configuration > Hub Transport.  Here there will be 2 Receive Connectors listed.

The one we will be dealing with is the one that starts with the word Default and is followed by the name of the Exchange 2010 server.  Right click on this Receive Connector and select properties.  Under the Permission Groups tab, check the box for Anonymous Users.  If this box is not checked then servers sending mail to you will not be able to connect.  Your e-mails with therefore be rejected.

One final task before we move on, is to reconfigure any firewall/router rules you may have for ports 25 and 443 to allow the Exchange 2010 server to now deal with SMTP traffic and Outlook Web App.

Step 7 – Installing Exchange 2010 SSL Certificate

Exchange 2010 installs with a self-signed certificate by default.  Whilst this will work, it will cause browser errors in the form of untrusted websites, Outlook errors for Autodiscover (which is used for free/busy information & Offline Address Book) and errors when using mobile devices and Outlook Anywhere.  Whilst for the most part there are ways around these problems, I won’t be covering them in this article because my recommendation, as any other Exchange specialist would recommend, would be to use a 3rd party certificate.  You can purchase certificates that work with all versions of Exchange from http://www.exchangecertificates.com

Unlike earlier versions of Exchange, we have a nice easy to use wizard in the Exchange Management Console for certificate generation.  This makes installing commercial certificates in Exchange 2010 much easier and less prone to error.

To start the New Exchange Certificate wizard do the following:

  • Click Start > All Programs > Microsoft Exchange Server 2010
  • Navigate to Microsoft Exchange On-Premises > Server Configuration
  • In the Actions pane click New Exchange Certificate

This will start the New Exchange Certificate Wizard

 

Enter a friendly name for the certificate. This can be whatever you like, but standard practice is to use the company name or something that can identify your company.  Click Next

DO NOT Select to create a wildcard certificate unless you plan on buying a certificate for your entire domain, which is not required for Exchange to function.  Click Next

On the following screen pull down the arrows for:

  • Client Access Server (Outlook Web App)
  • Client Access Server (Exchange ActiveSync)
  • Client Access Server (Web Services, Outlook Anywhere, and Autodiscover)

Make sure all the URLs are correct (examples can be found in my screen capture above) and then click Next.

Confirm the entries on the next page (it’s worth noting on this screen that the address shown in bold is what is known as a Common Name).  This could be important later as Outlook Anywhere requires the common name to be the same as the URL used in the RPC connection.  In most of my configurations I use the owa.gkvirtualdomain.co.uk as the common name.  To do this, highlight the URL and click the Set as Common Name option.  Click next when finished.

You then need to complete your organisation information as shown in the screen above.  Then click New on the next screen. And then finish.

You can then open the file you have specified to create the request with, copy and paste the entire contents into the 3rd party vendors website and follow their instructions for submitting it.

Once you receive the signed certificate, right click on the certificate request located as above and select Complete Pending Request.  Follow the instructions to import the certificate you have just received.

Step 8 – Migrate Exchange Data

Now we have Exchange installed, it’s time to migrate the data over.  We will start with the easy part as a bit of a break from the previous 6 steps.

To migrate the user mailboxes, open Exchange Management Console and navigate to Recipient Configuration > Mailbox. Highlight the mailboxes you want to move (the mailboxes that are on the Exchange 2003 server will appear as Legacy Mailboxes, as pictured above), right click on them and select New Local Move Request.

When the New Local Move Request wizard opens, click the browse option to select the Windows 2008/Exchange 2010 server mail store and click OK, then click next.

On the following screen, select what you would like to do when the wizard encounters corrupt messages. You have two options: either to skip only the corrupt message or to skip the whole mailbox.  Click next and on the following screen click New.

Once the move requests have been verified, we should see the screen above.  All the mailboxes you selected should hopefully show a green tick.  Please note that during the move mailbox process, the user will not have access to their mailbox as it is moved “offline”.

The next stage is to migrate the Public Folders. To do this complete the following steps on the SBS 2003 Server:

  • Click Start > All Programs > Microsoft Exchange Server > System Manager
  • Navigate to Administrative Groups > First Administrative Group > Servers > Servername > First Storage Group
  • Right click on the Public Folder Store and select Move All Replicas.  The only option that should appear in the list is your Exchange 2010 server.  Click OK.

Now that we have moved the data to the Exchange 2010 server it’s best to leave this for a day or so to a) make sure all the data is moved before we perform any other Exchange related tasks. b) allow all the outlook clients to update automatically with the new server settings.

Step 9 – Migrate SharePoint Services

If you are using companyweb for an intranet/document storage etc. then you will also need to migrate this.  If you are not using SharePoint then simply skip this step.

First thing you will need to do is to install the Windows SharePoint Services 3.0 which you downloaded as part of the pre-requisites.  This is the free version of SharePoint Services.  Only the version with Integrated Service Pack 2 will install on Windows 2008 R2.

Once you have downloaded Windows SharePoint Services 3.0, double click to start the installation on the Windows 2008 Server.  Read, agree to and accept the license agreement and click continue.  Select Basic installation.  This will install the standard single site installation.

Once the installation has finished, launch the SharePoint Products and Technologies Configuration Wizard.  Click next on the welcome screen and Yes to confirm you are OK with the services being restarted.
NOTE: While IIS restarts, the Outlook Web App will be temporarily unavailable.

On the final screen, check the box to ‘Run the SharePoint Products and Technologies Configuration Wizard now’ and click Close.

Click Next on the welcome screen and Yes to confirm you are OK with the services being restarted.  The wizard will run through again and complete the configuration.   Once finished click close.

Make sure you install the 32bit version on the Small Business Server and the 64bit version on the Windows 2008 server.

The next step we need to complete is to run a pre-scan on the current database to allow Windows SharePoint Service 3.0 to upgrade it when we move it to the Windows 2008 server.
Perform the following steps to achieve this:

  • Copy the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Bin\prescan.exe which can be found on the Windows 2008 server to the Small Business Server.  It doesn’t matter where you put this
  • Launch a command prompt (Start > Run > CMD)
  • From the command prompt run: prescan /V http://companyweb and press enter

Once you have done this still, working on the Small Business server perform the following tasks:

  • Navigate to Start > Administrative Tools > Internet Information Services (IIS)
  • Navigate to servername > Web Sites and right click on companyweb and select stop

We now need to launch the SQL Server Management Studio Express, this can be done by:

  • Click Start > All Programs > Microsoft SQL Server 2005 > SQL Server management Studio Express
  • In the dropdown list on the connection screen, ensure that SERVERNAME\SHAREPOINT is selected and click connect

Before we perform any additional steps, we are going to take a backup of the database used for companyweb.  Follow these steps to perform a backup:

  • Expand the Databases folder
  • Locate the database called STS_SBSSERVERNAME_1 right click on the database and select Tasks then Backup

On the backup screen, the only section you need to change is the destination.  Make sure the “backup to” is set to disk and then click Add.

If you receive the error message above, don’t panic, it’s easily solved by using the following procedure:

  • Click Start > Run > Type regedit > Click OK
  • Navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\SharePoint\MSSQLServer
  • Right click and create a new String Value called BackupDirectory
  • Double click the new value to edit it and give it a value of C:

Close Regedit and try clicking the Add button again on the Backup Screen, specify a location for where you would like to save the backup and click OK.

We are now going to detach the database from the SBS 2003 server.  Still in SQL Server Management Studio Express, right-click on the STS_SBSSERVERNAME_1 select tasks and then Detach.

Locate the Database and Log file, which by default will be located in C:\ Program Files\Microsoft SQL Server\MSSQL$SharePoint\Data on the Small Business Server.  You need to copy the STS_SBSSERVERNAME_1.MDF  and STS_SBSSERVERNAME_1_LOG.LDF files to a folder on the destination server, don’t copy them in to the SQL Server data folder.

Working on the Windows 2008 server perform the following steps:

  • Navigate to Start > All Programs > Microsoft SQL Server 2005 > SQL Server Management Studio Express
  • On the connection window enter \\.\pipe\mssql$microsoft##ssee\sql\query in the servername box and click connect
  • Right click on Databases and click attach
  • Click the Add button and select the STS_SBSSERVERNAME_1.MDF you copied from the Small Business Server earlier

We now need to create the website in IIS.  To do this, do the following:

  • Navigate to Start > Administrative Tools > Internet Information Services (IIS) Manager
  • Expand the servername
  • Right click on Sites and select New Site

On the Add Web Site wizard, enter a site name of companyweb, specify a physical path and host name of companyweb as shown in the image above.  You can change these if you wish, but keeping the site name/host name the same will mean the URL your clients use will not change.

Launch DNS manager from Start > Administrative Tools > DNS.  Expand the forward lookup zone for your internal domain name and locate the CNAME record called companyweb.  This should currently be using the Small Business Server’s server name.  Double-click this record to edit it and change it to use the Windows 2008 server instead.

And then finally we need to setup SharePoint Service.  To do this perform the following steps:

  • Navigate to Start > Administrative Tools > SharePoint 3.0 Central Administration
  • Click Application Management
  • Select Create or Extend Web Application
  • On the next screen select  Create a New Web Application

On the screen that appears, complete the fields as listed below.  If nothing is specified, please leave the default settings.

In the IIS Web Site Section choose the following:

  • Use an Existing Website and then select companyweb from the drop down list

In the Security Configuration Section

  • Set Authentication Provider to NTLM
  • Set Allow Anonymous to No
  • Set Use Secure Socket Layers (SSL) to no

In the Application Pool Section

  • Use Existing Application pool and Select companyweb from the drop down box

In the Database Name and Authentication Section

  • Database Server should be set to WINDOWS2008SERVERNAME\Microsoft##SSEE (where WINDOWS2008SERVERNAME is the name of the Windows 2008 Server)
  • Database Name should be set to STS_SBSSERVERNAME_1
  • Database authentication should be set to Windows Authentication (recommended)

In the Search Server Section

  • Pull down the drop down list and select the Windows 2008 server from the list

Click OK and your SharePoint Website will be created.  Once the wizard has finished, from an Internet Browser type in http://companyweb/ and the companyweb website on the Windows 2008 server will be displayed.

Step 10 – Migrate shared user data

NOTE: This section is currently under review as I have been advised that this process does not work correctly.

Because this step is so generic and it could be different for every server, I am not going to go into specifics, only the more general steps that need to be accomplished.

The shares that are in use on the Small Business Server need to be recreated on the Windows 2008 server.  One way we can do this is backup the share definitions from the Small Business Server and restore them to the Windows 2008 server.  This involves working in the registry so please be careful and follow the instructions accurately.  The instructions on how to do this can be found here: http://support.microsoft.com/kb/125996

The next stage is to restore the actual data to the shares.  This is a lot easier if you ensure that the folder structure you have on the Small Business Server for shares is replicated on the Windows 2008 server.  You can simply use Windows Backup to backup and restore the data.  This will keep all permissions and ownership information intact.

You will then need to update any login scripts which will be located in \\LOCALHOST\SYSVOL on the Windows 2008 server to ensure that any mapped drives are updated.

You will also need to update any attributes that may be under the Profiles tab in Active Directory Users and Computers for the users themselves.

Step 11 – Uninstall Exchange 2003 from Small Business Server 2003

Hopefully you are arriving at this step a day or two after you have migrated all the mailboxes, if not then I would recommend you leave it for a day or two just to allow all client computers to automatically update the Exchange server setting in outlook.  If you uninstall Exchange 2003 from the Small Business Server and this hasn’t happened then the clients will have to be changed manually.

To perform this task we will need Small Business Server 2003 CD 2, which will be asked for during the uninstallation.  Before we can do this though, there are a few steps we need to perform otherwise we will not be able to uninstall it.

If you use Recipient Policies that are Manage Mailbox policies, then these will need to be removed.  Likewise, if you have Recipient Policies that are used for both e-mail address definition and mailbox management, the settings defined under Mailbox Manager Settings will need to be removed.  You DO NOT need to remove your e-mail address policies.

The Recipient Update Service is not used in Exchange 2010 and is therefore not required, so it can be removed.  To do this you will need to use ADSI Edit.  This can be done by using the following procedure:

  • click Start > Run > MMC > Click OK
  • Select File then Add/Remove Snap-in
  • Click Add and select ADSI Edit and click Add, then close and OK
  • Right click on the ADSI Edit and select ‘Connect to’.  From the drop down under ‘Select a well known Naming Context’, select Configuration and click OK
  • Expand Configuration > Services > Microsoft Exchange > Organisation Name > Address List Container > Recipient Update Services
  • Right click on Recipient Update Service (Enterprise Configuration) and select Delete.  There may also be a Recipient Update Service (ORGNAME) this also needs to be deleted

Only delete the Recipient Update Service entries under the container; DO NOT delete the container itself or any other entries

The final step in preparation for uninstalling Exchange Server 2003 is to delete the routing group connectors that would have been created as part of the installation.  I have highlighted them in the image below.  Simply right click on each connector and select delete.

We are now ready to uninstall Exchange 2003.  To do this, navigate to Start > Control Panel > Add or Remove Programs.  From the list of installed applications, highlight Windows Small Business Server 2003 and click Change/Remove.

Click next on the Welcome screen, and next on the screen that follows.  Once the component screen opens pull down the drop down next to Exchange Server and select remove, as shown below. Then click next and next again.

Step 12 – Transfer all 5 FSMO roles to Windows 2008 Domain Controller

Caution needs to be taken when performing this next step.  I would advise that ALL of the previous steps need to be completed before this is done as Small Business Server MUST hold all 5 FSMO roles.
Once you are ready, the roles can be transferred as follows.  Working on the Windows 2008 server do the following:

  • Click Start > Administrative Tools > Active Directory Users and Computers
  • Right click on the domain name and select Operations Masters.  You will see the screen below.
  • On each tab (RID, PDC & Infrastructure) click the change button.
  • Accept the confirmation that you want each role to be transferred.

That is 3 of the 5 roles transferred.  To do the next one, which is the Domain Naming Master we need to do the following:

  • Click Start > Administrative Tools > Active Directory Domains and Trusts.
  • Right click where it says Active Directory Domains and Trusts and select Operations Master.
  • Once again click the Change button and say yes to the notification dialog.

4 down with 1 to go.  To move the Schema Master role we need to do the following:

  • Click Start > Run and type regsvr32 schmmgmt.dll
  • Click OK to the confirmation
  • Click Start > Run and type MMC and click OK
  • Select File > Add/Remove Snap-in from the console
  • From the list select Active Directory Schema, click Add
  • Click Close and OK.
  • Right click on Active Directory Schema and select Change Active Directory Domain Controller
  • Choose the Windows 2008 Server from the list and click OK
  • Click OK on the warning Dialog box.
  • Right click on Active Directory Schema and select Operations Master
  • Click the Change button and say yes to the notification dialog

That’s all the FSMO roles transferred from the Small Business Server.  The next and final step is to demote the server from being a Domain Controller.

Step 13 – DCPROMO SBS 2003 server so it is no longer a domain controller and remove from network

This is the final step of the migration process.  If you have made it this far, well done!  This is the easy bit!

The first thing we need to do is make sure the Small Business Server is not a Global Catalog Server.  Click on Start > Administrative Tools > Active Directory Sites and Services.  Locate the Small Business Server as shown in the screen shot below.

Right click on NTDS settings located under the Small Business Server and select properties.  Remove the check from the Global Catalog check box and click OK.  Close Active Directory Sites and Services snap-in.

The final step is to run DCPROMO.  To do this, do the following:

  • Click Start > Run and type DCPROMO and click OK
  • Click next on the Welcome screen
  • DO NOT check the box that says “This server is the last domain controller in the domain” and Click next
  • Enter a new administrator password for the local administrator user and click next

The server will then remove Active Directory Services from the Small Business Server and it will no longer be a Domain Controller.

Once this has finished, allow the server to restart, login and then shut it down.  You have now completed the migration.

If you are still with me, well done!  There are a few sections of additional reading below if you would like to know some more detail about some of the processes we have just completed.  There is an excellent article from EE Expert tigermatt around the purpose of the FSMO roles which you will find under the further reading section.

Further Reading

Move/Migrate Sharepoint Services: http://technet.microsoft.com/en-us/library/cc288664.aspx
Move last legacy Exchange Server: http://technet.microsoft.com/en-us/library/bb288905(EXCHG.80).aspx
Demystifying the Active Directory FSMO Roles by tigermatt: http://tigermatt.wordpress.com/2010/04/03/demystifying-the-active-directory-fsmo-roles/

 

One of the most common problems with co-existing Exchange Servers (an organisation consisting of an Exchange 2003 server and an Exchange 2007 or 2010 server) is mailflow between the servers.

When Exchange 2007 or 2010 is installed in an existing Exchange 2003 organisation a Routing Group Connector (RGC) is configured during the installation of the Exchange 2007 / 2010 Exchange server to allow mailflow between the legacy server and the new one.

The way Exchange 2003 servers communicate with other Exchange 2003 servers or Exchange 2007 and 2010 servers is by utilising the Default SMTP Virtual Server.

One of the most common causes of disrupted mailflow is that the Default SMTP Virtual Server has been modified. Either the default port has been changed from the port 25 or a smarthost has been added (Delivery Tab / Advanced Button).

The smarthost configuration in Exchange 2003 should be performed using an SMTP Connector rather than modifying the Default Virtual SMTP Server. The general rule of thumb is to create a new Virtual Server rather than modify the existing one if a different port is required to send to a smarthost or a SPAM/Virus Appliance.

All of these actions can be performed using the Send Connectors in Exchange 2007/2010 so these settings should all be returned to default. This means that the Default SMTP Virtual Server should be using port 25 and should not have a smarthost configured.

Once you have done this mailflow should resume between the different versions of Exchange.

Pre-requisites

In order to perform a successful migration from Exchange Server 2003 to Google Apps you will require the following:

Once you have signed up for your Premium Google Apps or Education account, the first thing you will need to do is create your user accounts.  This can either be done manually through the control panel by uploading a CSV through the Advanced Tools section.

Once you have created your users there are a few settings that need to be changed in order for the new migration tool to work, these are:

  • Set the Email Migration API (EMAPI) option
  • Enable 2-Legged OAuth

Enabling the Email Migration API (EMAPI) option

This is required to allow the Migration to Exchange tool to access the required API’s so that it will function.  To enable this using the Google Apps Control Panel navigate to Advanced Tools and scroll right to the bottom of the page.  Put a check in the box next to Allow users to upload mail using the Email Migration API. (Administrators always have access to this API.)

Enable 2-Legged OAuth

This is similar to a service account in Exchange that allows you to gain access to all mailboxes using a single login (the administrative account).  To configure this using the Google Apps Control Panel navigate to Advanced Tools and under the section titled Authentication click Manage OAuth domain key.  Put a check in the box labelled Enable this consumer key then click Save Changes.  This will generate an OAuth consumer secret make a note of this because it will be required later.

Performing the Migration

I was shocked at how easy the migration was from Microsoft Exchange 2003 to Google Apps.  It’s as simple as 5 easy steps which I will explain below.

The first step is to create a CSV file of the users that you wish to migrate.  If like me your Google Apps username is the same as your Windows usernames then you simply need to create a file with a list of these usernames.  The same is true if the e-mail addresses are the same, simply create a list of e-mail addresses, 1 per line.

If they usernames or e-mail addresses don’t match then you will need to create a CSV that looks like the following:

user1, google_apps_user1
user2, google_apps_user2
user3, google_apps_user 3

or alternatively

user1@domain.com, google_apps_user1@googleappsdomain.com
user2@domain.com, google_apps_user2@googleappsdomain.com
user3@domain.com, google_apps_user3@googleappsdomain.com

Save the CSV file for reference later.

To start the migration we need to launch the Google Apps Migration tool.  Once you launch the tool click Next on the first screen of pre-requisites and then you will see the screen below.

On this screen you need to enter the NETBIOS name of your Exchange Server and then the SMTP domain you have registered with your Google Apps account.  The SMTP domain may well be the same on your Exchange Server and Google Apps, this is normal in a migration scenario.

Once you have entered the required information click Next.

This screen requires the service account you created earlier, in my case this is the Administrator account.  By default the Administrator user account will not have service account priviledges in Exchange Server 2003.

You will then be required to enter the Consumer key which is normally the domain name you will be migrating to and then the Consumer secret which you would have created in the section above under the heading of Enable 2-Legged OAuth

Once you have entered the required information click Next.

This screen we need to specify the CSV file we created earlier with our list of usernames that will be migrated.  You have an option to select Migrate all data or just new data.

The main reason I can see this being useful is if you want to migrate all the historical data to the new mailboxes on Google Apps, then move the users over to their new mailboxes and then perform another migration for anything that has changed during the cut over period.

Once you have made your choices click Next.

The next screen allows us to specify which data from Exchange will be migrated over to Google Apps.  The Migration tool does seem to perform data moves on all the selected mailboxes at the same time which if you don’t have a lot of bandwidth could cause problems.  If this is the case then the Restrict migration to n users at a time would be a very useful option.  Other than this it’s fairly self-explanatory.

Once you have made your choices click Next.

The next screen simply gives confirmation of what we have already entered, the option to edit these settings and probably more importantly the option to save the settings.  This would be especially useful if you will be performing a migration and then a second to pick up the changes.

When you are ready click Migrate.  This will then start the migration process.

For purchasing SSL Certificates please visit: http://www.exchangecertificates.com

There could be many reasons why you would want to export mail directly from the Exchange Mailbox Store.  You may be migrating to a hosted solution, you could be moving to a different Exchange organisation or you may simply be using Exmerge as a way of doing a brick level backup of your mail store.  This question has come up a lot recently with askers not wanting to migrate to Exchange 2010 but to start fresh and take their mailbox data with them.

Exmerge is a free utility available from Microsoft as a download using this link: http://www.microsoft.com/downloads/details.aspx?familyid=429163ec-dcdf-47dc-96da-1c12d67327d5&displaylang=en

Exmerge can be used against any version of Exchange from version 5.5 up to and including Exchange 2003, as long as the Exchange 2003 Management tools are installed on the system where you plan to use Exmerge.

NOTE: Outlook is not required for this process and should never be installed on an Exchange Server older than Exchange 2007.

Before we can run exmerge there are a few things we need to do.

Once you have downloaded Exmerge you will need to extract it into the C:\Program Files\ExchSrvr\Bin folder to allow it to run.  This is because it relies on DLL’s in this folder.  The other option would be to add this path in to the Environment Variables but this would require a reboot to take effect.  For this article I will assume you are extracting to the folder I have recommended above.

You will need a user account that has access to all the mailboxes that you will be exporting.  This type of account is commonly referred to as a service account.  If you don’t already have a service account I would recommend configuring a new user and then follow the instructions in this link: http://support.microsoft.com/kb/292509

Once you have made permission changes on the Information Store there may be a delay in them being applied of up to 2 hours.  This can be expedited by restarting the Microsoft Exchange Information Store service.

Please note that the Administrator user does not have these privileges by default and under a normal Exchange Server installation is specifically denied the required permissions.  This is why I always configure a new account specifically for this purpose.

Extraction Process

To extract the mailboxes from Exchange, login using the service account you have created and then run exmerge.exe from the c:\program files\exchsrvr\bin folder.

Click Next on the welcome screen and you will see the screen below.

The Extract and Import function will extract the mailboxes you choose to PST’s and then import them in to a source server of your choice in one process.  The option we need is the Extract or Import (Two Step Procedure).  This will allow us to extract the mailboxes to PST files ready for later use.  Select Extract or Import and then click Next.

You will then have 2 options.  Step 1 for extracting the data from the Exchange Server and Step 2 for importing.  We are going to be using Step 1 which will extract the mailboxes we choose into PST files and store them.  Select Step 1 and click Next.

The source server screen shown above is where the details of the Exchange Server, Domain Controller and Port Number for LDAP queries (optional).  For most scenarios you will only need to enter the name of the Exchange server.  The domain controller and port number is only used if you have a multiple domain configuration and need to specify a different domain controller.

NOTE: Exmerge will not extract mailboxes that are over 2GB in size in a single pass.  This is due to the size limitation of the PST format that exmerge uses.  To get around this we can use the options button on the source server screen as demonstrated below.

On the options screen select the Dates tab, this will allow you to specify a date range to export first, this is useful for the larger mailboxes over 2GB in size.  Splitting the export into 12 or 6 month exports should reduce the possibility of hitting the size limit but you will need to adjust these for your own individual requirements.

NOTE: When you run exmerge and specify a date range for export make sure that once the export has finished it’s important to rename the PST.  If you don’t do this then the next time you run exmerge to do the next date range it will overwrite the last PST

Once you have finished click OK and then Next on the source server screen to show the mailbox selection screen.

On this screen you can select the mailboxes you want to select either individually, using the CTRL button to select random mailboxes or click the Select All button to just select all mailboxes.  Remember that whatever selection you made in the options screen will be applied to ALL of these mailboxes for this export. Click Next.

Select the Locale that your Exchange Server is currently using, exmerge should detect this by default but it’s always worth just double checking.  Click Next.

On the target directory screen select the folder you would like the PST files saved to.  It’s worth noting that you can only select an existing folder so you will need to create a folder prior to clicking the Change Folder button.  Once selected click Next.

The Save Settings screen allows you to save the settings that have just been specified in the wizards in to the exmerge.ini file.  This is useful if you want to set the export up and then schedule it for another time or if you want to run regular backups using exmerge for brick level backup.  Once you have all these settings saved in exmerge.ini file you can then use exmerge in command line mode without the need to run through the wizard.

Once you click Next on this screen the extraction process will start so make sure you are happy with the settings you have made and click Next.

You will then see this screen.

Once the extraction process has finished click Finish.  If there are errors listed on the screen then you will need to review the exmerge.log file in c:\program files\exchsrvr\bin folder.

Issues that will cause problems with exporting data using Exmerge are:

  • Incorrect permissions (covered by creating a new service account)
  • Information Store being Dismounted
  • User account associated with the mailbox being disabled
  • Not enough disk space in the location where you are storing the PST files
  • Mailbox over 2GB in size
  • Corrupt items in mailbox (if this happens then the only option you have is to export using Outlook as exmerge will not export corrupt items)

For guidance on how to import your PST files in to Exchange 2010 see my other blog post here: https://demazter.wordpress.com/2010/03/23/importing-pst-files-in-to-exchange-2010/

With Exchange 2003 Enterprise, Exchange 2007 and Exchange 2010 there is no need to run an offline defrag of the Exchange database.  All of these versions will allow the creation of another mailbox store.  Once you have another mailbox store you can simply move the mailboxes from the fragmented sore to the new one.  This will provide you with a fully defragmented and error free mail store with the added bonus of no down time.

In Exchange 2003 Standard Edition with Service Pack 2 there is a soft database limit that can be set up to 75GB.  Many believe that simply running an offline defrag of their data store will help them to stay below the limit.  This is simply not true.

The 75GB limit in Exchange 2003 is a soft limit and it is based on the LOGICAL size of the database not the PHYSICAL size. The logical size of the database can be loosely calculated by taking the combined size of the EDB and STM files minus the free space reported in Event 1221 in the Application Event Log.   Guidance on finding the true size of the stores can be found here: http://technet.microsoft.com/en-us/library/aa996139(EXCHG.65).aspx

By default Exchange 2003 will run online maintenance every day, normally at around 5am.  Part of this maintenance is to run an online defrag of the database.  Details of what other tasks are run as part of the online maintenance can be found here: http://support.microsoft.com/kb/324358

Once the online maintenance has been completed there will be an event 1221 generated in the Application event log.  There will be one for each store.  The description will say “The database "<storage_group>\<mailbox_store> (<server_name>)" has <nnn> megabytes of free space after online defragmentation has terminated” this event shows how much free space is in the EDB file (it does not include the STM file).

Creating “white space”

The free space that is reported by Event 1221 is often referred to as “white space”.  This free space will be used by Exchange before expanding the physical size of the database.  If your database has reached the 75GB limit then you will need to create free space to bring the logical size of the database below the limit.

The easiest way to do this is to delete any unwanted mailboxes and ask your users to archive some mail or delete mail that is no longer required.

Depending on your deleted item retention period this may take a long time to be seen as free space.  If you are trying to alleviate an immediate problem then you can speed this process up by setting the deleted item retention periods to 0.  This will make any items that are deleted,  permanently deleted rather than sent to the dumpster, where you can recvover them with the tools, Recover Deleted Items option in the Deleted Items folder within Outlook.

This will then hopefully bring you below the logical limit of your database.

Only if PHYSICAL storage on your server is a problem should you perform an offline defrag of the database to recover the free space reported by Event 1221.  If there is no free space reported by Event 1221 then an offline defrag is a complete waste of time.

Offline Defrag

If you have read all of the above and you are still convinced you need to perform an offline defrag of the Exchange database then I would recommend you follow these guidelines:

  • Perform a FULL backup of the Exchange Information store using either Windows Backup or a 3rd Party Backup product.  It must be an Exchange aware backup and it must be a FULL backup of the store not a brick level backup.  This will ensure all the transaction logs are flushed.
  • Dismount the store and make a copy of the STM and EDB Files to another drive.  Consideration needs to be taken for the fact that the defragmentation process needs a minimum of 110% of the size of the store in free space.  So if your store is 75GB you need an extra 83GB of free space.  If the drive that the store is on does not have enough space then move it do a different volume and perform the defrag there.
  • Run the ESEUTIL /D “c:\program files\exchsrvr\mdbdata\priv1.edb” command to start the defragmentation

Please note that depending on the specification of the server and any other additional tasks that it may be performing you should expect a defrag to take anywhere from 4 – 7 GB per hour.  So if you have an 80GB file it could take up to (and probably longer) 20 hours to perform a full defrag.  During this time the Exchange Server will be unavailable to users.