Sometimes sending and receiving email using Outlook and Exchange Server can take a long time especially when using the SEND and RECEIVE buttons. The length of time can vary from 5 minutes to as long as 15 to 20 minutes.

It’s possible that the problem is an issue with UDP notifications to Outlook from Exchange Server. In Exchange Server 2010 UDP notifications are not issued and so Outlook, particularly Outlook 2003, is unable to register to receive notifications. And if there are any changes to a folder then Outlook will not know about those changes unless Outlook polls the server. Since the default polling interval for Outlook 2003 is about sixty seconds then at least that much time will be spent without notification of any folder changes and hence no notification of email being sent or received for that duration.

If any of the following symptoms are being experienced then there is a strong likelihood that the problem is because of long send and receives times:

• Outgoing email messages stay in the Outbox for up to one minute.
• New email messages are not arriving in the Inbox for up to one minute.
• Email messages that have been deleted from folders do not disappear from the folder for up to one minute.
• Items that are moved from one folder to another folder take up to one minute to disappear from the original folder.
• Folder updates are not occurring automatically at regular intervals

As already mentioned, this problem is more associated with Outlook 2003 because of the way it is designed to receive messages from Exchange server by using UDP for notifications. An administrator can alleviate themselves of this problem by upgrading to Outlook 2007 which uses asynchronous notification instead of UDP.

An administrator can resolve this problem with either one of two options:

1. An administrator can install the Update Rollup1 for Exchange Server 2010.
2. An administrator can use cache mode with their Outlook 2003 profile.

Here are the steps for Option 1:

Download the Update Rollup 1 for Exchange Server 2010 from article 976573, in the Microsoft Knowledge Base.

Follow the instructions to install the update. Next you will have to add the following registry data to the server by using the Client Access role. As always, you should always make a backup of the Registry before making any changes to it. The Registry is not the place to be without a backup if any errors are made when applying changes.

Here are the steps for making changes to the Registry to support the Update Rollup install:

1. Start the Registry Editor.
2. Find the following registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem
3. If the Registry subkey – \ParametersSystem – does not exist then create it.
4. Select and click on the registry subkey.
5. Add the following registry data:                                                                          
   Value type: REG_DWORD
   Value name: Maximum Polling Frequency
   Value data: any integer between 5000 and 120000 (decimal value)
6. Exit the Registry Editor.

Since the registry change is dynamically detected then the new settings will go into effect after the change is made and will then be applied to any new connections that clients make. An administrator can ensure that the new settings will be applied to all clients by recycling the Microsoft Exchange RPC Client Access service. This is usually done as a precaution since client connections can remain active for a long time.

And because Outlook 2003 does not poll the Exchange Server 2010 server in intervals that are less than 10 seconds, then any value less than 10000 should have the same effect.

Note that this change only enables polling to occur more frequently between Exchange Server 2010 and Outlook 2003 but does not renew UDP communication between them.

The second option for working around this problem is to use cache mode with the Outlook 2003 profile. This workaround can take the place of installing the Update Rollup 1 for Exchange Server 2010 if the install cannot be performed for some reason. Using this option will allow folder updates to occur because the cached mode synchronization process uses a different architecture.

Here are the steps for configuring your profile to use cached mode:

1. Exit Outlook 2003.
2. From the Control Panel, start Mail.
3. Click Email Accounts.
4. Click on “View or change existing email accounts”.
5. Click Next.
6. Select the Microsoft Exchange Server account and then click “Change”.
7. Enable cached mode by clicking on the “Use Cached Exchange Mode” check box.
8. Click Next.
9. Click Finish.
10. Start Outlook 2003.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting Long Send and Receive Times

Encrypting transmissions between servers using SMTP/TLS can protect email from prying eyes, but as with all transport layer encryption, it makes troubleshooting issues on the network much more difficult. With WireShark, or even running debug at the firewall, it is relatively easy to diagnose issues by simply observing the SMTP messages between mail servers to see if there are problems. When those messages are encrypted, your visibility into the network goes away, and you are left with event logs and other diagnostics. One of the more common problem areas you run into when using SMTP/TLS has to do with the certificates in use. Unfortunately, this also results in some of the most cryptic messages you’ve ever seen in event viewer, syslog, or /var/log/mail.d.

Fortunately, you can do some fairly low level troubleshooting of certificate issues with a little OpenSSL magic. If this sounds useful to use, please, read on.

Since most enterprise email systems support SMTP/TLS as a method to securing email transmissions using PKI certificates and the secure exchange of keys, the likelihood of you having to support this is on the rise. As with any other encryption, the tools most admins with a networking background turn to, like protocol analysers, become less and less useful because the very encryption that is intended to secure email also occludes the data exchanges between servers.

Since SMTP certificates are the root of SMTP/TLS, and have to be ‘just so’ before two servers can move on to exchanging email, we need to ensure that they are good to go before moving on to other checks.

To successfully use SMTP/TLS, the certificates used must be

• appropriate for the protocol,
• support digital signatures and key encipherment,
• the CN or SAN must match the hostname of the server presenting the certificate,
• and the client must (usually) trust the issuing CA.

If you are obtaining certificates from a public CA this is usually straightforward, but since more and more organisations are rolling their own to save money, this is not always so straight-forward.

While I roll my own at home, and often will do so at the office for strictly internal purposes, I always recommend that for an enterprise, use only certificates issued by a commercial CA whenever you are supporting connections from clients, customers, or other third parties. The few dollars spent on a certificate from a trusted CA is far cheaper than the efforts troubleshooting issues, or the negative impression a potential customer may get when presented with a warning about your certificate!

You can view the Client Hello and certificate download in WireShark, but sometimes it is easier to just drop to the command line. While Linux based MTAs will have OpenSSL installed already, Windows admins will want to go download OpenSSL for Win32 from Shining Light Productions. First, install the Visual C++ redistributables (linked from that site to MSFT,) then install OpenSSL. Once you have it installed, the commands are essentially the same on Windows and Linux, but we’ll show the Windows cmd prompt syntax below.

1. open a cmd prompt or terminal session.
2. change to the OpenSSL directory. In Windows that will be C:\OpenSSL-Win32\bin by default.
3. issue the following command, substituting the appropriate hostname, and you want to test port 587 as well.

c:\OpenSSL-Win32\bin>openssl s_client -connect demeter.retrohack.com:25 -starttl
 s smtp
 Loading 'screen' into random state - done
 CONNECTED(00000180)
 depth=0 CN = apollo
 verify error:num=20:unable to get local issuer certificate
 verify return:1
 depth=0 CN = apollo
 verify error:num=27:certificate not trusted
 verify return:1
 depth=0 CN = apollo
 verify error:num=21:unable to verify the first certificate
 verify return:1
 ---
 Certificate chain
  0 s:/CN=apollo
    i:/DC=home/DC=olympus/CN=olympus-CA
 ---
 Server certificate
 -----BEGIN CERTIFICATE-----
 MIIEzzCCA7egAwIBAgIKHJPqzQAAAAAAGDANBgkqhkiG9w0BAQUFADBEMRQwEgYK
 CZImiZPyLGQBGRYEaG9tZTEXMBUGCgmSJomT8ixkARkWB29seW1wdXMxEzARBgNV
 BAMTCm9seW1wdXMtQ0EwHhcNMTAwNDMwMTc1MTQ3WhcNMTIwNDI5MTc1MTQ3WjAR
 MQ8wDQYDVQQDEwZhcG9sbG8wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALZ8
 UOsppbvv7hZa6nxaFZAiQ1MKvY+bAUq3MZ7x6KhDIF/rl+9giuEHn+eX4FM81O1L
 fZMK6By/FWaBxMK7Bd51R66csrIUr04JFwAYeCEAx+MYn2WImHPAVF5d5o8dHg09
 IbG3vXquNDKEKIloR/9gnhogfi4szIxI/rDBdp69AgMBAAGjggJ4MIICdDAhBgkr
 BgEEAYI3FAIEFB4SAFcAZQBiAFMAZQByAHYAZQByMAsGA1UdDwQEAwIFoDATBgNV
 HSUEDDAKBggrBgEFBQcDATAvBgkrBgEEAYI3FQoEIjAgMAoGCCsGAQUFBwMBMAoG
 CCsGAQUFBwMCMAYGBFUdJQAwHQYDVR0OBBYEFNiXwZgWEG63djUQAJa7s0oCRVvh
 MDMGA1UdEQQsMCqCFyouZWRhbmRjb25uaWVmaXNoZXIuY29tgg8qLnJldHJvaGFj
 ay5jb20wHwYDVR0jBBgwFoAU8SoB0nFVGBwvTpNt7D5SYQIobnIwgcYGA1UdHwSB
 vjCBuzCBuKCBtaCBsoaBr2xkYXA6Ly8vQ049b2x5bXB1cy1DQSxDTj16ZXVzLENO
 PUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D
 b25maWd1cmF0aW9uLERDPW9seW1wdXMsREM9aG9tZT9jZXJ0aWZpY2F0ZVJldm9j
 YXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQw
 gb0GCCsGAQUFBwEBBIGwMIGtMIGqBggrBgEFBQcwAoaBnWxkYXA6Ly8vQ049b2x5
 bXB1cy1DQSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vy
 dmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vbHltcHVzLERDPWhvbWU/Y0FDZXJ0
 aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw
 DQYJKoZIhvcNAQEFBQADggEBADB1neeO9cReyIxyEtEQpyn/nEeeRZ6G4x6aqflB
 /m0YnpIN5C22vQ2FuANaHsJNVi/9U0B5b20V18lM5+6AjMBizadGUv3jcH+jsfT/
 JsHiY0C9NEE6kCUlQfD4YuPjiQvnyGjVVVK3UrIaM4YhH4qXZs21qsCWbaGkybIM
 uk+7viMm1dJoXOHW88ihdqYOwMNxBMbqd61BSWUfn580QV+T9uvz/Q1PF8e8k6Hp
 B8VWbirUh25CfkLdwe2M2Ys1Z+6AppsDf/Y1DQgHgnacWLv784IQBQjHQ45aEHvl
 fwkF3YlWKf7X2iAYmJI0SpwKErFKp8OuziisJi3qKI2NCCU=
 -----END CERTIFICATE-----
 subject=/CN=apollo
 issuer=/DC=home/DC=olympus/CN=olympus-CA
 ---
 No client certificate CA names sent
 ---
 SSL handshake has read 1783 bytes and written 443 bytes
 ---
 New, TLSv1/SSLv3, Cipher is AES128-SHA
 Server public key is 1024 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 SSL-Session:
     Protocol  : TLSv1
     Cipher    : AES128-SHA
     Session-ID: 44030000FDADD13038C7CECB27978C32091B850DAC5FF0B39E6BD48CFE3B7560

     Session-ID-ctx:
     Master-Key: D505277A00EF304B3DF7FE99E72618532A616ABE5A40FA26D0B73647E44BB4BB
 08515582DDD288306B08A51221D21D61
     Key-Arg   : None
     PSK identity: None
     PSK identity hint: None
     Start Time: 1283360267
     Timeout   : 300 (sec)
     Verify return code: 21 (unable to verify the first certificate)
 ---
 250 XSHADOW
 451 4.7.0 Timeout waiting for client input
 read:errno=0

The above example shows an exchange with a server where the admin (me) rolled his own certificate. From our client, we can see that we do not trust* the certificate issuing CA, /DC=home/DC=olympus/CN=olympus-CA.

*OpenSSL on Windows does not use the Windows certificate store, so even if you are running this on a domain joined machine and issued the certificate from an AD integrated PKI, you will still get this error unless you add the CA to OpenSSL’s list of trusted CAs.

Unless our server is configured to accept certificates from untrusted CAs, we are going to either have to trust this root CA, or have the admin of that mail server obtain a certificate from a trusted CA.

See that we can also see the entire certificate. That can help with further troubleshooting name mismatches, etc. Copy everything between —–BEGIN CERTIFICATE—– and  —–END CERTIFICATE—– to a separate text file, save it as a *.cer, and you can open it to view the certificate. From there we can see that this certificate has two wildcard values in the SAN, which should match to the FQDN we connected to.

If we attempt to connect to a server:port that does not support SMTP/TLS, we get this.

C:\OpenSSL-Win32\bin>openssl s_client -connect mail.global.frontbridge.com:25 -s
tarttls smtp -status
Loading 'screen' into random state - done
CONNECTED(00000180)
didn't found starttls in server response, try anyway...
8972:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:.\ssl\s23_lib
.c:184:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 299 bytes and written 254 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

Connecting to a server whose CA we trust, and whose certificate has no problems generates a lot less text.

C:\OpenSSL-Win32\bin>openssl s_client -connect mail.global.frontbridge.com:587 -
starttls smtp -status
Loading 'screen' into random state - done
connect: No error
connect:errno=0

With the above in mind, you should be able to easily identify or eliminate certificate issues when troubleshooting SMTP/TLS.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting SMTP/TLS with OpenSSL

Setting up email servers involves much planning and resources. One of the decision points in configuring email servers is that of deciding whether your server is to become a mail relay system. This will allow your Microsoft Exchange Server to forward email that it receives that is really intended for another domain. But there are problems that can happen when your Exchange server or one of your accounts on the Exchange server is setup to function as an open mail relay.

If your system has been configured as an open mail relay then outside email can be sent through your email server that can originate from both known and unknown users. In the early days, most email servers were set up as open mail relay server but now with the explosion of spammers, viruses and all the various methods to bring down exposed servers this practice of opening up your servers to the outside world have become less popular.

If your email server has not been configured correctly as a mail relay server then there will be obvious problems.

One of the hidden cost problems that can occur is that your email server might end up being blacklisted meaning that if your email server has been identified as a server that is a source for spammers email – even though your server is not the point at which spammer emails are created from – then your email server could be flagged on the network by other servers as an email server to deny email from. If your users begin to complain about their email not reaching their destinations then this might be a sign that your mail server has indeed been flagged as a server to avoid email communications with. Your Exchange Server will be added to the block lists of other email servers up and down the line. Another side effect of being an open mail relay is that the available bandwidth for your Internet connection could take a hit and your traffic could slow down considerably.

An email administrator can identity they are experiencing mail relay issues if one or more of the following symptoms occur:

• Logging shows receipt of non-delivery reports (NDRs) that contain error codes 5.0.0, 5.7.1, or 5.7.3.
• Email messages are no longer being sent or forwarded.
• You mail queues contain large numbers of unsolicited commercial email.
• Your Exchange server has been identified as an originator of unsolicited commercial email.
• The Application log contains one or more of the following events:

Event Type: Warning
Event Source: MSExchangeTransport
Event Category: SMTP Protocol
Event ID: 1710
Computer: Computer_Name
Description: An SMTP client authenticated as user “NT AUTHORITY\ANONYMOUS LOGON” attempted to send as ” User.one @ domain.edu “. Access was denied because the authenticated client does not have permission to Send As this SMTP address. Data: 0000: 05 00 07 80 …?

Event Type: Error
Event Source: MSExchangeTransport
Event Category: SMTP Protocol
Event ID: 7004
Date: Date
Time: Time
User: N/A
Computer: Computer_Name
Description: The description for Event ID ( 7004 ) in Source ( MSExchangeTransport ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: 1, 1, from, helo, 571 from IP Address We do not relay from you. ,HELO Domain_Name.com You will find mail stuck in the Remote Delivery queue to a remote domain, and the event log does not give you any details on the remote domain name. If you telnet to the remote domain on port 25, you will find that the connection is dropped immediately with the same error in the above event log entry: 571 from IP Address We do not relay from you.

Date: Date
Source: MSExchangeTransport
Time: Time
Category: (3)
Type: Warning
Event ID: 4001
User: N/A
Computer: Computer_Name
Description: Message delivery to the remote domain ‘Mail.Example.Com’ failed. The error message is ‘An SMTP protocol error occurred’. , MAIL, 550 Mail from dial-up rejected; see http://mail-abuse.org/dul/enduser.htm or contact Example helpdesk at. Data: 0000: d7 02 04 c0

Date: Date
Source: MSExchangeTransport
Time: Time
Category: (3)
Type: Warning
Event ID: 4001
User: N/A
Computer: Computer_Name
Description: Message delivery to the remote domain ‘Mail.Example.Com’ failed. The error message is ‘An SMTP protocol error occurred’. , MAIL, 550 5.7.1 Mail from Ip_Address refused by blackhole site dialups.mail-abuse.org. Data: 0000: d7 02 04 c0

An email administrator can resolve this open mail relay issue by returning the mail server to its non-open mail relay server status by reconfiguring the mail server settings. After that step, then an administrator will need to contact other Exchange server administrators to get their newly reconfigured mail server removed from the block lists.

If an administrator wishes to prevent other upstream hosts from forwarding email to their server then in the configuration settings they can check the checkbox, “Allow upstream relay hosts only”. Authenticated relays should still work in this situation.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting Relaying of Email

Using the Microsoft Exchange Replication service can sometimes mean that administrators must determine which occasional errors to fix later and which errors need correction as soon as possible.

Administrators will usually have the Microsoft Exchange Server 2007 Management Pack for Operations Manager (MOM) running which can relieve them of constantly having to monitor the Windows Application log on systems that run Exchange Server 2007.

If the following event or events are logged in the Details table then the Management Operations Manager will generate an alert such as: ‘A directory required by the Microsoft Exchange Replication Service does not exist.”

The event which causes this alert is as follows:

Product Name:    Exchange
Product Version:    8.0 (Exchange Server 2007)
Event ID:        2074
Event Source:        MSExchangeRepl
Alert Type:        Error
MOM Rule Path:    Microsoft Exchange Server/Exchange 2007/Mailbox/Continuous Replication
MOM Rule Name:    A directory required by the Microsoft Exchange Replication Service does not exist.

When this event occurs it means that the Microsoft Exchange Replication (MSExchangeRepl) service could not access the required directory for the source logs, the target logs, or the checkpoint file or could not access the “targetsystemdirectory”. The event can occur if there is a permission issue on the directory, a hardware failure, or a configuration failure. If an administrator has misconfigured the system to use a particular volume and then removed the volume that the configuration points to then the event ID 2074 may be generated. Replication will fail for the respective storage group. Once the misconfiguration has been corrected then an administrator can successfully resume the replication.

An administrator can correct the misconfiguration using the steps outlined below:

• Confirm that the directory permissions have been set correctly.
• Verify that the specified directory exists and can be accessed without errors.
• Ensure that the storage is configured correctly for the storage group.
• Ensure that the storage hardware is operating correctly.

There is another situation that administrators have encountered when error 2074 can be generated and that is if they have recently enabled Standby Continuous Replication (SCR) in their environment.

In RTM version of Exchange Server 2007 Microsoft introduced Local Continuous Replication and Cluster Continuous Replication which are variations of SQL Server’s Log shipping feature.

The RTM version of Exchange 2007 is configured with rules, that in a continuous replication environment, prevent a log file from being deleted only if it has been backed up first and then replayed into the copy of the database. However, when using SCR, this rule is modified.

Standby Continuous Replication allows truncation of the log files at the SCR source as soon as they have been inspected by all SCR target machines. Unfortunately the log file truncation at the SCR source server does not wait until all log files have been replayed into all SCR targets. The reasoning for not waiting is because of the large log replay latency times associated with some of the SCR target copies.

As mentioned earlier, enabling SCR in an environment can produce the  EventID 2074 from the MSExchangeRepl source. A more detailed error message would look similar to the following:

“The directory \\BYPASS\somefilename required be the Microsoft Exchange Replication Service for BYPASS\Storage does not exist. Check the system and its permissions”

Some administrators have unsuccessfully tried to fix the problem by reseeding the database and then resuming the storage group copy. The database can be reseeded but when the primary site tries to access the log file, it will still show this error in the application log. Reinstalling both nodes will also not fix the error.

The problem is that Standalone Continuous Replication enables share on the Storage Group log folder and if this share is not created then log shipping cannot start.  To correct this problem an administrator can create the share with the name of the source server such as, in this case, “somefilename”.

And another workaround is to set the permissions to Full Control since the setup process may not set the share permissions as needed.

Administrators have also reported that by stopping the sharing of the shares that have already been created then that will allow the replay service to recreate them with the proper permissions. I have not tried this particular workaround but thought I should include it as a possible solution.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting Exchange Error 2074

Microsoft introduced its first analyzer tool for Exchange in 2004. Called by the catchy title Microsoft Exchange Server Best Practices Analyzer, the software proved to be so successful that similar software was rolled out for troubleshooting other aspects of Exchange.

Best Practices Analyzer emerged after Microsoft observed certain patterns when addressing critical situations with its support services. Critical situations require urgent assistance to solve a problem that’s disrupting service to an organization’s members and its important business operations. What Microsoft found was that not only were the number of critical situations growing, but that 60 percent of them were caused by configuration errors, not bugs in Exchange. Moreover, new critical situations arising in some shops were the same ones that had emerged in other organizations just a few months earlier.

Microsoft began by creating a utility to gather key information throughout an Exchange environment. When a customer faced a critical situation, they were told to run the utility and Microsoft would sift through the data to ferret out the root cause of a problem.

Collecting data was only the first step. Next, an engine was developed that could analyze the data and expose it to a set of rules. The rules established thresholds. If a key data item was outside the acceptable range in a threshold, the rule would “fire” and a red flag would be raised for support folks.

With the basic model in hand, Microsoft began refining it. Performance was improved from taking 24 hours to collect and analyze information to two hours. The rules set was beefed up.

Once in action, however, it didn’t take Microsoft long to figure out that Exchange didn’t operate in a vacuum. Email problems can originate in the underlying infrastructure of a system, as well as in the applications running on top of Exchange. So Microsoft expanded its analyzer’s rules to take into account what’s running under Exchange and invited vendors running software on top of Exchange to submit rules for their programs that could be added to the tool.

The latest version of Best Practices Analyzer, version 2.8, was released in June 2007. True to its roots, the program collects data from repositories such as Active Directory, registry, metabase and performance monitor and applies best practice rules to the lot. A report is generated that an administrator can use to improve an Exchange environment’s performance, scalability and uptime. The program shouldn’t be used to scan Exchange 2007 or 2010, however, since the software is installed  automatically when those versions of Exchange are set up.

In addition to Best Practices, Microsoft also makes software for troubleshooting Exchange. Aptly named Exchange Troubleshooting Assistant, the software executes a set of troubleshooting steps to expose the fundamental causes of problems with performance, mail flow and database mounting issues. Like the Best Practices software, Troubleshooting Assistant collects key data for its purposes–configuration data, performance counters, event logs and tracing information from Exchange and other sources–and determines what data is needed to treat the symptoms of the problems it finds.

Another valuable analyzer offered by Microsoft is its web-based Exchange Remote Connectivity Analyzer. As its name suggests, it’s designed to help administrators solve connectivity problems. Client logons and mail flows scenarios are simulated by the tool. If a test fails, advice is offered for troubleshooting many of the errors discovered by the service.

Four tests are available from the main Connectivity Analyzer page.

There’s an Exchange ActiveSync test. It simulates the steps a mobile device takes to connect to an Exchange server using ActiveSync, or ActiveSync device uses to obtain settings from the Autodiscover service.

There’s a Web Services connectivity test. It walks through basic Exchange Web services tasks to confirm they’re working. It’s handy for troubleshooting external access from Web Services clients, such as Entourage EWS, Microsoft’s email client for Apple’s Mac computers. Entourage will be replaced in the new version of Office for the Mac expected to be released in the fall. The web Services test also verifies a service account’s ability to access a specific mailbox, create and trash items in it and access it via Exchange Impersonation.

There’s an Office connectivity test that examines the steps Outlook uses to connect via Outlook Anywhere or Outlook 2007 uses to obtain settings from the Autodiscover service.

There’s also Internet Email tests that check the steps an Internet email server uses to send inbound SMTP email to the tester’s domain or reviews an outbound IP address for certain requirements.

No one likes troubleshooting problems, but with Microsoft’s analytic tools, some of those snares can be solved with a minimum of fuss.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Use Microsoft’s analyzing tools to keep Exchange humming

Outlook 2010 includes some great, though rather less than obvious, troubleshooting capabilities. You can enable diagnostic logging from within advanced options of Outlook, and hidden within the application’s system tray icon is the option to test email auto-configuration as well as to determine what messages are displayed to the user.

Enabling this logging, and testing connections, are both great ways to diagnose connection issues and to determine whether any connection problems are on the client side, or the server side. If you’d like to learn more, please read on.

Enabling diagnostic logging cranks up the data generated by Outlook to 11, so it is not the sort of thing we want to just do and leave turned on. If you have a client with connection issues, it is the best way to generate detailed logs of what is going on between the client and the server. When this logging is enabled, Outlook will display a message in the title bar, and lots of disk activity will occur.Here’s how to proceed. One last time, remember…don’t do this just for kicks. It will generate potentially large files, and can also create a performance hit on the client. When you need to troubleshoot the client, turn it on. When you are done…turn it off! Here’s how to turn it on. And notice, this does not require any cryptic registry keys!

1. Launch Outlook 2010
2. Click File, Options.
3. Click Advanced.
4. Scroll down to Other, and check the box to enable troubleshooting logging.
5. Restart Outlook.

To turn it off, simply go back and clear the checkbox, then restart Outlook again.

With logging enabled, a pop up will appear in the system tray reminding you that Outlook logging is enabled.

Once enabled, several log files are generated. Most of them are found in c:\users\username\AppData\Local\Temp\Outlook Logging. Logging will include details for MAPI, SMTP, IMAP, and POP3 connections in cleartext. Logs will also be generated for all activities that involve the calendar, however these are stored in a binary format that requires MSFT support to use. If you are troubleshooting Free/Busy issues, you can find those logs in %temp%\OLKAS, which are fortunately in cleartext format.

With logging enabled, you can diagnose individual connection issues, but the client also has a hidden test mechanism built in to it. You can diagnose the AutoConfiguration settings that Outlook will pick up from Exchange Web Services using the Autodiscover URL. Once logging is enabled, here is how to launch the connection testing that is built into Outlook 2010.

1. Hold down the CTRL key and right-click the Outlook icon in the system tray.
2. Click Test E-mail AutoConfiguration…

This will generate a pop up dialog box that can provide insight into connection errors, name resolution errors, certificate issues, and more.

If you are working on a larger issue that affects multiple clients, keep in mind that you can push settings out using a group policy and the Office Customization Tool. The Outlk14.adm file can be used to configure logging with a Group Policy Object that will save you from having to visit individual machines. Apply it to an Organizational Unit, and consider filtering the application of the GPO using a security group to affect just a subset of the user population. Just always keep in mind that this diagnostic logging can impact client performance, so use this with care, and remember to disable logging when you have the information you need.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting Outlook 2010 connections

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.

Sometimes, though, errors can occur during backups of the database. Such an example can happen if Windows Backup is used for a full backup. Exchange Server can produce an error such as this one:

“The application will not be available for recovery
from this backup. The consistency check failed for
 the component Microsoft Exchange Server\
Microsoft Information Store\EXCHANGE\{guid}.
Contact the application vendor for help.”

An administrator should always check the event log. Upon doing so they can expect to see a message such as the following:

“A VSS writer has rejected an event with error 0x800423f3,
The writer experienced a transient error. If the backup
process is retried, the error may not reoccur.”

“Changes that the writer made to the writer components
while handling the event will not be available to the
requester. Check the event log for related events from
the application hosting the VSS writer.”

Operation:
BackupComplete Event

Context:
Execution Context: Writer
Writer Class Id: {76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}
Writer Name: Microsoft Exchange Replica Writer
Writer Instance Name: Exchange Replication Service
Writer Instance ID: {a53aea54-f2e5-4817-b03a-2743a05f3fda}
Command Line: “C:\Program Files\Microsoft\Exchange
Server\V14\bin\msexchangerepl.exe”
Process ID: 2968

One possible solution to the above error condition is to disable Microsoft Forefront Server Protections.

Another condition under which a system state backup can fail is if an incremental backup is attempted. If the server is running Forefront Protection for Exchange then it is possible for the backup to fail.while attempting to perform anything other than a full backup on a server running Forefront Protection for Exchange.

An administrator can determine if the failure is related to the Forefront Protection for Exchange by reviewing the Application Log and searching for the following error message:

“Error FSCVSSWriter 11003
Microsoft Forefront Protection VSS Writer failed when preparing for backup. Writer instance: FSCVSSWriter Error code: 0×00000000
Warning VSS 8229
A VSS writer has rejected an event with error 0×800423f0, The shadow-copy set contains only a subset of the volumes needed to correctly backup the selected components of the writer.

Changes that the writer made to the writer components while handling the event will not be available to the requester. Check the event log for related events from the application hosting the VSS writer.”

A supported hotfix is available from Microsoft that applies to Microsoft Forefront Protection 2010 for Exchange Server. However, this hotfix is intended to correct only the problem that has been described here. This hotfix should only be applied to systems that have experienced this specific problem. More information can be found about this hotfix by going to the Microsoft support site and reviewing article 2181692.

Other administrators have reported errors with the replicator service when they running in an Exchange Server cluster of two nodes.

When they launch TDP for mail, TDPEXC (TDPEXCC BACKUP * FULL /BACKUPMETHOD=VSS /BACKUPDESTINATION=TSM /Formreplica) on the passive node, they have reported the following error:

ANS5261W An attempt to create a snapshot has failed.
Another attempt will be made to create the snapshot in 30 seconds.
ANS1235E (RC-1) An unknown system error has occurred from which TSM cannot recover.
ACN5060E A Tivoli Storage Manager API error has occurred.

In this particular situation the backup action needs to backup the replication from the passive node. An administrator can run the following command from the exchange management shell:  “vssadmin list writers”.

The administrator should search for the line “Microsoft Exchange Writer” and check for an error message. If and error message is there then the administrator can restart the service “MSExchangeRepl” and try their backup again.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting Exchange Replication Service Errors

One of the frequent challenges I have faced as an email administrator is trying to troubleshoot a system from the outside. That is to say, while I am viewing the system from the inside, and have administrative rights to it, the problem I am working on may be related to something outside my control, and I have limited visibility into what is happening from the perspective of other systems. It can be just as important to know how other mail systems interact with your systems and to see this from the outside perspective as it is to review your own logs. Unless I had access to another email system, my Gmail account was my best, albeit limited, resource to use for testing.

Fortunately, I have found several online resources through the years to help with setting up, testing, and troubleshooting email systems. The following fourteen are those that I have found to be the most useful. Some are single purpose, others have lots of great tools. Together, they let me validate/test just about any aspect of my email system, both from a server perspective, and from a client’s. This post will divide them up into categories for their best use, provide links, and share a little about what you can use these for and what to expect.

Open Relay tests

As we all know, open relays are a plague upon us, and spammers’ best friends. Unfortunately it is all too easy to misconfigure many email services and wind up being an open relay. The first thing I do after opening up TCP 25 on the firewall is to make sure that I am not an open relay. Believing that being thorough is a good thing, I use two different sites to test.

1. MailRadar Open relay test
The MailRadar site maintains a free tool that will test your email server for relay using nineteen different tests, and display the results on screen as the tests are conducted. Passing all nineteen should give you a very good feeling.

2. Network Abuse Clearinghouse Mail Relay Testing
However, I do want a second opinion, so I also test with the Network Abuse Clearinghouse site. Six relay methods are tested by this site. Anonymous testing is permitted, but you will get more accurate results if you sign up for a free account, which actually tries to relay email instead of stopping with the RCPT TO command.

VRFY test

One way to reduce the amount of spam hitting your inboxes is to disable the VRFY command on your MTA. Different systems have different ways of doing this, but once you set the bit, how do you know it worked?

3. MailTester.com VRFY Test
This site provides a simple way to test your server to see if it responds to VRFY commands. Enter an email address, and it will validate your MX records, connect to your server, request your server to verify an address, and display the results.

SPF Records

There is a good article over at RetroHack.com on using SPF records. Sender Policy Framework uses TXT records in DNS to list servers allowed to send email on behalf of a domain, and to provide guidance on what a receiving MTA should do if it gets email purporting to be from a domain, but sent from a server not on the list. SPF records can be challenging to set up correctly, but there are three very useful sites to help you create and validate that you have the TXT record set up correctly.

4. Microsoft’s SPF Record wizard
It will walk you through a wizard (it is Microsoft) that at the end will create an SPF text string you can just copy and paste into your DNS record.

5. OpenSPF.org
They have a page on their site with another wizard based creator for SPF records. It is a little harder to follow the first time you are doing this, but does an excellent job of creating the text for your SPF record, and is easy to understand once you go through it once.

6. Kitterman Technical Services
KTS has a page on their site that can validate your SPF syntax before you create your record in DNS, and can also look it up in DNS to verify it is there and correctly formatted.

MX Records

While we’re looking at our DNS records, it’s a good idea to make sure your MX records are properly setup. Too many times I have seen folks skip that on the assumption that the DNS team did as requested, only to find a record was typoed or had not propagated yet.

7. WebSitePulse Email Validation
This site prompts you for your email address, and then it performs a DNS lookup for the associated MX records and displays the results. It is a little prettier than using dig at the command line, and offers testing from three global locations so you can make sure any changes have replicated throughout the DNS if necessary.

8. MXToolbox Diagnostics
In addition to testing your MX records, this site will also test for open relay and to verify that your PTR records are in place.

Sending a test email

While your Gmail or Hotmail account can be used to send a test email in to your system, you are only able to see things from the client’s perspective.

9. Zoneedit.com’s Email/SMTP Test Utility
This site lets you fill the name or ip.addr of your MTA, a ‘from’ address, and a ‘to’ address, and then sends a test email message. What is great about this is that it shows the SMTP session at the bottom of the screen, so that you can see your MTA’s banner, the HELO, and SMTP command exchanges. Seeing your server’s response codes can be very useful when troubleshooting inbound mail problems.

Blacklist checking

Frequently, your email system seems to be fine for 99% of the users, but you will get one guy who reports that he can’t send emails to a customer. Often the problem is on the receiving side, but sometimes you find that they are using a DNSBL service that has flagged your system

10. MailRadar’s RBL test
This page will test twenty-two different DNS based email blacklists (DNSBL) for your server to see if any of them list your MTA.

Client side stuff

We all know that spammers crawl sites looking to harvest email addresses for spamming. Since we can’t talk the web guys out of posting email addressing on webpages, let’s make the spammers work a little more for it.

11. Email address munger/encoder
This site can take an email address and encode it in ASCII or JavaScript which will look like a normal email to people, render a clickable link to programs, but escape the notice of most spiders.

Comprehensive tests

While the sites above are great for specific purposes, the last three are multitaskers. Like a good Leatherman, they provide you with many tools for comprehensive testing of your system. One site is tailor made for Exchange admins, one is probably an old friend but has some new tricks, and one will make security conscious admins smile.

12. Microsoft’s Exchange Test suite
Exchange admins will want to make this their home page. From this webpage you can test ActiveSync, Outlook Web Access, Outlook Anywhere, and SMTP flow. Most of the tests will require a valid user account on your system, so set that up for a non-privileged user first.

13. DNS Tools
The DNS Stuff site is probably well know to those of you who also maintain DNS, but there are plenty of tools for email admins too. There is a Spam Database Lookup to see if your MTA is on a DNSBL, a DNS Lookup to check for MX records, an Email Test for inbound mail, and an SPF Test to verify your records.

14. GFI Email Security Testing Zone
Using this site is like hitting the jackpot for email testing. Seventeen different vulnerabilities in email systems and clients can be safely tested by using this site, as well as checking your antimalware solution. Tests include MIME header, VBS attachments, Eicar test virus, blank filename attachments, and more.

While the above are my favourites, there are many others on the Internet, and I’m sure you have some that you find useful. Please share in the comments, and let me know the ones you use, like, or dislike.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

14 online resources for email admins

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.

But in order to get the most out of RPC over HTTP it requires proper configuration by the system and email administrators. And without the correct settings there will of course be problems for both the end users and the administrators.

Some of the errors that can occur include:

1. Users cannot select the “Connect to my Exchange mailbox using HTTP” check box.
2. Users are unable to connect to Exchange Server after having selected the “Connect to my Exchange mailbox using HTTP” check box.

When users cannot select the “Connect to my Exchange mailbox using HTTP” check box then this can mean that the email administrator may not have configured Exchange server to support this functionality. In this situation, an administrator should consult the Microsoft Office Resource Kit for more information.

The other possibility is that your organization may need to patch the Windows XP operating system software. When users are unable to select the “Connect to my Exchange mailbox using HTTP” check box it might be because the updates supporting RPC have not been installed yet.

This patch includes the Remote Procedure Call (RPC) Updates Needed for Exchange Server 2003.

In the second case when users are unable to connect to Exchange Server after having selected the “Connect to my Exchange mailbox using HTTP” check box it is possible that their problem is one of either an incorrect web address, certificate principal name or authentication type for the Exchange proxy server. In this case the following steps should be performed:

1. From the Tools menu, click email accounts and then select View or change existing email accounts. Then click on Next and select the Exchange email account for the user in question.
2. Click Change.
3. Click More Settings and then click the Connection tab.
4. From “Exchange over the Internet” select “Connect to my Exchange mailbox using HTTP”.
5. Click on “Exchange proxy settings.”
6. From Connection settings, in the “Use this URL to connect to my proxy server for Exchange” box, type the URL for your organization’s proxy server.
7. From Connection settings, in the Principal name for proxy server box, type the principal name for the fully qualified domain name of your Exchange front-end server.
8. From Proxy authentication settings, in the “Use this authentication when connecting to my proxy server for Exchange” list, select the authentication method as appropriate. Depending on your environment this may be one of “basic authentication” or “NTLM authentication”.

After completing the steps above your Outlook client should now be ready to communicate with Exchange using RPC over HTTP.

Additional troubleshooting steps may include:

1. Confirm installation of the RPC over HTTP network service on the Exchange 2003 server.
2. Ensure that a Server certificate exists on the Exchange 2003 machine as well as on the domain controller.

Lastly, if an administrator has confirmed that all the steps above have been completed then they can perform further diagnostics by running the “rpcdiag” command from the Outlook 2003 client.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting Connections to Exchange Server using HTTP

Understanding the underlying mechanics of how Exchange Server works and how it stores messages can be very helpful to administrators especially when problems occur and resolution is needed immediately.

One of the most important components of the Exchange Server is that of the database which contains all the messages and directory information before those messages are applied to the database. Exchange Server 5.5 Standard Edition uses fault-tolerant, transaction-based databases that can grow to a maximum of 16 GB.  The size of the database for Enterprise Edition is limited only by the hardware used for storage. As with all databases Exchange Server uses transaction log files to be able to reconstruct the data should a failure occur. This data has already been accepted by the server but has not yet been committed.

The important database components of Exchange Server 5.5 include the Information Store and the JET Database Engine. The Information Store is actually comprised of two separate databases: the private information store database, Priv.edb, which manages data in user mailboxes and the public information store, Pub.edb, which manages data in public folders. Both databases are based on the JET format used to track and maintain information by utilizing the log files.

Administrators can encounter problems with the Exchange Server if any of these log files or the database become corrupted for some reason. Typical areas where database files can become corrupted include:

• Page (file system) level
• Database (JET database engine) level
• Application (Exchange information store) level

And the three most common errors that are associated with file-level problems in an Exchange database are:

• -1018 JET_errReadVerifyFailure
• -1019 JET_errPageNotInitialized
• -1022 JET_errDiskIO

Most of the -1019 and -1022 errors are caused by problems in the underlying system but the -1019 and -1022 errors can also be the result of errors in the Exchange Server code itself.

Administrators will see the -1018 error most often. The -1018 error is most often caused by corruption at the file system level to the Exchange server database.

Fortunately, Exchange Server includes tools that can help detect file-level damage to pages in its databases. At the page level and at the database level there are tools that can be used for both detection of errors in the database and also for repair of those errors.

For detection only of errors at the page level the utility to use is called “Esefile.exe”. But for both the page level and the database level that tool is the “Eseutil.exe” utility that can be used for not only detection of errors but also be used for repair work. At the application level the tool to use is the “Isinteg.exe” utility which can be used for detection and repair of problems.

As is common with most stack oriented or tiered architectures any problems at the lower levels will most likely result in problems at the upper levels. In this architecture when there are problems at the page level then there will most likely be problems at the database or application levels. So if an administrator has used the “Eseutil.exe” utility to repair errors at one of the lower levels then they will most often have to use the “Isinteg.exe” utility to continue the repairs at the application level.

The cause of the “- 1018” error is most often found in one of the lower levels that Exchange Server is built on. The most basic causes of the “- 1018” errors are usually found at the page level and are the result of issues with drivers, firmware, or hardware.

Errors at the database and application level are usually related to issues in Exchange code or in third-party programs that integrate with Exchange Server.

When data on a disk drive has become corrupted it is usually the result of one or more of the following conditions:

• Incorrect data has been written to the storage media.
• Data has been written to the wrong place on the storage media.
• Data has become damaged or has been changed after being stored.

Preventing corruption of data or preserving the integrity of the data is very difficult and almost impossible to guarantee one-hundred percent of the time. Luckily there are utilities, such as those mentioned above, which can be utilized to detect both incorrect and misplaced data and warn administrators of such conditions via the “-1018” error codes.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting “–1018” Exchange Server Database Errors

When using Outlook 2007 in Cached Exchange Mode users can access their email and can read emails while in an offline mode. But when they try to access additional mailboxes and shared mail folders they note that they are only allowed to do so when the mailboxes and shared mail folder are available only in an online mode. There are some workarounds which will allow them to access additional mailboxes and shared mail folders in the offline mode.
Even though shared mail folders cannot be cached users can cache any other shared folder though such as Contacts, Calendar and Public Folders.

Additionally, if an administrator has granted full mailbox access to those additional mailboxes, then they could be set up as IMAP accounts. An email administrator can help with the IMAP settings.

Support for caching shared folders with Cached Exchange Mode depends on the version of Outlook that is running. There are workarounds for Outlook 2003 and Outlook 2007 but if administrators don’t want to spend time on implementing workarounds then they can upgrade to Outlook 2010 which has full caching support for additional mailboxes.

For administrators who need to continue to use Outlook 2003 and Outlook 2007 here are some of those workarounds.

• IMAP can be used for additional mailboxes.
  IMAP supports caching and syncing of email folders with the server mailbox. In order to connect to an additional mailbox as an IMAP account an administrator will need to grant full mailbox permissions on the additional mailbox. An Administrator can also create the IMAP settings for the mailbox.
• Configure an additional email profile.
  Once full mailbox access has been granted to the additional mailbox then an administrator can also configure it with its own mail profile. This will allow the mailbox to be cached since the mail profile the additional mailbox will be a component of the main mailbox. In order for the new mail profiles to be recognized, and the cache updated, the changes will require a restart of the Outlook client.
• Store shared data in a Public Folder.
  If only one or a small number of folders need to be shared then it might be easier to store the shared data in a Public Folder. This workaround will still allow full control of access to the folder by the owner. It will also allow the folder to be cached for off line usage if the Public Folder has been identified as a Favorite Folder.
• SharePoint is another workaround for sharing content.
  If your company is using SharePoint, then you can also share content via the SharePoint website. The benefit of this workaround is that Outlook can also connect to SharePoint and cache the contents from the SharePoint site. Outlook 2007 and SharePoint 2007 are needed if your organization wished to share more than just Contacts and Events.
• A pst-file can also be used as a workaround.
  Pst files can be used as a storage file through basic copy techniques. Although this is technically not a sharing or caching methodology, it will still allow end users to work off line with the pst file.  And since pst-files are stored locally they will always have access to their content. In order for files to maintain synchronization it will be necessary for end users or administrators to ensure that any change made to the local copy are manually replicated back to the original files once the user is working online.

Additionally, there is a hotfix available in the Outlook 2007 post-Service Pack 1 hotfix package that is dated February 24, 2008. Administrators can find for more information about the hotfix by viewing the following article, 957909 as listed in the Microsoft Knowledge Base.

The hotfix can be enabled by following the steps outlined below:

1. Exit Outlook 2007.
2. Start the Registry Editor. In Windows XP, click Start, click Run, type regedit in the Open box, and then click OK.
3. Locate and select the following registry key:
   HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Cached Mode
   As an alternate an administrator can also use the following registry key:
   HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\Cached Mode
4. Right click CacheOthersMail, and then click Modify.
5. In the Value data box enter a value of “1”. Next, click OK.
6. On the File menu, click Exit to exit Registry Editor.
7. Disable the headers with the following steps:

• On the File menu, click on “Cached Exchange Mode”.
• Clear the following options by selecting them:
  -    Download Headers and then Full Items
  -    Download Headers
  -    On Slow Connections Download Only Headers

If header mode is not disabled then it is possible for headers to get corrupted or stop responding.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting Caching Shared Mail Folders in Outlook 2007

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.

One indication that kernel memory resources are being depleted is when the server becomes slow or refuses additional requests and connections. Other signs that the server is running out of memory is if applications are beginning to fail. And if connections to the server are unsuccessful then an error such as error code 1450, “Insufficient System Resources” may be returned. The worst case scenario is one that administrators and end users are all too familiar with which is the hated blue screen kiss of death.

As with diagnostics of most system problems the error logs should always be checked for any tell-tale messages. Such messages can be found in the system log and may be reported as in the following error events:

Event ID: 2019
Source: SRV
Description: The server was unable to allocate from the system nonpaged pool because the pool was empty.

Event ID: 2020
Source: SRV
Description: The server was unable to allocate from the system paged pool because the pool was empty.

Event ID: 2000
Source: SRV
Description: The server’s call to a system service failed unexpectedly.

If the server continues to exhibit performance problems a temporary solution is to just reboot the server. Keep in mind that under standard load, there should be approximately 50 MB of available paged pool memory. If the available paged pool memory drops below 30 MB then an administrator should take steps immediately to free up memory on the server.

Other factors affecting the size of the paged pool memory include boot switches such as /USERVA and /3GB, registry settings, and, as already mentioned, physical memory. During Windows startup the system statically allocates paged pool memory. This is the place that administrators can customize how much memory is allocated. Each process is allocated memory based on the /Userva= switch. For example, if an administrator sets /3GB and /Userva=3030 then 3030MB of memory is reserved for the process space. This is different than just using the /3GB switch by itself which will reserve 3072MB. Using the /3GB and /Userva=3030 will save 42MB that can be used to increase the kernel memory space.

Another diagnostic approach is to review the number of connections per client to the Exchange server.  An administrator can use the “netstat” command to ascertain the number of connections. If there are more than twenty connections from a one IP address to the Exchange server over an extended length of time then this will be an area for further investigation.

Lastly, administrators can apply a hotfix for Exchange 2003 SP2 that is used to optimize the use of client tokens. Up to one-third of the token memory consumption that is related to MAPI clients can be reduced by applying this hotfix. Administrators should only apply this hotfix if their servers are experiencing paged pool memory depletion issues that are caused by token allocations. More information about hotfix can be found by reviewing the following article number, 912480, in the Microsoft Knowledge Base (http://support.microsoft.com/kb/912480/).

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting Pool Memory in Exchange Server 2003

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.

As an example, the DSN code 5.1.6, will contain the following message in the output report:

“The user directory attributes, such as homeMDB or msExchHomeServerName, may be missing or corrupted. Troubleshooting: Verify the integrity of the user directory attributes, and then run the Recipient Update Service again to make sure that the attributes that are required for transport are valid.”

For some DSN codes, an administrator might have to determine which records in DNS are consistent.

If your organization is not receiving any messages from the Internet or some users can receive emails while other uses can not then this condition might be due to delays in the email flow. These delays might be caused by reasons which range from poor or limited network conditions to incorrect SMTP configuration settings.

Some troubleshooting steps can include:

1. Issue the “Ping” command from a Command Prompt window to the designated gateway or email server to check for general network health.
2. Verify connectivity over port 25 and other designated SMTP ports to the designated gateway or email server.
3. Verify the SMTP service status to confirm there are no problems.
4. Review any filter settings such as: Sender ID, IMF, Recipient, Connection or Sender.
5. Test the connection between the gateway to the sender address by sending a test email.
6. Review the SMTP proxy settings for any conditions that could cause SMTP traffic to be hindered. 
7. Review the message tracking logs from the sending server through the network onto the destination server to determine where the test email message is getting bottlenecked.
8. Review and confirm that the local domains are correctly registered.

If all of the above steps still do not help isolate the bottleneck then there may be another problem such as too many cached restrictions, back links, and searches are being placed on an individual folder. If an administrator believes this to be the case then they can try the following fix:

Add the Reset Views registry value for either the public or private information store. This change will have to be made in the Registry so please back up the registry before making any changes. More information can be found in the Microsoft Support Article ID 216076 (http://support.microsoft.com/kb/216076).

Additionally, a workaround would be to decrease the Aging Keep Time value for the affected database (either the public or private information store).

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

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.

Diagnostic information can be collected by an administrator by increasing the diagnostic logging for the MSExchangeDSAccess and MSExchangeTransport services. An administrator can increase the logging by performing the following steps:

1. Click Start, then Run and type regedit in the command field. Hit ENTER.
2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Diagnostics
3. Set all the categories under this registry subkey to the value of “5”.
4. Locate and then click the following registry subkey:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess\Diagnostics
5. Set all categories under this registry subkey to the value of “5”.
6. Exit the Registry Editor.

The following events may be logged in the Application log after you increase the diagnostic logging for the MSExchangeDSAccess and MSExchangeTransport services:

Event ID: 8024
Source:ExchangeAL
Category: LDAP Operations
Description: LDAP Search Initial Page on directory DirectoryName at base ‘DistinguishedName’ was unsuccessful. Directory returned the LDAP error:[0x34] Unavailable

Event ID: 9004
Source: MSExchangeTransport
Category: Categorizer
Type: Error
Description: Categorizer encountered a hard error while processing a message. While processing User ’smtp:user@example.com’, the function ‘CPhatCat::HrIsRecipientInSameRG’ called ‘MDAGetInfo’ which returned error code ‘0×80040920′ (). A DSN has been generated.

Event ID: 9003
Source: MSExchangeTransport
Category: Categorizer
Type: Warning
Description: Categorizer is temporarily unable to process a message. While processing user ’smtp:user@domain.com’, the function ‘CPhatCat::CompleteUserMailDrop’ called ‘SetTargetServer’ which returned error code ‘0xc0040559′ (The categorizer encountered an error. The operation will be restarted.).

Event ID: 929
Source: MSExchangeTransport
Category: Routing Engine/Service
Type: Error
Description: Failed in reading Connector’s DS Info Process Id: 8176 Process location: C:\WINDOWS\system32\inetsrv\inetinfo.exe ConnectorDN: DistinguishedName Hr:c004038a Attribute:[msExchSourceBridgeheadServersDN]

Event ID: 6004
Source: MSExchangeTransport
Category: Categorizer
Type: Warning
Description: The categorizer is unable to categorize messages due to a retryable error.

Event ID: 9035
Source: MSExchangeTransport
Category: Categorizer
Type: Warning
Description: Categorization of the message failed with a retryable error. Either some of the admin objects were renamed recently and changes were not picked or journaling was turned on for MDB (DistinguishedName) and the journal recipient’s mailbox is deleted.

If these Event IDs are logged then an administrator can use any of the following methods to resolve this issue:

1. Verify that the global catalog server is available.
2. Verify that the Exchange servers have sufficient permissions.
3. Verify that the attributes of user object are correct.
4. Verify that the message archive location is valid if message archiving is enabled.
5. Verify that the mailbox store on the SMTP bridgehead server is mounted.
6. Verify whether this issue occurs when you send messages to a large distribution list.
7. Verify whether any third-party software is installed on the Exchange server.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting the Messages Awaiting Directory Lookup

Some problems that can occur with Microsoft Exchange Server, 2000 or 2003, involve the mailbox store or a public folder. Sometimes the problems are a result of attempts to mount either of those stores.

The error message you may receive will be similar to the following:

An internal processing error has occurred. Try restarting
the Exchange System Manager or the Microsoft Exchange
Information Store service, or both.
ID no: c1041724
Exchange System Manager

In the Application log the following event may be logged:

Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 9518
Date: date
Time: time
User: N/A
Computer: SERVERNAME
Description: Error 0xfffffc01 starting Storage Group
/DC=COM/DC=EXAMPLE/CN=CONFIGURATION/CN=SERVICES/
CN=MICROSOFT EXCHANGE/CN=FIRST ORGANIZATION/
CN=ADMINISTRATIVE GROUPS/CN=FIRST ADMINISTRATIVE GROUP/
CN=SERVERS/CN=ServerName/CN=INFORMATIONSTORE/
CN=FIRST STORAGE GROUP on the Microsoft Exchange Information
Store. Storage Group - Initialization of Jet failed

Administrators should take note of the Description field which lists the Error code number of 0xfffffc01. The error code will be produced if an incorrect drive letter was used for the log files or the Exchange database files. This usually happens if the drive letter has changed for either of those files.

It is also possible that the drives which contain the log files of the Exchange database files are being write access blocked. This can happen if antivirus software is running which may cause this problem. Administrators should temporarily shutdown the antivirus software and then try to mount the databases that are exhibiting problems. If there are no more problems then the next step would be to contact the antivirus software vendor and ask for the latest revisions and fixes.

If the problem still exists then it is most likely that the issue is caused by an incorrect drive letter set for the log files or the Exchange database files as previously mentioned. An administrator should confirm that there is a valid database path and a valid log file path. Exchange System Manager can be used for this process by following the steps outlined below:

1. Start the Exchange System Manager by clicking on Start and then selecting Programs. Next select Microsoft Exchange and click on System Manager.
2. You may need to expand the Administrative Groups if they are displayed. Find the administrative group that is exhibiting the problem.
3. Find and select the Servers that are showing the problem and then expand that selection.
4. Find and select the store that cannot be mounted and then right click on it and click the Properties field.
5. Go to the General tab and review both the path that is displayed in the Transaction log field and the path that is displayed in the System path field. If those paths are incorrect then you’ll need to locate the folder that contains the transaction log files or the database files. The default location for both sets of files is the following directory path:
   %PROGRAMFILES%\Exchsrvr\mdbdata
6. Next, click OK on the directory path.
7. Repeat steps 3 through 5 for each store group that appears and then confirm the paths for the transaction log files and the database files.
8. The paths for the transaction log files and database files should now be complete for each storage group. Next you’ll need to verify the database paths for each store in each storage group. You can do so by following the steps below:

• Expand a storage group such as the First Storage Group.
• Right-click the StoreName (ServerName), and then click Properties.
• Verify the path that appears in the Exchange database field by clicking on the Database tab. Next, verify the path that appears in the Exchange streaming database field.
• If any path is incorrect, click Browse to locate the correct folder for the database file. The Exchange database file (.edb) and the Exchange streaming database file (.stm) have a default location:
  %PROGRAMFILES%\Exchsrvr\mdbdata
• Click on OK
• Verify the paths for each mailbox store or public folder store that is present in each storage group by following steps 8b through 8e

Lastly, mount either the public folder store or the mailbox store.

Additionally the application log may show this error message:

Event ID: 9518
Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Description: Error 0xfffffddc starting Storage Group
Path_of_Storage_Group on the Microsoft Exchange
Information Store. Storage Group -
Initialization of Jet failed.

The error message can occur if an attempt was made to mount a dismounted Exchange database in Exchange System Manager.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting MSExchangeIS Error 9518

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.

Fortunately there is a hotfix available which includes support for these event IDs, 7034 and 1000. The hotfix should be applied only to systems that are having this particular problem. The hotfix can be obtained from the Microsoft Customer Service and Support center.

Another issue that can cause many problems is when the Information Store crashes. When the Information Store crashes an error code will get logged in the event log which may look like this:
 
Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 9659
Date: 
Time:
User:  N/A
Computer: EXCH
Description:
The Microsoft Exchange Information Store encountered an unexpected exception 0xC0000005 at address 00412CAB while processing a request for user (some username).
For more information, click http://www.microsoft.com/contentredirect.asp.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 45 00 63 00 44 00 6f 00   E.c.D.o.
0008: 52 00 70 00 63 00 45 00   R.p.

An administrator should check if any anti-virus software running on the Exchange server is allowed to scan the transaction logs. There have been reported problems when anti-virus software is scanning the log files during backup commit actions.

It should be noted that the 9659 event ID indicates a general event. The best practice would be to collect and analyze the dump files to isolate what caused the event code.

Another reason for this error code to get logged is if there is a corrupted message in a Microsoft® Exchange Server mailbox. As you can see from the logged error message above the error message includes the name of the user who has a corrupted message in their mailbox. Knowing this information allows an administrator to work backwards through the messages in the inbox for that user and isolate which email caused the error.

Sometimes the error code message received will look similar to the following:

Event ID : 9659
Source : MSExchangeIS
Type : Error
Description : The Microsoft Exchange Information Store encountered an unexpected exception 0xC0000005 at address <address> while processing a request for user <OTHER_SERVER$>.

If you receive this message then the Store.exe process has most likely stopped responding on the system that is running Microsoft Exchange Server 2007.

The solution to this problem is to install Update Rollup 1 for Exchange Server 2007 Service Pack 1. More information about this Update Rollup can be obtained at the site: Description of Update Rollup 1 for Exchange Server 2007 Service Pack 1

If you have the release version of Exchange Server 2007 then an administrator can install Update Rollup 6 for Exchange Server 2007.

If further analysis is needed then an administrator can review the Application log and System log. Search for related Warning events or Error events that come before or after MSExchangeIS event 9659. There will be more details about these events which can help identify the root cause of these errors.

Lastly, diagnostic logging can be increased on the MSExchangeIS and MSExchangeTransport components for more information. Review the Microsoft Knowledge Base article 821912, “How to Collect Diagnostic Data to Help Troubleshoot Information Store Issues” for help with increasing the logging levels.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting MSExchange Information Store Errors

Most people would think that usernames are minor problems. But for the end user who has been working at a company for a long time and then suddenly they find their login does not work it can be a source of frustration that, if not fixed soon, can disrupt their workflow and diminish their productivity.

So administrators should treat and end users login problems due to unrecognized usernames with degrees of priority that escalate upwards at an increasing rate the longer a user is unable to login to their email accounts.

There are more than a couple scenarios that users can unknowingly lose their login privileges.

If an end user has recently left the company for whatever reason then an administrator will need to follow a (hopefully) predefined procedure which will allow for the removal of a now inactive account from the system.

One method that inexperienced administrators will use is to try to reuse the existing account of the newly changed employee. This means that rather than creating a new account and removing the old account an administrator will simply rename the existing account within Active Directory using a new employee’s information. Unfortunately this method does not guarantee that the old user’s accounts – and username – are not entirely removed from the system. Somewhere in the internals of the system, the directories and any databases – in this case Active Directory – there are remnants of the previous user’s information. A likely repository of information is the Exchange server that can contain the old user’s information such as their username.

As a result of a username not being completely removed from the system whenever an email is sent with the rename user’s account the mail header fields can be populated with username’s that were previously associated with the old account. The “To” and “Cc” fields might automatically be completed with a username as soon as the new user begins to type in an email address. For instance an auto complete might complete the email address in a “To” field with something like “John Doe <john.doe@somedomain.com>”. But if the new user’s name is typed into one of the fields then auto complete will incorrectly complete the email address to look something like “Jake Newuser <Jim>”. 

So renaming an old account is not the best email management practice. This method just results in the attributes of the account being modified but not the Security Identifier (SID) of the original account. Each user’s SID is a unique ID number that is used by the system or domain controller to identify the user to the system. The SID’s are composed of a string of alphanumeric characters and assigned to a specific user or group on a domain controlled network. Underneath the readable usernames is the SIDs associated with the individual logins. Active Directory or Kerberos domain authentication are used to store the passwords for the accounts. Based on the username and password the SID can be verified whether or not it is associated with the user account information.

So although the username may have been changed the underlying SID remains the same. Modifying a username associated with an email account using the rename function will modify all the properties associated with the user account but not the SID. After “renaming” an account it will then be possible for the new user to log into the mailbox and see all the old email contained in the previous mailbox but now under a new username.

The display name, account name, user principal name, first name, last name, e-mail address, and so on are all separate attributes and are modified in other places, generally properties fields. Renaming an account doesn’t change anything about an associated mailbox. It is not an all in one operation for deleting the old account and creating a new account. Only the common name (cn) attribute is changed.

Another scenario which may occur is if an employee has had a recent change to their marital status and their name has changed. They might submit a request that their current username – and all corresponding email properties – be changed to reflect their new name. It also may be the case that someone new has replaced another employee within a department.

We’ve already seen what problems can occur when simply renaming an old account is performed. One solution is to use email aliases. This can easily be done by changing the settings in Exchange. The alias can be seen as the part contained within the brackets of an email address field and looks like < > as in “John Doe <JDoe>”. New and external emails both inbound and outbound are not affected.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting Username Issues

In large organizations it can be a very convenient capability to allow some of your co-workers access to your calendar. This feature supports collaboration and helps to avoid over scheduling of meetings and appointments. Along with that capability is another feature that can allow other users access to your mailbox. This other feature is referred to as granting delegation access.

Granting access for other users to access your mailbox understandably involves a very large amount of trust. However the benefits can be worth it if the conditions exist to give someone else access to your email. But disregarding the privacy issues there can also be problems with granting delegation access.

There are two methods used for granting someone else access to your email:

1. Granting Delegate access:  This method is used to grant access to one or more of your Outlook folders. These folders can include: Calendar, Inbox, Notes, Tasks, Contacts and Journal. The users who you grant delegate access to will also have the “Send on behalf of” right explicitly granted to them. The delegated users can access the delegated folders by clicking on “File”, then “Open” and then clicking on “Other Users Folder”. Delegated access can be restricted through additional steps if necessary. Note that a delegate can be given different permissions for different folders. This allows the owner to control access to items in their Exchange mailbox. Usually if access to your calendar or inbox has already been granted without any problems then the “Send on behalf of” capability can also be given at the discretion of the owner of the inbox.
2. Granting specific folder permissions: This method is probably the best one to begin with when giving someone else access to your inbox and other folders. This method provides the same functionality as the Grant Delegate access method but it does not automatically give the “Send on behalf of” right to the specified users who are given permissions to your folders. In addition the “permission granted” users will need to add your mailbox folders to their own Outlook account. Once they have added your folders to their account then they will be able to see only those folders which they have been given permission to view.

Granting access to others to view your mailbox and other folders, and to respond to your email messages received, should be implemented only after one has set up rules and policies to guide the granted delegate in what manner to use your mailbox and what the boundaries are for responding to email messages. Failure to do so can result in leaked email messages and confidential company information.

Communications to mailboxes that are monitored by delegates should be marked as “private” or “confidential” to ensure that only the owner – not the delegate – will view the email communication. And on the receiving end, the owner should instruct the delegate that any email messages marked as “private” or “confidential” are not to be opened. This can help to maintain the integrity of the email communications between the sender and the recipients of mail inboxes managed by delegates.

Sometimes there are more delegates than who are actually listed in the permissions/delegate list. If this is the case then some cleanup may be in order. An administrator should check if the “Default” and “Anonymous” entries exist and, if so, is the “Anonymous” entry set to “none”.

Sometimes during a server migration mailbox folders such as calendars or inboxes that were previously accessed by delegates are no longer viewable by those delegates. One solution is to remove the delegates through the owner’s account and then re-add the same delegate. If the delegate still cannot view the owner’s folders then an administrator should go to the Exchange Advanced tab and click Mailbox Rights for both the owner and the delegate. Then verify that the “Associated External Account” permissions box is unchecked and that SELF has “Full Mailbox Access”. A third solution, to the migration problem, is to wait until the mailbox folders have been completely migrated to the new server and then to check the parameters on the Exchange General tab. Select the Delivery Options and then verify that the delegate is listed in the “Send on behalf of” box. If not then add the delegate.

Lastly, sometimes when a user has been granted delegate access they are unable to use Microsoft Outlook web access (OWA) to modify any of the folders for which they have access. An administrator should ensure that full write access has also been granted through OWA to the mailbox that has been delegated. Configuring the delegate as the owner of the mailbox can solve this problem if using Outlook web access.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting Delegated Email Issues

Administration of a server or of an enterprise of servers will often require the installation of updates to keep a system patched with the latest fixes. But at some point an upgrade or a migration will be needed. Email administrators, or any administrator of a system for that matter, will sooner or later encounter a situation where the most recent migration has not gone well.

Sometimes it is necessary to rollback to a previous working version to keep the users and the managers happy. It could also be the case that the most recent upgrade or migration effort inadvertently skipped a step or a patch or a fix was not yet installed to bring the system up to a supportable level.

Migration of Exchange server can have its own problems as well. Some administrators have reported a problem with Public Folders after having moved from Exchange Server 2000 to Exchange Server 2007.

If you have moved everything from one server to another then you might also be thinking about turning off all the old MSExch services on the older server. If you do this then you might end up with a situation where you are asked to logon to the older server every time you logon to your new server. What is happening is that the new Exchange Server is trying to get public folders from the old Exchange server. The result is that access to public folders is going to be hampered because the old Exchange server’s public folders are still trying to be accessed. An administrator can verify this scenario by right-clicking on the Outlook icon in the system tray. If you click cancel on the logon box then the public folders connection will be redirected to an EXch server in another domain. At this point some administrators have reported that their access has slow down.

It is possible to save the same public folder content on multiple Microsoft Exchange servers by using public folder replicas. The concept of using replicas is used in many applications such as database applications and also in disaster recovery strategies. The replicas must be updated at regular intervals so as to maintain the integrity of the data, in this case email messages, specifically public folder replicas must be refreshed at frequent intervals.

Exchange Server updates the public folder replicas by sending and receiving replication messages to each of the servers that contain public folder replicas. The sending and receiving of public folder replication messages creates a trail of communications which can be used for diagnostic purposes when there are problems with the replicas. These messages can be used to diagnose:

1. Which systems have sent any public folder replication messages.
2. Which systems have received any public folder replication messages.
3. Which systems have responded to any received public folder replication messages.

By analyzing the data an administrator can determine if a particular system is having problems with receiving or sending public folder replicas. Once it is determined which system is having problems then an administrator can further diagnose and isolate the problem through more tests.

One such test is to run the shell command “get-publicfolder -recurse | fl name,replicas” . The expectation is that the tree returned will display a populated public folder. If the tree is empty then more diagnostics will need to be run.

Error logs should also be checked for indications of a problem with the public folders.

When configuring public folder replication an administrator should use the System Manager tool to specify the target destination system as the replication server of another system for the source folders that need to be replicated. The replicated folders should indicate that they are “in sync” or “local modified”.

An administrator can confirm the status of the current public folder replicas by opening a command prompt and typing in the following commands:

1. cd D:\support\Exdeploy (hit enter)
2. pfmigrate.wsf /S:OLDSERVERNAME /T:NEWSERVERNAME /R /F:c:\LOGNAME.log

The above commands will create a report of the current public folder replicas. A report file – LOGNAME.log – will be created. An administrator should review the file to confirm that the OLDSERVERNAME is the name of the old server such as Exchange 2003 and that the NEWSERVERNAME is the name of the new server such as Exchange 2007.

To confirm that a successful replication was created and that each designated public folder exists on the new server an administrator can view the LOGNAME.log file for verification.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting Public Folder Replication Problems

Occasionally when a user sends email they may receive a Non Delivery Report (NDR) with error code 5.1.1 from the destination email server such as Microsoft Exchange 2000 and 2003 Server. This is an error message that is indicating that the recipient does not exist on the destination email server. And to add more confusion to the situation it is possible that the intended recipient of the first unsuccessful email is able to send email to the original sender and that original sender can successfully reply back to what was the original recipient.

If there are problems with delivering email to a recipient then a Non Delivery Report will be sent back to the sender. The NDR message is a subclass of a larger group of delivery status notifications. The delivery status notifications define three types of status:

1. Success (2.X.X numeric codes)
2. Persistent transient failure (4.X.X numeric codes)
3. Permanent failures (5.X.X numeric codes)

Most NDRs are sent because of failures so those error codes will be of the form 4.X.X or 5.X.X. This implies that the server is able to identify the reason for the failure and so is able to assign an error code which identifies the failure. The NDR which is sent back to the sender of the original email will contain the assigned error code.

Here is an example of what an Outlook client might see when they receive the 5.1.1 error message:

Your message did not reach some or all of the intended recipients.

Subject: Original Message
Sent: 3/24/2002 11:40 AM

The following recipient(s) could not be reached:
user@domain.com on 3/24/2002 11:40 AM
The e-mail account does not exist at the organization this message was sent to.
Check the e-mail address, or contact the recipient directly to find out the
correct address.
<server.domain.com #5.1.1>

In this example, the server that is reporting the 5.1.1 error code is listed as “server.domain.com”. It is important to note that sometimes the server that is reporting the problem is not the same as the server that is experiencing the problem.

Another example of the error code is a basic message such as: “511 – recipient address has invalid format”.

Here is a list of reasons why the 5.1.1 error may be produced:

1. There is no email account on the destination email server’s site for the recipient’s email address. This may happen if the email account was moved from one administrative group to another administrative group. If the recipient email user then replies to an old email during the transition then an old administrative group style LegDN will be used and the NDR will be sent back to the sender. The same result would also happen if the moved user did not recreate their Outlook profile.
2. Note that if an administrator tries to take a short cut by simply renaming an account in active directory then it will most likely result in NDR messages being created. A workaround would be to put the old legDN in as an x.500 address. This will prevent NDRs from being generated when email is replied to or sent to the old legdn. Note that it is not a Microsoft recommended practice to change the legdn’s.
3. The email message was sent to obsolete personal address book entries. The email account may once have existed there but has since been removed. The account may no longer exist if the end user has left the company and their account has been deactivated or deleted. It is also possible that the email address used is incorrect.
4. The categorizer rejected delivery because you configured your SMTP contact with characters that do not meet the requirements of RFC0821.

To correct this problem an administrator should verify that the recipient’s email address is formatted correctly and then resend the message. Confirm that the receiver’s email server is able to resolve the recipient’s email address.

If the email was sent to a user internal to the organization within the same domain, then it usually means that the recipient’s email address, as shown in either of the “To”, “Cc”, or “Bcc” fields, does not exist in your organization’s email system. If the email was sent to a user email address external to your company then the recipient’s email address should be verified by contacting administrators responsible for the destination email server site.

Liked this post? Get more email management and administration related news from TheEmailAdmin.com!

Troubleshooting Exchange Error 5.1.1