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

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

In most all companies the sending and receiving of email messages happens almost all the time particularly between the hours of 8 to 5 for typical usages. But as administrators and managers know very well email is constantly being routed, sitting in queues and waiting to be read.

Sometimes while on conference calls I will not only be conversing on the conference call but at the same time be instant messaging with 2 to 4 colleagues as well as sending and receiving text and email messages – at least during times when I am not speaking on the call.

And like most all other users I have often had the experience of telling someone that “I’m going to send you that email right now with the attached document we spoke of.” I immediately create the email message and then hit the send button and watch as my screen changes to indicate that the message has been sent. Usually I get confirmation back from the recipient while I am talking with them on the phone that they have received my email message in what seemed like only seconds for the them to receive it.

But occasionally I will send an email with the recipient standing by on the phone with me and they will not receive for minutes and sometimes longer. This can be a very frustrating experience for people especially when their working relationships are co-dependent – the other person can’t start their work until they have received a certain email from their fellow co-worker.

Email is supposed to be sent and then routed from mail server to mail server until it reaches the intended recipient’s email inbox. But sometimes users will call the helpdesk or contact their administrators and ask frustratingly, “Why is email slow today!?!”

Sometimes users can miss important meetings if they can’t read their email and as a result miss important meeting invitations. In the worst cases those notifications come after the meeting has already been held.

There are many reasons for email to “slow” down along its journey to reach the recipient’s inbox.

Here then are five reasons for email delays:

1. Most cases of delayed email are due to overloaded mail servers. A server may become overloaded and need to store messages in a queue until it can catch up later when the load goes down. Overloading can occur when someone sends a mass mailing, or massive amounts of “spam”. Another cause is when a host repeatedly sends a message or messages in a very short amount of time thus forcing the receiving email server to become to busy processing all those email messages.
2. Incorrect email server configuration. It’s very easy for system settings to be altered in such a way that the email communications are adversely affected.
3. Email server crashed. Sometimes a site cannot be reached. This occurs routinely on the Internet and, when it happens, messages destined for this site are queued for later delivery. If a significant portion of the Internet is unavailable (for example, due to an outage), thousands of mail servers start to queue mail. When this happens then sometimes thousands of email messages can be queued for several hours.
4. Wrong firewall settings. Configure your firewall software to grant access to the Internet for Outlook.exe. By default, most email clients have outgoing access on port 25 and incoming access on port 110.
5. Email server running out of free space. There are three reasons why this can occur:

• This issue can occur if an antivirus event sink is installed on your system. This issue may be caused by a leak of MailMsg objects. Exchange Server 2003 has a default limit of 90,000 MailMsg objects that can be allocated. When this limit has been reached, the Exchange server cannot process additional messages. For more information about this limit can be found in the Microsoft Knowledge Base article 258748: How to set a limit on the number of SMTP messages in queues.
• A second reason why the email server can be running out of space is that the Exchange routing engine does not have sufficient permissions to write the messages to the BadMail, Pickup, and Queue folders that are located under the \Mailroot\VSI # folder.
• This problem may occur if your Exchange server received a large amount of spam email messages. In this situation, the BadMail folder fills with messages that your server cannot handle.
• And lastly, the hard disk is almost full.

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

Top 5 Reasons for Email Delays

With the many email tools that users have available to them they are bound to run into problems and compatibility issues at one time or another. One of the activities that many email users employ is the ability to read their emails from outside clients other than Outlook. But when it comes to synchronizing your outside email accounts while at the same running Outlook then issues can arise.

Some email applications only support POP3 access to their end users email folders. While POP3 access from the outside will allow users the ability to read their email messages in an offline mode from other clients such as Outlook, that capability does not extend to being able to synchronize their external email with Outlook. Thus an end user can spend a lot of time performing a manual synchronization which can be a laborious process.

If employees within your company need to access their email from external sources other than Outlook then they can download their external email into Microsoft Outlook and read their email messages. Likewise, end users can delete those messages while running Outlook but those deleted messages will not show up as deleted within their external email applications.

Users can get around these constraints by running versions of their external email applications that support the IMAP protocol which will allow them to read and delete email messages via Outlook and have those read and delete actions reflected within their external email applications.

This capability can most likely be found and enabled via the POP/IMAP settings of your end users email application.

If however your end users require additional synchronization capabilities then here is a list of tools to help with synchronizing Outlook with external email applications.

1. EnterpriseSync is a multi-mailbox automated tool that enables syncing of public folder items with Blackberries, iPhones and other PDAs. Since the tool requires no installation on client systems and it can run as a service this makes it the ideal tool for administrators to manage groups of users. It has the ability to sync Contacts, Tasks and Calendar Items, filter items to be copied based on the category of the item and copy from up to three central folders into one local folder per item type.
2. PSTsync allows your end users to select only the folders they wish to synchronize. Most all folders can be synchronized such as Contacts, Calendar, Notes, sub-folders and even custom folders.
3. Easy2Sync for Outlook keeps your personal store in sync on multiple computers. The free version of Easy2Sync synchronizes the inbox and outboxes whereas the Home Edition can synchronize all email folders. The Business Edition can synchronize all folder types. Easy2Sync supports Outlook 2010 (32 and 64 bit) and portable USB installations for the synchronization of emails, contacts and calendars.
4. SimpleSYN supports synchronization of Outlook data on multiple computers. All emails, notes, tasks, appointments, contacts, deletions and folders are updated and immediately available on all computers. Each Outlook folder can be setup individually for independent synchronization directions such as one direction for new email only.
5. Add2Outlook is a 2-way Outlook calendar, contact and/or task synchronizer for desktops, laptops and mobile devices. Add2Outlook is a client-side solution which offers 2-way folder replication of new calendar items, contact entries or task entries and 4-way synchronization of edits.
6. Qsynchronization for Outlook  can not only copy items between Outlook folders but it can also be used to synchronize folders between PST files on different machines.
7. CodeTwo Exchange Sync is an application which enables automatic synchronization of data between selected folders on Microsoft Exchange Server. Most all types of data are supported by CodeTwo Exchange Sync such as: email, calendar, contacts, tasks, etc. One of the nice features of CodeTwo is its ability to filter items before performing sync operations.
8. gSyncit is a tool which allows you to sync Outlook with Google Contacts, Calendars, Documents with Microsoft Outlook Calendars, Notes, and Tasks.
9. LG Outlook Sync is a utility to synchronize your MS Outlook data with your LG devices. The current LG Outlook Sync supports:  Verizon – enV Touch(VX11000), enV 3(VX9200), Chocolate Touch (VX8575), VX8370, Accolade (VX5600), Cosmos (VN250). MetroPCS (MN240) and U.S. Cellular (UN610). Currently LG Outlook Sync can synchronize your contact and calendar information only.
10. Sync your Samsung Phone’s Contacts/Calendar with Outlook using BitPim.  BitPim can be used to synchronize your Samsung phone with Outlook.

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

10 Tools for Synchronizing Outlook Email

Whether you admin Exchange, Sendmail, MailEnable, Lotus Notes, or any other Internet email system, there are certain things that all these systems have in common. There are certain configurations that must be supported, and others that must not be, which newly live systems often miss. Whether you are an experienced admin, or  relatively new to the world of email, the seven deadly sins of mail server misconfiguration can pop up and bite you. Take heed, and check your systems to ensure you are good to go. Failing to do so can result in very bad things, like being added to DNS Blacklists.

1. Open Relay

Let’s get the worst of the lot out of the way up front. The SMTP protocol was designed to get mail to the destination address. SMTP servers like to relay. Being an open relay not only enables spammers to use your system to distribute their noise, it is the shortest path between point A and point B, where B stands for BANNED FROM SENDING EMAIL. Use one of the open relay tests discussed here to ensure that your system is not configured as an open relay. Do this within the first 10 seconds after opening TCP 25 on the firewall, because it will only be a matter of minutes before spammers scanning for relays try to abuse your system.

2. Plain-text Authentication

For every strong password policy, there is someone who allows plain-text authentication. Practically every mail system on the market that supports client protocols (POP3, IMAP) supports the encrypted versions using TLS (POPS, IMAPS.) Ensure that the product you have chosen supports the TLS protocols, disable the plaintext versions and only allow encrypted authentication to further protect the integrity of your users credentials.

3. DNS errors

Email systems require more records in DNS than any other system, largely because of the number of spammers out there spoofing addresses or running scripts from home machines. Make sure that your email systems have valid A (and CNAME if relevant) records, and also the required MX records for all systems (even outbound only MTAs,) PTR records, and SPF records. If you do not control your in-addr.arpa zone, contact your ISP to add the appropriate PTR records for your mailservers, and see this article on setting up SPF records.

4. Banner information disclosure

Using complex fingerprinting techniques, many email systems can be identified, but it requires skill and patience to do so. Most bad guys out there either use automated scanners to grab banners, or just telnet to TCP 25 and read the response to a HELO packet. Reconfigure all Internet accessible email servers to use a custom banner that does not reveal the version of mail server, or any internal names or ip.addrs. You can indulge your creative side when you do this!

5. RFC 2142 names

Folks, the RFCs are the rules of the road, where the road means the information superhighway we all use. RFC2142 defines certain mailboxes that must be supported on a domain, including POSTMASTER and ABUSE. Both of these are relevant to our interests, as the POSTMASTER address is intended to represent the person(s) responsible for an email system for the domain, and the ABUSE address is where to submit complaints about inappropriate activities, like spamming. Sure, both will get a TON of spam, but you need to set them up anyway, and then check them regularly for legitimate mails from other sysadmins.

6. Not scanning inbound and outbound mail

While it is critical to scan all incoming mail for malware, phishing attempts, and other inappropriate content, it is just as important that you scan outgoing mail to ensure that your users are not leaking state secrets, abusing your corporate email for their own gain, or <gasp> sending out emails as the result of some malware. Ensure that your company has an Acceptable Use Policy, attach a standard corporate disclaimer to all outbound mails, and scan to ensure that prohibited information like customer NPI, or infected attachments are not included in outbound mail. It’s called acting responsibly, and being a good Internet citizen.

7. Not setting reasonable limits

While you may have terabytes of storage, and an OC-48 connection, not everyone else does. Set a reasonable limit on attachment sizes, the number of addressees an outbound email can target, and the rate at which outbound emails can be sent. You do not want your company perceived as a bulk sender, and you don’t want to overwhelm an email system when someone in marketing tries to send the print-ready PDF that is 112MB to all 30 of the contacts at the customer’s business, when they should have saved it as Internet publish ready so it would come in at 867KB and mailed a link so they could download it at their convenience.

While there are plenty of other things that you need to pay attention to (storage, backups, connectivity to name a few) avoiding these seven deadly sins will go a long way towards making your email efforts successful, and help avoid the sorts of things that we like to call career-limiting events.

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

7 Deadly Sins of Mail Server Misconfigurations

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

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

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

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

Memory, disk I/O and processor utilization are the obvious server components to monitor for any application in a production and non-production environment. How an IT department responds to the lack of resources will differ based on the priorities of the applications and more importantly on the budget that is allocated for capital expenditures.

If the server is lacking in memory then the most often knee-jerk reaction is to simply buy more memory. But with Exchange Server there are tuning parameters which can be adjusted to optimize the amount of memory that is needed by the server. Ideally, these adjustments will result in less memory usage by the Exchange Server.

When the store process of Exchange Server 2003 is started, Exchange Server will perform an optimal memory configuration check. If the memory settings are not optimal then an event 9665 is logged in Event Viewer.

This 9665 error can happen for multiple reasons such as:

• The SystemPages value in the registry is set outside the range of 24000 to 31000.
• The server is running Windows 2000 and has 1GB or more of physical memory, but does not have the /3GB switch set in the boot.ini file.
• The server is running Windows Server 2003 and has 1GB or more of physical memory and the /3GB switch is set but the /USERVA setting is not listed in the boot.ini file.

The /3GB switch can be added to the Boot.ini file on the server when the Exchange Server 2003 system has 1GB of memory or more installed and contains mailboxes or public folders. However, it is recommended that administrators do not add the /3GB switch when the systems do not contain any mailboxes or public folders.

Adding or removing the /3GB switch is just one step in the process of tuning Exchange Server for best performance. But keep in mind that with Exchange Server 2003 and the /3GB switch that as the utilization is increased then the efficiency of Exchange Server decreases particularly on systems with more than 4GB. This is due to the fact that Exchange Server 2003 does not support instancing, Physical Address Extension (PAE), or Address Windowing Extensions (AWE). It hits its efficiency limit around the 4GB mark.

There is a lot more to discuss about memory usage of Exchange Server systems and in future blog posts I will discuss other tuning configuration setting opportunities.

With respect to monitoring tools Doug does discuss running Performance Monitor on your Exchange Server to collect statistics on the various Exchange Server components installed on the system.

But other tools that administrators should become familiar with include:

• Exchange Server Profile Analyzer - This tool can be used to collect data about server performance, mailbox storage, user access and mail message routing.
• Load Generator Tool which can be used to test the sending and receiving of email messages (MAPI, OWA, ActiveSync, IMAP, POP, SMTP) to Exchange Server. It can also be used to simulate the load generated by some number of users and email messages.
• JetStress tool which can run performance tests against Exchange Server to test the database and log file loads produced by a specific number of users against Exchange.

Doug has also included a link to an Exchange Server performance monitoring document entitled ‘Troubleshooting Microsoft Exchange Server Performance‘. Administrators who wish to dig deeper into the subject of performance monitoring for Exchange Server will find the document most valuable.

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

Monitoring Performance of Exchange Server

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

In a blog written by Kentc, the author has brought up the subject of Outlook Connectors and their role in allowing email users to synchronize their personal email tools with Outlook. It can be used to synchronize an end-users’ email, calendar, and contacts with Outlook using a technology called DeltaSync.

The Wikipedia definition for DeltaSync is listed as follows:

“DeltaSync is a proprietary Microsoft communications protocol for synchronizing web services with offline clients.[1] Windows Live Hotmail is exposed to offline clients using DeltaSync, and Outlook Connector and the Windows Live Mail client use it for offline access. Microsoft is pushing for this protocol instead of POP3 or IMAP4 for supporting various advanced features like contacts, calendar, notes synchronizing. Using the DeltaSync protocol, Microsoft intends to provide a common platform for any compatible device to implement a client which can two-way synchronize mail, contacts, calendar and notes.”

Kentc has written that many users would like to be able to easily respond to emails from their Outlook application but at the same time indicate that the email they are sending is coming from a personal email application such as Hotmail.
I think that it’s great to have that kind of flexibility but the downside is that it makes it easier for users to be able to slip into spending time on personal email matters at work when they are being paid by their employer for time spent working on matters related to the employers’ business rather than on personal email matters.

Be that as it may, from a pure technology perspective I can definitely get excited about the pure technology and work involved in writing a software tool such as an Outlook Connector.

On the flip side, the author does point out an advantage of this Outlook Connector such as being able to drag an appointment from an employee’s work calendar to their Hotmail Calendar using Outlook’s side by side Calendar support. This can be very helpful for employees in that they can avoid the scheduling conflicts that can happen in the very busy lives that we all lead. And for the employer the same advantage also applies to help reduce scheduling conflicts and miscommunications.

Some of your end users may not want to synchronize all of their folders so administrators can configure the Outlook connectors to support synchronizing only specific folders to Outlook. The steps below outline how to configure the Outlook Connector for sending and receiving emails.

For Outlook 2002 or Outlook 2003 here are the steps to follow:

1. From Outlook, click on Tools and then click on Email Accounts.
2. Click on View or “change existing email accounts”
3. Click the Next button.
4. Click on“Software602 Groupware Server” account and then choose “Change”.
5. Click on the More Settings button, and then the Folders tab.
6. Click on the “Show Only Subscribed Folders” radio button and then select the folders to be downloaded by placing a check mark in the checkbox to the left of the folder name. If you do not want to download email from a folder, click on the check mark to remove it from the corresponding checkbox.
7. Click on the Ok button, then Ok again and then select Finish to save the configuration

Make sure you do not unsubscribe the default Outlook folders such as: Calendar, Contacts, Deleted Items, Drafts, Journal, Sent Item, Notes, Outbox and Tasks. Outlook will automatically recreate these folders on the server if their status changes to unsubscribed.

For Outlook 2007 here are the steps to follow:

1. From Outlook, click on “Tools” and then click on Account Settings.
2. Click on the “Software602 Groupware Server” account and then choose Change.
3. Click on the More Settings button, then the Folders tab.
4. Click on the “Show Only Subscribed Folders” radio button, then select the folders to be downloaded by placing a checkmark in the checkbox to the left of the folder name. If you do not want to download email from a folder, click on the check mark to remove it from the corresponding checkbox.
5. Click on the Ok button, then Ok again, and then select Finish to save the configuration.

Likewise, for Outlook 2007, make sure you do not unsubscribe the default Outlook folders such as: Calendar, Contacts, Deleted Items, Drafts, Journal, Sent Item, Notes, Outbox and Tasks. Outlook will automatically recreate these folders on the server if their status changes to unsubscribed.

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

The Outlook Connector Advantage

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

Are your users on Microsoft Outlook and Exchange server  complaining about lethargic performance? Here are some things to troubleshoot when you want to quell the griping.

1. Antiquated Software. Are you still on Exchange 2003? That old 32-bit warhorse will have a tough time meeting the email demands of a modern organization. New 64-bit versions of Exchange–2007 and 2010–support more memory and bigger buffers, as well as other speed enhancements. As a result, they can be from five to 10 times more efficient than 2003 in handling mail. While upgrading to a new version of Exchange isn’t an immediate solution to your problems, it’s something to advocate as a long term solution.
2. Mailbox Limits. Both Exchange 2003 and 2007 have 2GB limits on mailbox sizes. However, Outlook users can  exceed those limits. The rub is, the greater that 2GB limit is exceeded, the bigger the hit the user will see in performance. One way to address that problem is to deploy an archiving solution. It will automatically archive a user’s emails when his or her mailbox approaches or exceeds the 2GB limit.
3. Overstuffed Folders. Too many messages stored in a single folder will impair Outlook’s performance. Microsoft recommends that between 3500 to 5000 messages should be placed in a single folder. An archiving solution can address this folder problem, too, as well as creating more top-level folders or sub-folders in folders with high growth rates such as Inbox, Sent and Calendar.
4. Anti-Virus Software. Local anti-virus software can make Outlook work harder than necessary. Each time a message is opened, its body and any attachments to it are scanned by the anti-virus software. That can result in delays of as much as 20 seconds. An alternative to local virus scans is to scan messages in transit at the Exchange Hub Transport servers. With malware scans performed at the servers, you can disable scanning at the client end of things and boost performance for your users.
   
5. Flakey Indexing. Indexing was introduced into Outlook in 2007. It’s a great feature because it quickens the time it takes to find anything in the program. If the index  is corrupted, however, the function can cripple Outlook. How do you know if the index is corrupt? If Outlook never seems to finish indexing messages, that’s definitely a sign that something is wrong with the feature. The best thing to do then is to delete the index and re-index all your messages. Yes, that’s going to slow things down in Outlook for a while, but faster performance will be the reward at the end of the process.
6. Too Many Rules. Users create rules in Outlook to manipulate messages in the program. Messages from the boss, for instance, might be shipped to an Ignore Until Harassed folder. The amount of space allocated to each folder for rules is 32KB, which will accommodate 40 to 50 rules. As a folder approaches the space ceiling, Outlook starts to slow down. The solution to this problem is simple: use fewer rules in your folders.
7. The Myth of New Hardware. A brand new desktop will run faster than a four-year-old clunker, but you should be careful that new hardware isn’t masking old problems. A user with an old machine and 80,000 messages in his or her inbox may see a performance boost with a new machine, but that doesn’t remove the fact that there were too many messages in the inbox in the first place. What’s more, while the user with the new computer may be whistling along at his or her desk, those 80,000 messages are still taxing Exchange’s performance and in turn, hurting other users on the system.
8. Shared Folders Headache. Outlook 2007 and 2010 turn on by default shared folder caching. That can create performance problems, especially for Outlook’s calendar module. You see, with shared folder caching on, when you open another person’s calendar, the entire calendar is sent to your calendar. What’s more,  when you’re online, Outlook syncs your calendar with all the calendars you’re linked to on your system. That can really slow things down. It can take up to 20 seconds before your calendar is displayed. The simple solution to that problem is to turn off shared folder caching.
9. Wacky MAPI. Most of the devices in Outlook/Exchange environments use MAPI to communicate. That can create bottlenecks for both clients and servers. On a client, for example, you may have Outlook, Microsoft CRM, integrated voice mail and an email archiving application all trying to send and receive information on a single network adapter. On the server side, you have numerous requests being sent  to your server from numerous devices deployed by numerous users. One way to address those problems is to scale your Outlook/Exchange environment on the basis of the number of devices on the network, not the number of users. In addition, efforts should be made to control the number of MAPI devices in use on the system.
10. Disappearing DNS. Although it’s not a common problem, sometimes a user is sent to a phantom server by a corrupt DNS. When Outlook can’t find the phantom server, it has to search for another. That results in delays that users see as slow performance. Running Exchange’s “Best Practice Analyzer” will most often identify those kinds of DNS problems.

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

10 reasons why Outlook is running sooooo slowly

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

Most people who use Outlook will know that individual email messages can be marked with different priorities.  Usually this is used solely as a way to flag the importance of the email to the recipient, and people who receive large volumes of daily email will often use filtered views to bring the highest priority emails to the surface for action.

What a lot of people don’t also realise is that the priority flag on a message can also be used by Exchange Server 2010 to deliver high priority messages before normal or low priority messages.

This capability becomes important in Exchange environments that are very large, complex, or spam geographically diverse areas.  In these types of environments email latency can become noticeable, unlike smaller environments where a few hundred recipients on one or two servers see virtually no delay in sending and receiving email.

When you combine long distance with high volume it is easy to see how important emails might be delayed in an unacceptable way if they are simply processed in a “first in, first out” order.

Priority Queuing is enabled on Hub Transport servers and is performed on a server by server basis.  By default it is disabled, so the administrator is able to choose which servers have priority queuing enabled and can do so only where necessary in the organization.

In addition to turning the feature on or off the administrator can also configure a size limit for email messages to be treated according to their set priority.  For example, a size limit of 512Kb would mean that any emails larger than that which are flagged as High priority will be downgraded to Normal priority.  This is something to be considered carefully by the administrator depending on the nature of the business – if the highest priority emails often contain attachments (eg contract bids and tenders) then a low size threshold would negate the benefit of priority queuing).

The server can also be configured with different delay notification thresholds for each priority.  Obviously a high priority message that is delayed for more than 30 minutes warrants a notification, whereas a normal message can withstand a longer delay without notifying the sender.

When priority queuing has been enabled it opens up the possibility that some email users will abuse it by unnecessarily setting High priority flags on messages that do not specifically warrant it.  There are two ways to control who can use priority queuing in the organization:

• Per-Mailbox – each mailbox has a setting to downgrade any High priority messages to Normal priority automatically.  By default this is disabled, and so when priority queuing is enabled in Hub Transport servers anyone can make use of it.  This per-mailbox setting could be turned on for all users with a script or template used at time of mailbox creation.  Alternatively it could be set only on users identified as regular abusers of the feature.
• Transport Rules – another approach would be to use a Transport Rule to detect any messages set as High priority, and if they are not sent by approved users of the feature take action such as reject the message.  This is probably a bit heavy handed and would deny the users the ability to use priority flags to signal the importance of a message to other users in their inboxes.

Although useful within the organization priority queuing is of no benefit once the email leaves the organization and is sent to an external party.  Any delays or problems experienced outside of the organization could still impact the timely delivery of high priority emails.  So while it I useful for several scenarios it is not a 100% solution to all high priority message delivery.

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

Exchange Server 2010 Priority Message Delivery

Developing an email retention policy is an important step in every company’s email management process. And as always every organization’s retention policy will differ depending on the needs of the company, the industry they belong to and the resources available to them. The purpose of having an email retention policy is to help employees determine what information should be retained and for how long based on what emails – or even instant messages – are sent or received by the employees.

Most companies must be prepared to respond to the legal discovery process which, if not planned well, can use up valuable time and personnel. This sometimes means that companies must be able to produce emails upon demand and often within extremely short timelines.

Email administrators should operate from the position that every email their company sends or receives will at some time be requested to be produced and displayed in a court of law. It is the administrator’s responsibility to manage and retain all emails as targeted for retention in an email retention policy. But to help develop a good email retention policy IT departments and administrators should always meet with their companies’ legal department to help formulate valid email retention strategies.

Here then are some of the basic best practices for an email retention policy:

1. Define what categories of email must be retained. This step is to ensure that all employees understand what constitutes a retainable email record for the purpose of e-discovery. Such a definition of a “retainable email record” might include: Any document that relates to company business and is of the nature of being informational, communicative or as part of a decision making processes such as; made or received in connection with the transaction of company related business functions and could thus be created, received, retained, maintained or filed by the company as evidence of its activities or because of the informational value of the data in the document.
2. Define what categories of email does not have to be retained and may therefore be deleted during the course of regular business. This list may be modified when additional types of email are identified as not qualifying as retainable email records. Such categories that might be identified as not required might include:
   - Personal e-mail unrelated to company business.
   - Spam or unsolicited advertisements or sales promotions.
   - Email that is only facilitative and not substantive. For example, emails that schedule meetings or appointments.
   - Any attachments to email that are identical copies of forms, records, reference books, or any other materials that are made, or acquired, and preserved solely for reference.
   - Any attachments to email that are duplicates of documents or records that have been stored and managed outside the email system.
3. Organizations will need to have systems in place that enable the identification of all sources of potentially relevant data, including legacy data, back-up media, deleted data, portable media, remote, or third-party locations under their custody or control.
4. Terms and definitions should be clearly defined. Such terms and definitions might look like the following: “Approved Electronic Mail” includes all mail systems supported by the IT support group. “Approved Encrypted email and file techniques” includes the use of DES and PGP. “Approved Instant Messenging System” includes AOL, Pidgin, Trillian, Digsby, etc.
5. A description of what information must be included on the properties page of each email record identified for retention. Such properties could include: the date and time sent and received, the recipients email address and name, the subject line, any parties listed on the blind copy list, who opened the email, and any other information which the IT department and legal department deems as requisite for retention.
6. Lastly the responsibility for the email retention policy should be clearly defined within the policy. An example of such a policy might be: “The Information Technology department is responsible for ensuring the efficient use of email systems and email retention enforcement according to this policy. Where issues arise, the IT department will interact directly with the employee and notify their manager as necessary. The interpretation of appropriate use and future revisions of this policy are the responsibility of the IT and legal departments of the organization.

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

Six Email Retention Best Practices

Email administrators of Exchange Server have at some time or another implemented a Public Folder for their organization as a means to store messages, files (as message attachments), calendars or contacts. Some of these folders never really get used very much but other organization’s public folders are heavily used. Those folders that are heavily used must be planned for very well in order to be managed for their database size and expected growth rate.

A ‘best practices and best policies for managing public folders’ that are heavily used must also be defined by the email administrators responsible for their implementation. Here is a list of best practices to follow when planning, deploying and managing public folders.

1. Before you decide to implement Exchange Server public folders, an IT department should determine that the functionality provided by public folders will meet the business needs of the organization.  Evaluate the features and functionality that are provided by public folders and match those features and their benefits with the needs of the organization.
2. Determine which clients and/or department within your organization will benefit from using public folders. Decide which of the two available top-level hierarchies for public folders and the type of top-level hierarchy is best needed by your organization.
3. Implement the process of “referral” whereby a user will be redirected to another store of copy content should the first public folder store they connect to not include their expected content.
4. Configure Exchange Server to optimize message delivery for public folders and set their mail-enable or mail-disable status as appropriate for your organization. Mail-enabling allows authorized users to post items to public folders by using standard email.
5. Plan for capacity. This is a very basic step in the planning process but one which can help to avoid problems long after a public folder has been placed into a production environment. The first step in the capacity planning process is to determine how much data will be stored in the database. This will allow administrators to calculate their database size and from there extrapolate future data size amounts based on estimated growth rates. And to ensure that those growth rate estimates stay on target another best practice is needed.
6. Monitor the size of the public folder. Administrators must constantly monitor their public folders as this will help them to determine if their original growth rate assumptions were underestimated, on target or overestimated. If any changes are introduced into the environment such as unplanned for additional users then the original growth rates should be adjusted to incorporate the new growth estimates. Overall database and individual folder growth should be monitored on a server by server basis to avoid growing database problems in the future.
7. Include the overhead associated with the database. As a general rule, to determine the size of the database the amount that is stored should be multiplied by a scaling factor of 1.6. This 1.6 value has been determined by Microsoft through tests and is used as a general guideline based on averages. Microsoft does not recommend running a public folder on databases that are less than 1.6 times the size of the data. This 1.6 scaling factor is associated with the maintenance and the process of preparing and maintaining the database indexes. For example, if your database must store up to 2 GB of data, you should plan to implement a 3.2 GB database.
8. On a regular basis administrators should examine the daily amounts of content replication and hierarchy replication as these replicated data can also affect growth rates of databases. Monitoring the physical growth rates of the data stored on the disk drives.
9. It is very important to maintain the online database in Exchange Server. Some of those online database tasks can include:
   •    Delete messages which have passed their deleted item retention date.
   •    Ensure that messages in public folders are marked as expired once they have passed their expiration dates.
   •    Watch for deleted mailboxes and confirm the contents have been deleted.
   •    Free up additional database space through online defragmentation. This means that database objects which are no longer used are marked for deletion and removed.
   As part of an online maintenance best practices it is a general rule to run online maintenance at least four hours a day. Make sure that a full online maintenance schedule is completed at least once a week.
10. Another important best practice when you manage data on public folder databases is the enforcement of appropriate policies for content expiration and size limit. It is very important for administrators to set and implement limits on the folder sizes before they are made available to end users.

If administrators follow these general practices they will ensure a high level of performance for their organization and of the use of their public folders.

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

Ten Best Practices for Exchange Server Public Folders

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

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

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

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

The situation which Paul describes in his post is that of essentially creating filters so as to prevent abusive emails sent to co-workers but this capability could also be used to block or filter out emails of a political nature which could become the basis for a challenge to the right of free speech. I know this sounds a little extreme but let’s see how this could possibly play out using Transport rules.

The way this type of a word filtering Transport rule would work is that a rule would be configured to include:

• A condition that would identify email messages sent from internal senders to internal recipients.
• The condition would identify certain words or phrases in the email subject, body, or attachments.
• An action to be applied against any email that matched the condition above.
• And any exceptions to that rule would also be created.

So in our example, if a company or any other organization decided that email messages that contained the words “Libertarian Party” were to be identified as inappropriate they could create a Transport rule which recognized those key words and then sent those emails to the “bit bucket” or trash can. Exceptions to the rule might be something along the lines of if no profanities were found in the email then let the email message pass through to the internal recipient.

Another possible action to be taken when a Transport rule was initiated is to redirect the filtered email to the company’s legal department or to security for further review.

I do agree with Paul that implementing a company wide filtering system such that every internal email sent is scrutinized by a key word or phrase methodology would be very complex and costly in terms of not only compute resources but capital outlays.  There would sure to be some overhead from using a single centralized filtering system as a single point of failure that would most likely impact performance and prove costly should the system ever go down.

Paul points out that even “…Exchange Server’s own anti-spam filtering can’t help.”  He notes that any emails sent between mailboxes within the same organization is given a Spam Confidence Level (SCL) of -1 (on a scale of 0 to 9) which means that Exchange Server is treat the email message as trusted.  With a “-1” SCL value assigned to the email message this basically eliminates any further SCL-based filtering decisions from being applied to those emails. This could also mean that the email sender had possibly been white listed in some manner.

A SCL value of 0 means that email message is most likely not spam whereas a SCL value of 9 means that the email message is most likely spam which would make that email message obviously eligible for SCL-based filtering decisions to be applied.

It is for these reasons that Transport rules should be considered as a component for any email content filtering system that requires an intra-company email messaging filtering capability. And since administrators can configure this feature centrally the benefit is that the effect is rippled across all Hub Transport servers in the organization allowing for a streamlined and distributed implementation.

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

Exchange Server 2010 Email Abuse Prevention