Alberto Ortega’s Blog

t’s a very common issue to get this Application error on a Back-End Exchange Server 2003. One thing we know, it’s an LDAP error, but sometimes it can become very tricky to get rid of.
This error look like this on the Event Application Log:

LDAP returned the error [20] No Such Object when importing the transaction

dn: <GUID=546E8A04-4E64-4EE0-850C-1093237A65F7>

changetype: Modify

member:add:<GUID=A0005D87-5BDC-4000-8816-889B80C4A619>

-

DC=domain,DC=com

For more information, click http://www.microsoft.com/contentredirect.asp.

And generally you are likely to receive more than one of these errors logged.

First follow this easy work around that you can found in many places:

1) Move the following groups to the default User container, on every domain that you have run domainprep setup:
a. The Exchange Enterprise Servers group.
b. The Exchange Domain Servers group.
c. The Exchange Services group.

2) Check to make sure there is an Exchange Domain Servers group in each domain. If there isn’t then run setup /domainprep in each child domain.

If none of those helped you, let’s dig deeper into the error. If we analyze what is being logged, we can discover some interesting issues. What this LDAP command is trying to do is to modify an AD object add another AD object to it. That is:

LDAP returned the error [20] No Such Object when importing the transaction

dn: <GUID=546E8A04-4E64-4EE0-850C-1093237A65F7> (object being modified - container)

changetype: Modify (command: Modify)

member:add:<GUID=A0005D87-5BDC-4000-8816-889B80C4A619> (object being added to container )

-

DC=domain,DC=com

For more information, click http://www.microsoft.com/contentredirect.asp.

So, the MSExchangeAL service cannot perform this operation. To solve this issue we are going’ to manually perform the operation.

First, we have to know which AD Objects those GUID’s are refereeing to. To accomplish these task we use a tool called ADFind to translate the GUID’s to domain names that we can easily find on the forest.

Download the ADFind tool from http://www.joeware.net/win/free/tools/adfind.htm

Then execute the tool like this:

–Find the object being modified (container):

adfind -gc -b -binenc -f "(objectGuid={{GUID:546E8A04-4E64-4EE0-850C-1093237A65F7}})" –dn

If the object exists we will get the AD common name:

Ex: CN=Exchange Enterprise Servers,CN=Users,DC=domain1,DC=com

–Find the object being added to the container:

adfind -gc -b -binenc -f "(objectGuid={{GUID: A0005D87-5BDC-4000-8816-889B80C4A619}})" –dn

If the object exists we will get the AD common name:

Ex: CN=Exchange Domain Servers,CN=Users,DC=domain2,DC=ws

After that we realize that the task that the LDAP query wanted to do was to Add the Exchange Domain Servers security group from domain2 to the Exchange Enterprise Servers security group from domain1. Now go using AD Users an Computers Snap-in to do the task manually and the error will go away.

Related Links:

LDAP Errors : http://www.eventid.net/display.asp?eventid=8270&eventno=332&source=MSExchangeAL&phase=1

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