All those System Administrators running their Exchange Server 2007 on a Windows 2003 (64-bit) server have the previlage to get access to the traditional NTBackup utility to backup their exchange stores. But those who are running their Exchange Server 2007 on Windows 2008 (64-bit) must have faced the dilema of which tool to use to backup their mail stores. This is because Windows Server Backup in Windows Server 2008 no longer supports Exchange-aware backups or restores. In order to back up and restore Exchange Server 2007 Service Pack 1 (SP1) on Windows Server 2008, you must use an Exchange-aware application that supports the Volume Shadow Copy Service (VSS) writer for Exchange 2007, such as Microsoft System Center Data Protection Manager, a third-party Exchange-aware VSS-based application, or a third-party Exchange-aware application that uses the streaming backup APIs locally on the Exchange server to make a backup locally on the Exchange server.

What does all this mean? Nothing but shelling out extra $$$ to invest in a backup solution unless you are interested in a very simple backup solution to assure that the logs get truncated and you have backup copies which you can restore. Here is a basic hack which can help one save a couple of $$$.

Step #1

Get access to a Windows 2003 R2 Server which is running a 64-bit OS. Assuming that you are not running your production Exchange Server 2007 in 32-bit environment, we require the 64-bit version library files. If you do not have a one handy, you can get the source files and then expand the DLL’s or install one in a virtual environment.

Step #2

Copy the ntbackup.exe, ntmsapi.dll, and vssapi.dll files from C:\windows\system32 into a new folder on your Exchange Server 2007 running on Windows 2008. I created a folder called NTBackup under Program Files and placed them there.

Step # 3

Right click Ntbackup.exe and choose “Run as administrator”.

Your should see the Exchange Server Information Store as part of your backup wizard.

Select the Information Stores that you want to backup. Choose the Backup media or filename and the path where you want to store your backups. Once you have finished the configuration, click on Start Backup and the exchange store backups should start.

Once the backup is complete, you should see all the transaction logs getting truncated (hope circular logging is not enabled) and also the mail store would be stamped with the Last Full Backup date and time stamp.

One thing to note though: you cannot back up a storage group in a Standby Continuous Replication (SCR) environment. Backups of storage group copies are available for Local Continuous Replication (LCR) or Cluster Continuous Replication only.

Here is a quick check list for System Engineers and Data Base Administrators to lock down MS SQL Server and secure the database server:

Communication: If possible and if budget permits, do not expose the SQL Server directly to the Internet. Allow the communication from a web server to the SQL database server over an internal IP address.

Strong Passwords: Ensure that the server uses a strong password for the “sa” account. Use a combination of letters, numbers and symbols. This make it difficult for Brute Force hacks to guess the password.

Authentication: Keep this to Windows Authentication if possible and avoid setting SQL to run under Mixed Mode. Windows Authentication will require SQL server to check the Active Directory and moreover the logins will not be stored in the SQL server.

Service Packs and Updates: Make sure that the SQL Server is always patched with the latest Service Pack and Security Updates. This ensures that the latest security vulnerabilities are addressed and blocked.

Service Accounts: Run both MSSQLSERVER and SQLSERVERAGENT under the Domain User permissions. Do not run them under any Administrator account. This ensures very less damage in case the user account or the server is compromised.

Block Ports: If there is no need to expose the MS SQL Server to the Internet, block port 1433 and 1434 at the firewall. This means that the SQL Server will not be accessible from the Internet, thus making it hard for outside attackers to reach to the server. It also prevents worms and viruses.

Backups: Encrypt and compress the backup files. Put a password on the backups and store them to a safe location. Do not keep them on the server.

Patching the Windows Operating System in an organization with multiple desktops and many flavors of operating systems is a mammoth task. It is vital for any Systems Administrator to ensure all systems are properly patched and updated to safe guard against virus, worms, and Trojans. The biggest challenge in running Windows Update on individual machines is the inconvenience of visiting each desktop and approving the updates manually. Moreover, the amount of bandwidth used at each desktop to download the updates is huge not to forget the lack of centralized reporting.

So why do we need a centralized patch management policy? Well, the answer is simple – the systems are prone to risks and threats when exposed to the Internet or medias like USB pen drives, wireless networks and devices, etc. We all, at some point, might have experienced or read about the havoc caused by Blaster or the Sasser worms. Today software vendors have stepped up the releases of emergency and critical updates in a formalized manner to encounter these threats. Microsoft’s Patch Tuesday is a good example that highlights that. To learn more about this program, click here.

WSUS from Microsoft is a boon to Network and System Administrators in this scenario. WSUS (Windows Server Update Services) is basically designed to run on a company’s network and automate the process of patching. This free product from Microsoft does a fair job of streamlining the overall patch management process of an organization with centralized reporting. For a Network or System Administrator it is just a simple task of installing the WSUS server on a system and then configures all Desktops to use the WSUS server for software updates. This can be easily achieved by creating a group policy and linking the policy to the correct OU using Group Policy Editor. The Desktops would automatically announce their current status to the WSUS server with details like which patches are needed to be installed, which patches have failed to install, which patches have been successfully installed, etc.

In a nutshell, WSUS seems to be a good product especially when there is no price tag attached to it and starting with WSUS 3.0 the reports have also improved over its predecessor.

In this article I’ve tried to explain how to install or upgrade an organization running on Exchange Server 2003 to Exchange Server 2007 SP1 on a Windows 2008 Server. In the next post I’ll be talking about some post install configurations and then after how to remove Exchange 2003 from the organization once everything is migrated to Exchange 2007.

There is no in-place upgrade supported with Exchange 2007 and so the only option is to upgrade to Exchange Server 2007 by adding it to the current Exchange 2003 organization and then moving all the resources from Exchange 2003 to Exchange 2007 and thereafter removing the Exchange 2003 Server. This means that we have no option but to perform a migration. So let’s get on with it.

Prerequisites

The first step is to prepare our new Windows 2008 server so that it is ready for Exchange Server 2007 installation. Please note that we are talking about the 64-bit version of Exchange Server 2007 SP1 as the 32-bit version is not supported in production environment.

We will need the following components installed before we proceed:

• .Net Framework version 2.0 and 3.0
• .Net Framework version 2.0 update or Service Pack 1
• IIS 7 (various components)

 

• Windows PowerShell
•  
• MMC -Microsoft Management Console 3.0 (installed by default so can be skipped)

The following components should not be installed (were required in Exchange 2003):

• Network News Transfer Protocol (NNTP)
• Simple Mail Transfer Protocol (SMTP)

Once we have installed the prerequisites, let’s proceed towards the installation.

Installation Process

We are going to install all Exchange Server Roles (HUB, CAS and MAILBOX) on one single box except for the Edge Transport Role. Let’s start by first preparing the Active Directory for Exchange 2007. Actually, the installer would do this automatically, but I like to perform this manually so that we can see what’s happening and understand it better. Here is what we will do before we run the installer of Exchange 2007:

• Prepare the schema for legacy Exchange permissions. This is because we are migrating from Exchange 2003 in the current organization.
• Prepare Schema
• Prepare Active Directory
• Prepare the Domain

The first thing that we do is to update the schema for legacy permissions. In order to do this we must login to the Domain Controller which is the Schema Master at the forest root and run the command from there.

Type Setup /PrepareLegacyExchangePermissions and press Enter.

 

This must be run as an Exchange Admin account and also ensure that you are in the local server’s Administrator group. The safest thing to do is to add the user account you are logged in with to the Enterprise Administrators Group, Schema Administrator Group and Domain Administrators Group. Also, the domain should be able to communicate with all other domains in the forest and we should all ample time for the replication to finish once this command is run.

Next, we will proceed towards updating the Schema from the Windows 2008 Server.  Type Setup /PrepareSchema and press Enter.

 

We can see that the task failed with an error on the server. This is because the Remote Server Administration Tools were not installed. We can do this using the GUI but I’ve used the command line. Type ServerManagerCmd -I RSAT-ADDS and press Enter.

 

Here we go, the Remote Server Administration Tools have been installed and we need to reboot our Windows 2008 server before proceeding further.

Once the server has rebooted, let’s try preparing the Schema once again. Type the command that we used earlier – Setup /PrepareSchema and press Enter.

 

This time the task completed without error. Let’s move on.

Type Setup /PrepareAD to proceed with the Active Directory preparation.

 

Once this is completed, move on with preparing the domain.

Type Setup /PrepareDomain and press Enter.
Note: this setup can be skipped if you do not have multiple domains within the forest.

 

Great, we are done with preparing our Active Directory for Exchange Server 2007 SP1 installation and now we can run the installer. If you have geographically dispersed domains, please allow enough time for replication to happen over the WAN links.

So, with the Active Directory now ready, we are ready to complete the installation. Start the setup. The first screen that we see is as under:

 

Since we have already taken care of the prerequisites, we can directly proceed to Step-4 i.e. Install Microsoft Exchange Server 2007 SP1. Click on it and we will be presented with the standard EULA.

 

Accept the License Agreement and click Next.

 

We now have a choice of a Typical Installation or a Custom Installation. Since I like to see what configuration options are available, I always tend to choose the Custom option. Also, for this example, we are going to install the Exchange server in the D: drive instead of the C: drive. You can change the path to your liking here. Once the selections are done, click Next.

The next screen allows us to choose which roles we want to install.

 

We will choose all the three main roles i.e. Mailbox Role, Client Access Role (CAS) and Hub Transport Role (HUB). I’m not choosing the Unified Messaging Role (UM) as I intend to do a separate article on this in the near future.

Once the selections have been done, click Next.

 

Here we go. The installer now prompts for the Mail Flow setting. Since we have an Exchange 2003 server we will need to browse and select the same so as to enable it as a Bridgehead server in the routing group. Once selected, click Next.

 

In the Readiness Check page, wait for all the readiness checks to complete and then click Install.

The installation process takes some time so it would be a good idea to sit back and relax over a cup of coffee. During the installation process, if we open up the System Manager on Exchange Server 2003, we will notice a new routing group.

 

Once the installation process completes, we now have a working environment of the new Exchange Server 2007 SP1. The process of installing Exchange 2007 on a Windows 2008 server is fairly simple.

To verify the installation, open the new Exchange Management Shell and type Get-ExchangeServer. A list of all Exchange 2007 server roles that we installed would be displayed. It is a good idea now to open up the Management Console of Exchange and run the Exchange Best Practices Analyzer. It will give a good idea about the deployment and would help in determining if the configuration has been done in accordance to the Microsoft best practices.