I’ve been reading through several forums on the web to looking for resolutions to the blank email problem. Unfortunately there is no all-encompassing, single silver bullet out there that will satisfy everyone.

What originally got me started down this path is that I was reading through a blog forum – “Office for MacHelp.com” – and I came across a blog entitled, “Exchange Mail sent as HTML in Outlook 2011 is received as plain text”, written by Diane Ross.

In her comments she related an issue some administrators have encountered after recently upgrading their Exchange servers from 2003 to 2010. Prior to the upgrade, users were able to see all their email messages and to check whether they were sent as HTML messages or as Plain Text messages. But after the upgrade only plain text messages were making it through to the end user. HTML formatted messages would arrive but were not viewable – they were displayed as blank messages. Not so good.

So I dug around the web looking for that one-size-fits-all solution. Sorry to say, it’s not there. But I did find some options that can be used to resolve this problem.

One solution is to run the following command:

get-remotedomain | set-remotedomain -ContentType MimeHtmlText

Once the ContentType parameter has been set then an administrator should restart the Exchange Transport Service.

The set-remotedomain cmdlet is used to define the parameters which affect the managed connections of a remote domain. Such parameter settings can affect the exchange of mail messages, how messages are formatted and any associated policies. Any messages that are sent to or received from remote domains can also have different character sets.

The following command can be used to view the current setting of the ContentType parameter of the remote domain:

Get-RemoteDomain | FL

In the solution example above, the contenttype parameter on the Exchange server is being set to MimeHtmlText. The ContentType parameter can be used to define how messages that are sent should be formatted and what their content type should be. The ContentType parameter has three possible values: MimeText, MimeHtml and MimeHtmlText.

The MimeText content type takes all messages that use text formatting and converts them to Multi-purpose Internet Mail Extension (MIME) messages. The MimeHtml content type takes all messages that use HTML formatting and converts them to MIME messages. And lastly, the MimeHtmlText content type takes all messages that use HTML formatting and converts them to MIME messages. However, if the HTML formatted message was originally a text message then that message is sent out as a MIME message with text formatting. MimeHtmlText is the default setting.

After the remote domain’s ContentType has been set then an administrator should restart the Exchange Transport Service.

Another solution was found that basically involves turning off your anti-virus protection. What was happening was that the anti-virus application was removing the content of the email messages whenever HTML formatting was used. If the option to scan outbound email messages is not selected then the result is that the messages will be viewable and not blank. Unfortunately the anti-virus protection will not be able to scan the messages for viruses so this really isn’t the best choice.

An example of this problem is when the ESET NOD32 4.x anti-virus software is installed on client machines. In this case some Exchange 2010 users may receive email messages that do not contain any content. An administrator should check with their respective vendor’s technical support team to see if a solution had been created.

There is another situation that results in blank email messages whenever an Internet Message Access Protocol (IMAP) client application is used to read email messages and Exchange Server 2010 is the email server. If the content type of the MIME message is multipart and the multipart has only a single subpart then this will produce a blank email message.

The following is an example of a MIME message that cannot be read by an IMAP client:

Content-Type: multipart/mixed;
boundary=”-1970672470-1383129417-1288825231=:5310″
Subject: test
MIME-Version: 1.0

—1970672470-1383129417-1288825231=:5310
Content-Type: text/plain; charset=”ISO-8859-1″; format=flowed
Content-Transfer-Encoding: 8BIT

. . . . . . .

—1970672470-1383129417-1288825231=:5310–

The problem is that the Microsoft Exchange IMAP4 service does not send back the correct response to the IMAP FETCH (BODYSTRUCTURE) command. The solution to this particular problem is to install the Update Rollup 3 for Exchange Server 2010 Service Pack 1.

Blank Email Messages

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

There are multiple management roles that are included with Microsoft Exchange Server 2010. Many of the roles get assigned to management role groups or management role assignment policies. Together, these management role groups and management role policies control who is permitted to manage and use the various capabilities of Exchange Server.

The permissions that result from the combination of the management role groups and management role assignment policies can affect how Exchange Server is maintained and administered. If there are problems during the installation of Exchange Server then it can adversely affect the creation of administrative management role assignments. For example, an administrator may see roles beginning with “My” that get assigned to the Organization Management role group.

Additionally, the management roles can affect many aspects of the administration of the Exchange Server. The Role Based Access Control model of Exchange Server 2010 includes the management role. It is this role that can get assigned to several management role policies. It can also get assigned to role assignment groups, universal security groups and users. Using the management roles, administrators can edit Exchange Server components that include: transport rules, recipients and mailboxes. Administration of the Exchange Server components is performed through the use of cmdlets or scripts. A cmdlet or script along with its corresponding parameters is called a management role group. The cmdlets or scripts are included with the role and can be executed by those who are assigned the role.

Here is a list of some of the roles that are assigned to management role groups or management role assignment policies:

• Active Directory Permissions Role – Active Directory permissions can be configured by administrators who have the management role assigned to them. Transport Receive and Send connectors, and Send As and Send on behalf of permissions for mailboxes are all features that use Active Directory permissions or Access Control Lists (ACLs).
• Address Lists Role – Administrators who have the Address Lists management role assigned to them can create, modify, view, and remove address lists, global address lists (GALs), and offline address lists (OABs) within their organization.
• Application Impersonation Role – Applications that are assigned the Application Impersonation role are allowed to take on the role of specific users in an organization in order to execute actions as if they were that user.
• Audit Logs Role – The administrator audit log can be configured by users who are assigned the Audit Logs management role.
• Cmdlet Extension Agents Role – Administrators are allowed to enable or disable the cmdlet extension agents in an organization if they are assigned the Cmdlet Extension Agents management role. They are also allowed to set the priority.
• Database Availability Groups Role – Administrators are allowed to manage database availability groups in an organization if they are assigned the Database Availability Groups management role. The Database Availability Groups role is the highest administrator level that is responsible for the high availability configuration in an organization.
• Database Copies Role – Administrators are allowed to add, remove, suspend, resume, view, and update database copies on individual servers if they are assigned the Database Copies management role.
• Databases Role – Administrators are allowed to create, manage, mount, and dismount mailbox and public folder databases on individual servers if they are assigned the Databases management role.
• Disaster Recovery Role – Administrators are allowed to restore mailboxes and database availability groups, create mailbox databases, and start and stop database availability groups in an organization if they are assigned the Disaster Recovery management role.
• Distribution Groups Role  – Administrators are allowed to create, modify, view, and remove distribution groups, and add or remove distribution group members in an organization if they are assigned the Distribution Groups management role.
• Edge Subscriptions Role – Administrators are allowed to manage edge synchronization and subscription configuration between Edge Transport servers and Hub Transport servers in an organization if they are assigned the Edge Subscriptions management role.
• E-Mail Address Policies Role – Administrators are allowed to manage e-mail address policies in an organization if they are assigned the E-Mail Address Policies management role.
• Exchange Connectors Role – Administrators are allowed to create, modify, view, and remove routing group connectors and delivery agent connectors if they are assigned the Exchange Connectors management role.
• Exchange Server Certificates Role – Administrators are allowed to create, import, export, and manage Exchange server certificates on individual servers if they are assigned the Exchange Server Certificates management role.
• Exchange Servers Role- Administrators are allowed to perform the following actions if they assigned the Exchange Servers management role.
  • Database availability groups can be added or removed.
  • Unified Messaging servers can be enabled or disabled.
  • Outlook Anywhere can be enabled or disabled.
  • Edit configurations of Hub Transport, Client Access, Mailbox and Unified Messaging server.
  • Edit Outlook Anywhere configuration.
  • Edit content filtering configuration on Hub Transport servers.
  • Edit general Exchange server configuration.
  • View the server role configuration.

In future posts I will discuss additional Exchange Server management roles.

List of Built-In Management Roles

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

When end users type in email addresses they sometimes make use of an Outlook auto-complete feature which fills in the extra characters of the email address for them. But where does this information come from? The answer is that the email address data is stored in a file that has “.nk2” as its filename extension. This file is also known as the nickname cache file.

End users can be typing in email addresses into the To: or Cc fields and at some point, after enough characters have been typed in, the email address will be automatically completed based on the data in the .nk2 file. This file is located in each user’s profile in the C:\Documents and Settings\someusername\Application Data\Microsoft\Outlook directory. This is normally a hidden directory. The file is called the (Outlook Profile) name.nk2.

The name.nk2 file is always updated with the most recent email address that the user has typed in. Subsequent use of the same email address will be auto completed based on the most recent name that was entered. The nickname cache is imported into a hidden message in the users default message store the first time that Outlook is started. Once the nickname cache has been imported then the profilename.nk2 file is renamed to profilename.nk2.old. Subsequent restarts of Outlook do not import the nickname cache file.

However, updates to the nickname cache are not performed on the profilename.nk2 file. Instead, updates are made to the hidden message in the default message store. Multiple Outlook profiles result in merging each of those cache files into a new Outlook nickname cache upon the first start of Outlook when that profile is used. This will result in multiple .nk2 files.

Sometimes an administrator will be asked to import a nickname cache file. An example of this is when someone wants to share their nickname cache so that another user does not have to type in all the email addresses contained within the other users’ cache. This can be very useful for employees who are working on large projects or when companies or small divisions are merged together.

If an administrator is going to import an .nk2 file then they must first confirm that the .nk2 file is in the %appdata%\Microsoft\Outlook folder. The current Outlook profile will be used as the name of the .nk2 file. The profile name, by default, is “Outlook”. An administrator can follow these steps to import an .nk2 file:

1. Click Start
2. Click Control Panel
3. Double click Mail
4. Click Show Profiles from the Mail Setup dialog box
5. Click Start
6. Click Run
7. Type “outlook.exe /importnk2” in the Open box
8. Click OK.

Once these steps have been completed then the appropriate .nk2 file will have been imported into the Outlook profile.
Sometimes the nickname cache gets corrupted. When this happens then Outlook is unable to identify recipients. It may produce incorrect recipient email addresses when it automatically completes the email address. Or, it may send messages to the wrong recipients.

An administrator can import a previous copy of the nickname cache in order to restore a corrupted copy of the cache. But an administrator can also choose to reset the nickname cache to fix the automatic completion mechanism in Outlook. If they are using Microsoft Exchange Server then the nickname cache is stored in a hidden message in their mailbox.

Here are the steps on how to remove nickname cache entries, one at a time when using Outlook 2010:

1. Create a new email message
2. Enter the first couple of characters of the nickname cache entry that will be removed from the cache
3. As soon as you see the entry in the “suggested names” list, highlight the name by moving the mouse pointer over it but do not click on it
4. An “X” icon will appear next to the highlighted name
5. Click the “X” icon and the name will be removed from the list.

If an administrator chooses to reset the entire nickname cache, in Outlook 2010, then they can follow these steps:

1. Click File (BackStage)
2. Click Options
3. Click the Mail tab
4. Click Empty Auto-Complete List shown below Send Messages.

The above actions will cause Outlook to generate a new nickname cache.

A much simple way to reset the nickname cache is to start Outlook with the “/CleanAutoCompleteCache” option. For example, at the command line issue the following command: Outlook.exe /CleanAutoCompleteCache.

Troubleshooting the Nickname Cache File

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

When working with Outlook folders administrators will often run into the question of how to manage the Outlook Secure Temp Folder. Sometimes users are not able to open the attachments that come with their emails specifically addressed to them. This problem can be very irritating especially to an end user who has been waiting for a very important email message.

For example, the CEO of your organization may be trying to open a PowerPoint presentation as an attachment to an email they received. And while there may be several window applications open already containing various Microsoft Office documents your CEO still cannot see his document in any of those PowerPoint windows.

One of the easiest assumptions to make as a possible cause of the problem is that this is a memory issue – specifically, a lack of memory issue. In this scenario, it may be recommended to the end user that they close out some of their applications and then try to open their attachment again. If this doesn’t help then a reboot of their system can be tried.

System administrators who have been around a while will most often have their own favorite set of performance monitoring tools. One tool that everyone has used at one time or another is the Windows performance monitor tool, “perfmon”. It can be launched by clicking the Start button, selecting Run, and then typing in “perfmon” on the command line. With this tool an administrator can monitor memory usage, disk storage and processor utilization.

Another place to look at is the storage area that Outlook uses for storage of temporary data. This storage area is known as the Secure Temporary File Folder. Outlook stores copies of attachments that are to be used by other applications.

During normal processing, Outlook will remove the temporary files after the application has closed and completed its processing of the attachments. But sometimes Outlook has to close or is shut down for some reason and the application(s) associated with the stored attachment files are still up and running. Under this condition Outlook may not release the contents of its temporary file folder. The fact that Outlook has closed and has not cleaned out its temporary file folder is not a problem. The problem occurs when the number of files in the folder exceeds a count of ninety-nine (99).

Unfortunately, the number of files that Outlook can store in the temporary file folder using the same name is limited. When Outlook closes and leaves files in the temporary file folder those files become “orphaned” files if their source attachment has the same name. Even if the attachment to the email message has been opened from the Preview pane, and Outlook is exited, a user will not receive a prompt to save any changes.
If there are ninety-nine such “orphaned” files in the temporary file folder then upon opening the one-hundredth file and error message will be generated indicating that the associated attachment cannot be opened.

The error message will look similar to the following:

“Can’t create file: (filename.doc). Right click the folder you want to create the file in and then click properties on the shortcut menu to check your permissions for the folder”

As an example, if an end user receives a report document every day, such as “Sales.doc”, and the end user exits out of Outlook each day, before they close the attachment document, then after ninety-nine days there will be ninety-nine copies of “Sales.doc” in the temporary file folder. Then, on the one-hundredth day, an error message will be generated when the end user attempts to open that same named document. An administrator can correct this situation by deleting all files, in the secure temporary file folder, that have the same name.

When Outlook 2010 first tries to use a temporary file, it examines the registry to determine whether the following value exists.

HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Security

or

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\Security
Value Name: OutlookSecureTempFolder
Data Type: REG_SZ

If the value exists, and the path is a valid path, then Outlook 2010 will use that location for its temporary files. If the registry value does not exist or references an invalid path then Outlook 2010 will create a new subdirectory under the Temporary Internet Files directory to be used for storing temporary files. The newly created subdirectory name is randomly generated and thus is unknown.

An administrator can find this newly created subdirectory by following the steps below.

1. Click on the Start button.
2. Select Run.
3. Type the following command, “C:\Documents and Settings\ username \Local Settings\Temporary Internet Files\Content.Outlook”
4. Click OK.
5. Open the subfolder (or subfolders) under the Content.Outlook folder. (Look for a folder name that consists of a sequence of letter and numbers such as DR1C8HID.)

Troubleshooting Outlook Secure Temp Folder

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In his article, “Cross Org Availability using Federation Trust and Organization Relationship”, Ben Winzenz discusses some of the issues that can occur when organizations need to share Exchange server availability status with other Exchange organizations.

He notes that there are multiple ways to enable the sharing of availability status. Some of those scenarios include:

1. Exchange server is running in both organizations.
2. Different versions of Exchange server is running in the organizations.
3. Multiple Exchange servers are running in the organizations.

The requirements to support the sharing of the availability status are explained very well, and the author explains some problems and issues that can occur with the sharing of the availability status.

There are other scenarios related to availability in an Exchange Server/Outlook environment that are also of interest to email administrators. For example, one of the scenarios not fully explored, but yet still related to availability, is the Free/Busy status feature of Outlook.

The Internet Free/Busy status is a feature of Microsoft Outlook that allows end users to check on the availability status of their peers and co-workers. Using the feature, an end-user can check the calendar schedule of their co-workers in order to schedule meetings and avoid schedule conflicts. End-users are able to self-publish their Free/Busy status via a user-specified Uniform Resource Locator (URL) file server and to share this URL file server with their co-workers.

However, there are some issues related to the Free/Busy feature which administrators may encounter after migrating to Exchange Server 2010.

One of those issues occurs when end users are unable to publish their Free/Busy status in Exchange Server 2010. When this error occurs their availability will appear as a series of hash marks. If administrators view the error log they will see the following event ID:

Event ID : 8207
Category : General
Source : MSExchangeFBPublish
Type : Error
Message : Error updating public folder with free/busy information on virtual machine  (ExchangeServerName). The error number is 0×80004005

An administrator can attempt to clear and regenerate the Free/Busy information on the system running Outlook by executing a command with a path similar to the following:

C:\Program Files\Microsoft Office\Outlook.exe /cleanfreebusy

If you recently migrated to Exchange Server 2010 or have a newly installed Exchange Server 2010 environment, then you may receive an error message such as: “Unable to clean your freebusy information”.

This can happen if the Exchange Server 2010 organization does not contain replicas of any Free/Busy folders.

Administrators can correct this problem with the following steps:

1. Run the following command in the Exchange Management Shell: get-publicfolder -Identity “\NON_IPM_SUBTREE\SCHEDULE+ FREE BUSY” -Recurse | fl name,Replicas
2. Next, run this command: set-publicfolder -Identity “\NON_IPM_SUBTREE\SCHEDULE+ FREE BUSY\<Name of Folder>” -replicas “<Target PF Database>”
3. View the public folder group and confirm that it contain a replica as defined in step one.

In a post-migration situation, there can be problems if the old server still contains the “Schedule + Free Busy” information and the Exchange server administrator has not replicated the information to the new server. If the old server has not yet been taken offline – and is still up and running while the newly migrated server is also up and running – then the new server will function correctly except for the free/busy information component. This situation can also occur if the “Schedule+Free/Busy” system folder has become corrupted.

If the replicas have already been migrated and contain valid data then errors associated with the Free/Busy state may simply be related to the user not having published their information correctly or not at all.

Administrators may need to remind or inform their end-user community how to publish their Free/Busy Information to the Internet using Microsoft Outlook 2010 by sending a note to end users that has the following instructions:

1. Open the File tab to display the File menu.
2. Click Options.
3. Open the Calendar tab and choose Free/Busy Options.
4. Open the Permissions tab and select “Other Free/Busy”.
5. In the Internet Free/Busy section place a checkmark in the “Publish at My Location” check box.
6. Type the fully qualified pathname of the server that you will use to publish your Free/Busy Information. (Examples of valid URL format names include:  http://somedomain.com/, file://\\somedomain.com, or ftp://somedomain.com.)

Note that Free/Busy files use the .vfb file name extension. A valid URL format is:

ftp://Someserver/Freebusy/Somename.vfb

Free/Busy Outlook Feature

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

As more and more organizations move to Outlook 2010 they will have many discussions surrounding how to secure their email. They are probably already using certificates to secure their email communications with digital signatures. Setting up secure email can be a complex task and involve multiple decisions. Sometimes, it is almost better to remind users to simply put only content into their emails that would not cause them to lose any sleep at night should those contents be posted on the internet somewhere.

Among the many decisions to be made will be deciding which Certificate Authorities to use. Other decisions can include: whether self-signed certificates are allowed or what are the archival policies of your organization as they relate to the archival of received certificates, etc. One of the primary decisions your organization will have to make is how to configure the security settings in Outlook. You will want those security settings to match the organization’s security policies.

There are many cryptography settings in Outlook 2010 that an administrator can control. By using the Outlook 2010 Group Policy template, an organization can configure the settings for secure messaging and message encryption to match the security policies of their organization. For instance, all outgoing email communications could be configured to include a security label to indicate a confidentiality level. Email intended to be sent to a global address list could also be blocked based on the security settings that are configured. The Office Customization Tool (OCT) can be used to configure the default security settings for your organization.

With that in mind, here is a list of security policies that can be configured for cryptography using the OCT. The specific settings can be found in Microsoft Outlook 2010\Security\Cryptography. These settings can also be found in User Configuration\Administrative Templates\Microsoft Outlook 2010\Security\Cryptography for Group Policy.

1. All outgoing email messages should be encryption enabled.
2. A message should be entered that will be displayed to end users when Outlook cannot obtain the digital ID that will allow a message to be decoded.
3. A list of policies that are allowed in the policies extension of a certificate should be entered for the Fortezza certification policy cryptographic extension. Semicolons should be used to separate the policy list.
4. Your organization’s policies should impose their own format policy for S/MIME messages. For instance, the transport neutral encapsulation format (TNEF) should be used for all S/MIME messages.
5. Do not allow end users to get access to the “Publish to GAL” button. GAL is the acronym for the Global Address List. This button allows users to publish certificates to their organization’s directory. Unfortunately, these certificates can be obtained from anywhere outside of your organization and are, thus, not part of your organization’s normal digital certificate review process.
6. All S/MIME-signed email messages should have a security label attached to them. Users can add a digital signature to their email messages by selecting a security label by opening the Security Properties dialog box from the Security Settings option.
7. There are different methods to use when verifying a user’s email address. One method is to simply send an email to the originator of the email and wait for a response. But what you don’t want to do is to verify the user’s email address based on the address of the certificate used for encryption.
8. The Message formats option should be set to the Fortezza format, the S/MIME format or a combination of the two.
9. All outgoing email messages should be required to have digital signatures.
10. Administrators should configure Outlook user interface to display the cryptography icons.
11. The minimum key length for an encrypted email message should be set. Having the minimum key length specified will trigger a warning message to the user when they try to send a message that has a key length less than the minimum setting. The warning message can still be ignored by the end user if they choose to still send their email message.
12. Administrators should disable the “Continue” button as part of the normal Encryption warning dialog process. This button pops up when a user tries to send a message to someone who is not allowed to receive encrypted messages.
13. A security-enhanced receipt should be requested for all outgoing signed email messages.
14. All signed email messages should be sent in clear text.

List of Cryptography Policies for Outlook

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In Nino Bilic’s article, “help-us-understand-how-you-manage-your-discovery-mailboxes”, he asks for feedback from system administrators regarding how they manage their Exchange discovery mailboxes. 

Among the questions he asks are:

1. What type of management tasks are performed on discovery mailboxes?
2. Do system administrators need to manage the access permissions?
3. Do system administrators need to change quotas or rest passwords?
4. How often are these management tasks performed? Quarterly? Monthly?
5. What tools are used to manage discovery mailboxes?

When discussing the discovery mailbox it is worth noting that the discovery mailbox, by default, is created by the Exchange Server 2010 setup process. The intent of having a discovery mailbox is to allow system administrators  to perform discovery searches on these target mailboxes. One of the tools available for system administrators to use is the Exchange Control Panel.

If additional discovery mailboxes are needed, then system administrators can create them based on the organization’s requirements. Unfortunately, discovery mailboxes cannot be used for other purposes. Additionally they cannot be migrated to support other types of mailboxes. But system administrators can use the same process for removal or deletion of discovery mailboxes as is used for other mailboxes

Administrators must be aware of the contents of the discovery mailboxes once the mailboxes have been populated. Most likely they will contain sensitive information that can find its way into courtrooms or, at the very least, used within law firms to help prepare their cases. The point is that these mailboxes should be treated as vulnerable points of any organization or company. Secure access to the mailboxes should be high up on the priority list for all administrators in control of these discovery mailboxes.

Fortunately, Exchange Server 2010 allows administrators to assign the multi-mailbox search tasks to end users without having to give them system administrator privileges. Multi-Mailbox searches are fast and light-weight in their use of system resources because they use the same index catalog as created by the Exchange Search engine.

By assigning the multi-mailbox search tasks to end users administrators have less to worry about in terms of security. They do not have to worry about end users making unauthorized changes to the Exchange server configuration as they would have if they had assigned full system administrator privileges instead.

End users can be granted Multi-Mailbox search capabilities by being assigned the Role Based Access Control (RBAC) permission. This permission allows end users the ability to perform Multi-Mailbox search operations as needed.

The Multi-Mailbox search uses the same index catalog as is created by the Exchange Search engine. Thus it is faster and at the same time less demanding on resources. All you have to do is to assign the RBAC permission to the user who needs to carry out the Multi-Mailbox search operation.

The discovery management RBAC role group is allowed to perform two operations: Multi-Mailbox search and Legal Hold. Members of the discovery management RBAC can perform Multi-Mailbox searches within their organization and can also set the status of any mailbox to that of Legal Hold status. By default, there are no members who belong to the discovery management role group.

Administrators can give the discovery management RBAC permission to an end user with the following command:

Add-RoleGroupMember -Identity “Discovery Management” -Member User

The discovery mailbox has an associated Active Directory user account. It is disabled by default. If a discovery mailbox is removed then all search results contained in the mailbox are removed. The default storage quota size for all discovery mailboxes is 50GB. However, if more storage is needed then an administrator can increase the storage quota size.

New discovery mailboxes can be created using the “New-Mailbox” command. For example, to create a new discovery mailbox named “Discovery_Mailbox-1”, run the following command:

New-Mailbox “Discovery_Mailbox-1” –Discovery –UserPrincipalName discovery_mailbox-1@mydomain.com

Administrators who are new to an organization will find it useful to get a list of all discovery mailboxes on the system. They can get the list by running the following command:

Get-Mailbox -Filter { RecipientTypeDetails -eq “DiscoveryMailbox” }

Discovery mailboxes are useful to organizations that are subject to legal discoveries. They can also be used for auditing purposes or for personnel matters that involve the Human Resources department. As many discovery mailboxes that are needed can be created for an organization. Once created, discovery mailboxes cannot be used to receive emails from end users as there are multiple delivery restrictions that are placed on discovery mailboxes. And although they cannot receive email messages they are visible in Exchange address lists.

Discovery Mailboxes

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Installing software is always an activity that administrators must allocate extra time to in order to prepare for the unexpected problems that can occur. And of course there is the time that must be allocated to handle the prerequisites.

If Exchange Server is being installed on a global catalog server then there is the possibility that not all of the services will start upon initialization. If this happens then an administrator can manually start some of the services. This situation may result in the shutdown process taking more time than if the services had been started automatically. Administrators can review the log files for the following error messages:
Event ID : 1005
Source : MSExchangeSA
Category : General
Type : Error
Description : Unexpected error The Local Security Authority cannot be contacted ID no: 80090304 Microsoft Exchange System Attendant occurred.

Event ID: 1121
Source: MSExchangeIS
Category: General
Type: Error
Description: Error 0x96e connecting to the Microsoft Active Directory.

Event ID: 2601
Source: MSExchange ADAccess
Category: General
Type: Warning
Description: Process MSEXCHANGEADTOPOLOGY (PID=1624). When initializing a remote procedure call (RPC) to the Microsoft Exchange Active Directory Topology service, Exchange could not retrieve the SID for account <WKGUID=DC1301662F547445B9C490A52961F8FC,CN=Microsoft Exchange,CN=Services,CN=Configuration,…> – Error code=80040934. The Microsoft Exchange Active Directory Topology service will continue starting with limited permissions.

Event ID: 5000
Source: MSExchangeIS
Category: General
Type: Error
Description: Unable to initialize the Microsoft Exchange Information Store service. – Error 0x96e.

These error messages are generated when Exchange Server attempts to start but the Exchange Server dependent services and the domain controller do not completely start up. At this point an administrator will receive messages indicating that there was a problem with the Exchange Server startup process. Administrators can check their monitoring application to confirm whether the services are running or not. It is still possible for an administrator to manually start up the appropriate Exchange Server processes.

In addition to manually restarting the services, administrators can also change the dependencies to circumvent the problematic services. For example, the Netlogon service and the LSASS service are not needed by Exchanger Server services. Such services and their dependencies include:

Another alternate solution is to set the Microsoft Exchange system attendant and other services to restart automatically. Fortunately, all of the services can be set to restart automatically. And they can be set so that they continuously restart on their own until they are eventually started up. During this time, error messages will continue to be generated. Understand that this procedure is just a workaround but will support a successful startup of the Exchange Server.

After the installation of Exchange Server comes the installation of the Update Rollups. If during the install of Update Rollup 2 you receive a 1063 error message then it is most likely that the install failed. An administrator can create an installation log by using the following Setup Program switch:
Exchange2010-Rollup1KB976573-x64-en.msp /lvx c:\logFilePath\InstallationLogFile.log

The installation log file will most likely contain messages similar to the following:
////////////
MSI (s) (60:74) [Timestamp]: Doing action: CA_START_REMOVEDATA_SERVICES
Action start Time: CA_START_REMOVEDATA_SERVICES.
MSI (s) (60:74) [Timestamp]: Transforming table CustomAction.
MSI (s) (60:74) [Timestamp]: Transforming table CustomAction.
MSI (s) (60:74) [Timestamp]: Note: 1: 2262 2: CustomAction 3: -2147287038
MSI (s) (60:74) [Timestamp]: Note: 1: 2235 2: 3: ExtendedType 4: SELECT `Action`,`Type`,`Source`,`Target`, NULL, `ExtendedType` FROM `CustomAction` WHERE `Action` = ‘CA_START_REMOVEDATA_SERVICES’
MSI (s) (60:74) [Timestamp]: Transforming table CustomAction.
MSI (s) (60:74) [Timestamp]: Transforming table CustomAction.
MSI (s) (60:74) [Timestamp]: Note: 1: 2262 2: CustomAction 3: -2147287038
.
. (Lot’s of messages deleted here in the interest of space.)
.
MSI (s) (60:74) [Timestamp]: Transforming table InstallExecuteSequence.
MSI (s) (60:74) [Timestamp]: Transforming table InstallExecuteSequence.
MSI (s) (60:74) [Timestamp]: Note: 1: 2262 2: InstallExecuteSequence 3: -2147287038
Action ended Time: INSTALL. Return value 3.
////////////

These error messages are generated when the Group Policy Object (GPO), ExecutionPolicy, defines one or both of the following policies: the MachinePolicy and/or the UserPolicy. Just the mere fact that one or both of these policies are defined can cause the series of error messages to be generated. Administrators can stop these error messages from being generated by simply deleting any definition of the MachinePolicy and UserPolicy in the ExecutionPolicy. Use the Microsoft Management Console (MMC) to make these changes.

Troubleshooting Installation of Exchange Server

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Many times users will report that they are unable to access their email mailboxes. This can cause a lot of problems not only for the end users but to the organization in general. At a minimum, not being able to access email can results in frustrations and loss of productivity but from a wider viewpoint this can lead to loss of revenue to the organization and especially to one focused on sales.

There are many reasons for email to become inaccessible. The usual suspects are either the network connections or the email server. If, after troubleshooting the network and the server hardware, an administrator finds that neither are the source of the problem then it is time to drill down into the soft internals of the Exchange server.

In the case where mailboxes are inaccessible after a migration, an administrator should review the configurations of the mailboxes. If an Exchange mailbox has been migrated to a managed environment then an administrator can review the configurations of the mailboxes by using the following steps:

1. Confirm that the source primary Simple Mail Transport Protocol (SMTP) address is the same as the managed primary SMTP address.
2. Confirm that the source primary SMTP address is the same as the managed primary SMTP address.
3. Confirm that the source target address has been specified as a proxy address on the destination object. Additionally the source target address should refer to the correct managed domain name.
4. Confirm that the managed mailbox does not have a target address that is listed. An administrator can use the ADSI Edit or LDP to search for the managed mailbox and check the targetAddress attribute.
5. Confirm that the source object is not specified as a mailbox. Also check that it does not have a HomeMDB or HomeMTA attribute.

If all of the above steps are completed successfully and the problem was with a user mailbox, then an administrator should confirm that the managed mailbox is specified as a linkedmailbox. They should also confirm that the linkedmasteraccount field lists the correct domain.

If all of the above steps are completed successfully but the problem was with a shared mailbox then an administrator should confirm that the user is listed explicitly and has full mailbox access.

An administrator can also test MAPI connectivity access by running the following command using Exchange Management Shell (EMS): test-mapiconnectivity <alias>.

As part of the troubleshooting process it always best to grant “Full Access” permission for a mailbox or “Receive As” permission for a mailbox database. “Full Access” permission is given to the user on a specific mailbox. Once they have “Full Access” permission then a user can open and read the contents of only that particular mailbox.

When using Exchange 2010 Service Pack 1 (SP1), Outlook 2007 and Outlook 2010 clients are automatically mapped to any mailbox that a user has been granted Full Access permission to use. There is an autodiscover feature that loads all mailboxes for a user that has been granted full access to, including shared mailboxes. This is one area that administrators need to watch as a potential cause of overloading the server. If overloading of the server occurs then performance will suffer. Most often, administrators are granted full access to all the mailboxes in the system. This can lead to overloading of the server when Outlook attempts to open all the mailboxes at startup time.

Another possible reason for inaccessible mailboxes is when some users have multiple mailboxes on the same system where Exchange server is running. In this case, users do not have to log on to each separate account to gain access to all of their Outlook accounts.

They may find that they can read their mail but are unable to send mail from their account. In this case it is most likely that the user permission to access the mailbox has been set to “Receive As” permission. “Read As” permission will allow a user to still log on to their mailbox and review their email messages but they won’t be able to send email. If this is the situation then an administrator will have to set their permission on the mailbox to “Full Access” for the end user to be able to send email. Remember to stop and then restart the Exchange Information Store service to allow immediate access.

Troubleshooting Access to Mailboxes

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Exchange Server uses several components and processes to route email messages from outside the organization through the internals of an Exchange Server transport pipeline. Many of the components and processes include: SMTP Receive, Submission, Categorizer, Local Delivery and SMTP Send.

A couple of ways that email messages can enter the transport pipeline include through a receive connector or via the pickup directory. Messages may also be placed in the submission queue by the store driver. One action that is always performed is the categorizing of the received email message. After categorizing the message, the message is placed in a delivery queue to await delivery to a mailbox or for routing to a recipient on another server maybe within a different company.

Queues are used to hold messages or data that needs further processing before reaching their final destination. Each queue of messages is processed based on its location in the transport pipeline. The transport system holds messages inside memory queues for processing. If the transport service goes down then the contents of the memory queues are “committed” to the database so as not to lose any data. These transport queues should be monitored in order to establish a baseline of activity and performance levels. If there is a problem with processing any of the messages then the messages will stay inside the queue until the problem is resolved. An administrator can use the Queue Viewer (Exchange Management Console) to correct any problems with the queues.

Exchange server contains five types of queues: submission queue, mailbox delivery queue, remote delivery queue, poison message queue, and the unreachable queue. Message data that are being processed can be found inside these queues.  Here are the details about these queues:

• Submission Queue – This queue is the first queue to receive messages for further processing. The categorizer stores the messages in this queue for actions to be taken by the Transport agents. Messages from the SMTP receive; pickup directory and store driver can also be placed in the queue. There are multiple submission queues to support the number of transport servers that are running. Messages in the submission queue are exclusive and are not existent in other queues.
• Mailbox Delivery Queue – This queue contains messages that are waiting to be delivered to a mailbox server within the same server location. Only the Hub server has mailbox delivery queues. A Hub server can have multiple mailbox delivery queues whereas only one submission queue exists on a transport server.
• Remote Delivery Queue – This queue holds messages temporarily while they are being routed to remote servers using SMTP.  The remote server destinations can be external domains, SMTP connectors or destinations outside the scope of the AD site where the Hub server is located. Hub and Edge servers may have multiple remote delivery queues. Queues are automatically created and when there are no messages in the queues – for three minutes – then the queues are deleted.
• Poison Message Queue – This queue contains messages that have been determined to have problems in an Exchange environment after a server failure. The messages in this queue have a suspended status and can no longer be processed although they can still be manually deleted by an administrator. An administrator can also decide that a message in this queue can still be processed. If there are no messages in this queue then the queue will not be viewable through the queue viewer or by using the get-queue command. One poison message queue is on each transport server.
• Undeliverable Queue – This queue contains messages that cannot be routed to their intended destinations. One undeliverable queue is on each transport server. Dropped connections or unavailable mail servers can result in email messages ending up in this queue.

Some of the management activities that an administrator can perform using the queue viewer include:

1. Change the location of the Queue database – An administrator can change the location of the queue database of the queue database transaction logs
2. Filter queue – The Queue Viewer or the Exchange Management Shell can be used to filter queues on a server that has the Exchange Server 2010 Hub Transport server role or the Edge Transport server role installed. An administrator can create detailed filters based on specific criteria that can then be used to discover highly problematic mail flow issues. Administrators can also perform actions that result in different status messages for the queues.
3. Suspend queue – Disable the delivery of currently queued messages.
4. Resume queue – Enable the queue for further processing.
5. View queue – An administrator can view queues that are running on systems that have the Microsoft Exchange Server 2010 Hub Transport server role or the Edge Transport server role installed.
6. Retry queue – Override a retry timer that was set because of a failed connection attempt to the next hop. The override enables the connection to be made to the next hop.
7. Filter message in queue – The Queue Viewer or the Exchange Management Shell can be used to filter messages in the queues on a system that has the Exchange Server 2010 Hub Transport server role or the Edge Transport server role installed. An administrator can adjust their search to zero in on messages that may be causing mail flow problems. Operations can then be performed to alter the status of the message.
8. Suspend message – Temporarily stop delivery of a message.
9. Resume message – Resume delivery of a suspended message.
10. Remove message – A message is permanently deleted from a queue. Messages can be deleted with or without notifications sent to the sender of the message.
11. Export message – Make a copy of the message and store it on the disk drive. An administrator must first suspend the message before exporting it.

Administrators should be aware of the fact that the list of queues can be very large, depending on current mail flow. The list of queues may also be different based on how often messages arrive and leave the server.

List of Management Tasks for Transport Queues

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In his article, “Exchange 2010 Mailbox Moves and Mailbox Resiliency”, Ross Smith discusses certain data loss scenarios that can exist even though Exchange Server 2010 includes continuous replication block mode. Continuous replication block mode was added to Exchange Server 2010 to provide greater protection from mailbox data losses.

Ross Smith specifically describes scenarios that result from a high logging generation rate environment. These scenarios often occur during mailbox move operations. One example given is when a mailbox has been moved from an active database to a second passive database. Then, right after the move, the server hosting the primary (or active) database fails. As a result of the primary server failure, the second database is then activated. But because the “AttemptCopyLastLogs” operation is unable to complete, the recently copied mailbox will not have a complete copy of the pre-move mailbox.

He then further discusses the Data Guarantee API and some of the API calls that can be used to help maintain and ensure successful mailbox move operations. Some of the calls mentioned include:  Check Replication Health and Check Replication Flush.

The Mailbox Replication service (MRS) is a service that administrators can monitor with the Data Guarantee API. The MRS is located on the Exchange 2010 Client Access server and is the service that actually does the work of moving mailboxes from one database to another. The mailbox moves are initiated using move request cmdlets. The specific cmdlet used to move mailboxes is known as the “Move-Mailbox” cmdlet.

The benefit of using the MRS to move mailboxes is that the mailboxes are still available to end users even while the mailboxes are being moved. Administrators can view, start or stop, cancel and manage the active move mailbox requests from any Exchange 2010 server. The mailbox replication service is also responsible for importing and exporting .pst files, and restoring disabled and soft-deleted mailboxes. All move requests in the Active Directory site are constantly monitored by the replication service. All instances of MRS use a sharing mechanism that prevents simultaneous move requests from being executed.

Additionally, there is a MRS throttling mechanism which can be used to adjust the parameter settings that control the mailbox replication service. Adjusting these settings allows an administrator to affect the performance service. Even though all MRS instances are aware of the tasks of other MRS instances, they each have their own configuration settings. An administrator can adjust the MRS settings of the MSExchangeMailboxReplication.exe.config file that, by default, is located in the same folder that Exchange server is located: <Exchange Installation Path>\Program Files\Microsoft\Exchange Server\V14\Bin\MSExchangeMailboxReplication.exe.config. The configuration file can be found on all Client Access servers.

Typical MRS settings may look like:

<MRSConfiguration
MaxRetries = “50″
MaxCleanupRetries = “5″
MaxStallRetryPeriod = “00:15:00″
RetryDelay = “00:00:30″
MaxMoveHistoryLength = “2″
MaxActiveMovesPerSourceMDB = “7″
MaxActiveMovesPerTargetMDB = “2″
MaxActiveMovesPerSourceServer = “40″
MaxActiveMovesPerTargetServer = “4″
MaxTotalMovesPerMRS = “100″
FullScanMoveJobsPollingPeriod = “00:10:00″
MinimumTimeBeforePickingJobsFromSameDatabase = “00:00:04″
ServerCountsNotOlderThan = “00:10:00″
MRSAbandonedMoveJobDetectionTime = “01:00:00″
BackoffIntervalForProxyConnectionLimitReached = “00:30:00″
DataGuaranteeCheckPeriod = “00:00:10″
DataGuaranteeTimeout = “00:30:00″
DataGuaranteeLogRollDelay = “00:01:00″
EnableDataGuaranteeCheck = “true”
DisableMrsProxyCompression = “false”
DisableMrsProxyBuffering = “false”
MinBatchSize = “100″
MinBatchSizeKB = “256″ />
</configuration>

Here is a brief description for some of those configuration settings:

• MaxRetries: This setting controls the maximum number of times MRS will attempt to perform a task after a transient failure has occurred. The values range from 0 through 1000. The default value is 60.
• MaxCleanupRetries: This setting controls the number of times that MRS should attempt to clean up a task. If the maximum number of attempts is reached, the task fails. The values range from 0 through 100. The default value is 5.
• RetryDelay: This setting controls the amount of time MRS will wait before it retries a task after a transient failure. The values range from 00:00:10 (10 seconds) through 00:30:00 (30 minutes). The default value is 00:00:30 (30 seconds).
• MaxTotalMovesPerMRS: This setting controls how many “move requests” can be processed by a single CAS system.  The values range from 0 to 1024. The default value is 100.
• MaxActiveMovesPerSourceServer: This setting controls the maximum number of move requests that are allowed per source server. The values range from 0 to 1000. The default value is 50.
• MaxActiveMovesPerTargetServer: This setting controls the maximum number of move requests per target server. The values range from 0 to 1000. The default value is 5.
• MaxActiveMovesPerSourceMDB: This setting controls the maximum number of move requests per source mailbox database. The values range from 0 to 100. The default value is 5.
• FullScanMoveJobsPollingPeriod: This setting controls how often each instance of MRS scans for new tasks. The values range from 00:03:00 (3 minutes) through 1.00:00:00 (1 day). The default value is 00:10:00 (10 minutes).

Any changes made to the MSExchangeMailboxReplication.exe.config file should also be made on all other Client Access servers. Only experienced administrators should make changes to the configuration file. As always, keep track of all changes made to the configuration file.

Mailbox Replication Service

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Remote Procedure Calls (RPCs) are a communication technology that allows clients and servers to communicate with one another via inter-process requests and responses. RPC technology has been around since the mid-70s and is now widely incorporated into most operating systems.

A client will send a request to a remote server asking for a specific command or procedure to be executed on that server. The client waits for a response from the server before it continues with its own processing. The benefit of such inter-process communications is that commands and procedures can be executed on remote servers and then their results sent back to the remote clients for further processing. Additionally, developers do not have to worry about developing new security functions or flow control methods for their client applications as they can simply use a common set of routines.

In the world of Outlook and Exchange, RPC over HTTP/s is a technology which can be used for connecting Outlook clients to the organization’s Exchange server. Using RPC technology, Outlook clients can retrieve email without having to worry about the underlying protocol stacks such as: TCP/IP, NetBIOS over TCP/IP and IPX/SX.

RPC over HTTP/s can be used across the Internet, or across a corporate WAN, and thus make it easier for clients to access their email from remote locations. Administrators only need to open TCP ports 80 – and 443 for SSL – on the firewall to facilitate communications.

Some of the error messages that can be generated when an Outlook client attempts to connect to a server either through a remote procedure call (RPC) or through secure HTTP (HTTP/S)  include the following:

“There is a problem with the proxy server’s security certificate. Outlook is unable to connect to this server.”

“There is a problem with the proxy server’s security certificate. The name on the security certificate is invalid or does not match the name of the site. Outlook is unable to connect to this server.”

“There is a problem with the proxy server’s security certificate. The security certificate is not from a trusted certifying authority. Outlook is unable to connect to this server.”

These error messages are usually an indication of one or more of the following situations:

1. A certificate authority (CA) is required to make a connection to the server.
2. The certificate supplied is invalid.
3. The certificate supplied has been revoked.
4. The certificate authority has not been trusted.
5. The name of the site on the certificate is not a match.

To correct these problems an administrator can perform the following actions:

1. Review the certificate and make the necessary corrections.
2. Install the trusted root certificate.

When reviewing the certificate, an administrator should verify that the dates in the “Valid to” fields are valid for the current usage. Administrators should also verify that the data in the Subject field matches the site name.

There are other RPC related error messages that can be generated besides the ones listed above. Sometimes the sources of the problems can be found within the registry. More specifically, the problems are due to what is “not” in the registry.

The registry contains values – or should contain values – that are required by Outlook to make connections to Exchange Server when using RPC. Those values include:

Subkey and data values must be defined and entered correctly or else Outlook will not be able to make the RPC connections to the Exchange Server.

On the Exchange Server side, it too must also have RPC registry entries. Without these entries the server cannot respond to client requests – basically the Exchange services have not been registered.

Administrators can use the RPC Dump tool to troubleshoot any problems related to RPC issues. For instance, the RPC Dump tool can be used to identify protocols that clients can use to make their connections with the Exchange Server. The RPC Dump tool can also be used to show which RPC applications are running on the server.

Another tool that administrators can use to troubleshoot RPC related issues is the Network Monitor tool. Administrators can use the Network Monitor tool to capture RPC traffic from the client to the server. Then, by reviewing the trace data they can identify potential reasons for RPC communication errors such as:

• Non-existent RPC data. This could indicate a missing RPC subkey. Or maybe a missing entry.
• Missing registry values. For instance, a missing “ncacn_ip_tcp” registry value in the ClientProtocols registry subkey can result in the Microsoft Exchange Information Store service not being available.

Troubleshooting Outlook RPC Connections

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Communications between computer systems can occur synchronously or asynchronously. Some of the benefits of asynchronous communications are that they are faster, can run over lower bandwidth technologies and require less maintenance of the connection.

But when a more reliable connection is needed then synchronous communications are used. Such synchronous communications include Remote Procedure Calls (RPC) and the Distributed Component Object Model (DCOM). But because there is more hand shaking going on with synchronous communications it is generally not as fast as asynchronous communications. An alternative solution for email communications is to use an asynchronous programming model such as Message Queuing.

Microsoft Message Queuing (MSMQ) operations provide several messaging features including: authentication, encryption, dead-letter queues, security, and other basic features. If any of these features have problems then Message Queuing operations in general will also have problems.

Microsoft Message Queuing works very well in a distributed environment made up of a variety of applications. Applications running on different systems can communicate across the network and communicate with systems that are not online at the moment. The technology uses queues for the storing of data. The message queues are used by a message service to forward the data onto another queue. Then a “receiver” application pulls the data from the second queue. At this point the data is then processed. The technology is facilitated by multiple sending and receiving applications.

One of the benefits of using message queues is that communication is not broken even though systems may be down for short periods of time. Messages in the queues are not lost even though a system, or systems, is unable to receive communications. Client applications send their message data and then are free to continue their own processing independent of any problems between systems. Once a server queue becomes available then the message queue service on the client can forward the message data to the server queue for processing by the receiver application. This technology is known as a store and forward technology.

However, it is not without occasional errors. Sometimes the communication operations will result in MSEXchangeRepl error messages on the Exchange Server such as the following:

Source: MSExchangeRepl
Event ID: 2163
Task Category: Service
Level: Error
Description:
The log copier for database ‘DB’ received an error from the source server ‘server’: File ‘Drive:\Logs\#######.log’ could not be opened. The process cannot access the file because it is being used by another process. The copier will automatically retry after a short delay.

This error can occur when a log from a source has not yet been closed or flushed and the log copier component is trying to copy it. The log has to be closed for the copy operation to succeed. The event is generated because new log files are being polled instead of waiting for the source logs to complete their close-flush-notify operation.

Administrators should note that Event ID 2163, whose source is MSExchangeRepl, is not a cause for concern as per Microsoft web site and can be ignored.

As mentioned earlier if there are problems with any of the features of Message Queuing then there will be problems in general. More troublesome issues can result in failure such as is shown in this event description for Event ID 2163:

Product:     Windows Operating System
ID:     2163
Source:     MSMQ
Version:     6.0
Symbolic Name:     QM_SERVICE_STOPPED
Message:     The Message Queuing service stopped.

Note that the source for this event is the MSMQ service itself. There are several reasons for the Message Queuing service to stop. The best place to look for what may be the cause of this failure is to check the event logs. There may be an issue with the start up of the service which can result in the failure message. Once those issues have been identified and fixed then the MSMQ service will need to be restarted.

Administrator privilege is required in order to restart the service. The MSMQ service can be restarted with the following steps:

1. Open the Services snap-in.
2. Click Start.
3. Type services.msc in the search box.
4. Press Enter.
5. Right-click Message Queuing.
6. Click Restart.

Note that all dependent services must also be restarted.

Lastly, an administrator should verify that the MSMQ Service is installed and running. As with the procedure to restart Message Queuing, the operator will need Administrator privileges or an appropriate authority level.

A successful restart of the MSMQ Service can be performed using the following steps:

1. Open the Services snap-in.
2. Click Start.
3. Type services.msc in the search box.
4. Press Enter.
5. Locate the Message Queuing service.
6. The value in the Status column should be displayed as Started.

Troubleshooting Message Queuing

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Everyone knows that without an active practice of management in place that our lives and every facet of our businesses can result in a chaotic existence. We need to manage our checking accounts, our income and expenses, the food we eat, the amount of paperwork we keep, etc.

The same concept of management applies to our email systems. We need to implement a usage and accounting email system to track and report how much of our computer resources are being consumed so that we can properly bill out to the various departments we support in our organizations.

Administrators also need to monitor the flow of emails that are incoming and outgoing from their systems so as to create trending reports and to project when systems will become overloaded. Trending and analysis of email communications make it easier for administrators to request additional resources from their IT departments in terms of bringing newer and larger systems online. It may be that those resources are physical in nature or that the newly requested resources are virtual resources. The point is that, without monitoring and managing their systems resource usage and having the corresponding reports to support their trend analysis, administrators will have a tougher time in asking for upgrades or more system resources.

Managing your email systems also involves the practice of archiving an organization’s email messages so that they can easily be recalled at a later date when needed.

Here are five benefits of Email Management:

1. Reduced Litigation Costs
   It is a given that companies and organizations should have some methodology for storing old email messages. An email archiving system should be able to captures every email, – along with their attachments – that comes into or out of an organization. A complete archiving solution would also include some capacity for scanning and indexing of email messages. Indexes should, at the very least, be based on: who the sender is, who is the recipient, the message content, attachments, metadata, etc. and classified according to results. Because all email is preserved in the archive in its original form (ensuring that no messages are tampered with, altered or deleted) for the entire retention period set by the company, there is no backup media restoration to contend with. Having a storage system that is easily searchable is one goal of an email archiving system. Another goal is being able to reproduce the original email messages on demand. Each of these goals will have long-term benefits by reducing the costs of litigation.
2. Increased Recovery Time
   Having every megabyte of data stored on backup servers is an important starting point for post-disaster recovery, but having a well-defined archiving system for email can help a business get back up and running much more quickly after a disaster occurs. Essentially, knowing where data came from (and thus, where it should be restored to), can be the difference between a calm recovery and a frantic one.
3. Reduced Exposure to Spam
   Having an automated technology in place that can easily identify and delete spam can be a great benefit to any organization. It can help to save the most important non-renewable resource that any company cannot lose. And that is Time. Organizations can save a lot of time that might otherwise be wasted on reading spam email messages by blocking spam before it ever reaches an end user’s inbox. Good anti-spam solutions can block email messages based on their addresses, subject lines and content. Look for solutions that can also block based on origin and on non-existent recipient addresses.
4. Reduced Exposure to Security Threats
   Everyone knows that viruses can severely impact an organization’s operations if their email servers are running in an exposed mode. When exposed servers are unprotected then viruses can and will attack. And once a server goes down it can have a domino effect on the rest of production. The result is that all departments within a company or organization will experience severe downtime and with downtime comes loss of money and services.
5. Reduced Compliance Costs
   There has been a number of regulatory bodies defining the compliance measures that organizations must follow for their respective industries. Compliance regulations govern many industries such as: financial services, manufacturing, health care and customer care. When companies stay in compliance with their respective regulatory agencies then the benefits can include:
   • More effective auditing practices.
   • Well-defined retention and disposal policies.
   • Identification of confidential and/or sensitive information.

5 Email Management Benefits

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In his blog, “Exchange 2010 Unified Messaging”, GregK discusses some of the differences between Exchange 2007 Unified Messaging and Exchange 2010 Unified Messaging.

Unified Messaging (UM) can perform name lookups based on information derived from who is the calling party and who is the called party. When a missed call notification is sent out it can include the caller’s name based on information it receives from the lookup. Also, when a caller leaves a voice message, for a UM-enabled user, the caller information can be derived based on the existence of the calling party’s name in Active Directory or in the called party’s personal Contacts.

Greg describes the differences between how Exchange 2010 Unified Messaging supports Caller ID Resolution and how Caller ID Resolution is handled in Exchange 2007 UM. He notes that most people would prefer to see Caller ID resolution display the names of the callers as opposed to displaying their phone numbers. Prior to Exchange 2010 UM, Exchange 2007 Caller ID information was displayed based on the following factors:

• Resolve extension against the called person’s dial plan.
• Resolve SIP address against SIP proxy address.
• Resolve against the called person’s personal contacts.
• Resolve E164 number against MsRtcSip-Line.

Greg notes that Exchange 2010 added Active Directory lookup heuristics on multiple attributes, but that those attributes were not indexed and could not be queried by Exchange Unified Messaging. So, to make it easier for suffix searches, Unified Messaging copied the reversed phone number to a Dual Tone Multiple-Frequency (DTMF) map attribute. Dual Tone Multiple-Frequency is commonly known as touchtone.

Additional phone numbers can also be searched which include:

• telephoneNumber, otherTelephone
• homePhone, otherHomePhone
• mobile, otherMobile
• facsimileTelephoneNumber, otherFacsimileTelephoneNumber

This capability makes it easier for users to interact with their system using either DTMF or voice inputs. The configuration, of the Unified Messaging dial plans and auto attendants, determines which method – DTMF or voice inputs – will be used by the users to interact with their system.

If the DTMF interface is used then callers can use the telephone keypad to locate users and navigate the Unified Messaging menu system when they call a subscriber access number configured on a dial plan or when they call a telephone number configured on an auto attendant.

Administrators should be aware that, after upgrading to Exchange Unified Messaging  2010 SP1, the UM Auto Attendant for call transfers may fail for Office Communications Server 2007 R2 dial plans. Because Communications Server can be used for routing phone calls to a phone extension it has sometimes resulted in an error based on the values in the location profile.

Before Exchange UM 2010 SP1, the location profile was sent by Exchange Server to the Communications Server to indicate how to transfer a call to an extension. This information came from the UM dial plan. The location profile was indicated in the Refer-To header in the REFER (the message used to transfer the call to the extension).

REFER sip:alice@server0.com SIP/2.0
Via: SIP/2.0/UDP test.server0.com;branch=z9hG4bK2293940223
To: <sip:alice@test.server0.com>
From: <sip: amit@test.server0.com >;tag=193402342
Call-ID: 898234234@ test.server0.com
CSeq: 123 REFER
Max-Forwards: 70
Refer-To: clark@test.server0.com;phone-context=test.server0.com
Contact: sip:amit@test.server0.com
Content-Length: 0

For transfer of the call to be successful, the UM dial plan must have the exact same information – name – as the Communications Server location profile. But in Exchange UM 2010 SP1, the location profile information is no longer relayed. In the Refer-To header, you will see something similar to the following:

REFER sip:alice@server0.com SIP/2.0
Via: SIP/2.0/UDP test.server0.com;branch=z9hG4bK2293940223
To: <sip:alice@test.server0.com>
From: <sip: amit@test.server0.com >;tag=193402342
Call-ID: 898234234@ test.server0.com
CSeq: 123 REFER
Max-Forwards: 70
Refer-To: clark@test.server0.com;phone-context=user-default
Contact: sip:amit@test.server0.com
Content-Length: 0

The setting “phone-context=user-default” in the Refer-To field indicates that the default location profile should be used by Communications Server. This Exchange UM action is what allows Communications Server to select the best location profile. Unfortunately, it also means that Communications Server must have a default location profile configured to make use of this feature.

As a result, administrators may find that Exchange UM 2010 SP1 dial-by-extension does not work for the Communications Server dial plan. Or, they may encounter a situation where the call transfer – via key mappings in UM Auto Attendant to extensions – does not work. If either of these situations occurs then it usually means that the location profile was not selected. Otherwise, the Communications server would have known how to route the call to an extension using the default location profile. Administrators will not have these issues as long as they are running Exchange UM 2010 SP1 with Communications Server 2007 R2 and the Communications Server has been updated with the latest updates.

With the 64-bit release of Exchange Server many organizations will want to leverage the additional Unified Messaging support for a seamless integration of their telephone and data networks. The result will be greater employee productivity as messaging becomes another communication mechanism of your email systems.

Exchange Server and Unified Messaging

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In his blog article, “Exchange mailbox protection explained” , Stephen J. Bigelow discusses the problems with unprotected Exchange mailboxes and the various options for protecting them.

He explains that unsecured mailboxes can be easily compromised and their contents stolen. There are other problems associated with unsecured mailboxes such as: identity verification, privacy and proof of delivery. Additionally unsecured electronic mailboxes are subject to spam, viruses, and other harmful malware that is all too common with using popular, everyday email systems like Hotmail, AOL, Gmail and even Outlook. And almost all of these mail systems use the open-to-anyone Internet as their communications vehicle.

Stephen goes on to explain that the loss of email data impacts not only the productivity of the employee but also the productivity of the company or organization that the employee works for.

If I think about how the loss of my email content would affect my business activities then I immediately start thinking about backing up my data. I cannot afford to lose any of my emails. As an email administrator it is your responsibility to protect against the loss of, or the invasion of, all emails that circulate through your organization’s email server.

Stephen explains the various ways that an Exchange Server administrator can protect the email contents of their servers.

One of the options available to administrators using Exchange Server 2007 is known as “Cluster Continuous Replication”. Using Cluster Continuous Replication allows an administrator to: reduce the frequency of their full backups, reduce the total amount of data backed up and to shorten the recovery time objective (RTO). The RTO can be found in their department’s service level agreement (SLA) documents outlining the level of service which they are to provide for their customers’ or organization’s various departments.

Cluster continuous replication (CCR) is a high availability feature that combines the asynchronous log shipping and replay technology of Exchange server with the fail-over and management features provided by the Cluster service. CCR is designed to provide high availability for Exchange Mailbox servers by eliminating single points of failure and without requiring any special hardware. And there are no shared storage requirements to implement cluster continuous replication.

A second copy of the database is continuously and asynchronously updated using the database failure recovery functionality of Exchange Server. Thus, CCR operates in an active-passive mode with changes being made to an active copy of the database while the second (passive) database is also updated. Copying of the logs and replays are continuously performed.

The key points about Cluster Continuous Replication include the following:

• Continuous replication is asynchronous so not every log file that exists on the active server will be on the passive server. The logs are not copied until they are closed and no longer used by the Mailbox server. However, if an administrator has scheduled an outage on the active server for routine maintenance then the log files will be kept in sync.
• Continuous replication places almost no load on the CPU or input/output (I/O) devices. Secure file sharing is used by the passive node to obtain access to the logs.
• Servers in the cluster will take on both active and passive roles depending on their failover status. What may have been a passive node initially can change after a failover from the active node to the passive node. And vice-versa – the status of the active node can change to being a passive node after a failover has occurred.
• The time it takes to failover from node 1 to node 2 is the same amount of time it would take to failover from node 2 to node 1. On small servers, the estimated failover time is less than two minutes. For larger servers, a scheduled outage can be less than four minutes due to the time it takes to perform a controlled shutdown of an active node.
• CCR can be combined with standby continuous replication (SCR) to replicate storage groups locally in a primary data center. Replicating locally could provide for more highly available servers, using CCR, should a failure occur on the active server. A secondary remote datacenter could contain a passive node in a failover cluster that hosts the SCR targets for site resiliency. If the primary datacenter failed then the SCR targets hosted in the remote standby cluster could be quickly activated.

As noted by Stephen, in his article, CCR has been replaced with database availability groups (DAGs) in Exchange Server 2010.

Protecting Mailboxes with Cluster Continuous Replication (CCR)

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Occasionally, administrators will receive error messages in the application log that are more generic in their descriptions of the problems than an administrator would like them to be. It is so much easier to troubleshoot a problem when there are more details available associated with the received error.

One such error message which does contain details is the error message associated with Event ID 12014. The error message will contain many details and resembles the following text description:

“Microsoft Exchange could not find a certificate that contains the domain name mail.server.com in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Internet with a FQDN parameter of mail.server.com. If the connector’s FQDN is not specified, the computer’s FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.”

Event 12014 is a Warning event that indicates that a problem occurred while loading a certificate to be used for STARTTLS. This problem generally occurs if one or both of the following conditions is true:

1. The fully qualified domain name (FQDN) that is specified in the Warning event has been defined on a Receive connector or Send connector on a Microsoft Exchange Server 2007 transport server. In addition, the same computer that contains the FQDN in the Subject, or Subject Alternative Name fields, does not have a certificate installed.
2. There may be a third-party or custom certificate installed on the server which contains a matching FQDN. And the certificate has not been enabled for the Simple Mail Transfer Protocol (SMTP) service.

One of the Transport Layer Security (TLS) requirements is that a valid certificate must be installed in the system’s personal certificate store.

In order to begin troubleshooting the server, the account that an administrator uses must be delegated the following:

• Exchange View-Only Administrator role to run the Get-ExchangeCertificate cmdlet
• Exchange Server Administrator role and local Administrators group for the target server to run the New-ExchangeCertificate cmdlet or the Enable-ExchangeCertificate cmdlet

Additionally, if the server has the Edge Transport server role installed then to run any of these cmdlets on the system, an administrator must log on by using an account that is a member of the local Administrators group on that system.

An administrator should first review the configuration of the certificates that are installed on the Exchange server and the configuration of all Receive connectors and Send connectors that are installed on the server. An administrator can use the following commands to view the configuration:

1. Get-ExchangeCertificate | FL *
2. Get-ReceiveConnector | FL name, fqdn, objectClass Get-SendConnector | FL name, fqdn, objectClass

In order to display the services that are enabled for the installed certificate, an administrator must use the asterisk (*) when they run the FL argument on the Get-ExchangeCertificate cmdlet. The services values will not display if the * is not specified in the task parameters.

After running the above commands, the FQDN that is returned with the Warning event should be compared with the FQDN that is defined on each connector and with the CertificateDomains values that are defined on each certificate. The CertificateDomains value is a concatenation of the Subject and Subject Alternative Name fields on the certificate.

An administrator should verify that each connector that is using TLS has a corresponding certificate that includes the FQDN of the connector in the CertificateDomains values of the certificate. Make a note of any connectors that are enabled for TLS but do not have a corresponding certificate where the FQDN of the connector is in the CertificateDomains values of the certificate.

The Services value on each certificate should also be inspected. Note that a certificate for TLS must be enabled for the SMTP service that uses a Services value of SMTP.

If the FQDN is not listed on the CertificateDomains parameter, then an administrator must create a new certificate and specify the FQDN of the connector that is returned in this warning message. The certificate can be created by using the New-ExchangeCertificate cmdlet. A third-party or custom certificate may also be used. You can use the New-ExchangeCertificate cmdlet to generate the certificate request.

Lastly, if a third-party or custom certificate has been installed on the server and the certificate contains a matching FQDN but is not yet enabled for the SMTP service, then it must be enabled for the SMTP service.

Troubleshooting Event ID 12014

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Whether you are considering migrating to a new version of Exchange server or you are contemplating a first-time install of Exchange server, as an administrator you will greatly benefit from knowing and documenting your environment. Administrators should be able to pull up documentation, graphical charts and spreadsheets that illustrate their networks, existing servers and their data/application path topography. Not only will this benefit you in your planning efforts but it will also provide a quick path for troubleshooting problems as they arise.

Here is an outline for administrators to follow in their pre-troubleshooting efforts:

1. Understand your topology
2. Understand your servers and workloads
3. Know your Backup strategy
4. Document your Exchange Server configuration and settings
5. Know your client interfaces
6. Review and document all your Network connections and communication paths
7. Know your Environment changes

The details of these steps are as follows:

1. Understand your topology

It is an understatement to say that IT departments and administrators should understand the physical layouts and the logical flow of their email communications though their organization. These diagrams can become crucial to have during the troubleshooting process so it is best to have both diagrams – for quick at a glance viewings – as well as spreadsheets showing the details. Diagrams should include the following:

• Cities
• Locations and IP addresses of firewalls, Domain Controllers and Exchange Servers
• Bandwidth and latency of site links
• Subnets

For logical structures, the corresponding diagrams would contain the following:

• Active Directory topology (domain names, forest names, AD Sites, and trusts)
• Domain Controllers
• Exchange servers and Exchange Virtual Servers (for clusters)
• Site link costs
• Number of users

  2. Understand your servers and workloads

To help with understanding the workload requirements of Exchange server, administrators should document the following parameters:

• Number of mailboxes
• Usage patterns of the mailboxes (heavy, light, medium)
• Exchange Server version, service pack and rollup level
• Device driver versions
• Item counts in mailbox folders (higher item counts indicate a greater load)
• The number of hard drive spindles and controllers
• Protocols and driver connections (SCSI, iSCSI, SATA, JBOD, SAS, SAN)
• Directory and file locations of the databases, log files and server files
• Amount of memory on the Exchange server system
• Roles on the Exchange server system
• Location of the server relative to the firewall and network

  3. Know your Backup strategy

• How often is your Exchange server system backed up?
• How long does the backup take?
• Can backup be restored in the time specified in your Service Level Agreement?
• How often are rebuilds and restores tested?
• Do you have a high availability solution (CCR/SCR)?

  4. Document your Exchange Server configuration and settings

• What version of the operating system are you running?
• What is the operating system Service Pack level?
• Do you have Administrative Groups?
• What is the name of the Exchange Server(s)?
• What is the hardware manufacturer and model of the server(s)?
• What kind of Anti-Virus software is installed?
• Are there any Front End servers? If so, how many?
• Are there any Back End servers? If so, how many?
• Are there any Edge role servers? If so, how many?
• How many Exchange Server Mailbox roles servers are there?
• How many Exchange Server CAS role servers are there?
• How many and what kind of High Availability solutions have been deployed?

  5. Know your client interfaces

• What are the Outlook client versions and service packs?
• Is Outlook running in Exchange cached mode or online mode?
• Are there any third party add-ins enabled in Outlook?

  6. Review and document all your Network connections and communication paths

• Are the Exchange servers on the same network or separated by a WAN?
• Enumerate and list all the network devices between the Exchange servers, i.e. routers, switches and firewalls
• What network cards and drivers are installed on the Exchange servers?
• Are any network interface cards configured for teaming? If so, which ports or links?

  7. Know your Environment changes

• Have there been any recent changes in the environment including server changes, network changes, group policy changes, software updates, security patches, etc.?
• Do Exchange administrators have the ability to install software on the Exchange server?
• Can changes to the environment be easily tracked?

All of the above parameters, if well documented and diagrammed, can be an immense help to administrators when problems arise and troubleshooting efforts begin.

7 Steps to Troubleshoot Exchange Server Environment

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

There are times when an Exchange mailbox database cannot be mounted. The reasons for this mount operation failing can vary based on the scenarios involved.

If an administrator has created a mailbox database in a multiple domain environment and then goes to mount it on Exchange Server 2010 the mount may fail. The Exchange Management Console will display the following error message:

Failed to mount database
‘<ProductionDB>’.

<ProductionDB>
Failed
Error:
Couldn’t mount the database that you specified. Specified database:
<ProductionDB>; Error code: An Active Manager
operation failed. Error: The database action failed. Error: Operation
failed
with message: MapiExceptionNotFound: Unable to mount database.
(hr=0x8004010f,
ec=-2147221233)
[Database: <ProductionDB>, Server:
<Servername>].

An Active Manager operation failed. Error: The database action failed. Error:
Operation failed with message: MapiExceptionNotFound: Unable to mount
database.
(hr=0x8004010f, ec=-2147221233)
[Database: <ProductionDB>, Server:
<Servername>

An Active Manager operation failed. Error: Operation failed with message:
MapiExceptionNotFound: Unable to mount database. (hr=0x8004010f,
ec=-2147221233)
[Server: e14mbxndb2.Enterprise.emory.net]

MapiExceptionNotFound: Unable to mount database. (hr=0x8004010f,
ec=-2147221233)

If the Mailbox database is mounted via a command in Exchange Management Shell, then the following error message will be received:

[PS] C:\Windows\system32>New-MailboxDatabase -EdbFilePath <FilePath> -LogFolderPath <FolderPath> -Server <ServerName> -Name <DatabaseName> Active Directory operation failed on <Mailbox>. This error is not retriable. Additional information: The name reference is invalid. This may be caused by replication latency between Active Directory domain controllers. Active directory response: 000020B5: AtrErr: DSID-03152392, #1: 0: 000020B5: DSID-03152392, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 200f4 (homeMDB) + CategoryInfo : NotSpecified: (0:Int32) [New-MailboxDatabase], ADOperationException + FullyQualifiedErrorId : 8022381D,Microsoft.Exchange.Management.SystemConfigurationTasks.NewMailboxDatabase

An administrator should also review the Application log. The following event message will be recorded:

Log Name:      Application
Source:        MSExchange Configuration Cmdlet – Remote Management
Event ID:      4
Task Category: General
Level:         Error
Keywords:      Classic
Description: (PID 8136, Thread 2652) Task New-MailboxDatabase writing error when processing record of index 0. Error: Microsoft.Exchange.Data.Directory.ADOperationException: Active Directory operation failed on <Mailbox>. This error is not retriable. Additional information: The name reference is invalid.
This may be caused by replication latency between Active Directory domain controllers.
Active directory response: 000020B5: AtrErr: DSID-03152392, #1:
0: 000020B5: DSID-03152392, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 200f4 (homeMDB)
—> System.DirectoryServices.Protocols.DirectoryOperationException: A value in the request is invalid.
at System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(Int32 messageId, LdapOperation operation, ResultAll resultType, TimeSpan requestTimeOut, Boolean exceptionOnTimeOut)
at System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
at Microsoft.Exchange.Data.Directory.PooledLdapConnection.SendRequest(DirectoryRequest request, LdapOperation ldapOperation, IAccountingObject budget)
at Microsoft.Exchange.Data.Directory.ADSession.ExecuteModificationRequest(ADObject entry, DirectoryRequest request, ADObjectId originalId, Boolean emptyObjectSessionOnException)
— End of inner exception stack trace —
at Microsoft.Exchange.Data.Directory.ADSession.AnalyzeDirectoryError(PooledLdapConnection connection, DirectoryRequest request, DirectoryException de, Int32 totalRetries, Int32 retriesOnServer)
at Microsoft.Exchange.Data.Directory.ADSession.ExecuteModificationRequest(ADObject entry, DirectoryRequest request, ADObjectId originalId, Boolean emptyObjectSessionOnException)
at Microsoft.Exchange.Data.Directory.ADSession.Save(ADObject instanceToSave, IEnumerable`1 properties)
at Microsoft.Exchange.Management.SystemConfigurationTasks.NewMailboxDatabase.SaveSystemMailbox(MailboxDatabase mdb, Server owningServer, ADObjectId rootOrgContainerId, ADSystemConfigurationSession configSession, ADRecipientSession recipientSession, ADObjectId[] forcedReplicationSites, TaskWarningLoggingDelegate writeWarning, TaskVerboseLoggingDelegate writeVerbose)
at Microsoft.Exchange.Management.SystemConfigurationTasks.NewMailboxDatabase.WriteResult()
at Microsoft.Exchange.Configuration.Tasks.NewTaskBase`1.InternalProcessRecord()
at Microsoft.Exchange.Configuration.Tasks.NewADTaskBase`1.InternalProcessRecord()
at Microsoft.Exchange.Management.SystemConfigurationTasks.NewDatabaseTask`1.InternalProcessRecord()
at Microsoft.Exchange.Management.SystemConfigurationTasks.NewMailboxDatabase.InternalProcessRecord()
at Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord()

The problem is that the ConfigurationDomainController parameter and the PreferredGlobalCatalog parameter contain different values – they should be the same. The mailbox database operation fails because of the replication latency that occurs between the preferred global catalog and the configured domain controllers.

An administrator can correct this problem by setting the preferred Active Directory server in Exchange Management Shell to the following value:
Set-ADServerSettings –PreferredServer <DC FQDN>

It is also possible that the Exchange Administrative group is missing write permission for the msExchDatabaseCreated object. An administrator can add the write permission by following these steps:

1. Log on to the Exchange server with an account that has administrative credentials.
2. Open the Exchange Management Shell.
3. Type “CD<space> \” and press ENTER.
4. Run the following command:

Add-ADPermission -id “CN=<FourthCoffee>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<fourthcoffee>,DC=com” -User “Exchange Servers” -AccessRights WriteProperty -Properties “ms-Exch-Database-Created”

Another scenario can occur when Outlook is disconnected and the Exchange server mailbox database is not mounted. If an administrator attempts to mount the database then the following error message will be received:
Exchange is unable to mount the database that you specified. Specified database: Servername\First Storage Group\Mailbox Database; Error code: mapiExceptionCallFailed: Unable to mount database. (hr=0×80004005, ec=-528)

It is possible that the log file that is written into the database has been removed. An administrator should move the Checkpoint file and all log files to a different folder and then try to mount database again. This scenario assumes that the database was shut down cleanly. If the database was not shut down cleanly then an administrator may need to restore the database by means of the backup. A database repair may also be necessary.

Troubleshooting Mounting an Exchange Mailbox Database

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Implementing Exchange Server 2010 requires ports to be opened for the server and clients to communicate with one another. The necessary ports are opened to support communication through the Windows Firewall which filters inbound and outbound traffic based on firewall rules. Fortunately Exchange Server 2010 setup creates Windows Firewall rules that support those operations. In the past, administrators needed to use the Security Configuration Wizard (SCW) to open up those ports but as of 2010 this is no longer necessary.

Under certain circumstances some of these ports are not opened such as the following:

1. On servers that have Internet Information Services (IIS) installed, Windows opens the HTTP (port 80, TCP) and HTTPS (port 443, TCP) ports. Exchange Server 2010 Setup does not open these ports.
2. On Windows Server 2008 and Windows Server 2008 Release 2, Windows Firewall with Advanced Security allow administrators more latitude in how and when a port is opened. For instance, an administrator can specify the process or service to associate with a port that can then be opened. Being able to create a rule that associates the opening of a port with a process or a service adds another granular level of security. Exchange Setup can create firewall rules using a specified process or service. Additionally, rules that are not restricted to the process or service may also be created for compatibility reasons. Such compatibility rules will contain the word (GFW) in the rule name. An administrator can disable or remove these additional compatibility rules if they do not believe they are necessary.
3. Inside Exchange server there are a lot of services that use remote procedure calls (RPCs) for communications with the host servers. The processes and services that need to communicate with the Exchange server are not allowed to assign their own port numbers. If they were allowed to do so then there would be many problems and difficulties in completing communications. To avoid these conflicts, multiple processes and services must register with the RPC service to request a port number for communications with the server. The client connects to the server on TCP port 135 – the RPC Endpoint Mapper service, receives an assigned port number, and then continues communication to the server with the newly acquired port number.

This is where Exchange 2010 Setup comes into play. Exchange 2010 Setup will create two firewall rules for a process that uses RPCs. One rule is used for the process to communicate with the RPC Endpoint Mapper. The other rule is used for communications to the server with the newly acquired port number.

Although an administrator cannot modify the Windows Firewall rules created by Exchange 2010 Setup then can create custom rules based on them. Administrators can also delete or disable them. When troubleshooting a break in email communications, administrators should review the Firewall rules to see if any parameters have changed.

This table shows some of the Windows Firewall rules created by Exchange Setup. Ports that are opened for each server role are also listed. Windows Firewall with the Advanced Security MMC snap-in can be used to view these rules.

Troubleshooting Exchange and Firewall Rules

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators