Alberto Ortega’s Blog

Say you have planned your AD Forest topology and Exchange Server 2003 deploy carefull. You have executed forestprep and domainprep on each corresponding PDC, but there is no way that the Information Store service get started.

Check your Event Log and seek for the first Exchnage Server related error that is being logged. If the error being logged looks something like this:

"Process MAD.EXE (PID=524). All Global Catalog Servers in use are not responding:
pdc.mydomain.ad"

You have already realize that your Exchnage Server cannot contact the Global Caltalog Server. This can happen if you have installed Exchange 2003 on a child domain that is not marked as a Global Catalog.

In theory this shouldn´t happen, just one GC on the Forest should be enough for the Exchange Server to startup. But DSAccess does not use any domain controller that does not have permissions to read the SACL on the nTSecurityDescriptor attribute in the domain controller. In orther words, if that permission is not granted on the GC Server, that GC is unusable by the Exchange Server. The domainprep process is responsible for adding the SACL right to the GC domain controller (but for some reason this didn´t happen on my forest).

Since there are no GC’s in the child domain, there is nothing for the System Attendant to talk to and therefore won’t start.

The solution is to make the child domain a GC as well. Now your Exchange Server will be able to find a Global Catalog to talk to and the problem is gone.

Related Links: http://support.microsoft.com/kb/316300

You can prevent certain users to send internet based eMail, by restricting them to open an outgoing SMTP Connection.

This delivery restrictions relies upon an SMTP Connector. The most common configuration for your SMTP Connector to allow outgoing mail is:

SMTP Connector:

General: Use DNS to route each address space on this connector

Delivery Restrictions:
       By default, messages from everyone are: Accepted

Address:
Type: SMTP
Address: *
Cost: 1

Now if you want to restrict some specific domain user to send outgoing mail you could add a Delivery Restriction by following this steps:

1. Open you SMTP Connector properties.

2. Click on the “Delivery Restrictions” tab, and add the restricted user to the “Reject messages from” section.

This should work great, but for performance issues SMTP Connectors Delivery Restrictions are disabled by default. This is the tricky part of the process,  restriction checking is controlled by a registry key that must be set on the Exchange bridgehead that is the source for the connector that is being checked. If you specify a restriction, but do not create the registry key, the restriction is not checked.

To enable restriction checking follow the following steps:

1.Start Registry Editor (Regedt32.exe).

2.Locate and click the following registry key:

HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/Resvc/Parameters/

3.On the Edit menu, click Add Value, and then add the following registry value:

Value Name: CheckConnectorRestrictions
Data Type: REG_DWORD
Radix: Hexadecimal
Value: 1

4.Quit Registry Editor.

5.Restart the Microsoft Exchange Routing Engine service and the Simple Mail Transfer Protocol (SMTP) services for this change to take effect.

Links:

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q277872

http://www.msexchange.org/tutorials/MF009.html

Migration between Exchange 2003 Servers can become complex when the servers cannot reach each other. There also exist many tools and ways to perform the migration. Now we are going through two processes that has been executed successfully on a medium-size organization (150 Accounts).

On these scenario two options has been considered and compared against:

1. Account Migration: The “cleanest way”, using the Active Directory Migration Tool (ADMT 2.0, get it from: http://www.microsoft.com/downloads/details.aspx?FamilyID=788975b1-5849-4707-9817-8c9773c25c6c&DisplayLang=en):
   1. Migrate all domain accounts from the Source domain to the Destination domain. You can also migrate all passwords so users doesn’t have to reenter them.
      Passwords won’t be migrated unless you install the DLL for password migration, follow steps described here: http://support.microsoft.com/?kbid=326480#XSLTH4143121123120121120120
   2. Create an empty mailbox for each user on destination Forest. Accomplish this task by using the “Exchange Tasks” tool from AD.
   3. Use EXMerge tool to migrate all messages from Source Exchange Server to Destination Exchange Server, populating all mailboxes created on previous step.
      EXMerge execution is quite simple, but there are many issues to be aware when running this tool. What you have to check is:

i. PST file should not be read-only : http://www.kbalertz.com/kb_323 671.aspx

ii. Check for mapi32.dll: http://www.kbalertz.com/kb_317 946.aspx

iii. Account privileges: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q323546

1. Mailboxes Migration: Use the MailMig tool shipped with Exchange Server 2003 to perform a mailbox migration:
   1. Export all mailboxes from Source exchange Server to a “.pst” file using the MailMig tool Start > All Programs > Microsoft Exchange > Deployment > Migration Wizard.
   2. Use the same tool in order to import all exported mailboxes into the destination Exchange Server.
   3. The import process creates accounts on the destination AD, on an OU specified during the process, but unfortunately these accounts loose some properties when created, that’s why this process is not as recommended as the first described. The reason is that you have to go through each account created and update the properties that differ from the original account.
      One reason why you should use this process rather than account migration is that it is much more straightforward than the previous, and it’s simplicity becomes worthy when migrating a small number of accounts