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.
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.
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.
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.
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.
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.
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:
- 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.
- 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.
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:
- Understand your topology
- Understand your servers and workloads
- Know your Backup strategy
- Document your Exchange Server configuration and settings
- Know your client interfaces
- Review and document all your Network connections and communication paths
- Know your Environment changes
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
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
with message: MapiExceptionNotFound: Unable to mount database.
[Database: <ProductionDB>, Server:
An Active Manager operation failed. Error: The database action failed. Error:
Operation failed with message: MapiExceptionNotFound: Unable to mount
[Database: <ProductionDB>, Server:
An Active Manager operation failed. Error: Operation failed with message:
MapiExceptionNotFound: Unable to mount database. (hr=0x8004010f,
MapiExceptionNotFound: Unable to mount database. (hr=0x8004010f,
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
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:
- 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.
- 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.
- 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.