The Administrative Audit Logging feature is one of the great additions to Exchange 2010. A short time ago, I wrote about eDiscovery which utilizes litigation hold. Administrative auditing is in that similar vein of thinking but, in my opinion, is geared more towards a change control mentality. This feature can be equally useful for small, single administrator environments as well as larger environments where several admins have their hands in the cookie jar.

Administrative Audit Logging takes advantage of the fact that all Exchange Management Console (EMC) activities are actually running Exchange Management Shell (EMS) cmdlets in the background for you. Admin audit logging simply keeps a log of any change you perform that creates, modifies, or removes anything in Exchange. Any cmdlet beginning with Get- or Search- is notlogged by default.

How to enable Administrative Audit Logging

By default, the administrator audit agent is already running. However; to begin logging that activity, administrator audit logging needs to be enabled. This is done using the Set-AdminAuditLogConfig cmdlet. In SP1 and later, this will begin logging administrator actions to the arbitration mailbox which uses a disabled account. For those running RTM, you’ll also need to run the cmdlet with the -AdminAuditLogMailbox parameter. SP1 and later

Set-AdminAuditLogConfig -AdminAuditLogEnabled $true

RTM add

Set-AdminAuditLogConfig -AdminAuditLogMailbox ‘AuditLog@YourDomain.com’

Enable Exchange 2010 Administrative Audit Logging

Search log

Viewing contents of the audit log in EMS is done using the Search-AdminAuditLog cmdlet.

To fine tune the search, add the -Cmdlets parameter with interesting commands listed. RTM users should use the -AdminAuditLogCmdlets parameter with the list of cmdlets surrounded by single quotes.

For example, if I simply want to search for the user account and date/time that somebody ran the Mount-Database or Dismount-Database cmdlets, I would run the following.

Search-AdminAuditLog -Cmdlets Mount-Database,Dismount-Database | Format-Table ObjectModified,Caller,Succeeded,Rundate

Search Exchange 2010 audit log

Let’s say you wanted to search within a given time frame for the use of the New-Mailbox, Set-Mailbox, and Delete-Mailbox cmdlets. Also, we’ll pipe the output to Format-Table to format command output. For the time constraints, we’ll add the -StartDate and -EndDate parameter.

Search-AdminAuditLog -StartDate ‘12/01/2011’ -EndDate ‘02/02/2012’ -Cmdlets New-Mailbox,Set-Mailbox,Delete-Mailbox | Format-Table RunDate,CmdletName

Write to audit log

It is also possible to write custom entries to the audit log. This is done using the Write-AdminAuditLog cmdlet. Use this cmdlet with the -Comment parameter and your comment surround by single quotes. Viewing those comments can be a little tricky as an array has to be created to read the contents of the comment.

Write-AdminAuditLog -Comment ‘Hello World.’

Search-AdminAuditLog -Cmdlets Write-AdminAuditLog | Select Rundate, @{n=”Comment”;e={$_.CmdletParameters[0].value}}

Write to the Exchange 2010 audit log

Email search results

Results of the search can also be emailed by using the New-AdminAuditLogSearch cmdet. The cmdlet generates an XML file and is delivered to the email that you specify. For example, if you wanted to have a report for a specific time span sent to auditor@YourDomain.com, you would use the following EMS cmdlet and parameters.

New-AdminAuditLogSearch -StartDate ‘01/01/2012’ -EndDate ‘02/01/2012’ -StatusEmailRecipients ‘Auditor@YourDomain.com’

Exchange Control Panel reports

In addition to generating a report using EMS, you can also use ECP to generate reports of the logged activity. Logon to ECP and Manage Your Organization and then click Rules & Auditing. From there, click Export the administrator audit log. This will email the results as an XML file. OutlookWebAccesspolicy may need to be modified to view in OWA.

Export the Administrator Audit Log

• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)
• eDiscovery in Exchange – Part 5: Export and search (0)

In my experience, gathering eDiscovery is not something I do every day. I’m guessing that for most of you, this is also true. The first time I had to do this I was still trying to figure out the correct syntax on the Get-Mailbox, Restore-Mailbox, and Export-Mailbox cmdlets to yield the results that I wanted. That process was quickly hamstrung when I had to troubleshoot confusing error messages regarding the target folder. So what I’ve hoped to do with the eDiscovery series, as well as these troubleshooting articles, is remove some of the frustration by sharing what I’ve learned.

Exchange 2010

Before moving on, in Part 5 of the eDiscovery in Exchange series, I briefly discussed the new search features in Exchange 2010. It’s unlikely you will have a problem with the Full Access permission because the new search feature and pre-defined roles take care of permissions issues. Simply delegating the Discovery Management administrator role to a user gives them the access they need to perform the search. That is done using the Role Based Access Control (RBAC) tool in EMC.

Exchange 2007

One scenario I ran into when attempting to perform eDiscovery was what seemed like an error telling me there was a problem with the target mailboxes. What I eventually discovered was that, even though the message may say the words “target mailbox” or “target destination”, the problem results because of permissions problems on the source mailboxes.

When attempting to run the Export-Mailbox and do not have Full Access permission, you will see the following errors repeated for each mailbox:

Error at top of results list for Export-Mailbox

Error at end of results list for Export-Mailbox

This error indicates a problem with the source mailbox.

“Error occurred in the step: Moving messages. Failed to copy messages to the destination mailbox store with error:

MAPI or an unspecified service provider.

ID no: 00000000-0000-00000000, error code: -1056749164″

If you are using the Get-Mailbox cmdlet to get a group of mailboxes, you will see these errors once for every source mailbox for which the user account does not have proper access.

The solution for this is to simply give the account you’re using the Full Access permission to the mailboxes that you’ll be searching. This can be done per mailbox, organization unit, database, or any other group you get using EMS.

Let’s say you needed to add the Full Access permission to all the mailboxes in a single database. You would use the Get-Mailbox cmdlet piped to the Add-ADPermission cmdlet similar to the example below.

Get-Mailbox -Database “Ex2007MB\First Storage Group\Mailbox Database” | Add-AdPermission -User “YOURDOMAIN\Administrator” -AccessRights GenericAll

The Add-MailboxPermission cmdlet can also be used.

Get-Mailbox -Database “Ex2007MB\First Storage Group\Mailbox Database” | Add-MailboxPermission -User “YOURDOMAIN\Administrator” -AccessRights fullaccess

If you have a small number of mailboxes to manage, Exchange Management Console can also be used by right-clicking a mailbox and selecting Manage Full Access Permission.

Full Access Permission

Once you have successfully added the Full Access permission, the Export-Mailbox cmdlet will display a status message indicating the mailbox has been exported.

Successful Export

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)
• eDiscovery in Exchange – Part 5: Export and search (0)

As a follow up to the five part eDiscoveryinExchange series, I thought it might be helpful to provide some information for a couple of troubleshooting tips that may come in handy while working through the eDiscovery process. An issue you may run into could be due to corrupted items in your Exchange database. The corresponding error message is “This mailbox exceeded the maximum number of corrupted items.” For legal inquiry, you’ll want to do what you can to ensure all possible results are included.

As before I’ll address the Exchange 2007 method of fixing as well as the improved methods in Exchange 2010.

Exchange 2007

In Exchange 2007, the Export-Mailbox cmdlet will fail to execute due to bad items in the mailbox. Isinteg, can help with corrupted Exchange items by logically repairing the database.

isinteg

Isinteg is used to logically repair a database. This is most likely the cause of the corrupted items. Run isinteg -s ServerName -fix -test alltests multiple times until all bad items are repaired. The utility needs to run multiple times to take care of all items.

ServerName should be the name of your mailbox server. If you are in a CCR environment, the cluster name should be used. A list of databases on the server will be displayed, type in the number of the corresponding database you need to check and press Enter. When isinteg is finished, look for rows where the number of fixes is greater than zero. If any are not zero, run isinteg again until it does not result in any more fixes.

isinteg

-BadItemLimit

Even after all that, you may still be getting an error about bad items when attempting to run the Export-Mailbox cmdlet. In this case, it may be necessary to include the -BadItemLimit parameter. For example, adding -BadItemLimit 10 to the end of the Export-Mailbox cmdlet would allow up to 10 bad items and still export all other items.

Get-Mailbox -Database “Ex2007MB\First Storage Group\Mailbox Database” | Export-Mailbox -PSTFolderPath C:\Temp\export.pst -TargetFolder Results -AllContentKeywords “keyword” -BadItemLimit 10

Exchange 2010

There should not be a reason in Exchange 2010 to use the Export-Mailbox cmdlet for eDiscovery. Exchange 2010 fundamentally changed the way mailbox information is stored. Exchange 2007 used a schema where tables worked across an entire database. This necessitated repairing an entire database when corruption may only be related to a single mailbox. Exchange 2010 now uses tables that are specific to each mailbox.

Because of this change in architecture, repairing a mailbox is much less time consuming. New-MailboxRepairRequest cmdlet (see alsoNew-PublicFolderDatabaseRepairRequest for Public Folder specific options). This one cmdlet replaces the need to run isinteg. The new cmdlet also does not require that the database be dismounted and taken offline. This tool can be run while user’s are still using their mailboxes. As with every cmdlet in EMS, there are many parameters that can be used to control the scope. You could repair a certain type of error on one mailbox or repair all error types for an entire database.

To repair all search folders for an entire database use the –Database and –CorruptionType parameters:

New-MailboxRepairRequest -Database “Accounting Dept” -CorruptionType SearchFolder

Exchange 2010 – 1 New-MailboxRepairRequest Fix Search Folder Corruption One Database

To repair all corruption for a mailbox use the –Mailbox and –CorruptionType parameters:

New-MailboxRepairRequest -Mailbox JohnDoe -CorruptionType AggregateCounts, FolderView, ProvisionedFolder, SearchFolder

Exchange 2010 – 2 New-MailboxRepairRequest Fix All One Mailbox

To see the results of the repair request, look in the Application Event Log for event 10047 (initiated), 10059 (complete database repair), and 10048 (successful completion with no corruptions remain).

Exchange 2010 – 3 Application Events 10047,10048,10059

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)
• eDiscovery in Exchange – Part 5: Export and search (0)

Since the uptake of smartphones has become more widespread, it is more than likely that your end users will require access to their corporate email via their smartphones. Whether or not the smartphone is company supplied . It is certainly a sensible idea to make sure that we have policies in place to protect our data should it end up in the wrong hands.

Exchange ActiveSync Mailbox Policies

Exchange 2010 has a feature called “Exchange ActiveSync Mailbox Policies”. You can find this in the Exchange Management Console, within the “Organization Configuration\Client Access” node from the tree view. You will notice that within the Exchange ActiveSync Mailbox Policies tab, you can create multiple policies – these can then be applied to different groups of users. I just want a common policy throughout my entire organization, so I will just modify the default policy that is already listed.

Exchange ActiveSync Mailbox Policies

Using the policy properties, you can force devices to use a passcode, set the minimum length or enable encryption, and so on.We can disable some function of an smartphone such as its camera, or Wi-Fi should this be a requirement in your organization.

Once a compatible ActiveSync device is synchronized with your Exchange organization, the appropriate policy will be applied, and the smartphone will react accordingly. It should be noted though that these policies do not apply to all devices , so it’s important to check it out first. The vast majority of smartphones in our organization are iPhones – Apple published a list of the supported policies on their developer site.

Exchange Remote Wipe

Should the inevitable happen, and a user loses their phone with all their company emails and trade secrets on it, and it doesn’t look like it’s coming back any time soon, we have a couple of ways of performing a remote device wipe. Firstly, the end user can do it on their own via Outlook Web Access (great if they lose the device when the helpdesk isn’t yet open!). The user will need to log into OWA, and select options from the top right, then select “see all options” from the menu. Once you’re in the OWA options screen, select phone from the right, and you should be presented with a list of mobile devices associated with your Exchange account. From the list of devices, simply select the device in question, and click the “wipe device button”.

Chances are that the end users will just ring the helpdesk to request that the device be remotely wiped. An Exchange administrator can easily do this from the Exchange Management Console. Navigate to the Recipient Configuration\Mailbox node from the tree view. In the main area of the console, right click the user in question, then select “manage mobile phone” from the context menu. You will be presented with a list of mobile devices that are associated with the user’s Exchange account – select the appropriate device, click the “remote wipe” radio button, then click the “clear” button.

Exchange Remote Wipe

Shortly after this, the mobile device should perform a full wipe and erase all data. If your staff are accessing your corporate emails via their personal smartphones, it might be an idea to let them know that you have the ability to wipe mobile devices should they be lost – many users might lose their smartphones and never tell you otherwise!

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• How to change the allowable message size in Exchange 2010 (0)
• eDiscovery in Exchange – Part 5: Export and search (0)

In Exchange one of the most common changes from the default that is required by business need is to increase the default allowed message size. This seems like a simple task, but in an attempt to make this type of setting as flexible as possible it must be set in at least two locations, with the potential for many more. Below I’ll outline each of the locations to change this setting both in the Exchange Management Console (EMC) and the Shell.

Outbound Send Connector(s)

To begin with Exchange 2010 separates the setting for inbound and outbound mail. In Exchange terminology these are referred to as Send and Receive Connectors. For each of these connector types you can have multiple connectors, each having their own message size restriction. In the case of the Send Connector this is done so you specify different settings depending on the external domain. For example you may want to allow 30 MB message to go out by default but if you have a connector to a well connected partner organization allow up to 50 MB.

In EMC you change this setting in Organization Configuration> Hub Transport> Send Connectors section. If you double click on each of your connectors (most of you will probably only have one) you will see a “Maximum Message Size” setting.

Exchange maximum message size – Send-Connector

To perform this same task from the Exchange Shell you only need the following command, changing the connector’s name and the size you want to set.

Set-SendConnector "Outbound" -MaxMessageSize 50MB

If you think about it in a situation where you have many connectors this can be extremely handy because you can cut and paste multiple commands and keep the mouse click count down.

Receive Connector(s)

Receive connectors are the same idea as Send connectors, but for the inbound messages. By default you’ll have two of these, “Client MAIL” which handles inbound messages from the individual Outlook or OWA clients, and “Default MAIL” which handles mail from anyone else. In some situations you may want to lock this down tighter. In my corporate environment the Default MAIL connector will only accept mail from the IP of my spam filtering appliance, and then have a separate connector for devices within my organization which I would like to relay.

Again in the configuration of each of these connectors you set a “Maximum Message Size” like seen below. The setting is changed at Server Configuration> Hub Transport> Receive Connectors.

Exchange maximum message size – Receive Connector

The Exchange Management Shell command for setting Receive Connector message size limits is very similar to the send connector command.

Set-ReceiveConnector "Default MAIL" -MaxMessageSize 50MB

Individual User Mailboxes

Finally as an Exchange administrator you are able to set Messages Size restrictions for both the inbound and outbound. I don’t generally set these unless I’ve got a problem user. Good example is the ever present user who gets regular e-mails with 20 unresized pictures of his/her grandkids. For this reason if you get complaints from a user you may want to check here to see if something is set.

This setting is set in the Mailbox properties, on the Mail Flow Settings tab, under Message Size Restrictions. You’ll have to check the box for each direction if you want to change the setting.

Exchange mailbox message size restrictions

For each mailbox you would like to change via the EMS you simply need to enter the following command.

Set-Mailbox –Identity “John Smith” –MaxSendSize 10mb –MaxReceiveSize 10mb

Order of Precedence

So how are these applied? Generally where the message first hits a limit is where the size restriction will take place. For example on an inbound message the Receive connector is applied first, if it passes it will then check the user’s mailbox for restrictions. In all cases, either inbound or outbound, the user mailbox setting trumps everything.

Spam Filter (optional)

As a final gotcha in trouble shooting this type of issue, you may want to check your external spam filter if you have one to make sure it doesn’t have this type of setting and it isn’t too low. I personally use a Barracuda Spam & Virus Firewall 300Vx and by default it will allow up to 100 MB messages, but this may vary depending on your vendor.

Barracuda Spam & Virus Firewall 300Vx

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• eDiscovery in Exchange – Part 5: Export and search (0)

Exchange 2007

Getting results in Exchange 2007 is done using the Get-Mailbox Exchange Management Shell (EMS) cmdlet piped to the Export-Mailbox cmdlet. All messages in the source mailboxes are moved to a destination, searched, and then either filed or removed from target. Dumpster messages are included. There are at least a couple ways the two cmdlets could be used to extract email by keyword.

Export to another mailbox in Exchange 2007

Exporting to another mailbox takes less prep time than exporting directly to a PST file as you don’t need a workstation with a special setup. In another post, I recommended having a separate mailbox database and mailbox to store the results of the search. I feel this allows you as the administrator to take another step to ensure that data related to a case is preserved separately from the production database.

Exporting to that database and mailbox is done using Get-Mailbox piped to Export-Mailbox. Incidentally, Get-Mailbox may not be required if you are only searching a single mailbox.

For this example, let’s modify the search when you need to search a recovered database instead of the live database. Searching the recovery database is done with the Get-MailboxStatistics and Restore-Mailbox cmdlets.

Get-MailboxStatistics -Database “Server\Recovery Storage Group\Mailbox Database” | Restore-Mailbox -Identity TargetMailbox -RSGDatabase “Server\Recovery Storage Group\Mailbox Database” -TargetFolder TargetFolder -AllContentKeywords “Keyword”

Each mailbox will be listed in the target folder in the target mailbox.

Exchange 2007 Recovery Database Search

Export to PST file(s)

Exporting to a PST file has a few requirements. First, you need a workstation with the 32-bit version of EMS installed. You also need to have Outlook installed on the same workstation. On the server side, you’ll want to have at least Update Rollup 4 for Exchange 2007 SP1.

The following EMS cmdlets can be run from the workstation once it is ready.

Get-Mailbox -Database “Ex2007MB\First Storage Group\Mailbox Database” | Export-Mailbox -PSTFolderPath C:\Temp\export.pst -TargetFolder Results -AllContentKeywords “keyword”

Get-Mailbox and Export-Mailbox each have several parameters which could be used.

Exchange 2007 Live Database Export to .pst

Exchange 2010

Exchange 2010 greatly streamlines to process of searching for legal inquiry email and extracting it to media. Now an administrator simply uses the Role Based Access Control (RBAC) tool in the Toolbox in Exchange Management Console (EMC) to give a designee the Discovery permission to mailboxes or databases. The designee can then perform their own searches utilizing tools available through Outlook Web Access (OWA). The designee also has permission to view results in the Discovery Mailbox.

Add Designee to Role and Search

To delegate permissions, open the RBAC User Editor tool. Select Discovery Management and click Details. Add members who should be designees. The Discovery Management administrator role has the Litigation Hold and Mailbox Search roles.

Exchange 2010 Role Based Access Control (RBAC)

To run search, the logged on user should click options, see all options, then click Manage My Organization. Next click Mail Control and then click Discovery. The screen allows the user to create a new search or view details of a previous search. Clicking the open link in the view on the right will open the Discovery Mailbox so that results can be viewed.

Export to PST file(s)

The process to export to PST in Exchange 2010 is much easier. Any user who has been assigned the Discovery role can have the Discovery Search Mailbox added as another account in Outlook. Results can be analyzed and ultimately exported to PST using Outlook.

This concludes the five part eDiscovery in Exchange series.

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)

If your inquiry will be done on a live database, this step of the process is not necessary. However; there are several scenarios where you’d want to perform the inquiry on a snapshot of the mailbox database from a previous point in time.

Exchange 2007

Create Recovery Storage Group

The first step is to use the Database Recovery Assistant to create a recovery storage group. This will provide a place to restore the database from DPM.

In Exchange Management Console (EMC) click Tools, Database Recovery Assistant, and Open Tool. If you have clustered mailbox servers, this should be done from the active node. Click Create Recovery Storage Group and then select a database to associate with and click Next. Specify appropriate file paths for the restored database and click Create the Recovery Storage Group. Review the details and click Go back to task center. There will now be new options available in the Manage Recovery Storage Group category.

Exchange 2007 – Create Recovery Storage Group

Exchange 2007 – Troubleshooting Assistant with additional options in Manage Recovery Storage Group

Restore Database to Recovery Storage Group from DPM

Next, the database with the appropriate information should be restored. In DPM, this can be done by opening DPM Administrator Console and clicking Recovery. Locate the appropriate date and source by selecting the calendar date and backup medium. Right click the database and select Recover. In the Recovery Wizard, choose the option Recover to Recovery Storage Group. Click Browse to select the mailbox server. Type in the name of the storage group and database. Storage group name by default is Recovery Storage Group. Database name will vary but should match the associated database name. On the next screen, disable Mount Database when recovery completes and click next. On the Summary screen click Recover. Recovery time will depend on the size the database.

Use Database Recovery Assistant to mount restored database

At this point the database has been restored to the Recovery Storage Group and is ready to be mounted. In Database Recovery Assistant, click Mount or Dismount Databases in the Recovery Storage Group. Select the dismounted database and then click Mount Selected Database. Click Go Back to Task Center.

Create mailbox for the search results

At this point, you’re nearly ready to begin searching the database to move email based on keywords. Prior to doing so, we need to complete the final preparation of designating which mailbox will contain the results of the search. I’ve seen some literature in the past that suggests a folder be created in the designated user’s mailbox that will be reviewing the results. This would be appropriate for internal investigations that may not lead to the need for eDiscovery. However; when legal discovery is necessary, I feel it’s best to have a dedicated mailbox and possibly even a dedicated mailbox database for storing nothing else.

Exchange 2010

Create Recovery Database

Similar to Exchange 2007, a place needs to be prepared to restore the database from DPM. Creating the recovery database can be done through Exchange Management Shell (EMS). Type in the following command all on one line to create a place for the recovered database. New-MailboxDatabase -Recovery -Name RDB2 -Server vEx2010 -EdbFilePath “E:\Recovery\RDB2\RDB2.EDB” -LogFolderPath “E:\Recovery\RDB2″

Restore Database to Recovery Database from DPM

Restoring the Exchange 2010 database as a Recovery Database is nearly identical to the process described earlier for Exchange 2007. The wizard in DPM only has different labeling of options. Choose Recovery Database as the restore option and otherwise follow the same directions and discussed earlier for Exchange 2007.

DPM 2010 Recovery Wizard

DPM Mailbox Server and Database Name specification

Mailbox for Search Results

Exchange 2010 has a built in Discovery Mailbox meant for doing legal discovery. It is no longer necessary to create a special mailbox to act as a secure place to store email matching eDiscovery search parameters.

At this point, the recovered database is ready to be searched. In the next post I’ll discuss how to perform the search by keyword and ultimately provide those search results to another party.

• Exchange 2010 Administrative Audit Logging (0)
• DPM 2012 – Part 4: Certificate based authentication (0)
• DPM 2012 – Part 3: Other improvements (2)
• DPM 2012 – Part 2: Role Based Access and scoped console (0)
• DPM 2012 – Part 1: Installation and Console (0)

Where Messaging Records Management (MRM) is applied can be controlled at a couple levels.

MRM at the organization level

Some organizations may have a policy that does not allow employees to keep email for more than a period of time. This would be done when the company wants to establish a standardized practice to protect themselves legally. Others may do so to control storage costs and consumption. Whatever the reason, Messaging Records Management policies that automatically delete email need to be put on hold, modified, or both.

Open EMC, navigate to Server Configuration, and click Mailbox. Right-click the effected server in the top pane and select Properties. Click the Messaging Records Management tab. Modify the schedule to Never Run. Because this affects all mailboxes on the server, you may want to skip this step. There may be some mailboxes that you know will not have information related to the inquiry.

Database Maintenance Schedule Exchange 2010

MRM at the individual mailbox level

Rather than disabling or modifying a MRM policy for the entire organization, you also have the option to exclude individual mailboxes. Viewing the mailbox properties, selecting Mailbox Settings, and then viewing Messaging Records Management properties will allow you to disable MRM for that individual mailbox.

In Exchange 2010 SP1, you also have the option of viewing the properties of a Retention Policy to see a list of mailboxes that use that particular policy. Simply remove the mailboxes that should not have the policy applied.

Modify Messaging Records Management policy

Messaging Records Management policies propagate to your entire Exchange organization, so take care when modifying policies. Modify a policy in both Exchange 2007 and 2010 by opening EMC, navigating to Organization Configuration, and clicking Mailbox. Click Managed Default Folders, Managed Custom Folders, and/or Managed Folder Mailbox Policies (2010 RTM) depending on where your policies are located and which folders they affect. Policies can be removed or can be affectively disabled by unchecking Length of retention period (days). You might also extend the number of days to a number of days equivalent to 5 or 10 years which accomplishes the same goal.

If you are using Exchange 2010 SP1 or later, you will instead have tabs labeled Retention Policy Tags and Retention Policies.

Exchange 2010 Mailbox Litigation Hold

Up until this point, I’ve covered a lot of options that can be mixed and matched depending on your circumstances. What’s been missing from Exchange up until version 2010, was a quick and simple way to bypass any of the automation mentioned previously. Exchange 2010 adds a checkbox to a mailboxe’s MRM properties called Enable Litigation Hold.

This small checkbox is one of the most significant improvements from version 2007.

Mailbox Messaging Records Management Exchange 2010

At this point, I feel an Exchange administrator has taken adequate measures to assure that email has been preserved. I know many of you may have other input and have unique experiences of your own. Please comment and let the community know what I’m missing.

In the next part of the eDiscovery in Exchange series, I’ll describe how to navigate through the next phase of actually gathering email for legal inquiry.

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)

There are many situations which could trigger the need to assure that email is being preserved. Some events are quite obvious while others may not be.

Before proceeding further, I must point out that prior to an event your company or organization should have an established list of guidelines that you will follow in the event eDiscovery of email may be required. I would recommend also having the procedures reviewed by your legal staff.

As an Exchange Administrator, here’s a scenario that should always trigger the execution of eDiscovery preservation. Your supervisor has notified you that an employee has been using your email system to harass another employee. The offended employee has told the Human Resources department that they are going to file a lawsuit against your company. This scenario is easily recognizable as a trigger to prompt you to preserve email.

Here are a couple that maybe aren’t so obvious. An employee has been terminated due to poor performance or you hear a rumor that an employee has been using their corporate email address for activities that could warrant termination. These scenarios may not be as obvious but these should also trigger preservation of email.

The overall rule is that an Exchange Administrator should begin preserving email even before being instructed to do so by a manager or supervisor whenever he or she first becomes aware of a situation that could require the use of eDiscovery in the future.

So now that we know when to preserve email, how do we do it in Exchange?

What NOT to do in Exchange 2007

Let me start by covering what NOT to do for Exchange 2007 mail boxes. Do NOT move affected mailboxes to another database.  Although most mailbox items are moved when a mailbox is moved to another database, the items in the dumpster are not moved. Dumpster items include any mailbox items that were permanently deleted but still fall within the database deleted item period mentioned in step later on.

In Exchange 2010, this is no longer a concern due to changes in the way the dumpster works. Dumpster items in Exchange 2010 mailboxes will stay with the mailbox when it is moved. This is not helpful when moving a mailbox from a pre Exchange 2010 server to 2010 as dumpster data will still be lost.

Retain Backups

This step can vary greatly depending on how you do backups. In a utshell, backup the affected database to a location where it will not be overwritten. If you backup to tape, backup the database to a tape and set that tape aside outside of the normal tape rotation. If you backup to disk, backup the database to a separate location outside of the normal location. Other snapshots may be necessary depending on the circumstances. If litigation concerns a former employee, this may be all that’s required. For current employees, this should be ongoing.

Modify Database Deletion Settings

The default for an Exchange database is to keep permanently deleted items and mailboxes for 14 and 30 days respectively. Consider the example where an offending employee will continue to remain employed. Your employer can be held responsible for lack of action if email is deleted due to default settings. My recommendation would be to choose a period of time of at least two or three years.

For Exchange 2007, open Exchange Management Console (EMC). Navigate to Server Configuration and click Mailbox. Right-click the effected database and click Properties. Modify Deletion Settings located on the Limits tab.

eDiscovery in Exchange – Database deletion settings

In Exchange 2010, Navigate under Organization Configuration and click Mailbox in EMC. Right-click the effected database in the top pane and click Properties. Modify Deletion Settings located on the Limits tab.

Also on the Limits tab is a checkbox that is critical to assuring nothing is removed before it makes it is backed up. Simply check the box for Don’t permanently delete items until the database has been backed up.

In the next post, I’ll discuss Messaging Records Management  and Exchange 2010 Mailbox Litigation Hold.

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)

From time to time, Exchange Administrators are called on to preserve and produce information for legal inquiry. Often times, this occurs without any prior warning and action must be taken immediately upon notification. Because a task like this often just piles more work and time on top of an already busy schedule, I’m hoping to trigger some useful discussion. My goal is that this series of articles, along with reader comment, can become a “go to” resource when email legal inquiry is required in your organization.

Background

If you Google “eDiscovery in Exchange”, or other similar phrases, you’ll find a plethora of results. Many will eventually guide you to purchasing software. When you’ve been tasked with producing email related to specific people or keywords, and time is of the essence, the last thing you want to do is purchase new software and learn how to purchase, install, setup, and use.

I’ve been in this situation a couple times so I’ve had to learn about the process. I want to share what I know to make life easier on you when you are in the same situation.

Most of my experience is using Exchange 2007, but I’ll also be covering Exchange 2010 as there are much better tools built in out of the box.

Be proactive

Before the need for eDiscovery ever arises, I think it’s important to take a few steps to ensure that your email resides in one place. In the past, PST files were a great way to archive email so that the Exchange database storage was used only for current email. Hard drive space was expensive. In contrast, drive space is cheap and Exchange databases are much more mobile. With that in mind, I believe every Exchange organization should prevent the use of PST files.

Let’s say an organization allows an employee to save email to a PST file that lives on a USB drive. There a few problems I have with that. Number one, you now have a user moving some of their email off company computers and essentially becoming the administrator for that email. Number two, the USB drive can be easily taken offsite and now that email is completely out of your control. Number three, when eDiscovery is required, the Exchange administrator may not know that PST file exist.

If the cause of legal inquiry is in fact the hypothetical person we’re discussing, things can get complicated quickly. It looks very bad when both parties submit everything they know and the disgruntled employee can produce 500 more emails than the employer they are suing.

Fortunately, this can all be easily avoided by simply disabling auto-archive and saving to PST files.

Disable Auto-Archive and saving to PST files.

1. Distribute group policy to all users disabling saving to PST files.
2. Add Outlook .adm to a GPO
3. Go to Microsoft Office Outlook/Tools | Options…/Others/AutoArchive
4. Disable AutoArchive Settings.
5. Go to Microsoft Office Outlook/Miscellaneous/PST Settings. <
6. Enable Prevent users from adding new content to existing PST files.

Disable PST files

In the next article in this series, we’ll continue the discussion focusing on what steps you should take when notice is given to preserve email.

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)

Upgrade

Upgrading the CUCMBE server, while it may seem daunting on the surface, was actually quite easy. The version 8.5 image file has to be downloaded from Cisco and saved on an FTP server. From the CUCMBE Unified OS Administration web page, click Install/Upgrade and direct the web page to look for images on your FTP server. Select the appropriate image, select option to restart later manually, and click Install. The server will copy the image to the local hard drive, create a new 8.5 installation in a new partition, and then wait for you to switch versions. The beauty of the process is that 8.5 installs on its own partition. This means that should the 8.5 switch not go as well as you might hope, you can still switch back to 8.0. Restart and switch versions either in the web interface or over a Telnet connection.

Cisco Unity Connection – Switch to version 8.5

Active Directory account

Now an Active Directory (AD) account needs special permissions to Exchange mailboxes. Of the three major steps, getting the correct mailbox permissions may be the hardest. I say this because getting the correct syntax for your environment may take some trial and error. That was the case for me. Once the correct syntax is worked out, the task is easily accomplished using the Add-ADPermission cmdlet in Exchange Management Shell (EMS). Please refer to the article, Configuring Cisco Unity Connection 8.5 and Later and Microsoft Exchange for Unified Messaging for more information specific to your environment (login required).

Enable Unified Messaging

If you’re a football fan, getting to step three is like the last two days of the lockout. We just have a couple more items to handle. Unity needs to have the Unified Messaging settings configured so it can use the AD account to synchronize with Exchange. Each user needs configuration added to utilize that connection.

Cisco Unity Connection Administration

To setup Unity, configure Unified Messaging Services by adding new UM settings. Specify a display name, authentication mode, and protocol the account should use to interact with client access web services. The service settings also need to include the Exchange version, account settings, and which service capabilities to use. For my purposes, I simply enabled Synchronize Connection and Exchange Mailboxes (Single Inbox). Click the Test button to verify settings.

Now that Unity has settings to use for synchronization, accounts need to be enabled. This is done by adding new Unified Messaging Account settings. When configuring this, make sure the Account Information section uses the Primary SMTP Address for the user. Enable Synchronize Connection and Exchange Mailboxes (Single Inbox) on this screen as well. Click the Test button to verify settings.

At this point, Single Inbox is enabled and each configured user should see new voice mail in their Outlook Inboxes.

In summary, version 8.5 was able to meet our needs. The syntax getting the Unified Messaging account setup to synchronize with Exchange was the trickiest step. Having said that, the Cisco documents I referred to previously provide all the information needed to complete successfully. Each document has several links to additional documentation that may be relevant to your environment.

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)

As an IT professional, it’s very common to wear different specialty hats depending on the needs of each day. Those of you in small IT shops understand what I mean: Monday, you might be configuring routers and switches, Tuesday, you might be setting up an Exchange server. With the arrival of VoIP, the blurred line that once existed between voice and network has almost completely evaporated. I’ll be sharing with you a prime example of how the two worlds have converged into one as I share my experience upgrading my Cisco Unity Connection server. We wanted to add the ability to synchronize voicemail messages directly to the Exchange Inbox. In the Cisco world, this feature is called Single Inbox.

Cisco Unity Connection – Microsoft Exchange

With version 8.0, Cisco left out what I consider to be one key feature. For some reason, they did not include a mechanism to synchronize voice mail with the Exchange Inbox. The only way to view email from Outlook was to create a new connection using IMAP. The system previous to our Cisco system was able to sync with the Inbox so a few of my users had grown accustomed to managing voice mail using the Outlook Inbox as well as Activesync on their cell phone. I’m understating when I say we were disappointed to find that 8.0 did not include this feature. However; we proceeded with the promise that 8.5 would have this feature and installed Cisco Unified Communications Manager Business Edition (CUCMBE). CUCMBE is the combination of Call Manager and Unity (voice mail) on one server.

So how does version 8.5 do it? The answer is by utilizing the Exchange Client Access (ECA) server web services that many of you Exchange administrators out there probably already have running for OWA, Activesync, OAB, etc. Version 8.5 synchronizes with Exchange versions 2003, 2007, and 2010. The beauty of adding Single Inbox is that it doesn’t require a great deal of configuration on the Exchange or Cisco side.

In a nutshell Single Inbox (in version 8.5) places an email in a user’s Inbox with a .wav file of the voice message. If you delete this message from your Outlook Inbox, the message is also deleted on the Unity server. If you later mark the message as unread, the voice mail indicator light on your phone turns on. For more information about Single Inbox please refer to Single Inbox in Cisco Unity Connection 8.5 and Later.

Gaining this new functionality for users of version 8.0 can be accomplished in these steps:

1. Upgrade Cisco Unified Communications Manager Business Edition (CUCMBE) to version 8.5.
2. Add Exchange mailbox permissions to an Active Directory account that is used to synchronize voice mail.
3. Enable unified messaging in Cisco Unity Connection and on each voice mailbox.

In my next article, I’ll outline the three steps in a little more detail, provide a couple links to essential documentation, and summarize my experience.

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)

GFI is raffling off three licenses of their email archiving software. Each license can be used to archive 50 mailboxes for one year. The deadline of this contest is September 1, 2011. If you want to take part in this raffle, please send an email with the subject "GFI MailArchiver" to .

With all the regulatory and contractual requirements around email archiving, businesses of any size need to implement an archiving solution. When you consider how archiving can improve the user experience (and cut down on restore tickets) it should be pretty obvious that you want email archiving. Being a fan of other GFI products, I decided to take GFI MailArchiver for a spin.

System requirements

Of course, to implement an email archiving software, you need a server to run it, and while I will be archiving content from Exchange, GFI MailArchiver is not Exchange. As such, it can run on lesser hardware, and even on 32bit operating systems. There is both a 32bit and a 64bit version of the software, and its hardware requirements are fairly low. A 2GHz processor with 2GB of RAM is recommended, though it will work on less. The only thing you want to ‘go large’ on with your archiving system is disk, so that you have plenty of room to store years of email. Smaller orgs can use the included Firebird database, while larger user bases will want to use SQL Express or full SQL. You also need to install .NET Framework 2.0, ASP .Net 2.0, IIS, MDAC, and when not installing on top of an Exchange server, the MAPI Client and Collaboration Data Objects 1.2.1. I really prefer the idea of running an email archiving solution separate from Exchange for several reasons:

• Performance
• As an alternate way to get to email when Exchange is in maintenance
• In case separation of duties is required (such as if Exchange admins should not have access to the archive)

But for testing I installed it on my CAS/HUB/MB server. Throughout the evaluation, this server remained very responsive and seemed to handle the load well. Disk performance showed the need for something more than a single VHD running on a single SATA drive, but in production a robust SAN hosting the content drive should rock.

There is also an Outlook Connector (in both 32 and 64bit flavours) that enables users to view archived content from within Outlook. This supports Outlook 2003, 2007, and 2010, and is accessible from an installed server. Running as an add-on to Outlook, its hardware requirements are negligible.

Installation

Installation of the server is very straightforward. The only real options are to change the default administrator@localdomain email address for notifications, and to choose a different web site than default if you don’t want to access the archive using a virtual directory. It was very nice that a reboot was not required. After the install completes, a wizard launches that walks you through setting up your first archive, and a journaling mailbox. It prompts you for your database server (or to use the internal database for smaller deployments) and then to name your first archive. Two more nexts (options for remote storage or local, and UNC path) and your Archive Store is done. Now for the Journal Mailbox. If you already have one created from Exchange you can use that, or GFI MailArchiver can set one up for you. This process takes a few moments, and then you are done.

Configuration

The default configuration is set up to archive all mailboxes without exception which, if you are implementing email archiving, is the way to go. You can create exceptions to this, and set retention policies which can automatically delete email that ages past the point you want it laying around. Policies can be based on sender, recipient, subject, or body content. You can also configure rules for how to handle email flagged as spam, retaining it for a short period of time before deleting it permanently.

Email Archiving Software – GFI MailArchiver

You also have the ability here to set up classification rules based on the same values, and audit settings to match requirements for compliance audit and review. Note though that auditing will require that you are using MS SQL instead of the included Firebird database. You can also set a legal hold on an archive, ensuring that nothing is deleted by user or policy.

Let’s get rid of those PSTs!

The option to Import Old Emails gives you an instruction page on how to export old mail from mailboxes and PST files; either local or on a network share. This is a great way to incorporate all those old PSTs that your mail hoarders refuse to give up…just in case, but that are chewing up room on file servers and are outside of any hope for discovery and audit. The actual tool is already installed on the server and accessible through the start menu; it’s not browser based.

GFI MailArchiver – Import/Export

As you can tell from the screenshot, it also supports importing mail from GFI MailEssentials and can be used to export email from an archive.

Seek and ye shall find

Of course, an archive that cannot be searched is no better than a hundred PSTs scattered over a dozen departmental file servers. MailArchiver enables you to search a single archive or across all archives (or anything in between) for mail using a wide range of options, like shown below.

GFI MailArchiver – Search

You can also set date ranges to narrow the scope. Results can be viewed, forwarded, or exported, and searches can be saved for reuse. Date conditions can be selected or entered free-form (which I appreciate) and matches can use ‘*’ and ‘?’ like other searches.

Conclusion

GFI MailArchiver is easy to install, low on system requirements, and easy to get up and running. Any shop that has on-premise email owes it to themselves to check out this product so that they can add archiving to their messaging. With pricing based on number of users, a small company with a single Exchange server could add email archiving for under $1000 a year, which is a bargain. Download a free trial and see for yourself just how easy it is to add archiving to your messaging solution.

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)

In my last post I introduced Forefront TMG’s functionality to secure Exchange 2010. Today, I will show you how to configure Exchange and Forefront to work together.

Install the SSL-Certificate

1. Open the „Exchange Management Console“ and export under „Server Configuration – > Exchange Certificate“ the Exchange certificate by right clicking „Export Exchange certificate“.
2. Name the certificate, enter a password and save it as a *.pfx file.
3. Copy the file to your Forefront TMG server.
4. Open a „Microsoft Management Console“ on the Forefront TMG Server by typing “mmc” in the Command Shell.
5. Add the Certificate Snap-in by „File -> Add/Remove Snap-In“ and choose the “local Computer” in the „Computer account“ dialog.
6. Open the certificate-tree (Local Computer) and select „Personal“.
7. Right click on the „Personal“-folder and select „All Tasks -> Import…“
8. Import the *.pfx file. You have to choose *.pfx as the file-type instead of the default *.cer. In the next dialogs keep the default settings.

Create a Web Listener

1. Open the „Forefront TMG Management Console“. On the right column choose the tab „Toolbox -> Network Objects“. Create a „Weblistener“ by using the “New” option.
2. Now you have to name the Listener. In the next dialog keep the default setting https.
3. Allocate the external network to the Web Listener. If you want to use preauthentication for your internal network, too, you have to add the internal network.
4. In the dialog „Listener SSL Certificates“ choose the certificate you copied to the Forefront Server in the previous step.
5. Under „Authentication Settings“ choose „HTML Form Authentication“. By this choice you make sure that web-based Authentication is used for OWA and that the „Basic Authentication“ is used for Outlook Anywhere and Exchange ActiveSync. To force the user to authenticate click the „Advanced“-Button and select the option „Require all users to authenticate“.
6. If you want to use „Single Sign On“, provide the address .contoso.com.
7. Close the dialog by clicking on „Next“ and „Finish“.

Create a Web Farm

1. Create a new „Server Farm“ in the Forefront TMG Management Console. You can do this by choosing „Network Objects“ in the right column and open the menu „New“.
2. Name the Server Farm „Exchange Client Access Server“ and add your Client Access Server on the next page.
3. To configure the „Server Farm Connectivity Monitoring“ properly you must change the entry under „Send an HTTP/HTTPS GET request“ to „HTTPS://*/OWA/“.

The Exchange „Publishing Rule“

1. In the Forefront TMG Management Console open the context menu of the „Firewall Policy“. You can find the node „Firewall Policy“ in the left column. Create a new access rule by choosing „New->Exchange Web Client Access Publishing Rule“.
2. Name the rule „Exchange Outlook Web App“.
3. On the first page of the dialog select the Exchange version „Exchange 2010“. Choose „Outlook Web Access“ as the corresponding protocol.
4. In the next dialog choose „Publish a server farm of load balanced Web servers“. You should select this option even if you have currently only one Client Access Server, because you can easily add another server to the rule later on.
5. On the next page choose SSL.
6. Under „Internal Publishing Details“ enter the URL mail.contoso.com.
7. In the next step choose the Server Farm you created before.
8. In the selection list „Accept requests for“ you should keep the option „This domain name (type below)“. The „Public name“ is mail.contoso.com.
9. In the next dialog choose the Web Listener you created before.
10. As the authentication method select „Basic authentication“. Make sure that the Client Access Server is supporting this authentication method. Otherwise you have to change the configuration of your Client Access Server.
11. On the last page you can give access rights to specific users. If everybody should be able to use OWA keep the option „All Authenticated Users“. Never use the option „All Users“ because the users won’t see an authentication dialog then and therefore can’t connect.
12. Close the wizard.

For now only OWA has been configured for secure access. If you want to secure Exchange ActiveSync and Outlook Anywhere you have to create “Publishing Rules” for them, too. You can do this by following the steps as listed above. The only difference is in step three. There you have to choose the corresponding service.

To use Autodiscover you have to add the Autodiscover URL to the Outlook Anywhere Publishing Rule.

1. Open the „Properties“ dialogue of the rule.
2. Under the tab „Public Name“ add via „New“ the Autodiscover URL (e.g. autodiscover.contoso.com).

Last but not least you have to change your DNS entries. They have to point to the external IP address of Forefront TMG. Be careful when changing them, though. If the FQDN of your MX-entry is the same as the FQDN of the Client Access Server you have to create a new MX-entry and A-record. Otherwise the SMTP-requests are directed to the external IP of the Forefront TMG and not to your Exchange Server.

When you access OWA now you should see the following screen:

On the first glance it looks similar to before, but perhaps you have noticed the line “Secured by Forefront Threat Management Gateway” already. After you tested everything thoroughly you should delete the old firewall rules. Now it’s time to lean back and relax, because you have severely increased the security of your Exchange installation.

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)

An essential part of an Exchange 2010 deployment is the availability of e-mail everywhere at any time. For your users, this feature eases work; for you as an administrator, it means more work, because you have to secure the Exchange Server against attacks from outside your corporate network.

I often see that Exchange 2010 is published directly to the internet by allowing access to the various ports from the internet. However, this approach undermines most of the security features of Forefront TMG. Forefront supports Preauthentication, which means the users do not authenticate with the Exchange Server but with Forefront. Forefront then passes the privileges to the Exchange Server.

This improves security in various ways; one of them is that you do not have to publish Exchange to the internet. Another security feature of Forefront is that it can act as a web proxy. Here the protection mechanism is the same as with Preauthentication. From the Internet, nobody sees your Exchange Server. It is completely hidden behind the firewall.

Forefront also supports web filters and e-mail filters. When the access to Exchange is secured by SSL, which is absolutely needed to have at least some basic protection, and only passed through the firewall to Exchange, these filters cannot work because all they see is the encrypted stream of bytes. Forefront can bridge SSL. This means that the users still use SSL to access their e-mail, but Forefront TMG can inspect the network traffic.

When SSL is bridged, the user establishes a SSL connection with Forefront TMG and Forefront TMG establishes a SSL connection with Exchange. Thus, the tunnel is interrupted and Forefront can inspect the traffic. However, even though the SSL tunnel does not directly connect the user with Exchange, all network traffic is still secured by SSL.

Before I write about the actual configuration steps, I want to provide you with a picture of the network topology and list the prerequisites of this guide. The network topology is pretty simple in my case, but it can be even simpler. The Exchange 2010 Client Access Server and the Mailbox Server can reside on the same server. There is no need for them to be installed on separate machines.

Prerequisites for securing Exchange 2010 with Forefront TMG

1. A working Exchange 2010 and Forefront TMG installation.
2. You have to have Split-DNS configured, which means you use the same domain name for your internal and external network. I use the name contoso.com.
3. Outlook Web APP (OWA), Outlook Anywhere, and Exchange ActiveSync use the FQDN mail.contoso.com.
4. You need a valid certificate. mail.contoso.com must be the certificates principal and autodiscover.contoso.com has to be listed under “Subject Alternative Name”.

If you can fulfill these prerequisites, you can follow the step-by-step guide to secure your Exchange 2010 Server in my next article.

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)

The best security solutions are layered ones, taking a defense in depth approach so that there is no single layer between vital information resources and disaster. Nowhere can this be more critical than in protecting your Exchange infrastructure from malware attacks. In this post we will go over the seven key layers you should have in your game plan.

1. Consider a cloud solution as the first line of defense

The right place to stop malware (and spam) is as far away from your systems as possible. Using a solid SaaS solution is a great way to filter out malware and spam before it ever gets to your perimeter. This saves you on bandwidth, CPU cycles, and storage space and can reduce the number of threats crossing your border by an order of magnitude.

2. Deploy a packet filtering firewall with intrusion prevention at the perimeter

This firewall should be able to recognise protocol level attacks and shun source addresses.

3. Use the Edge Transport Server role The Edge Transport Server role is specifically designed to filter messages while they are still in your DMZ using anti-spam and antimalware agents. If something does get through, the inner firewall is still in place to protect your internal systems from threats. Use an antimalware product designed to work on the Edge Transport role and to scan messages with multiple engines.

4. Deploy that inner firewall. Whether this is a separate physical firewall, or another VLAN of a three-legged deployment, this firewall not only protects your internal systems from threats, but should prevent outbound SMTP from anything other than your Exchange infrastructure. That way, any malware that tries to send SMTP messages will be blocked, and detected.

5. Implement antimalware on the Hub Transport Server The Hub Transport Server role can also perform antimalware and anti-spam screening. Personally, I like to have one pair of antivirus engines running on the Edge Transport server, and a different pair on the Hub Transport, so that messages are scanned by four different engines overall.

6. Don’t forget the Mailbox server Messages passed between mailboxes on the same Mailbox Server won’t pass through a Hub Transport server. Make sure messages are being scanned on the Mailbox Server.

7. Use a comprehensive antimalware suite on your clients You want to make sure that your antimalware solution includes protection for Outlook as a last line of defense. It also helps to protect from any personal email accounts that your users might setup their Outlook client to access, if they have administrative rights.

As with all of your other servers, make sure you are also running antivirus on the operating system of each of your Exchange servers to protect the server itself. This is a critical step that cannot be skipped, to ensure that your Exchange servers are protected from threats that are not originating from email. Remember, your Exchange servers are still Windows servers, with all of the services and administrative shares that all your other servers have. Keep in mind that client antimalware can interfere with Exchange if it is not properly configured. Make sure to follow Microsoft’s recommendations on exempting key directories and processes of Exchange to avoid any problems.

There are a lot of layers that need to be protected, but there are a lot of layers in an Exchange infrastructure, and each is just as important as any other. Covering all your bases is the best way to minimize your risks, and maximize your defenses.

Additional reading:

• Top 10 Security Predictions For 2011
• File-Level Antivirus Scanning on Exchange 2010
• A Patch Management Strategy for Your Network
• Evolution of Defense in depth

This guest post was provided by Ed Fisher on behalf of GFI Software, a software developer that produces network and messaging security solutions for SMBs. Information about GFI email security for Exchange Server/SMTP/Lotus solution

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)

Email is the lifeblood of businesses today. Everyone needs email access and they need it everywhere, in the office, at home, at the airport and in the motel room where they’re meeting their lover. Maybe that last one is stretching it a bit but email connectivity from everywhere and on every device is certainly a top priority for many Exchange administrators.

Fortunately Microsoft provides an online tool to help troubleshoot remote connectivity that has steadily improved over the years; the Exchange Remote Connectivity Analyzer

Exchange Active Sync

The first two tests on the main screen are related to mobile devices. There’s a test to make sure your Autodiscover DNS records are published correctly in DNS and available from the internet. There’s also a test to verify connectivity to your Exchange Active Sync server (Client Access Server role).

You have to specify the server (or use Autodiscover), a valid username and password as well as acknowledge that the details you provide are valid. All the tests ran fairly quickly in my testing.

It gives me peace of mind to run through a few of these tests before telling the client “yes – your new shiny smartphone will work just fine with email”.

Outlook Anywhere

After making sure people can get their emails, calendars and so forth on their mobile devices it’s almost as crucial to make sure their Outlook “just works” no matter where they are. Notwithstanding newer technologies such as Direct Access; Outlook Anywhere / RPC over HTTPS is an anchor for many a road warrior armed with a laptop.

Again you have to specify an email address, username and password and either use Autodiscover to find your server or manually enter the details. If you do enter the server details manually make sure to leave the https:// bit out of it.

SMTP In and Out

Perhaps more crucial for you as an administrator than the above user-centric access methods is basic mail flow in and out of your organisation. While you can always test SMTP mail with a Telnet session (see here for instructions) this can be laborious so this test is quicker.

All that is required is an email address for the inbound test, if all goes well a test email shows up in your inbox.

For the outgoing test you’ll need to provide the IP address of your outgoing email server as well as an email address. It’ll also do a reverse DNS check, a block list check (RBL) and a Sender ID check.

Conclusion

For those times when you’re tearing your hair out, trying to figure out why it’s not working when it should be, the Exchange Remote Connectivity Analyzer can be your hair’s best friend. Similar tests can be done elsewhere (http://www.mxtoolbox.com for instance) but nothing is as specifically geared towards Exchange as this tool.

Exchange Remote Connectivity Analyzer

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)

In September and October Alexander Weiss wrote a series of articles here on 4sysops around the technical aspects of deploying Exchange 2010 roles and migrating from Exchange 2003. This time around I thought we’d focus on the planning phase of a medium to large sized migration from earlier versions of Exchange to Exchange 2010.

Microsoft has offered for some time, and recently updated, the Exchange Server Deployment Assistant. It’s an online wizard that asks a series of questions about your current environment and in the end produces a customized check list with instructions for each step you need to take in your migration. These types of “design” questions are crucial in controlling how your environment will look and are similar to the concepts behind questions you’d encounter on an Exchange MCITP certification exam.

Planning is vital as email is “mission critical”; thus a large and possibly complex setup that’s going to be migrated needs precise planning. Whilst this tool doesn’t give you everything (it doesn’t cover all different combinations – yet) it’s a good starting point.

Company A

This fictitious company is a medium sized engineering / manufacturing business. Head office is in Germany, with smaller offices in the US and China; Company A has about 1200 employees. In 2004 their old Lotus Notes environment was successfully migrated to Exchange 2003 which has served the company well for the last six years. Company A is risk adverse and decided to skip Exchange 2007 but is now focusing on migration planning for an in house implementation of Exchange 2010 in early 2011.

When you start the tool you’re faced with three options, On Premises Only, Coexistence (On Premises + Cloud) and Cloud only. Cloud only takes you to the Technet documentation site rather than further wizard pages, showing that this tool isn’t complete. Selecting the first button brings us to the option of which version we’re upgrading from, including an option where there’s a mix of Exchange 2003 and 2007 servers. Company A uses OWA (who doesn’t?) but with 1200 users and three offices the migration won’t happen over a weekend, they don’t have a disjointed namespace but they’d like to continue using their extensive public folder infrastructure, they’ll use a hosted messaging hygiene solution instead of the Exchange Edge role but they’re definitely looking to implement UM as it’s one of the drivers behind the Exchange 2010 project.

After these few questions are answered a 20 step checklist is presented with in depth recommendations for each step. This can be downloaded as a PDF or each step can be navigated online.

Each step features an introduction and explanation followed by detailed instructions and finally a part called “how do I know this worked?”.

Company B

This book publishing company has 5500 users, with a head office in Sweden and smaller offices spread all over Europe, Asia and the US. Currently running an on premise Exchange 2003 system they’re looking to move to the (Office 365) cloud. For a time (six to twelve months) they’re expecting a co-existence scenario whilst transferring each office and group of users to the cloud.

The questions here are different, Company B want on-premise credentials linked to the cloud; they’d like the same email domain for all users; all outgoing mail doesn’t have to go through an in-house server; free/busy calendar data should be shared amongst all users and a single URL should link to OWA for both cloud and on-premise users. Company B’s answers results in a 29 step list with detailed information on how configure an Office 365 and on-premise co-existence.

Conclusion

If your company or clients are looking at going to Exchange 2010 and / or the cloud make sure you make the Exchange Deployment Assistant the first step in your planning– it will help you tremendously with only a small investment in time.

Resources

Technet articles on how to plan for and deploy Exchange 2010, including migration documentation here.

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)

For many organizations, it’s a good idea to centrally manage email signatures and email disclaimers – it gives a consistent branding on your email communications, and you’re not relying on end users to set them up correctly and keep them consistent. If you’re running Microsoft Exchange 2010, you have the ability to do this out of the box, using ‘Transport Rules’. Applying signatures this way should also save you space in your mailbox databases, due to the fact that signatures won’t be added on to each message in every users “Sent Items” folder.

To get started with a basic signature, open the Exchange Management Console, and navigate to: ‘Organization Configuration’ >> ‘Hub Transport’, then select the ‘Transport Rules’ tab, finally click the ‘New Transport Rule’ link in the actions pane on the right. The Transport Rule wizard should then start, you’ll need to provide a name for your rule, and then select which user or group of users this rule should apply to. In your first instance, it’s probably a good idea just to apply it to yourself to test with, later you can apply the rule to other individuals, distribution groups  etc. Have a look through the options available to you in step 1, they are quite flexible with who the rules can be applied to. In step two of the transport rule wizard, you will need to chose the ‘append disclaimer text’ action, and then enter your text by clicking the appropriate hyperlink in the bottom pane of the wizard.

Before we move on to step 3 of the wizard, you should be aware that signatures and disclaimers can only be appended to the absolute end of emails. If you want to have a signature at the end of each reply, you will need to look into 3^rd party solutions. Due to this fact, I always add an exclusion rule, for any email with ‘FW:’ or ‘RE:’ in the subject, in order to prevent a build up of signatures right at the end of an email conversation, which could confuse people. Once you’ve added this exclusion rule, the wizard will confirm your choices, and then create the transport rule. At this stage, if you send an email that matches the criteria in step 1 of the wizard, you should see your signature applied.

Dynamic email signatures

The best aspect of adding signatures via Exchange transport rules is the fact that certain attributes from Active Directory can be dynamically inserted into the signatures – just insert the attribute name into the disclaimer text in the transport rule, with ‘%%’ on either side of the attribute name (e.g. %phoneNumber%). Unfortunately not all AD attributes will work, but there are a number of useful ones available, the full list is provided on Microsoft TechNet.

For our next signature, go back and edit the previous transport rule you created, and edit the disclaimer text to include some dynamic attributes. We will also need to add some very basic HTML to format the signature:

Now when a mail matching our criteria is processed by Exchange, it should have our name added in bold, along with our phone number. You could get more creative with the HTML in the signature, inserting company logos, or creating tables.

Text only email signatures

If you’re sending a text only email (Many mobile devices will send these out – including iPhones and Blackberries), Exchange will have to convert your signature to a text only format. It’s always a good idea to check what the converted version looks like – especially if you’ve used a lot of HTML.

It’s also worth noting that a bug in pre SP1 meant that when Exchange converted HTML messages to text only, the signature ended up with <html> and <body> tags at the start of it. This issue was fixed in Exchange SP1.

Chaining email signatures

Finally, as you build your signature system up for your organization – it may help to be aware that you can create multiple transport rules that build up your signature and disclaimer in chunks. For example, one rule could include generic name and contact details, followed by another section with a departmental marketing line, followed by a global disclaimer message. By setting the priority of each transport rule, you can ensure that they will be joined together in the correct order.

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)

The Mailbox Server Role is the last role you need to install to have a working Exchange 2010 environment. The two Server Roles that I haven’t talked about yet—namely, the Edge Server Role and the Unified Messaging Server Role—are specialized roles that either improve security or centralize communication in one inbox. Exchange 2010 will run well without them, so I won’t cover these topics in my Exchange 2010 deployment series.

The deployment of the Mailbox Server Role is straightforward. The Mailbox Server Role is quite resource intensive, so unless you have a very small amount of users and data you should deploy it on its own server. The mailbox server is also the place where all your data resides, so it needs plenty of hard disk space. A video is available at TechNet that supports you in deciding how to size the mailbox server. There is also a tool to calculate Exchange 2010 Mailbox Server Role Requirements.

If you want to install the Mailbox Server Role on a bare server, on which no other Exchange Server Roles reside, you have to install the prerequisites first. This is easily accomplished by executing the following commands in PowerShell:

     Import-Module ServerManager

     Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,
             Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,
             Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,
             RSAT-Web-Server –Restart

You are now ready to launch the installation wizard from the installation media. You should be familiar with the process by now: Choose which language pack to install, and then start the installation wizard. As this is the third time you will be using the wizards, I won’t bore you by explaining the details again.

If the installation has completed successfully, you are done with the installation part of the Exchange 2010 deployment for now. It is time to configure the different Server Roles. But if you want to add more security, high availability, or a unified inbox to your Exchange environment later, you will meet your old friend the installation wizard again.

The newly created mailbox server already has a default database. I recommend changing the paths of the mailbox database file and the transaction log folder. If you want maximum performance, you should put each of them on a different drive. You can change the paths easily by launching the Exchange Management Console and navigating to Organization Configuration -> Mailbox. Before you do so, you have to dismount the database; you can find that option by right-clicking the database’s name. After dismounting it you can choose the “Move Database Path” option from the context menu. A small wizard will be launched where you can set the database name, database path, and location of the transaction logs.

If public folders are used in your environment, a default public folder database should be created during the installation. You should also change the path settings for this database. You may want to change some settings for Message Tracking and Records Management, too. This can’t be done with the Exchange Management Console, though. You need to use the Exchange Management Shell. To alter the Message Tracking settings you have to use this command:

Set-MailboxServer <MailboxServerName> -ManagedFolderAssistantSchedule
              <AssistantSchedule>

For the Records Management settings use this command:

Set-MailboxServer <MailboxServerName> -MessageTrackingLogPath <LogPath>
              -MessageTrackingLogMaxAge <MaxAge>
              -MessageTrackingLogMaxDirectorySize <LogDirSize>
              -MessageTrackingLogMaxFileSize <LogFileSize>
              -MessageTrackingLogSubjectLoggingEnabled <SubjectLogEnabled>

In upcoming articles I will show you how to move your mailboxes to the Exchange 2010 mailbox server and how you can replicate the Public Folders.

• Exchange 2010 Administrative Audit Logging (0)
• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)