6 options for connecting Exchange to the Internet

When it comes to designing an Exchange 2010 infrastructure, one of the key design decisions you have to make is “how will the system connect to the Internet?” Microsoft has separated out the Internet connected parts of Exchange into what it calls the Edge Transport role, but you do have other options.

This post will discuss six options for deploying your edge connectivity and integrating it into your Exchange 2010 infrastructure, and include some pros and cons for each. Knowing what your options are will help you to determine what the best solution is for your system.

1. Deploy the edge transport role in the DMZ

If you follow Microsoft’s own recommendations for deploying Exchange 2010, you will build a DMZ server that does not belong to your domain, deploy it into a screened subnet/DMZ, and install the Edge Transport role. You can still manage this server’s Exchange components by subscribing it to your Exchange organization using the Edge Subscription service, but otherwise it runs as a bastion host in your DMZ.

Pros:

• This is Microsoft’s recommended solution.
• You can still manage the server as part of your Exchange organization.

Cons:

• This requires an additional server license as well as an Exchange license.
• If you deploy this the Microsoft way, as a DMZ server in workgroup mode, you must maintain the operating system separate from your domain.

2. Deploy the edge transport role on a TMG server

If you already have Microsoft Forefront Threat Management Gateway deployed, you can install the Edge Transport role onto your TMG server(s.) This option lets you leverage your existing TMG server(s) and also strengthens Exchange’s own defenses with Forefront TMG’s.

Pros:

• By leveraging your existing TMG server(s,) you have less operating system licenses to purchase.
• You can still manage Exchange using the Edge Subscription.

Cons:

• If your TMG admins are not also the Exchange admins, they may not wish to do this, and it will add complexity to managing the TMG servers.
• If you have deployed your TMG servers in a cluster, you should install Exchange Edge Transport role on both, which will require two licenses. Of course, you probably want fault tolerance with this anyway, so this may not be a big an issue.
• Your TMG servers will require more RAM and consume more CPU resources than without Exchange.

3. Publish the edge transport role using TMG

In an ideal world without hardware or budget constraints, I would lean towards this design. You will still deploy the Edge Transport Role, but you will publish the mail protocols through your TMG infrastructure.

Pros:

• This follows Microsoft’s recommendations for dedicated Edge servers, and adds additional security by publishing them through the TMG.
• Separates the management of TMG from Exchange, while still leveraging both.

Cons:

• This does require more hardware, and more operating system licenses than any other option.
• When troubleshooting mail flow, there is an additional step all mail must take.

4. Deploy an mail screening appliance in the DMZ

There are lots of mail appliances on the market today, offering anti-spam, anti-malware, content inspection, logging, archiving, and more. Appliances are typically hardened, purpose-built solutions, that do what they are built to do very well.

Pros:

• You can get the best ‘bang for the buck’ from these solutions, as they are built specifically to do mail screening.
• Appliances typically require less maintenance and administration than server based solutions.

Cons:

• These can be expensive, both to acquire and for the annual subscriptions that most require.
• They can also require some expertise to deploy, though most vendors are happy to sell you professional services to get up and running.
• When troubleshooting, these can be a ‘black-box.’ Make sure you look at their logging and reporting capabilities and are comfortable with that.

5. Deploy a mail screening server in the DMZ

Like an appliance, this option uses an application installed on top of a server to perform anti-spam, anti-malware, content inspection, logging, archiving and more.

Pros:

• While the cost of the server and operating system may equal or exceed appliances, the servers will generally be easier to deal with for your administrators, and could be leveraged for other services if they have capacity.
• Windows-based applications are often more transparent, and easier to troubleshoot.

Cons:

• As a server, it needs as much maintenance as any other.
• They also require annual subscriptions that can be costly to maintain.

6. Deploy a cloud based solution

Whether you call it Software as a Service, an outsourced solution, or a cloud based service, you are moving your mail screening offsite; having mail flow through a service provider for anti-spam, anti-malware, content inspection, logging, archiving, and more, and then delivering only clean mail to your Exchange infrastructure. This is how I do things now, augmenting my TMG services with GFI’s Max MailEdge.

Pros:

• By filtering mail before it hits your pipe, you are not worried about spam consuming bandwidth, CPU, or disk on your system.
• These cloud providers are generally better able to screen mail at scale, making them a very cost effective solution.

Cons:

• Because content is being screened (and potentially blocked) off site, your ability to immediately check to see if an important mail has been blocked, and to release it, may be limited. While most of these service providers have options for reporting and releasing email, they are an external service. You cannot just log onto the server and check the queue.
• Not all services offer the same degree of flexibility and customization as an in-house solution.

When it comes to your edge services for Exchange, it’s good to know that you have options. Go through an exercise to define what your minimum requirements are for your content screening solution, and then investigate each of the possibilities based on budget, flexibility, and administrative overhead, to find the one that fits for you.

Unavailable Exchange Server 2010 Features and Changes

Something gained, something lost – so the saying goes as I remember. And with Microsoft Exchange Server 2010 there were many features lost, I mean removed. Here is a list of the features that were removed.

1. In Exchange Server 2007 you had three different types of replication to support high availability. But as of Exchange Server 2010, Local Continuous Replication (LCR), Cluster Continuous Replication (CCR) and Standby Continuous Replication (SCR) are no longer available. Even Single Copy Clusters (SCCs) have been removed. SCCs are reminiscent of earlier high availability solutions for Exchange but as of Exchange Server 2010 they are being replaced by Database Availability Groups (DAGs). Database Availability Groups are easily configured and are similar to disk drive related fault-tolerant solutions.
2. The deployment of Auto Archive based retention settings through Outlook 2010 via the Group Policy is no longer available. Retention policies can now be set by way of the Messaging Records Management (MRM) features in Microsoft Exchange Server 2007 and later versions.
3. Windows Server Fail-over Clustering has also been removed from Exchange Server 2010. A lot of Exchange Administrators reported that the fail-over clustering was too complex and difficult to manage. The result was that there were more errors and problems associated with Windows Server Fail-over Clustering to outweigh the benefits. It was therefore pulled from Exchange Server 2010.
4. Exchange Server 2007 included built-in support for incoming faxes but is no longer supported in Exchange 2010. Email administrators will have to evaluate third party solutions to meet their fax requirements. One such company is Concord Fax from Concord Technologies. Both incoming and outgoing fax services will need to be evaluated.
5. Exchange Server 2010 no longer includes Storage Groups. Administrators can still work with the Storage Group concept in terms of a database, log files and a checkpoint file. But they are better known simply as a Database. It is similar to the Cluster Continuous Replication (CCR) in Exchange Server 2007 in that there is only one Database per Storage Group.
6. There were major reengineering efforts made to the Exchange Server 2010 database which affected the Single Instance Storage (SIS). As a result of those changes the Single Instance Storage (SIS) was removed. This change has affected the size of the Exchange Server database when emails and their attachments are sent. For example, a 1MB message sent to 200 recipients can result in the database growing by 200MBs. Administrators need to readjust their sizing calculations to bring their storage estimates up to date and in line with the new growth projections.
7. Client authentication using Integrated Windows authentication (NTLM) for POP3 and IMAP4 users has been impacted in Exchange Server 2010. NTLM is no longer supported for POP3 or IMAP4 client connectivity. The recommended POP3 and IMAP4 setting alternatives to NTLM are:  Kerberos (GSSAPI) and Plain Text Authentication with SSL. If NTLM is used then connections from POP3 or IMAP4 client programs to Exchange 2010 will fail. Administrators who need the NTLM capability can still use an Exchange 2003 or Exchange 2007 server in their environment.
8. Architectural changes include:

• Routing groups – Exchange Server 2010 uses Active Directory site-based routing.
• Administrative groups – Exchange Server 2010 uses the Exchange 2007 split permissions model that’s based on universal security groups.
• Intelligent Message Filter – Exchange Server 2010 uses anti-spam agents in the Hub Transport and Edge Transport server roles.
• Link state routing – Exchange Server 2010 uses Active Directory site-based routing.
• Routing objects – If you need this functionality, retain an Exchange 2003 server in your Exchange 2010 organization.
• Network-attached storage – Exchange Server 2010 supports Internet SCSI (iSCSI).
• Exchange Installable File System (ExIFS) – Use Exchange Web Services or MAPI.
• Event service – If you need this functionality, retain an Exchange 2003 server in your Exchange 2010 organization.
• Recovery storage group – Exchange 2010 uses the recovery database.
• User Datagram Protocol (UDP) – Support for User Datagram Protocol (UDP) notifications is removed from Exchange Server 2010. This impacts the user experience when Outlook 2003 clients connect to their mailboxes on Exchange 2010 server. In Outlook 2003, users will experience long send and receive times if they are connected to an Exchange Server 2010 mailbox.

Reasons To Try exchange 2010

When a new version of a software application is released it doesn’t exactly get the same reception as a new release of the iPhone or of an updated sports car. In fact, new applications and software updates are always tested for bugs and potential incompatibilities before going into a production environment.

Luckily, Exchange Server 2010 has been out for some time now and there are many new features of Exchange Server for email administrators to employ to make their jobs easier – features such as email archiving, retention and discovery that all administrators will appreciate. Administrators who must be able to produce archived emails on demand or within specific time constraints will benefit greatly from Exchange Server 2010. Whether the needs are for legal purposes or for other reasons administrators know that being able to produce documents on demand can save their companies, and themselves, valuable time.

Here then are the first four of ten new features and reasons to try Exchange Server 2010.

1. Exchange Server 2010 has a new feature entitled “Personal Archive” that will allow end users to administer their own archived emails, thereby freeing up more time for administers to work on administrative tasks.When users view their primary mailbox folders in Outlook they can also view this special mailbox that contains their archived email. Retention policies can be specified which will allow emails to be automatically retained within the Personal Archive mailbox without requiring further administrative attention. In addition, an import capability also exists which allows the importing of previously stored data from .pst files into Exchange Server. Personal Archives can be used as a secondary storage mailbox for users to store email messages that are of special significance to them. Email messages can be moved or copied between the primary mailbox and their personal archive mailbox. It obviates the need for .pst files which have been known to be accessible to users other than the owners of those files. Thus, Personal Archive mailboxes are another way to help administrators indirectly manage risk in their environment.
2. With the additional retention management policies included with Exchange Server 2010 administrators can now automate the archival and deletion process of their email messages. A Legal Hold feature is also included that can place on hold emails which have been edited or have been entirely deleted. This can help administrators meet the requests of any legal proceedings. In Exchange Server 2010, the Legal Hold can be used to:
   • Give users the ability to place their own legal holds on email.
   • Keep email messages “frozen” and unalterable.
   • Protect mailbox messages from being deleted or edited.
   • Protect mailbox messages against automatic Messaging Records Management (MRM) deletion.
   • Avoid needing to suspend MRM in order to protect email messages.
   • Allow discovery searches of email messages while in “Legal Hold” state.
3. Exchange Server 2010 includes a new e-discovery mechanism which makes it easier for administrators to troubleshoot email messaging issues, comply with auditor requests, and can help administrators address pending legal requests. Various email message types can be specified as targets to be searched for during the e-discovery process. Email searches can be performed on both the user’s primary mailbox and the user’s archived mailbox. In addition, the e-discovery feature can be accessed through a new web-based multi-mailbox search capability. The e-discovery authority can also be delegated to other members of the administrator’s team to help offload the work of the administrator.
4. These days it is taken for granted that most everyone has at least one mobile device with them. I often see people checking their email in places that I never used to see before, such as while walking to catch a train or a bus. With the explosion of mobile devices and with all of our habits in place it is hard not to be reaching for your iPhone or other mobile device to check your email even while on vacation. And for those of us who must get their email but also remain mobile there is an Exchange Server feature for just that situation.The Microsoft Exchange ActiveSync feature and Exchange Server 2010 allow users to work from almost anywhere and still remain productive. Exchange ActiveSync and Microsoft Exchange Server 2010 give users the ability to automatically synchronize their email, contacts, and calendar items with a multitude of mobile devices. And with a universal inbox users can also expect to receive input from their voicemail, RSS subscriptions and instant messaging applications. Access to all your mobile input is free and is already included in your Exchange Server 2010 software.

Microsoft tangles with VMware over Exchange “guidance”

Microsoft and VMware are at odds over some “guidance” the virtualizaton software maker has issued about Exchange and disaster recovery.

At issue is a section in a document published by VMware titled “Microsoft Exchange 2010 on VMware Availability and Recovery Options.” which discusses using Database Availability Groups (DAG) clustering for fast recovery following a disaster.

“Database level high availability can be achieved through the use of database availability groups.,” VMware said.

“In the event of a server host failure, a passive copy of the affected mailbox databases is activated,” it continued. “Client access servers establish MAPI connectivity to the newly active database copy and client connections are reestablished.”

“In the background, VMware HA powers-on the failed virtual machine on another server host, restoring the DAG membership and bringing the newly passive database up to date and ready to take over in case of a failure, or to be manually reactivated as the primary active database,” it said.

“While the use of database availability groups on top of hypervisor based clustering is not a formerly supported configuration, internal VMware tests have shown that the two technologies can co-exist and can be a viable solution to ensure maximum recoverability in the case of a host failure.,” it added.

That advice from VMware was bleakly viewed by Microsoft.

“While Microsoft embraces virtualizing Exchange servers because virtualization gives organizations additional choice and deployment flexibility to meet business requirements and lower IT costs, we’re concerned by deployment guidance that doesn’t accurately follow our Exchange best practices and deployment guidelines,” the company wrote at the Micrsoft Exchange Team blog.

“For example,” it continued, “we feel VMware’s misleading guidance represented in their recent “Exchange 2010 on VMware Availability and Recovery Options” document (and accompanying “Exchange 2010 on VMware Best Practices Guide”) puts Exchange customers at risk, and brushes aside important system requirements and supported configurations.”

“Their guidance could also greatly increase the overall cost of managing your Exchange infrastructure,” it added.

Microsoft went on to argue,

“Because hypervisor HA solutions are not application aware, they cannot adapt to non-hardware failures. Combining these solutions adds complexity and cost, without adding additional high availability.

“On the other hand,” it added, “an Exchange high availability solution does detect both hardware and application failures, and will automatically failover to another member server in the DAG, while reducing complexity.”

Needless to say, VMware didn’t take kindly to Microsoft’s criticism of the virtualization software maker’s advice. Far from reckless, Alex Fontana and Scott Salyer wrote at VMware’s Virtual Reality blog, the advice “can help our customers get greater value out of virtualizing Exchange.”

The VMware solution reduces complexity, they maintain.

“VMware HA is a very simple mechanism that automatically reboots a failed virtual machine on any available host in the vSphere cluster in the case of a host failure,” they explained. “From an application standpoint, the behavior of VMware HA is equivalent to a simple power-on of the machine on which the application is running. It is completely transparent to the OS and the application.”

When a DAG fails in the real world, an administrator will power on that node to restore availability protection. VMware HA does the same thing, only automatically, Fontana and Salyer asserted.

“Seems to us like that’s a pretty reasonable thing to do, and many of our customers agree and are happily using this in production,” the pair wrote.

The approach doesn’t increase the cost of deploying Exchange, the argued, because computing requirements remained unchanged since HA doesn’t rely on failover instances. Neither does it affect overall storage requirements, they contended.

Moreover, what could be simpler for administrators? “When a DAG node fails, you no longer need to manually detect the failure and bring the node back up–VMware HA does that automatically,” they added. “And VMware HA doesn’t require any OS- or app-level configuration changes.”

While VMware makes a strong case for its advice, when the rubber meets the road, that is, when something goes wrong and an administrator needs Microsoft to come to the rescue, the advice could backfire on those who heed it.

As Scott Lowe points out in his blog at VirtualizationAdmin.com:

“VMware is probably in the wrong when it comes to actively recommending to customers what Microsoft considers an unsupported configuration. While the solution is almost 100 percent likely to work from a technical perspective (and, this has been tested), Microsoft is known for their strict support policies when it comes to virtualization and, from the standpoint of ability to get support when necessary, this unsupported configuration could leave customers at risk for not getting support.”

Nevertheless, Lowe called Microsoft on the carpet for its position on the VMware solution.

“Microsoft: If you have solid technical reasons for not supporting HA (not DRS) for DAG members complete with the test results and numbers to back up the ‘cost and complexity’ claim, we want to hear it!” he wrote. “If there is something to the claim, additional information will help customers make much better decisions regarding availability and will go a long way toward helping us understand this stance.”

6 options for connecting Exchange to the Internet

When it comes to designing an Exchange 2010 infrastructure, one of the key design decisions you have to make is “how will the system connect to the Internet?” Microsoft has separated out the Internet connected parts of Exchange into what it calls the Edge Transport role, but you do have other options.

This post will discuss six options for deploying your edge connectivity and integrating it into your Exchange 2010 infrastructure, and include some pros and cons for each. Knowing what your options are will help you to determine what the best solution is for your system.

1. Deploy the edge transport role in the DMZ

If you follow Microsoft’s own recommendations for deploying Exchange 2010, you will build a DMZ server that does not belong to your domain, deploy it into a screened subnet/DMZ, and install the Edge Transport role. You can still manage this server’s Exchange components by subscribing it to your Exchange organization using the Edge Subscription service, but otherwise it runs as a bastion host in your DMZ.

Pros:

• This is Microsoft’s recommended solution.
• You can still manage the server as part of your Exchange organization.

Cons:

• This requires an additional server license as well as an Exchange license.
• If you deploy this the Microsoft way, as a DMZ server in workgroup mode, you must maintain the operating system separate from your domain.

2. Deploy the edge transport role on a TMG server

If you already have Microsoft Forefront Threat Management Gateway deployed, you can install the Edge Transport role onto your TMG server(s.) This option lets you leverage your existing TMG server(s) and also strengthens Exchange’s own defenses with Forefront TMG’s.

Pros:

• By leveraging your existing TMG server(s,) you have less operating system licenses to purchase.
• You can still manage Exchange using the Edge Subscription.

Cons:

• If your TMG admins are not also the Exchange admins, they may not wish to do this, and it will add complexity to managing the TMG servers.
• If you have deployed your TMG servers in a cluster, you should install Exchange Edge Transport role on both, which will require two licenses. Of course, you probably want fault tolerance with this anyway, so this may not be a big an issue.
• Your TMG servers will require more RAM and consume more CPU resources than without Exchange.

3. Publish the edge transport role using TMG

In an ideal world without hardware or budget constraints, I would lean towards this design. You will still deploy the Edge Transport Role, but you will publish the mail protocols through your TMG infrastructure.

Pros:

• This follows Microsoft’s recommendations for dedicated Edge servers, and adds additional security by publishing them through the TMG.
• Separates the management of TMG from Exchange, while still leveraging both.

Cons:

• This does require more hardware, and more operating system licenses than any other option.
• When troubleshooting mail flow, there is an additional step all mail must take.

4. Deploy an mail screening appliance in the DMZ

There are lots of mail appliances on the market today, offering anti-spam, anti-malware, content inspection, logging, archiving, and more. Appliances are typically hardened, purpose-built solutions, that do what they are built to do very well.

Pros:

• You can get the best ‘bang for the buck’ from these solutions, as they are built specifically to do mail screening.
• Appliances typically require less maintenance and administration than server based solutions.

Cons:

• These can be expensive, both to acquire and for the annual subscriptions that most require.
• They can also require some expertise to deploy, though most vendors are happy to sell you professional services to get up and running.
• When troubleshooting, these can be a ‘black-box.’ Make sure you look at their logging and reporting capabilities and are comfortable with that.

5. Deploy a mail screening server in the DMZ

Like an appliance, this option uses an application installed on top of a server to perform anti-spam, anti-malware, content inspection, logging, archiving and more.

Pros:

• While the cost of the server and operating system may equal or exceed appliances, the servers will generally be easier to deal with for your administrators, and could be leveraged for other services if they have capacity.
• Windows-based applications are often more transparent, and easier to troubleshoot.

Cons:

• As a server, it needs as much maintenance as any other.
• They also require annual subscriptions that can be costly to maintain.

6. Deploy a cloud based solution

Whether you call it Software as a Service, an outsourced solution, or a cloud based service, you are moving your mail screening offsite; having mail flow through a service provider for anti-spam, anti-malware, content inspection, logging, archiving, and more, and then delivering only clean mail to your Exchange infrastructure. This is how I do things now, augmenting my TMG services with GFI’s Max MailEdge.

Pros:

• By filtering mail before it hits your pipe, you are not worried about spam consuming bandwidth, CPU, or disk on your system.
• These cloud providers are generally better able to screen mail at scale, making them a very cost effective solution.

Cons:

• Because content is being screened (and potentially blocked) off site, your ability to immediately check to see if an important mail has been blocked, and to release it, may be limited. While most of these service providers have options for reporting and releasing email, they are an external service. You cannot just log onto the server and check the queue.
• Not all services offer the same degree of flexibility and customization as an in-house solution.

When it comes to your edge services for Exchange, it’s good to know that you have options. Go through an exercise to define what your minimum requirements are for your content screening solution, and then investigate each of the possibilities based on budget, flexibility, and administrative overhead, to find the one that fits for you.

4 Ways to Supercharge your Exchange Server using the MX record

The Mail Exchanger (MX) record is part of the Domain Name Server (DNS) system designed to translate human readable domain names into IP addresses.  Much like how Web browsers determine the IP address of web servers via DNS, the MX entry directs incoming mails towards the email server for the associated domain.  On this front, administrators with a more technical interest will want to check out the exhaustive details of the MX record is defined under RFC 1035.

So how does the MX record concern the mail administrator?  Similar to how DNS can be used to implement advanced solutions such as load-balancing or failover hardware, the MX record can also be used to bolster the capability and robustness of your email server.  Obviously, deployment scenarios vary greatly depending on actual requirements and needs; I’ve briefly summarized a list of possible ways that tweaking the inbound MX record can help you better manage your Exchange Server deployment.

1. Third party anti-malware or anti-spam filtering
   This is probably the most common reason of modifying a domain’s MX record these days.  Businesses can quickly and easily offload the hassle (and computational resources required) of filtering spam and other malware by redirecting incoming emails to the service provider of their choice.  This vendor will then perform the necessary filtering before forwarding the “cleaned” e-mails back to the correct email server – sparing businesses the need for new hardware purchases or software licensing.Indeed, by specializing in malware or spam detection and with the ability to refine their techniques across all its customers, these cloud-based providers typically achieve much better detection rates versus stand-alone appliances.  And yes, you can easily switch to another provider by simply “throwing the switch” and modifying the MX record accordingly.
2. Transition to new servers
   While upgrading a new mail server is not a situation frequently encountered by administrators, the occasion does arise at times where it simply cannot be avoided.  An example that came to mind would be when Microsoft made the decision to release Exchange 2007 – and Exchange 2010 subsequently – only in 64-bit editions. Organisations with incompatible hardware had no choice but to acquire new hardware in order to use Exchange Server 2007 or Exchange Server 2010.The option for transitioning between two versions of Exchange is clearly no longer an option, leaving a time-consuming migration as the only way to move the old data over to the newer machine.  You can read all about the related intricate here.  The key point here though, is that companies can ensure that no emails are lost (or bounce) in the interim by tweaking their MX records to point to the new server before taking the old Exchange Server offline.
3. Load Balancing
   Larger organizations who are concerned about their Exchange infrastructure being overwhelmed by a deluge of emails can also use their MX record to load balance between multiple Exchange Servers deployed Edge Transport Server role.  In fact, this is the recommended way of doing it, as noted by Microsoft TechNet here: “You can load-balance SMTP traffic to your organization between Edge Transport servers by defining more than one mail exchange (MX) resource record with the same priority in the Domain Name System (DNS) database for your mail domain.”Note that configuring the same priority for both servers is critical for any form of load balancing to take place.  Moving ahead, consistency between multiple Edge Transport servers can be achieved via the use of cloned configuration scripts.
4. Business Continuity
   The idea behind a secondary MX record is simple; the secondary server is contacted to receive incoming emails should the primary server be too busy.  For businesses with only one Exchange server, the secondary MX entry can be set up as a relay server to store new emails in the event of an outage with the former. Once the email server has been restored, new emails cached by the relay server are forwarded.The advantages are simple; no nasty error messages are generated should your Exchange Server go down (or while it is rebooting after installing a patch), and incoming messages are not unnecessarily delayed courtesy of the increasing wait times between each mail delivery attempt.  As you can see, businesses can make use of this method to increase their Exchange Server uptime at minimum cost to themselves.

I’ve merely gone through some of the more common and more useful methods of modifying the MX record today.  As you can imagine, the above techniques work not only for Microsoft Exchange, but can also be useful for other email servers.  One thing for sure, the MX record is an extremely powerful way to manage the “flow” of incoming emails.

Back up Microsoft Exchange 2010 using Windows Server Backup(step by step guide)

Exchange Management Console view of this database

No matter how small the Exchange implementation, the data needs to be backed up. Many Exchange shops (particularly smaller ones) have relied on the ubiquitous Windows Server Backup utility to protect their Exchange environments against disaster. Although there was a period of time when Exchange and Windows Server Backup didn’t work together, with Windows Server 2008 R2 and Exchange 2010, this is not the case, and the backup and recovery of Exchange using this tool is a relatively simple process.

For the demonstration in this tutorial, I’ll back up a single Exchange 2010 mailbox database that exists on a server named MAIL3. At Westminster College, we’re currently in a pilot phase for an Exchange 2010 rollout, and we’re using Windows Server Backup during this phase. Once we’re in full production, we’ll move to our normal enterprise backup application.

How to use Windows Server Backup with Exchange 2010
This screen gives you a look at the Exchange Management Console view of this database. The other two databases you see reside on a different Exchange server.

Windows Server Backup is not yet installed.

Start the Windows Server Backup tool by going to Start | All Programs | Accessories | System Tools | Windows Server Backup. More than likely, you’ll end up with a screen like this one that tells you the backup tool is not yet installed on your server.

Click Add Features to add a new server feature

To add the Windows Server Backup bits to your Windows Server 2008 R2 server, open Server Manager, navigate to the Features item, and click the Add Features link.

Add the backup tool

On the Select Features page, locate the Windows Server Backup Features option and select it. Although it’s not required, it’s also recommended that you install the Command-Line Tools so that you can script backup jobs if you like.

Review your selections and click Install

When you get to the Confirm Installation Selections page, look over your selections and click the Install button to add the features.

The backup tool has been installed.

At the end of the process, you will receive the results screen shown here.

The Windows Server Backup window is mostly blank to start.

Now that Windows Server Backup is installed, when you restart the utility, you’ll be greeted with a screen like this one. At the top of the window, Windows Server Backup will tell you that there are no current backups configured, and all of the informational areas of the window will be blank since there is no detail to share until after an initial backup is run.

Schedule a server backup

I’ll jump right into creating a backup schedule in order to schedule a regular backup of this Exchange Server database. To start the process, go to the Action menu and choose Backup Schedule.

Backup Schedule Wizard Getting Started page

Starting the backup schedule kicks off a wizard that begins with a welcome screen that outlines what decisions you need to make. For the purposes of this tutorial, I’ll stick mostly with defaults.

Choose what to back up

On the next page of the wizard, you’re asked to decide what you’d like to back up. You can choose to back up the entire server (this includes all data, applications, and system state), or you can choose to perform a custom backup, which allows you to make granular options about what to back up. You see in this figure that I’m performing a full server backup that will use 17.52 GB of space.

Decide at what time(s) each day you’d like to run backups

Although the backup default is to run every day at 9:00 P.M., you can choose to run the backup at a different time or, if you need a shorter recovery period, can choose to run multiple backups each day. To add additional daily backups, select the button next to More Than Once A Day, specify the times you’d like, and click the Add button. After you make your choices, click the Next button.

Where do you want to save backups?

With the “what” and the “when” out of the way, it’s time to consider the “where”; specifically, you need to make sure to back up your information to a location that can survive a server failure.

You can choose to back data up to a hard drive that you’ve dedicated to this purpose. Ideally, this would be a removable drive of some kind that you can store away from the server. If you can’t do this, you can back data up to an existing server volume, although you may take a performance hit and, if the server is lost in a disaster, recovery won’t be possible. The option that I prefer is to back data up to a volume on a separate server. In my case, this second server resides in a different building.

Heed the warning

When you choose the remote location option, you’re told that each backup will overwrite previous backups and only the latest backup will be available. If you need multiple backups to be available, consider other backup options.

Specify where the backup should be saved

When you choose the remote backup option, you need to specify where the backup should be saved. On this screen, you’ll note that backups are being written to a server named Backup and to a folder named MAIL3 on a share named Exchange10. In the Access Control section of the window, the Inherit option is selected, indicating that anyone who has access to the shared folder also has access to the backup file. As such, set carefully controlled share and NTFS permissions on the resource.

Provide credentials for the remote backup location

For a remote share, you need to provide a user name and a password that has access to the backup destination.

Review your backup selections

Finally, the confirmation page appears, providing you with an opportunity to review your backup selections. When you’re done, click the Finish button.

Details about the next scheduled backup

When you get back to the backup console, you can click the View Details link under Next Backup to see details about your pending backup. This screen shows this detail window for the backup we just created.

Backup Once options

If you’d like to kick off a manual backup before the next scheduled backup, go to Action | Backup Once. On the first page of the Backup Once Wizard, you’re asked how you want to run the backup. Do you want to use the same options you used for your scheduled backup, or do you want to choose different backup options?

Backup summary page

The Backup Once Wizard provides you with a summary page. Click the Backup button to begin the backup process.

Backup status page

During the backup process, this window will display on the screen so that you can watch backup progress.

The backup is complete.

At the end of the process, you’ll see a final completion page.

Restore process

Proof
How do you actually know that Exchange was appropriately backed up? That’s revealed during the restore process. Although I’m not covering restores here, I will share this screen; it shows that the Exchange application was backed up and that, specifically, the database on the server named MAIL3 was the one that was saved.

Summary
While suitable mostly for small organizations and those running pilots, the Windows Server Backup utility can be a great way to back up your Exchange 2010 server without having to invest more dollars in software.

Exchange 2010 Database Availability Group

Database Availability Group (DAG) is the new Exchange 2010 high availability feature. This feature provides data availability together with service availability. DAG now is the only built-in way to protect data in Exchange 2010.

This article is composed of an introductory section where we look at the key facts of Database Availability Groups and a walk through the implementation of DAG. The introductory sections where authored after researching various TechNet articles and here I am reproducing salient information taken from TechNet. This information was restructured for Administrators to have a central reference point rather than having to go through many TechNet articles. So credits for the article introduction go to TechNet.

In Exchange 2007, we have Local Continuous Replication (LCR), Cluster Continuous Replication (CCR), Single Copy Clusters (SCC) and Standby Continuous Replication (SCR). Exchange 2010 combined on-site data replication (CCR) and off-site data replication (SCR) to produce one method to protect mailbox databases.

DAG is a group of up to 16 mailbox servers that host a set of databases and provide automatic database-level recovery from failures that affect individual servers or databases. Those mailbox servers can be geographically dispersed to replicate mailbox databases across sites. Any server in a DAG can host a copy of a mailbox database from any other server in the DAG.

Storage groups no longer exist in Exchange 2010. The mailbox database name is unique within an Exchange 2010 organization, they are now global objects and, as a result, the primary management interfaces for Exchange databases has moved within the Exchange Management Console from the Mailbox node under Server Configuration to the Mailbox node under Organization Configuration. Also continuous replication now operates at the database level because of Storage Group removal from Exchange 2010.

In Exchange 2007 the Microsoft Exchange Replication service on the passive node connects to the share on the active node and copies, or pulls, the log files using the Server Message Block (SMB) protocol. In Exchange 2010 SMB is no longer used for Log shipping and seeding. Instead, Exchange 2010 continuous replication uses a single administrator-defined TCP port, by default DAG uses port 64327. Also, Log shipping no longer uses a pull model where the passive copy pulls the closed log files from the active copy; now the active copy pushes the log files to each configured passive copy.

Another good enhancement is that seeding is no longer restricted to using only the active copy of the database. Passive copies of mailbox databases can now be specified as sources for database copy seeding and reseeding. In addition, Exchange 2010 includes built-in options for network encryption and compression for the data stream.

There are two editions of Exchange 2010, standard and enterprise editions. Both editions include DAGs, but standard edition is limited to 5 databases per server while the enterprise edition can host up to 100 databases per server. Note that if you want to use DAG with failover clustering, you have to install Exchange 2010 on the enterprise editions of Windows Server 2008. And all DAG members should run the same operating system, either Windows Server 2008 on all members or Windows Server 2008 R2 on all members.

Creating and Configuring DAG

There are specific networking requirements that must be met for each DAG and for each DAG member. Each DAG has a single MAPI network, which is used by other servers (e.g., other Exchange 2010 servers, directory servers, witness servers, etc.) to communicate with the DAG member, and zero or more Replication networks, which are networks that are dedicated to log shipping and seeding. However, unlike previous Exchange versions, database availability group configuration is supported using single network.

An IP address (either IPv4 or both IPv4 and IPv6) must be assigned to the DAG. This IP address must be on the subnet intended for the MAPI network.

You can assign static IP addresses to the DAG by using the DatabaseAvailabilityGroupIpAddresses parameter. If you use the Exchange Management Console (EMC) to create the DAG, or if you use the New-DatabaseAvailabilityGroup cmdlet without the DatabaseAvailabilityGroupIpAddresses parameter, the task will configure the DAG to use Dynamic Host Configuration Protocol (DHCP) to obtain the necessary IP addresses. If you don’t want the DAG to use DHCP, you can use the Set-DatabaseAvailabilityGroup cmdlet to configure one or more IP addresses for the DAG after it has been created.

Now we will create the DAG. In EMC | Organization Configuration | Mailbox. Click the Database Availability Groups tab, right-click and select New Database Availability Group:

Type a name for the DAG. Remember that the DAG must have a unique name inside the Exchange organization and it can consist of up to 15 characters. I will select the server that hosts the Hub Transport and Client Access server roles as a witness server, and define C:DAG1-WS as the witness directory

Click Next to start creating the DAG:

After DAG has been created, we can run the command “Get-DatabaseAvailabilityGroup DAG1 | fl” to see the default properties of the DAG:

Note that the DAG has no IP addresses configured. I don’t have DHCP in my test environment, so we have to configure an IP address for the DAG. To do so, we will use the command:
Set-DatabaseAvailabilityGroup DAG1 -DatabaseAvailabilityGroupIpAddresses 20.20.0.6

Now you can add servers to the DAG. In EMC | Organization Configuration | Mailbox, click the Database Availability Groups tab, right-click the DAG you want to manage, and then click Manage Database Availability Group Membership:

Click Add then select the servers you want to add. I will chose one server then add the second server using Exchange Management Shell.

Click Manage to add the server as a member to the DAG

Now we will configure the DAG networks to allow the replication on one subnet other than the MAPI network subnet. From the Database Availability Groups tab, select the DAG. At the bottom pane we can then configure the network properties for the selected DAG.

I will add an IPv4 subnet and remove the IPv6 subnet. Also make sure that the Enable replication check box is selected to allow the replication to happen over this network

Next we will disable the replication on the MAPI network. Open the properties of the second network which is configured with the IP of your internal network, uncheck Enable replication check box

Now we will add the second server using the command:
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer Ex14Mbx2 -Verbose

The -Verbose parameter instructs the command to provide detailed information about the operation.

To check the memebers after we have two members in the DAG, we can use the command:
Get-DatabaseAvailabilityGroup

Adding Mailbox Database Copies

Now that we have configured the DAG, we will continue by adding mailbox database copies to start protecting our databases.

We will configure the following scenario:
In all we have two mailbox servers, Ex14Mbx1 and Ex14Mbx2, with two mailbox databases, Main-DB01 and Main-DB02. Ex14Mbx1 holds the active Main-DB01 database copy and a passive copy of Main-DB02, the same applies for Ex14Mbx2; it holds the active Main-DB02 database copy and a passive copy of Main-DB01.

From EMC | Organization Configuration | Mailbox, click the Database Management tab, and right-click the database for which we want to add a copy

In the Add Mailbox Database Copy window click browse and select the DAG member that you will configure to host the database copy

In the Add Mailbox Database Copy window, there is an Activation preference number. This value is used when multiple database copies are added for one database and all the copies meet the same criteria for activation. In this case the copy assigned the lowest activation preference number will be activated.

Click add and wait for the command to complete successfully

After the copy has been created, we can check the health of the database copy using Exchange Management Console. In Exchange 2007 we had to use the Exchange Management Shell to check for mailbox databases and replication health. Now we can use the Database Management tab and look at the Copy Status colomn

Mailbox Database Switchover

The Mailbox server that hosts the active copy of a database is called the mailbox database master. Sometimes you may need to take the mailbox database master down for maintenance. In this case we need to move the active mailbox database to another mailbox server. This process is called a database switchover. In a database switchover, the active copy of a database is dismounted on the master and a passive copy of that database is mounted. The active mailbox database is mounted on another mailbox server which in its turn becomes the master.

To activate the mailbox database on another server, in EMC | Organization Configuration | Mailbox, click the Database Management tab, at the bottom pane right-click the copy that is hosted on the server on which you want to activate the copy

The following drop down list will appear to select from:

The options in the list are:

• Lossless If you specify this value, the database doesn’t automatically mount until all logs that were generated on the active copy have been copied to the passive copy.
• Good Availability If you specify this value, the database automatically mounts immediately after a failover if the copy queue length is less than or equal to 6. Exchange will attempt to replicate the remaining logs to the passive copy and then mounts the database. If the copy queue length is greater than 6, the database doesn’t mount.
• Best Effort If you specify this value, the database automatically mounts regardless of the size of the copy queue length. Because the database will mount with any amount of log loss, using this value could result in a large amount of data loss.
• Best Availability If you specify this value, the database automatically mounts immediately after a failover if the copy queue length is less than or equal to 12. The copy queue length is the number of logs recognized by the passive copy that needs to be replicated. If the copy queue length is more than 12, the database doesn’t automatically mount. When the copy queue length is less than or equal to 12, Exchange attempts to replicate the remaining logs to the passive copy and then mounts the database.

Click ok to start activating the copy on the second server. When the process finishes we can see the results in the console:

We can also activate the mailbox database copy on another server through Exchange Management Shell using the command:
Move-ActiveMailboxDatabase -Identity Main-DB02 -ActivateOnServer Ex14Mbx1

Conclusion

In this article we went through a brief overview of database availability groups. We introduced DAG, created and configured DAG to include two member servers. We created mailbox database copies within the DAG and tested moving the database copies between member servers.

Another vulnerability in OWA

Microsoft has finally patched a vulnerability in its Outlook Web Access application that has been known to the public since early summer. If successfully exploited by a hacker, the vulnerability could have been used to use the identity of an authenticated user to perform actions with that user’s computer without the user’s knowledge.

Although the vulnerability does not affect Microsoft Exchange Server 2007 Service Pack 3 and Microsoft Exchange Server 2010, it does affect earlier versions of Exchange 2007, as well as Exchange 2003 and Exchange 2000.

Microsoft’s solution to the problem may not please some system in administrators. It recommends that customers running versions of the program affected by the vulnerability upgrade those programs to versions unaffected by the flaw.

“Of course system administrators have nothing better to do than upgrade the version of Exchange on all of their mail servers and shift thousands of mailboxes to a new version of Exchange,” Lawrence Latif observed snidely in the Inquirer.

Potential damage from the vulnerability can be minimized by segmenting user rights in OWA. Segmentation lets an administrator control many of the features in the web application. Segmentation can be managed using the Exchange Management Console (EMC) or the Exchange Management Shell. With segmentation administrators can control:

• Address Lists. With Address Lists enabled, users can see all address lists in the Exchange organization. With it disabled, users can only see the default global address list.
• Calendar. Enabled, OWA users can see calendar folders. Disabled, they can’t see them.
• Change Password. Enabled, OWA users can change their Active Directory account password.
• Contacts. Enabled, OWA users can see contact folders. Disabled, they can’t.
• Email Signature. Enabled, OWA users can use their options to manage signatures on outgoing email messages.
• Exchange ActiveSync Integration. Enabled, users can manage mobile phones using OWA options.
• Instant Messaging. Enabled, instant messaging is available to OWA users.
• Journal. Enabled, OWA users can see the journal folder. Disabled, they can’t see it.
• Junk Email Filtering. Enabled, OWA users can control their junk mail settings. Disabled, they can’t control the settings, but system settings or settings created by the administrator will still apply to the mailbox.
• Notes. Enabled, OWA users have full access to the notes folder. Disabled, they can only view notes in the folder.
• Premium Client. Enabled, users can access the full version of OWA. Disabled, they can only access the light version.
• Public Folders. Enabled, OWA users can browse or read items in public folders.
• Recover Deleted Items. Enabled, OWA users can view recover or permanently delete items that were deleted from the Deleted Items folder.
• Reminders and Notifications. Enabled, OWA users can receive reminders for calendar items and tasks and notifications for new messages. Disabled, they will not receive reminders and notifications.
• Rules. Enabled, OWA users can view, create or modify server-side rules.
• S/MIME. Enabled, users can download S/MIME control for OWA and use it to read and compose signed and encrypted messages.
• Search Folders. Enabled, users can see the Search Folders icon in the OWA navigation pane and can access any search folders that exist on the server.
• Spelling Checker. Enabled, users can access spell checking in OWA.
• Tasks. Enabled, users have access to the Tasks features in OWA.
• Text Messaging. Enabled, users can send and receive text messages in OWA.
• Unified Messaging Integration. Enabled, users can manage Unified Messaging through OWA.

A particularly useless defense tactic recommended by Microsoft to address exposures created by the vulnerability is to hide the display of the OWA options panel, according to the Inquirer. That “should flummox only the most novice of script kiddies,” it declared.

A proof of concept of the vulnerability was released on July 8. It was described at that time by security experts as “a cross-site request forgery vulnerability… present in some versions of Microsoft Exchange (Outlook Web Access). A cross-site request forgery (CSRF) vulnerability in Microsoft Outlook Web Access… allows remote attackers to hijack the authentication of email users for requests that perform Outlook requests, as demonstrated by setting the auto-forward rule.”

In August, the Exploit Database tested the reported vulnerability and described it as a “straight forward” exploit.

“As soon as the target user visits the proper webpage,” it explained “the hidden form executes and a forwarding rule is created without drawing too much attention. The attacker could certainly try to hide any visible elements on the page and invoke the submission of a hidden form data to a simple javascript without any user involvement.”

Force Exchange 2007 To Send As Plain Text Format On A Per E-Mail And Domain Basis

Force Exchange 2007 To Send As Plain Text Format On A Per E-Mail And Domain Basis

Microsoft Exchange by default uses Rich Text Format to send all outbound mail. In some cases you may be forced to use plain text to send mail to some recipients which have trouble reading the rich text format. A common problem an administrator may experience is that some mail recipients receive the dredded winmail.dat attachment from users within their Exchange organisation.

This article will advise step by step instructions to force an Exchange 2007 server to send outbound mail on a per recipient and per E-Mail domain basis.

 

Forcing Exchange 2007 to send plain text on a domain level basis

 

This method requires you to create a new remote domain entry and use shell commands to configure the format Exchange will use when sending outbound mail to this domain only.

Create the Remote Domain:

1. Open the Exchange Management Console. Under “Organisation Configuration” container click “Hub Transport”.
2. Select the “Remote Domains” Tab and on th right under the actions pane click the “New remote domain” link.
3. Give the connector a name and enter the domain name you would like to send plan text to. e.g. domain.com. Click new then click finish.
4. Open the properties of the remove domain you just created and click the “format of original message sent as attachment to journal report” tab.
5. Under “Exchange rich-text format” select the “Never use” bullet point.

 

At this point you would assume that all outbound mail to this remote domain will be forced to be sent in plain text format but we need to perform some shell commands to the remote domain object before this can happen.

 

Apply the shell commands to the remote domain:

1. Open the shell and type “Get-RemoteDomain –Identity:domain.com | fl” where domain.com is the name of the remote domain object (not the actual remote domain name).
Here you will notice under “Content Type” the format is set to “MimeHTMLText”. To force plain text we want to set this as MimeText so HTML is not used.

2. In the shell prompt type “Set-RemoteDomain –Identity:domain.com -ContentType:MimeText” again where doman.com is the name of the remote domain. Typing the Get-RemoteDomain command will verify that the changes have been made and set the “Content Type” to MimeText.

Once these changes have been successfully completed the Exchange server will force the format as plain text regardless what is set on the end users outlook clien to any recipient in the “domain.com” E-Mail domain set in the “remote domain” object.

 

Forcing Exchange 2007 to send plain text on a recipient level basis

 

There may be a case where you need to have mail to 1 recipient in an E-Mail domain only sent as plain text. To do this you must create a contact item for this user and apply some shell commands to it.

1. Open the “Exchange Management Console”, select “Recipient Configuration” container then select the “Mail Contact” container.
2. Create a new contact for the remote recipient you was Exchange to for plain text format to.
3. Open the properties of the newly created contact. On the General tab under “Use MAPI rich text format” select “Never”.

We now need to apply the following shell commands to the newly created contact object to force plain text format.

1. In the shell prompt type “Get-MailContact -Identity “contact name” |fl”  where “contact name” is the display name of the newly created contact object. You will see that “Message Format” is Mime and “Message Body” Format is TextAndHtml. We need to change both of these to Text to force the use of plain text format.

2. To change these we need to type the following 3 shell commands after the other:

Set-MailContact -Identity “contact name” -MessageBodyFormat:Text
Set-MailContact -Identity “contact name” -MessageFormat:Text
Set-MailContact -Identity “contact name” -UsePreferMessageFormat:$true

Once this is done you will see that by typing the Get-MailContactl show both “Message For” and “Message Body” will be set to text.

 

Now all mail sent through your Exchange server to the recipient contact you created will be set as plain text and will not affect any other recipient in the same domain.

Michael Collins has over 10 years experience in computing and is a senior IT Consultant at Sphere IT Consulting.