Update Rollup 5 for Exchange 2007 SP1

The Update Rollup 5 for Exchange 2007 SP1 has been released and is available at Microsoft Download Center.
So would recommend that you should plan for its install as this has fixed quite a lot of issues.
More details at MS Exchange Team Blog.

Information Store Crashing, Exchange 2007

The Microsoft Information Store Service (Store.exe) is repeatedly crashing an Exchange 2007 Mailbox Server.
In the application log, we get the following error message and store.exe is crashing due to EXCDO.DLL file:

Faulting application store.exe, version XXXX, time stamp XXXX, faulting module EXCDO.DLL, version XXXX, time stamp XXXX, exception code XXXX, fault offset 0x00000000001ed390, process id 0x1fc8, application start time XXXX.

Have opened up a case with MS PSS and had them analyze the crash dumps. They have identified it as a Bug. The issue is casued by Mac's, Entourage clients that does calendar bookings in the ICS format and the crash is occuring due to Entourage Client accessing a badly created ICS.
MS will provide a fix to this issue in Update Rollup 6.

If anyone is experiencing this issue, make sure you call MS PSS first thing and have them provide the temp bug fix to you.

Web Services, Exchange 2007

Now that we have finished the final phase of our migration and we have fully migrated the Public Folders to the new Exchange 2007 environment, want to talk about this exciting new component of Exchange 2007, that is the Web Services. Well I think this is the most exciting and amazing new feature in Exchange 2007 that makes life very easy of an Exchange Admin.

The Web Services that are included in Microsoft Exchange Server 2007 provide an XML messaging interface for managing Exchange store items and accessing functionality on a computer that is running Exchange 2007 from client applications.

Exchange 2007 includes the following Web services:

1. Exchange Web Services
2. Autodiscover Service
3. Unified Messaging Web Service

1. Exchange Web Services

Exchange Web Services provides the functionality to enable client applications to communicate with the Exchange server. Exchange Web Services is deployed with the Client Access server (CAS) role. Microsoft Exchange Server 2007 clients connect to the computer that is running Exchange 2007 that has the Client Access server role installed in an Active Directory directory service site by using an HTTPS connection.

Some of the main operations that Exchange Web Services provide are:

• The Availability Service: Outlook 2007 clients can use HTTPS to connect and download free and busy data for other users through the Availability Service. Unlike previous versions of Exchange, free/busy data does not have to be stored in public folders, instead we access the target mailbox’s free/busy data directly from the calendar (via the Availability service).
• OOF: The ability to set Out-Of-Office messages is controlled by a new web service.
• OAB Distribution: Outlook can use HTTPS to locate and download the Offline Address Book (OAB) from a web distribution point.
• The Exchange Data Service operations: The Exchange Data Service operations enable the handling and organizing of items, folders, and attachments, as well as ambiguous name resolution and distribution list expansion.
• Notification and Synchronization Operations.

2. Autodiscover Service

The Autodiscover service provides a mechanism to automatically configure Exchange 2007 client applications to access the Client Access server.

It is used to set up client applications like Outlook to work with Exchange by returning configuration data that is necessary for applications to function properly without requiring users to know where to fetch the data, such as discovery of the server that hosts a user's mailbox.

3. Unified Messaging Web Service

The Unified Messaging Web Service provides an extensibility point for clients to read and change information about Unified Messaging properties. If your mailbox is enabled to use Exchange 2007 Unified Messaging, you can use Outlook 2007 to play a voice message back to a phone.

Will discuss about their configuration in detail in the coming posts :-)

Get HUB server stats from Message Tracking

Now in Exchange 2007, from Command Shell using Message Tracking, you can pull out some of the very exciting statistics which were never so easy from the previous versions of exchange.

Here we are talking about pulling up records like:

• Number of emails sent by HUB servers over a given period of time.
• Number of emails received by HUB servers over a given period of time.
• Number of emails sent by a particular sender or received by a particular recipient over a given period time

Example: To get the number of emails sent by a HUB server, run this command from EMS:

Get-MessageTrackinglog -server -start "MM/DD/YYYY hh:mm am/pm" -End "MM/DD/YYYY hh:mm /pm" -event SEND -ResultSize 999999 I measure-object

Similarly you can add the switches like -event RECEIVE to get the number of message recieved, -Sender "Email address" to get from a particular sender etc.

Read this article from Bharat Suneja to get more details on Message Tracking from Exchange Server 2007

Playing with RSG | Database Restore

This came across few days back when one of our production Exchange 2003 backend server went down due to hardware failure and was totaly dead.The Backup team was shortly in action to carry out the restore. The restore was done on the different server in a Recovery Storage Group (RSG).

Now the question is how to merge these mailboxes in RSG with the production ones... certainly direct merge was not possible as we didnt opt for Dialtone method as the production server was totaly dead and we didnt set up a new server to replace that one.

The one option was to to extract the mailboxes from RSG using Exmerge, delete the existing mailboxes of users and create new ones on another server, and then import that extracted mailboxes. But this is very time consuming.
However here's an another option to tweak the RSG to make it behave as the production store and move that mailboxes over.

The Recovery Storage Group is identified by the msExchRestore Attribute. The msExchRestore = TRUE property tells us if a database is a recovery database.
As such we cannot directly connect the mailbox from the RSG to user direcly. We have to modify this msExchRestore Attribute and make its value to Not Set so that it cannot be identified as RSG and we can connect the mailbox to the user.

The detailed steps are as follows:

1. Reset the MsExchRestore attribute on both the Recovery Storage Group, and the recovered mailbox store using Adsiedit:

Expand the Configuration Container node, and then browse the hierarchy to:
DC=Domain
DC=com
CN=Configuration
CN=Services
CN=Microsoft Exchange
CN=Administrative Groups
CN=Administrative Group Name
CN=Servers
CN=ExchangeServerName
CN=InformationStore
CN=Recovery Storage Group

Right click for Properties on the Recovery Storage Group, ensure that the checkbox for "Show Optional Attributes" is checked. Scroll down to the "MsExchRestore" attribute. Double-click the MsExchRestore attribute and check the Not Set parameter. Click OK, Apply, and OK to exit the properties pane.
Right click the "CN=MailBox Store(ServerName)" under the Recovery Storage Group, and select Properties. Ensure that the checkbox for "Show Optional Attributes" is checked. Scroll down to the "MsExchRestore" attribute. Double-click the MsExchRestore attribute and check the parameter. Click OK, Apply, and OK to exit the properties pane.
Close the AdsiEdit mmc

2. Now from the ADUC>Exchange Tasks, delete the mailboxes of the users that are in question.

3. In Exchange System Manager select the Recovery Storage Group, right click and select Refresh. Expand the Recovery Storage Group, then the mailbox store.

4. Select "Mailboxes" under the Mailbox Store, then right click the mailbox to be recovered, and select "Reconnect". The applet "Select a New User for this Mailbox" applet will appear. Enter the alias of the user you wish to associate with the recovered mailbox into the "Enter the Object Name to select" data entry field, the click "Check Name". The alias of the user should be resolved to the full display name. Click OK. You will see a pop-up stating "The operation has completed successfully".

5. Once its done for all the users, you can successfully move the mailboxes over to any of the servers.

IMAP not working for users | Mailbox server in different AD site than CAS

Here we have a cross site scenario where users from one site are trying to connect to the CAS that is on the different site.

By default, POP3 and IMAP4 connectivity between a Client Access server in one Active Directory site and a Mailbox server in another Active Directory site is not enabled. The Client Access server prevents users from logging on to their mailboxes by using POP3 or IMAP4 if their mailboxes are located on a Mailbox server in a different Active Directory site.

And we get the following warning in the application log of the Client Access Server:

User "User-Name" was prevented connecting to his/her mailbox because the Mailbox Server resides in a different ActiveDirectory site (CN=Site A,CN=Sites,CN=Configuration,DC=domain,DC=com) than the Client Access Server (CN=Site B,CN=Sites,CN=Configuration,DC=domain,DC=com) to which he/she connected. Either arrange for the Client Access Server and the Mailbox Server to reside in the same site, or change the configuration setting of AllowCrossSiteSessions to true.

To enable cross-site connectivity for POP3 and IMAP4 clients:

1. On the Client Access server, locate the POP3 and IMAP4 configuration files. By default, the location is C:\Program Files\Microsoft\Exchange Server\ClientAccess\PopImap.
2. Use the text editor to open the configuration files. The two configuration files are as follows:
   Microsoft.Exchange.Pop3.exe.Config
   Microsoft.Exchange.Imap4.exe.Config
3. Search for the key AllowCrossSiteSessions. add key="AllowCrossSiteSessions" value="false" /
4. Edit the line of the configuration file as follows. add key="AllowCrossSiteSessions" value="true" /
5. Repeat the steps in this procedure for each protocol for which you want to enable cross-site connectivity.
6. Restart the services for each configuration file that you have updated to enable cross-site connectivity.

More Details at Microsoft Technet.

500 Internal Server Error when using OWA with /Exchange

You get this 500 - Internal Server error while you access Outlook Web Access from https://CASServer.domainname.com/exchange while https://CASServer.domainname.com/owa works fine.
This happens when you have seperate Exchange 2007 Mailbox and CAS servers. Ideally the request should be redirecetd to /owa but you get 500 - Internal Server Error right after typing in your credentials in the forms login page.

This happens due to the fact that redirection is not working because ISAPI Extensions are not installed on the Mailbox Server. ISAPI extensions handle specific incoming requests to the IIS server. Extensions are loaded when they are first needed and kept in memory until the host process shuts down.

To fix this issue, please install the ISAPI Extensions on the mailbox server.

Here is the command that you have to run from the EMS to install them:

ServerManagerCmd -i Web-ISAPI-Ext

Make sure to do an IISRESET after this.

Storage Group not responding | Version Store Issues

This happend few days earlier on our exchange server... all users in a particular Storage Group were not able to connect to Outlook/OWA. The mails queued up for them on the server...
On looking at the server logs... there were lot of logon error messages... users were not able to logon to their mailbox... and at the beginning when it all started, there was one error message with Event Id 623. It says:

Information Store (2984) Storage Group 1: The version store for this instance (3) has reached its maximum size of 155MB. It is likely that a long running transaction is preventing cleanup of the version store and causing it to build up in size. Updates will be rejected until long-running transaction has been completely committed or rolled back.

Analysis

The Version Store keeps an in-memory list of modifications made to the database. It gives ESE the ability to track and manage the current transactions. Thus the Version Store is where transactions are held in memory until they can be written to disk.

Event 623 is the result, typically of a long running transaction. The result of this long running transaction is to exhaust resources in the version store. As a result, the Version Store no longer reaps deleted records causing unneeded data, which is marked as deleted, to accumulate in the database. The accumulation of unneeded data can exacerbate performance problems which can lead to event id 623. No more transaction can continue until this is clear.

Thus we will see 623 event indicating that the maximum Version Store size has been reached . All the Write operations to the database will fail because there's no more version store space to record the operation.

Why this happens

This can happen for one of the two reasons:

1) In order to properly reconcile write-conflicts and properly support repeatable reads, a given entry in the version store cannot be cleaned up until it is older that the oldest active transaction.
2) Version Store cleanup simply cant keep up with the load on the machine.

Possible Causes

- Online Maintenance Tasks running at peak times.
- Backups running at peak times.
- Disk I/O performance.
- Large Mails

Any of these can add up simultaneously and add to the performance degrade of the server.

More details and troubleshooting on this.

Useful Exchange Management Shell Cmdlets

Convert a legacy Exchange 2003 "resource" into a room mailbox in Exchange 2007

Move the mailbox to an Exchange 2007 server
Run: set-mailbox [MailboxName] –type Room
Then run: set-mailboxcalendarsettings [MailboxName] –AutomateProcessing AutoAccept

Configure the conference room resource mailboxes to remove attached files from meeting requests

Get-Mailbox - RecipientTypeDetails RoomMailbox Set-MailboxCalendarSettings -DeleteAttachments:$true

Get a list of Exchange ActiveSync users

$mbx = get-casmailbox where {$_.hasactivesyncdevicepartnership -eq $true -and $_.identity -notlike "*CAS_{*"} ; $mbx foreach {$name = $_.name; $device = get-activesync devicestatistics -mailbox $_.identity; $device foreach {write-host $mbx.name, $_.devicemodel, $_.devicephonenumber, $_.deviceid, $_.FirstSyncTime, $_.LastSuccessSync} }

Get details of single EAS mailbox

Get-ActivesyncDeviceStatistics -mailbox user@domain.com

An inappropriate message that has the subject line of exchange is sent to all users on the Exchange server 2007 mailbox server named Exch1. You need to delete this message from all the mailboxes.

Create a new mailbox named TempMailbox that has a folder named Export. Run the Get-Mailbox -Server Exch1 Export-Mailbox -TargetMailbox TempMailbox -TargetFolder Export -SubjectKeywords "Exchange" -DeleteContent cmdlet.

Get list of all user mailboxes with a list of email addresses attached to each user.

get-mailbox select-object name, alias, primarySmtpAddress Export-Csv C:\mailboxes.csv -NoTypeInformation

Generic User Accounts | Exchange 2007 Shared Mailboxes

In an organization, there are mailboxes required that are shared by many individuals in a particular department... I will say them as generic accounts that a group of people use for common mail access. However, the Information Security team may take it as offensive as they have an active mailbox enabled user account... and if you decide to close on them, it becomes really difficult as users are used to them as it helps them to organize and manage their tasks efficiently... and instead creating the Distribution List with the same email address won't solve the purpose.

In Exchange 2007, we have concept of shared mailbox recipient type. When we create a mailbox as 'shared' it creates a disabled active directory account to which the mailbox is connected. Shared mailboxes do not have an associated password so we must grant mailbox permissions for the users requiring access to that mailbox.

Advantages

• Disabled accounts act as a security measure.
• Since the user account is disabled by default no initial password is required.
• If desired, existing mailboxes can be converted to shared mailboxes. Users can still be able to access emails and continue to receive emails on that mailbox.
• Will let the users to continue their operations more or less the same way.
• No need to setup Distributions Lists on account of closure of their respective generic accounts.

Public Folder database dismounted after you move all the Public Folder Replicas from Exchange 2003 server to Exchange 2007 server

Issue with Public Folders

It has been observered that when we decommision the Exchange 2003 server after moving all the Public Folders Replicas from it to the Exchange 2007 Server, the Outlook stops connecting for all the clients... Public folders doesn't show anything from Outlook Web Access and even Public Folder Management Console on Exchange 2007 server doesnt show any of the Public Folders and the Public Folder database doesnt mount.

This typically happens when we manually remove the Exchange 2003 server hosting earlier all the Public Folder replicas.

This happens because the msExchOwningPFTree attribute had its value missing. This msExchOwningPFTree attribute controls the Public Folder database path and contains a list of all the stores in the hierarchy.

We need to specify its correct value in order to make Public Folders work. We can do it from ADSI Edit tool.

• Start the ADSI Edit tool
• Expand the Configuration container, then expand out each container as follows: CN=Services then CN=Microsoft Exchange then CN=YourExchangeOrg then CN=Administrative Groups then CN=AdminGroupofyourPFServer then CN=Servers then CN=YourPFServer then CN=InformationStore and then click on CN=StorageGroupContainingYourPFStore. In the pane on the right you see the public store object listed. Right click on the object and click on properties.
• In the list of attributes, double click on the msExchOwningPFTree attribute and specify the correct value.
• Restart Microsoft Exchange Information Store service.

Here is the Microsoft KB article that will help you to determine the correct value of msExchOwningPFTree attribute and set that up.

Find Users not using Default Exchange Storage Limit set via Mailbox Policy

Here's an LDAP query that I use frequently to search and display all the users in the domain that do not have the default mailbox store policy set.

(&((mailNickname=*)(mDBUseDefaults=FALSE)))

Windows update available that will turn off the SNP

There is a new High Priority Windows update available that will turn off the Scalable Networking Pack features which are installed by default in Windows 2003 SP 2.
http://msexchangeteam.com/archive/2008/03/12/448421.aspx
You have to reboot the server after applying this update.

SMTP Connectors | Exchange 2007

Microsoft has split connectors in Exchange 2007 into Receive Connectors and Send Connectors.

This transition to a separate send/receive configuration scheme makes it a lot easier to tell Exchange how you want it to behave, while minimizing the chances that you're going to change a parameter and cause unintended consequences.

By default, when you install the Exchange Hub Transport role, it creates two default receive connectors. If you've installed Exchange 2007 into an existing environment with 2003, then you probably already have a Send Connector (SMTP Connector).
While Receive connectors represent an inbound connection point for SMTP, Send connectors relay outbound communications.

The two default receive connectors are configured for authenticated SMTP transactions only.
The "Default" receive connector on Hub is configured for other Exchange servers to authenticate, but it does not accept anonymous email by default.

So users receive the following NDR when they try to send mail from any external address:

This is an automatically generated Delivery Status Notification

Delivery to the following recipient failed permanently:

test@Ex2007domain.com

Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 12): 530 5.7.1 Client was not authenticated

The easiest way to address this is to add the "Anonymous users" on the Default Receive Connector.

Here is an excellent MSExchange Team Blog for Configuring Exchange 2007 Hub Transport role to receive Internet mail.

Public Folders not able to receive External Emails

When we set the Mail Enabled Public Folders, it receive all the internal emails fine but is unable to receive any mail from outside and throws the NDR to the sender:

This is an automatically generated Delivery Status Notification.

Delivery to the following recipients failed.
abc@xyz.com

Final-Recipient: rfc822;abc@xyz.com
Action: failedStatus: 5.2.1
X-Display-Name: abc

This happens when Permission to Anonymous is set to None. Make sure Anonymous has atleast Contributor rights.

Stats Setup for monitoring the Website

Few days back, I needed to set up the monitoring for my front-end webmail server for bandwidth usage, number of hits, tracking of IP addresses, browsers etc... I looked into the number of options but inarguably found that Awstats is the best in this business.

AWStats is a free powerful and featureful tool that generates advanced web, streaming, ftp or mail server statistics, graphically. This log analyzer works as a CGI or from command line and shows you all possible information your log contains, in few graphical web pages.

The Setup consists of 5 major steps:

1. Installing Perl
2. The AWStats Setup
3. Setup IIS Logging
4. Setup AWStats Config File
5. Scheduling Log File Analysis

1. Installing Perl

Download the Perl binary for Windows. Grab the MSI version. GO ahead and run the install.
It will automatically create the Web Service Extension mapping in IIS. However you need to allow that from IIS manager.

2. The AWStats Setup

Now that Perl is installed, we can get AWStats all setup.

1. Run the Setup. Select all the defaults.
2. Copy the contents of its Bin directory to C:\Perl\Bin Folder.
3. Go into IIS Manager, create the virtual directory named stats under default Website for C:\Perl\Bin.
4. Give Execute Permissions, select Scripts and Executables from the dropdown.

3. Setup IIS Logging

Right click the website to be logged, go to properties, and then on the Configuration tab, check off
Enable Logging (if it isn’t already). Select W3C Extended Format from the dropdown, and then click Properties.
Proceed to the advanced tab and uncheck everything. There are certain items here that we’ll tick back off. Namely, the following items should be checked:

Date (date)
Time (time)
Client IP Address (c-ip)
Username (cs-username)
Method (cs-method)
URI Stem (cs-uri-stem)
Protocol Status (sc-status)
Bytes Sent (sc-bytes)
Protocol Version (cs-version)
User Agent (cs(User-Agent))
Referrer (cs(Referrer))

The IIS end is now done, the final step is to setup the AWStats.conf file.

4 . Setup AWStats Config file

It is already copied in the C:\Perl\Bin Folder directory. Copy the existing config file and save it as awstats.mywebsite.com.conf.
*mywebsite.com = name of the website you want to monitor.

The first parameter to setup is your log file item. The only important part is the final piece at the end with the date time codes. Here's the line from my config file below:

LogFile="C:\WINDOWS\system32\LogFiles\W3SVC1\ex%YY-0%MM-0%DD-0.log"

The config file and documentation say that one should specify LogFormat=2 for IIS. Unfortunately, IIS 6 does not follow this predefined format, so we’ll have to specify our own:

LogFormat="date time cs-method cs-uri-stem cs-username c-ip cs-version cs(User-Agent) cs(Referer) sc-status sc-bytes"

Then we have to specify the value of Site Domain. Site Domain must contain the main domain name, or the main intranet web server name, used to reach the web site.

SiteDomain="www.mywebsite.com"

5. Scheduling Log file Analysis

AWStats only analyzes log files when told to do so. It can easily be toggled from the command line, and running a scheduled task to do this is the best solution.

Here’s a command that look like:

c:\perl\bin\perl.exe awstats.pl -config=mywebsite.com –update


All set now, you can access the stats from http://mywebsite.com/stats

Out of Office Assistant not Working

The OOF message is a hidden entry in a user’s mailbox. The Out of Office Assistant creates a set of two rules in the Inbox subtree. The first contains a Message Class of IPM.Note.Rules.Oof.Template.MicrosoftMessage, whilst the other rule contains a Message Class of IPM.Note.Rules.OoFTemplate.Microsoft. If one or both of these rules are corrupted or unsynchronized with the OOF-enabled indicator, then it’s possible that the Out Of Office notification may no longer work.

To resolve this, use the Mdbvue32 (Microsoft Exchange Server Information Store Viewer) utility which can downloaded from here to delete the two entries for Out of Office.

Here are the instructions:

1. Run mdbvu32.exe.
2. Click OK to clear the first window that pops up.
3. Make sure that your profile is selected in the Choose Profile window and click OK.
4. Click on the MDB menu option.
5. Click on the OpenMessageStore option.
6. Make sure that "Mailbox- [user's full name]" is selected and click on Open.
7. Click on the MDB menu option again.
8. Click Open Root Folder.
9. In the Child Folders box - double click on "Top of Information Store".
10. In the next Child Folders box - double click on "Inbox".
11. Look in the Associated Messages in Fld box. All of your rules are in this box.
12. Examine each row of entries that appear under Associated Messages in Fld by double-clicking the CB items one at a time.

You are looking for two items that have the following message properties:

• The item that contains a message property Ox65EB that displays either OOF Rules or MSFT:TDX OOF Rules.
• The items that contain a message property PR_MESSAGE_CLASS that displays IPM.Note.Rules.OofTemplate.Microsoft.

13. Select both CB: values. To do so, press and hold down CTRL while you click both CB values under Associated Messages in Fld.
14. In the "Operations available (select operation, then push Call Function button)" text box, push the drop down button to reveal the list of functions.
15. Scroll down the list of functions until you see "lpFld -> deleteMessages() (ON SELECTED MSGS)" and then click on it to select it.
16. Next press the Call Function button. This will delete the rule that you selected.
17. Press the Close button to exit the MAPI_FOLDER window.
18. Press Close again to exit all the windows.

Reference: http://support.microsoft.com/kb/248709

Mail Delivery Slow: Messages Waiting to be Routed Queue Filled up

This issue stuck us 2 weeks back and we went all over by this. Suddenly we found out that the emails sent are being received after a lot of delay. Looking at the Exchange Server, I saw thousands of messages in Messages Waiting to be Routed Queue for Default SMTP Virtual Server and the number kept on increasing and the messages were going out very slow.

Slow mail delivery and mass queuing of mail in the Messages Waiting to be Routed queue in Exchange is typically caused by either Anti-Virus software on the Exchange server, by Distribution List expansion problems, or by connectivity problems between Exchange and Active Directory.

Antivirus was already ruled out as we tried disabling it from the registry as well but with no affect.

I opened up a case with MS PSS... turned up the diagnostics logging for MS Transport and MS DSAccess but nothing conclusive from the logs.

WE monitored the LDAP read and search times, SMTP categorizer queue length as it seemed to be the performace issue. Here is excellent MS guide for Troubleshoting Exchange Server Performance Issues.

Then we collected the Hang Dumps for Store.exe and Inetinfo.exe.

In the Store dump we see that we are waiting on WLAP calls to the GC’s.
From the Inetinfo dumps, we are waiting for the HrCheckRestrictions which means that the mail was probably to a DL that had restrictions placed on it.

So we figured out that Delviery Restrictions might be the cause of mail delivery being slow as we have applied the delivery restrictions on some Distribution Lists quite recently.

This problem occurs when lots of Lightweight Directory Access Protocol (LDAP) searches are initiated. Lots of LDAP searches are initiated when you send mail to distribution groups that include lots of users who have delivery restrictions configured on their mailboxes.

If you send a message to a group that contains many recipients, and if each of those recipients is also configured with a delivery restriction to reject messages from the members of a distribution group that contains many members, Exchange 2000/2003 Server must expand the restricted distribution group one time for each member of the group to which you sent the message. Also, if a failure that can be retried occurs during this process, Exchange Server stops the group expansion process, and then retries the connection an hour later. This causes the messages to be held in the categorizer queues, delays message processing, puts load on transports' Advanced Queuing and SMTP components, and eventually causes system queues to start backing up.

Here is the Excellent MS Exchange Team Blog for Performance issues due to connector restrictions.

Well, the solution to this above was the hotfix (already included in Exchange SP2) and change in one registry entry that defines the new Expansion Logic for restricted Distribution Group.

Here are the details:

1. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport
2. On the Edit menu, point to New, and then click Key
3. Type Parameters, and then press ENTER to name the new registry subkey.
4. Right-click Parameters, point to New, and then click DWORD Value.
5. Type RestrictionMethod, and then press ENTER to name the new registry entry.
6. Right-click RestrictionMethod, and then click Modify.
7. Type 2, and then press ENTER .

Reference: http://support.microsoft.com/default.aspx?scid=kb;EN-US;895407

Mailbox Move: Disconnected Mailbox remains on source Mailbox Store

I faced this issue while moving the mailbox from one mailbox store to a mailbox store on another server.
The mailbox is moved successfully and the user can access it fine on the server it was moved to.

However, the mailbox remains on the source mailbox store in a disconneced state and has small size. The number of items are shown as 0. The mailbox is disconnected and it does not allow you to purge or reconnect it to another user giving the message "This mailbox is already connected to a user."

To be able to purge the mailbox from the Target Store, try to move the mailbox back to that (original) Store. Move Mailbox will fail and gives you the message:

"A duplicate mailbox was found due to problems during a Move Mailbox procedure. The duplicate mailbox has been deleted. Try again later."

Hence when you run the cleanup agent on the original source mailbox store... that duplicate mailbox will be purged.

Reset the language for the folder names inside the Mailbox

In Exchange 2000/2003, when one of the following conditions takes place, the default language names of the folders inside the user's mailbox might change and names of standard folders in an Exchange mailbox, such as the Inbox, Sent Items, Public Folders, and so on, appear in different languages when seen from the client program:

1. You move a mailbox from one Exchange server to another Exchange server.
2. You create a new mailbox.

Exchange creates the folders based on the language of the Outlook client that first touches the mailbox, or the language of IE if OWA is first to touch the mailbox.

To reset the folder names, here is the registry tweak

In HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\11.0\Outlook\Setup, create a DWORD value ResetFolderNames and set its value to 1.

Here is more information about this from Microsoft.

Greylisting and Exchange

There is a potential issue between the Mail Servers that implement Greylisting and MS Exchange SMTP Servers.

Greylisting is used on some mail servers to tempfail first attempt of an email, asking the sending server to retry later. When Exchange tries to send mails to certain domains that implement ‘greylisting’, the mails fail to get delivered and an NDR is generated. Here is an example of what that NDR looks like:

"You do not have permission to send to this recipient. For assistance, contact your system administrator. server.domain.com #4.7.1 smtp;450 4.7.1 <recipient@greylistdomain.com>: Recipient address rejected: Greylisted"

The problem is that the sending Mail Servers are not delaying in response to a 450 "mailbox unavailable" response. The standard (RFC2821) specifies this as a transient condition and the sender should re-queue the message and resend it later. While it's reasonable to fail a message after receiving a number of these "transient failure" responses, the timeout before resending should be higher than 1 second - 10, 15 or 30 minutes are usual values.

By defaut, messages receiving a 4xx SMTP response are processed as a "glitch" 3 times before being put back into the queue for processing on the retry interval. So the problem is when the server resend the message 2 more times with a 1-second delay between attempts and then (presumably) fails delivery and notifies the sender that an error has occurred.

So as a workaround, we need to assertively set GlitchRetrySeconds to a value that allows the greylisting conditions to be satisfied, 120 seconds would do good in most of the cases.

How to Configure Glitch Retry Interval in Exchange Server 2003

Public Folders and Exchange 2007

Public folders are slowly being pushed out of Exchange into SharePoint 2007 and thus is no longer available in OWA from Exchange 2007.

Exchange 2007 client access server has some limitations in public folder support: no IMAP, NNTP, nor OWA access to Public Folders.

Only Public Folders that are stored on an Exchange 2003/2000 server can be accessed via a browser. There is a speculation that PF access via OWA 2007 will be made available when Exchange 2007 SP1 rolls out.
Also with the release of Exchange 2007 SP1, there will be the Public Folder Management Console for Public folders management. As of now public folder management can only be done through the command shell.

Exchange 2007 is surely de-emphasizing public folders. Public folders may not be included in future releases, but support for public folders will be maintained through at least 2016.

Here is what MS Exchange Team say about Exchange 2007 and Public Folders.

Restrict expanding a Distribution List for users

I have heard this question a lot... Here is way we can restrict expanding a distribution list so that the users can't see its members.

Use ADUC. Right-click the DL and click on "Exchange tasks...". From there, select "Hide membership".

This is useful when we have the Message restrictions applied on the properties page for the DL and it fails when the user expands the list to its members, then the message is sent again to everybody.

Exchange Management Shell

It may first appear as if the Exchange Management Shell is nothing more than a standard command prompt. But if you look at its prompt, you will notice that the letters "MSH" appear in brackets just ahead of the path.

The [MSH] tells you that you are not running in a true command prompt environment, but rather within a Microsoft Scripting Host shell. The Exchange Management Shell is nothing more than a Microsoft Scripting Host environment that has been extended to support Exchange Server commands.

There are many management tasks that are only performed on the Exchange Managament Shell and CANNOT be performed in Exchange Management Console. Some of them are:

• All Public Folder management.
• Give permissions to user's mailbox, entire database or the server.
• Advanced database, mailbox and recipient management.
• Advanced Transport Settings like setting a maximum message size limit for incoming and outgoing messages on the organization or connector, Set advanced SMTP connection settings etc.
• Certain Client Access settings also like set connection time-outs for POP3/IMAP4 servers (Set-IMAPSettings / Set-POPSettings), Prevent previous versions of Outlook from connecting to Exchange (Set-CASMailbox –MAPIBlockOutlookVersions), Enable/disable POP3 or IMAP4 for a user (Set-CASMailbox) etc...

Here is some collection of scripts for managing Exchange Server 2007 that are very useful for day to day operation and management.

Sender Policy Framework (SPF)

The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent sender address forgery. It is an attempt to control forged e-mail. SPF is not directly about stopping spam – junk email. It is about giving domain owners a way to say which mail sources are legitimate for their domain and which ones aren't.

The current version of SPF — called SPFv1 or SPF Classic — protects the envelope sender address, which is used for the delivery of messages.

Sender authentication protocols are designed to protect against forgery of e-mail sender identities, either in the envelope or in the header. In the envelope, first there is the "HELO" identity, which names the mail server (MTA) that is sending the message. The "MAIL FROM" identity is the e-mail address that is responsible for sending the message and where delivery errors (bounces) will eventually be reported. And the "RCPT TO" identity is the message's recipient address. The header contains another set of identities (besides other meta information about the message, such as the subject and the sending date).

SPF authenticates the envelope HELO and MAIL FROM identities by comparing the sending mail server's IP address to the list of authorized sending IP addresses published by the sender domain's owner in a "v=spf1" DNS record.

SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to play together:
(1) the domain owner publishes this information in an SPF record in the domain's DNS zone, and when someone else's mail server receives a message claiming to come from that domain, then
(2) the receiving server can check whether the message complies with the domain's stated policy. If, e.g., the message comes from an unknown server, it can be considered a fake.

Example of SPF Record

mydomain.com. TXT "v=spf1 mx a:machine1.mydomain.com include:gmail.com -all"

The parts of this SPF record mean the following:

v=spf1: SPF version 1
mx: the incoming mail servers (MX's) of the domain are authorized to also send mail for mydomain.com
a:machine1.mydomain.com: the machine machine1.mydomain.com is authorized, too
include:gmail.com: everything considered legitimate by gmail.com is legitimate for mydomain.com
-all: all other machines are not authorized

For detailed information on SPF records and their syntax, please refer www.openspf.org
The SPF Setup Wizard: http://old.openspf.org/wizard.html