Some of the new features of Exchange Server 2010 are that of the inclusion of two Volume Shadow Copy Service (VSS) Writers: the Replication Writer and the Store Writer. These writers make it easier for backup applications to create Windows Server 2008 VSS snapshots. For databases, Exchange Server includes the Replication Writer for replicating databases using the Database Mobility Features. And for those databases that are not replicated using a Database Availability Group (DAG) there is the Store Writer.

The Replication Writer is built into the Replication Service and is available on the passive node of the DAG server. The Replication Writer is used to support backing up particular databases that have had a shadow copy taken of the replicated instance of the transaction log files and of the replicated instance. By using the Store Writer, backups taken by Replication Writer can be restored to the active database location.

The Store Writer is built into the Exchange store and is available on any mailbox server. Store Writer is used for backing up and restoring active databases.

Continue reading Troubleshooting Exchange Replication Service Errors

Performance monitoring is a subject that is discussed frequently in IT departments. It is discussed before servers and applications are purchased, it is discussed while the servers are in the pre-production phase and it is discussed many times after the servers have gone into production.

If the server crashes then forensic analysis is performed to pinpoint the cause of the crash. Sometimes the cause of the crash can be traced back to the exhaustion of resources. But hopefully, with diligent monitoring of the server performance, those scenarios can be detected early as resource consumption ramps up the curve of utilization over time.

Luckily for administrators of Exchange Server there are many tools to help with the monitoring of Exchange Server.

In Doug Gowan’s blog, he has written a very informative guide to monitoring performance of the Exchange Server and has given an excellent overview of what components to monitor. In his blog, Doug discusses such components of the Exchange Server as: RPC operations, DSAccess, memory usage, disk usage and processor utilization.

Continue reading Monitoring Performance of Exchange Server

A major factor in moving from Outlook 2000 to Outlook 2003 was the advantage of utilizing RPC calls to make connections from Outlook clients to an Exchange server. The specific technology for making these internet connections was RPC over HTTP.  RPC means remote procedure calls and allow your Outlook MAPI clients to connect to Exchange servers using HTTP or the secure HTTPS protocol.

Remote Procedure Call (RPC) is a protocol that one application can use to request a service from another application running in another system in a network without having to understand network details. Remote Procedure Calls uses the client/server model. The requesting application is a client and the application which supplies the service is the server component. Remote Procedure Calls are synchronous operations that require the requesting application to wait until the results of the remote procedure are returned from the server. The uses of lightweight processes or threads that share the same address space allow multiple Remote Procedure Calls to be performed concurrently.

One of the advantages of using RPC over HTTP is that this methodology can support secure connections to the Exchange server and thus add an additional layer of security between the client and the server.

The other benefit is that these RPC commands could be encapsulated in HTTP. What this means from an administrator perspective is that only one of two ports would need to be opened at the firewall – port 443 or port 80 – as opposed to earlier versions which would have required two additional ports: port 135 and port 53. These ports were well known to hackers and used by them to create havoc within many organizations on a routine basis.

Continue reading Troubleshooting Connections to Exchange Server using HTTP

Administrators have many responsibilities when it comes to ensuring the reliability and performance of their servers. But sometimes their responsibilities get overshadowed by just trying to maintain a set level of performance. If their server performance slows down or begins to degrade they must be able to know where to go looking to correct the behavior before it begins to adversely impact their end user community.

One of those areas that can present performance problems is in the area of memory. And as one of the main components of server performance – CPU, I/O and memory – lack of memory resources can be fairly easily solved by purchasing and installing more memory. But when more memory is not the answer then the troubleshooting process can be more time consuming as there are more aspects of memory usage which must be examined.

Many times the memory performance problems don’t show up until the software applications – such as Outlook – have been upgraded. Some administrators have reported performance problems with paged and non-paged pool memory as the number of Outlook 2007 client have been added within the organization.

To solve this problem it is necessary that the paged pool memory used by client connections to the Exchange server be reduced. This can be accomplished by reducing the size and number of access tokens. Additionally, the client connections can also be distributed and managed so as to optimize performance.

Continue reading Troubleshooting Pool Memory in Exchange Server 2003

In his article, “Preventing Internal Email Abuse with Exchange Server 2010”, Paul Cunningham has stated,”… there is a lesser amount of attention given to preventing internal abuse of email systems. The risk of internal email abuse may seem low but for some organizations the risk is actually quite significant.”

In Exchange Server 2010, one of the more interesting features that have been improved is that of Transport Rule Predicates and Actions. Using Transport rules an administrator can create a rule which will inspect messages for conditions specified in the rules. The administrator can also create exceptions to the rules such that if those exceptions are met then no actions are applied to the email messages that have been identified by the rule which filtered out the identified message. With Exchange Server 2010 additional flexibility has been added for creating rules and actions to be taken against those identified messages.

In Paul Cunningham’s post he discusses how Transport Rules can be created and applied to internal messages with the purpose of identifying abusive email practices and their originators.

It is nice to have such a feature added to Exchange Server that can be used to help eliminate or at least reduce abusive internal emails sent and received within an organization. But I think companies and their IT departments will also have to speak with their legal departments to ensure they are not encroaching on any privacy laws.

Continue reading Exchange Server 2010 Email Abuse Prevention

In his article about Microsoft’s new Exchange Server feature, Mail Tips, author Paddy discusses the advantages of Mail Tips.

I agree with Paddy that this is a beneficial feature that all users within a company will appreciate. With Mail Tips, an end user – who is a sender of an email – will get helpful information before the sender sends out the email to the recipient.

Users will get informative messages about their recipient’s status while they are creating their email messages. Microsoft Exchange Server 2010 can notify the sender of any potential problems with the email message or any statuses of the recipient that the sender should know about such as if the potential recipient is out on vacation. All of this occurs while the message is being created.

The benefit to the end user is that they can modify their email message if needed based on the information they receive about the recipient list – information that was not previously available to them in earlier releases – before they send the email out. This also has the added benefit of reducing those annoying non-delivery reports (NDRs) that administrators have to deal with from time to time.

Continue reading Exchange Server 2010 Mail Tips Feature

Troubleshooting mail flow problems in Exchange Server can be a complicated process. There are many factors that can contribute to a slow down in processing and may include messages that are backing up in remote delivery queues due to bad DNS configuration or unintentional third party software settings. As previously discussed in another blog post some messages might be getting backed up in the Messages awaiting directory lookup queue in which case those backed up messages might be due to heavy distribution group expansions or permissions inheritance blocks. It is also possible that messages cannot be received due to a metadata corruption issue.

Some of the ways that the slow down of mail processing is exhibited include:

• Client response is very slow when email status is changed such as when end users change an email’s status from read to unread, or if email items are opened of deleted.
• Messaging Application Programming Interface (MAPI) error messages are generated that include the phrase “Client Operation Failed.”
• Log files in the Mdbdata folder show continuous growth even though very little has actually changed in the public folder resources or the mailbox resources.
• Attempts to improve the speed of processing are unsuccessful such as creating a new folder and moving the contents of the folder, with the slow responsiveness, to the new folder. The move is only temporarily successful as the speed of processing will continue to steadily decrease until the processing matches the previous unacceptable condition.
• Administrators may notice that some folders are more easily accessible than others within the same database and show no slowdown or problems in responsiveness. This uneven distribution of problems and responsiveness can include special folders such as gateway folders like the Mts-in and Mts-out folders.

If users are receiving unexpected non-delivery reports when sending messages then an administrator should review those NDRs to obtain the DSN code that is contained in the non-delivery report. Lookup the DSN code definition and then determine what actions will be needed to correct this error.

Continue reading Troubleshooting Mail Flow Problems in Exchange Server

Changes to the email server as with any server are often planned and usually involve patches, fixes and upgrades. Other changes are related to configuration settings and performance tuning. Sometimes the change might be to allow more email traffic to be handled by the existing email server.

One system administrator related that a change was made to the server that would allow more than just receiving POP3 email. Then the server was configured as the primary MX server in the global DNS settings. The result was that both incoming and outgoing email messages were held in the “Messages awaiting directory lookup” queue of Exchange Server 2003. This queue is also known as the pre-categorization queue.

How the process works is that messages from the pre-submission queue are placed into the pre-categorization queue by the advanced queuing engine. Once the messages are placed into the pre-categorization queue then the categorizer can process those messages.

The categorizer is responsible for resolving message addresses from the sender and receiver fields using Active Directory. Any distribution lists will be expanded as necessary. The categorizer also validates any restrictions or limits as related to the sender and receiver addresses.

Messages that have not yet been resolved are held in the Messages Awaiting Directory Lookup queue. Sometimes those unresolved messages can create a backup in the Messages Awaiting Directory Lookup queue if those messages are not resolved in a timely manner. The causes for the backup can range from slow services such as the global catalog lookup to inaccessible catalog servers. Messages can backup the queue on front end servers if the Exchange Information Store service has been disabled for some reason. It is best not to disable this functionality on the front end servers.

Continue reading Troubleshooting the Messages Awaiting Directory Lookup

Diagnosing and resolving issues with Microsoft Exchange server can be frustrating at times. Reviewing the error codes and logs is the best way to start diagnosing what the problem is before you start any resolutions.

Oftentimes administrators will find that after an upgrade they begin to experience problems that previously did not exist. For instance, after having installed Microsoft Exchange Server 2003 Service Pack 1 (SP1), administrators may find that the Microsoft Exchange Information Store service periodically crashes. Administrators should begin their diagnostic process by reviewing the system event logs. They may find that one or more events may be recorded in the system event log on the server similar to the following event error messages:

Event 1
Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7034
Date:  
Time:  
User:  N/A
Computer: Computer_Name
Description:
The Microsoft Exchange Information Store service terminated unexpectedly.  It has
done this 1 time(s).
Event2
Event Type:  Error
Event Source: Microsoft Exchange Server
Event Category: None
Event ID: 1000
Date:
Time:
User:  N/A
Description:
Faulting application store.exe, version 6.5.7226.3, stamp 407db771, faulting module exchmem.dll, version 6.5.7226.0, stamp 406d29b4, debug? 0, fault address 0×00004e3e.

There can be multiple reasons why these error messages are produced. One possible reason for this error message is if there is a malformed email message or other malformed item in the information store.

Continue reading Troubleshooting MSExchange Information Store Errors

The Outlook Personal Folders file (PST) had its day.  It was once the ultimate or perhaps only solution to reducing the cost of storing old emails within the Exchange server database.

Those days are largely gone.  Exchange servers can scale up to much larger database sizes than they could 10 years ago.  Disk and tape storage is cheap, and emails themselves are getting larger and larger.  And enterprise email archiving is efficient, cost effective, and even comes built in to the latest version of Exchange Server.

The benefits of the PST format are now close to nil, while all of the problems remain.  PST files are single-user access only, can’t be indexed or easily searched, are sensitive to corruption when they get larger or are being accessed over networks, and consume more space due to their general inefficiency.

But many organizations have a lot of archived emails still stored in PST files.  Moving to a new Exchange server doesn’t magically solve that problem.  The question is what should you do about all those PST files? Continue reading What to do With Those PST Files