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.

NT Backup Exchange 2007

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.

In the first step we have to configure a Server for monitoring and select/configure the resources to monitor. To do so, open the Exchange System Manager Snap-In and select the appropriate Server object in the Servers container.

Right-click the Server object and open the Properties for it.

Once the Properties dialog box is open, select the Monitoring tab as shown above.

There are many resources available for monitoring. We can add the following resources:

• Available Virtual Memory
• CPU Utilization
• Free disk space
• SMTP queue growth
• Windows 2003 Service
• X.400 queue growth

Many other 3rd party monitoring tools like Nagios can do most of the monitoring and so we will only add the two most critical items which are not monitored by Nagios. These are:

• Available Virtual Memory
• SMTP queue growth 

In the first step, we will add the Available Virtual Memory instance. Click on the Add button under Monitoring tab. A dialog box similar to the one shown below will open.

Select the Available Virtual Memory from the list and click on OK.

Configuring virtual memory monitoring is very similar to configuring CPU utilization monitoring. We have skipped the CPU Utilization Monitoring. Set the duration to 5 minutes, the warning threshold to 15% and the critical threshold to 10% for Available Virtual Memory. Once the values are set, click on OK.

Follow the process for adding another instance and select SMTP Queue Growth this time from the list.

If SMTP queues start backing up, it often indicates that there is a major problem. It shows that message transport has failed, the Internet connection has failed, or someone is using the server to send spam. In any event, we need to know that there is a problem.

We must input a warning and a critical state threshold value, but these values are entered in minutes. The idea is that we must tell Exchange how many minutes the queue should be constantly growing for before we generate a warning or a critical state message. We can use any values that we want, but I recommend setting the warning threshold at 10 minutes and the critical state threshold at 15 minutes.

Close the dialog boxes and the Properties once done. The next step is to configure an E-Mail notification for the recipients of the “Warning” and “Critical” state conditions. To do so, open the Notifications object under Tools.

Click on New and select E-mail Notification.

In this Property dialog box we can specify the monitoring Server and the Servers / Connectors to monitor. We also have to select the State (Critical and warning) for which we configure E-Mail notification.

First we will configure the Warning State notification.

In the “To” field select a recipient for the notifications. 

Change the Email server value to some other server in your organization which runs SMTP. If you do not have any, I suggest setting up a basic MS SMTP service in IIS. This is because when the monitored Server is the same Server as the monitoring Server we can run into trouble. The Server cannot send us an E-Mail notification when it is in an critical state and is unable to send E-Mails.

Next step is to configure E-mail Notifications for Critical State. Follow the same steps that we went through earlier for Warning state notification except for the fact that this time we will select Critical from the drop down.

Once done, close all the property pages and dialog boxes. We are done with the setup.

Now when one or more of the configured resources run into a “Critical” or “Warning” state we receive a E-Mail from an account “WMI@SERVERNAME” with a error message with the server name in the subject line and the condition of the resource / service in the E-Mail body.

Technorati Profile

Now that we have installed the Exchange Server 2007 SP1 in the organization, it’s time to move the user Mailboxes to Exchange 2007. Moving mailboxes is a very easy task and can be accomplished by using the Exchange Management Console or by using the PowerShell commands from command line. In this post I’m going to use the Exchange Management Console.

So, let’s open the Exchange Management Console and in the tree on the left, navigate to the Recipient Configuration and expand it. Under the node, select Mailbox.

Here we can see in the results pane that now we are able to see all the mailboxes that we have on our Exchange 2003 server and they are all marked as Legacy Mailboxes. This means that all the mailboxes are still on the Exchange 2003 Server and need to be moved to Exchange 2007.

In this example, we will move the Administrator mailbox. So we choose the account, right-click it and choose Move Mailbox.

The next screen provides us options as to where we want to move the mailbox and here we need to choose the mailbox database. I assume here that the Storage Groups and Mailbox Database are already created on Exchange Server 2007. If not, then that’s the first thing that you need to do.

In my example, I’m going to move the Administrator mailbox to the General Mailbox Database.

There now that we have selected the Mailbox Database, Exchange 2007 automatically appends it with the Server Name and the Storage Group. Click Next to proceed.

On the next screen we are presented with lot of options as what should be done if the Move Mailbox process encounters any errors or finds any corrupt messages in the mailbox. Either we can Skip the entire mailbox move or we can allow Exchange Server to move the mailbox and simply Skip the corrupted messages. Moreover, if we go ahead with that option, we can even define how many corrupted messages should be skipped before the Move Mailbox stops the process. Since, I would not like to skip any messages, I’ll choose “Skip the Mailbox” and move further.

Next we are presented with the scheduling screen which allows us to schedule the Move Mailbox process. This helps in particular when you are in a production environment with heavy traffic and want to schedule this unattended during off-peak hours. Moving mailboxes does not take much time and is entirely dependent on the number of items in the mailbox. Even in a production environment, while moving mailboxes, the user will hardly notice any issues and after moving the mailbox, the user may simply need to restart Outlook to get everything working again.

In the scheduling option, you can choose to move the mailboxes during off peak hours and also you have a choice to cancel the running task if the move mailbox task runs for certain hours. I’ll chose “Immediately” and move ahead in this example.

That’s the last screen that we see before we actually tell exchange to move the mail box. It allows you to do a quick round up of what we have selected and what options have been set. Once we have reviewed the options, click on “Move”.

While the mailbox is being moved, we can see the progress, the number of items found, the number of items moved, etc. If you select multiple mailboxes, note that by default Exchange 2007 moves only 4 mailboxes at a time. The remaining mailboxes will be shown as “Pending”.  Lot of checks are performed in the background by the Exchange Server during this process.

If all goes well, the final screen that we see is the confirmation showing us the status of the Move Mailbox process. Click on “Finish” to close the wizard. That’s it to Moving Mailboxes from Exchange 2003 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.

Microsoft officially released a public Beta of Exchange 2010 which was formerly code named ‘Exchange 14”. I was already blinded by the features that Exchange 2009 provided – Unified Messaging being the best of the many and now we have Exchange 2010 in the pipeline. There are so many improvements in this version that I can’t decide which ones to highlight and talk about first. The product claims to achieve high levels of reliability with greater flexibility, enhanced user experiences and increased protection for business communications.

OWA (Outlook Web Access) has been scaled out to support Internet Explorer – 7 and 8, Firefox 3 and Safari 3. Users will no longer be restricted to using Internet Explorer. OWA has been further improved to provide a web user with all the functionality of Outlook desktop client. Also, a new feature of conversation view has been added greatly reducing mailbox clutter.

Voice Mail Preview is another feature that deserves applause. OWA and Outlook 2010 support voice mail previews. Exchange 2010 automatically generates text based preview of a voice mail message received. Not sure how accurate this is going to be but the concept itself is worth it.

Users will be able to create and moderate their own Distribution Groups and can also decide who they want their Calendar and Contacts shared with.

Ever got bounce backs after sending emails with large attachments or accidently sent a personal email to everyone in your company? Now you need not worry about that. MailTips is a new feature added up which prompts you before you send a message.

Message Tracking and Delivery Reports has been improvised in Exchange 2010 – works well inside the Exchange Organization and federated servers.

No more Administrator privileges required to scan or search other mailboxes in the organization to meet compliance. Authorized users can perform MultiMailbox Searches without the use of administrative rights.

Self service via Exchange Control Panel (ECP) is now made available to the end-user. This means that a user can now update their personal details in their account which earlier required a help desk call or ticket.

Database portability and multiple options for high availability were already made available in Exchange 2009. These have been further improved in Exchange 2010 and also open possibilities of reducing the operations costs. Database Availability Groups now gives redundant mail stores with continuous replication. Database-level Failover gives automatic recovery and the I/O optimizations make Exchange 2010 better suited for SATA drives.

These are just some of the powerful features that have been released in the Beta. We may be having a few more added to these in the final specimen. Overall the new version of Exchange looks very promising and exciting.

There it was. All mailboxes along with data moved to new server. The only thing left there after was to update the configuration of the mailboxes using Powershell to point to the new server. Thank you to the team at Microsoft for making this less painful compared to Exchange 2003.

When migrating to Exchange 2007 from an exisiting organization, Exchange remains in a coexistence mode unless all mailboxes are migrated to 2007 and the 2003 servers are taken out. This means that during the migration process some users would be having their mailboxes on 2007 while some may be having their mailboxes on 2003. Users accessing their email via OWA, Outlook Anywhere, ActiveSync, Blackberry or RPC/HTTP should not be affected during this transition.

To overcome this, I setup the CAS role on a Virtual while keeping the HUB and Mailbox role on a physical machine. Isolating the CAS allows Exchange 2007 to proxy the requests to the Exchange 2003 organisation. Users who have their mailboxes on 2007 are presented with the new 2007 OWA login from https://yourdomain.com/owa while users with their mailboxes on 2003 still need to go to https://yourdomain.com/exchange. In order to ensure things worked right for RPC/HTTP, webmail, etc. I wrote a script and put it under the Default Site. Here is the script:

Now accessing the URL which the users originally used to access Outlook Web Access presented the users with a new interface of OWA from Exchange 2007. Users who had their mailboxes on Exchange 2007 were given the OWA 2007 experience while those who were having their mailboxes on Exchange 2003 – the request was automatically proxied to the Backend Server and they were presented with the experience of OWA 2003.

I found that the problem was with communication over SSL (Secure Socket Layer) because the Exchange virtual directory in Microsoft Internet Information Server (IIS) is configured to accept only Secure Sockets Layer (SSL) connections on our server. Naturally this has been done to keep the security in place and to ensure that no passwords are sent out in clear text since Basic Authentication is enabled and Integrated Authentication is turned off.

Upon further research I found that Microsoft-Server-ActiveSync and Outlook Mobile Access virtual directories only try to connect with the Exchange virtual directory over TCP port 80 (HTTP) and does not make use of TCP port 443 (HTTPS).

I also tried adding Root Certificate to the PDA using the Microsoft solution as highlighted in their KB — but things do not work so easily for me — ANYTIME. It’s always hard work.

The best option was to take off SSL for OMA and ActiveSync. I exported the configuration of Exchange directory from IIS and imported the same under ActiveSyncPDA. After the import I removed SSL option from the virtual directory. The next step was to add a new parameter in the registry:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMasSyncParameters

and set it to point to the new virtual directory called ActivesyncPDA.

Restarted IIS and this time the sync from PDA worked over GPRS and Wi-Fi connections.

So, a new server was setup which had the ISA 2004 configured and which could talk to the current network so that the traffic from ISA can flow to Exchange server and vice-versa. The challenge was that their current FQDN did not point to the real IP which was set on the external interface of ISA.

In order to over come that situation where ISA would show a URL error, I set the client machine’s host header entry (which was outside the network) to point to the real IP of the new ISA server’s external interface. Next setup was to configure the new ISA to allow SSL Bridging between ISA and Exchange and configure it to use Forms Based Authentication (FBA).

After configuration of the above, I tried to access the FQDN from an external client and nothing happened. That was bad!!

ISA denied the request until I enabled “Require All Users to Authenticate” check box (which is not mandatory). This time I was happy to see the OWA screen on the client. But my worries did not end there. If I tried to login, OWA would not open the Inbox. Obviously the next step was to verify if ISA was able to authenticate the user credentials against Active Directory. Yes, checking the monitoring logs should that it could. So what was missing???

After some more hair pulling, analysis and some more hair pulling the loophole was found. ISA was not able to redirect the request to the Exchange Server for some reason. Added a host entry with the internal IP address of Exchange Server on the ISA Server and tried it once again.

Voila! We are there. Now the clients can enjoy their secure Outlook Web Access solution. Yes, the migration of ISA is still pending — but that’s a different story.