Overview

When migrating Exchange mailbox from source to target whereby Symantec EV is connected to archiving the source mailboxes, by default after migration, when Symantec EV is re-directed to the newly migrated Exchange mailboxes in the target, it will create new and duplicate archives within the EV database. The root cause of this is because the EV procedure for recognizing mailboxes is dependent upon the msExchmailboxguid and the legacyExchangeDN Active Directory attributes. Quest do not migrate these attributes, because to do so would be incorrect, because Exchange should be assigning these unique key attributes automatically. Microsoft advise against doing this, therefore Quest follow these standards in full.

Resolving the problem

The solution is easier that what has been documented in the past. The following topics are the key to this process.

Symantec EV Policy Manager (EVPM)

EVPM is a side tool for the EV product which is a scripting method for modifying and controlling EV archives. A unique guide for this is available and shipped with the product, called the ‘Utilities’ documentation PDF. In order solve this problem, it is required to  re-enable all mailboxes that have been migrated in the target for archiving will mean that upon examining the newly migrated unique mailboxes in the target Exchange, it will see the Archive ID values and therefore realise this mailbox is now the newly migrated mailbox and map the two together in the database, resulting in one correct archive. Please note that this process is a trivial task and is not something to be seem as a long drawn out process.

Hidden ArchiveID MAPI property

This is a hidden message and is stored within each message. It is used by EV to identify messages which has been archived. When Quest migrates each message, we automatically bring over these properties so there is zero configuration changes requires for the Quest tool.

What is the EV procedure for migrations?

This is documented by Symantec at the following location:

http://seer.entsupport.symantec.com/docs/284956.htm

 

It is highly suggested that the following document should also be read from Symantec. It includes a scenario and procedure for the workings and configuration of EV:

http://www.symantec.com/connect/sites/default/files/managing-exchange-migrations-with-symantec-ev.pdf

How do I re-enable a mailbox?

Please note that the following snippet is taken from the Symantec EV Utilities Guide as an example. Mailboxes can either be enabled in bulk mode of individually. The bulk method is described further below.

 

;

; Enabling a mailbox

;

[Directory]

DirectoryComputerName= myserver

SiteName = MattSite

[Mailbox]

DistinguishedName = /o=Org1/ou=Admin Group/cn=Recipients/cn=jones

[Folder]

Name = mailboxroot

Enabled = true

;

; End

 

How do I bulk-script the re-enable mailbox procedure?

The bulk method can be done by either, enabling all users, running the script below against a batch set of specific users, or running against AD with a group or an LDAP query against an OU, for example. You can re-enable all users’ if you wish, depending upon your migration scenario. LDAP queries are done using the ‘LDAPQuery’ function of the EVPM tool, documented fully within the Utilities Guide PDF. The script below works by providing a bulk import file of distinguishedname attribute values for all of the target users you wish to update. Example contents of the input file would therefore be:

 

…………………………………………………………

 

CN=admin,OU=Users,DC=mattdamon,DC=com

CN=JohnDoe,OU=Users,DC=mattdamon,DC=com

CN=BruceWillis,OU=users,DC=mattdamon,DC=com

…………………………………………………………

 

The example vbs script would therefore be:

 

Const ForReading = 1

Const ForWriting = 2

Const OpenAsUnicode = -1

Const OverwriteIfExist = -1

 

Dim objFSO

Dim objShell, evpm

 

evpm = “c:\program files\enterprise vault\evpm.exe”

Set objFSO = CreateObject(”Scripting.FileSystemObject”)

 

Set objInputFile = objFSO.OpenTextFile(”C:\temp\input.txt”, ForReading)

Do Until objInputFile.AtEndOfStream

Set objOutputFile = objFSO.CreateTextFile(”C:\temp\evpm.ini”, OverwriteIfExist, OpenAsUnicode)

strLine = objInputFile.ReadLine

 

objOutputFile.WriteLine “[Directory]”

objOutputFile.WriteLine “directorycomputername = myserver”

objOutputFile.WriteLine “sitename = ExampleSite”

 

objOutputFile.WriteLine “[Mailbox]”

objOutputFile.WriteLine “distinguishedname = ” & strLine

 

objOutputFile.WriteLine “[Folder]”

objOutputFile.WriteLine “name = mailboxroot”

objOutputFile.WriteLine “Enabled = True”

 

set objShell = wscript.createObject(”wscript.shell”)

strExec = evpm & ” -e <exchange> -m <alias> -f c:\temp\evpm.ini”

 

objShell.Run strExec

objOutputFile.Close

Loop

objInputFile.Close

 

If you wish to script using an LDAP query then the following would be done. In this example it would enable all mailboxes with the extensionattribute1 attribute set with a value of 1.:

 

[Directory]

DirectoryComputerName= myserver

SiteName = ExampleSite

[Mailbox]

LDAPquery = extensionAttribute1 = 1

 [Folder]

Name = mailboxroot

Enabled = true

;

; End

Overview

This is an overview tutorial discussing the general troubleshooting techniques for MAPI_E_LOGON_FAILURE errors. These can be logon failures or access denied. Note that logon failure is generic and can be either communications, service failure or name resolution as the root cause. Generally the problem is lack of permissions or permissions denied.

The Quest product on this topic reports access errors in all Source or Target agents, but normally this is seen in either the Mail Source Agent or mail target Agent. The typical error below shows a standard access error which is extremely common. It is reported in agents, simply stating that we have no permissions or no MAPI access to the mailboxes with which we are trying to migrate.

02/02/2007 16:24:30 CSession::Logon TraceMsg 4800 Logging on to the mailbox ‘/o=TARGET/ou=First Administrative Group/cn=Recipients/cn=Ewan.Millington’ (Server: ‘EXCHANGE-SERVER’, user: ‘TARGET\qmmex’).
02/02/2007 16:24:30 CSession::Logon Error -2147221231 The information store could not be opened. - MAPI_E_LOGON_FAILED (MAPI 1.0) Low level error: 0×0 File: ‘aeWrapHelpers.h’ Line: ‘264′

What tools are required for troubleshooting and confirming permissions?

·         ADSIEdit: You will need to download ADSIEDIT which is part of the 200x server support tools. These can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyID=96a35011-fd83-419d-939b-9a772ea2df90&DisplayLang=en. Once installed you will need to register the adsiedit.dll. To do so use the following command via Start - Run ‘regsvr32 adsiedit’

 

·         MFCMAPI: This is a tool which allows you to connect to the Exchange server, store, mailbox, and public folder levels. It can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyID=55FDFFD7-1878-4637-9808-1E21ABB3AE37&displaylang=en

 

I’m not sure what permissions are actually required?

 ·         Essentially we required full mailbox access including send-as / receive-as rights to Exchange, including full rights to the ‘Exchange System Objects’ OU in Active Directory

·         Please read the Quick Start Guide PDF which is shipped by default with the software; Or

·         Please also see the following Solution article: https://support.quest.com/SUPPORT/index?page=solution&id=SOL38171

 

How do I set the required permissions?

 ·         Please read the Quick Start Guide PDF which is shipped by default with the software

  

Tutorial Contents

 ·         Step One: Natively Logon to a failing Mailbox

·         Step Two: Confirm Service Account Group membership

·         Step Three: Confirm Exchange Organization permissions

·         Step Four: Discussion of Scenarios

 

Step One: Natively Logon the Failing Mailbox

 Logon to Windows

 First logon to a machine, that has Outlook installed, as the Quest Service account credentials, and in domain of either source or target depending on where the error is being received. With Quest Mail Source (MSA) Agent, you should use the source domain, for the mail Target Agent (MTA) you should use the respective target domain. In this scenario we will use the Target domain to troubleshoot an error in the Mail Target Agent.

  

Obtain the LegacyExchangeDN (LEDN) of a failing User from the log file

 The following is gained from the highlight log snipped below, taken from the Mail Target Agent Log File:

02/02/2007 16:24:30 CSession::Logon TraceMsg 4800 Logging on to the mailbox ‘/o=TARGET/ou=First Administrative Group/cn=Recipients/cn=Ewan.Millington‘ (Server: ‘EXCHANGE-SERVER’, user: ‘TARGET\qmmex’).
02/02/2007 16:24:30 CSession::Logon Error -2147221231 The information store could not be opened. - MAPI_E_LOGON_FAILED (MAPI 1.0) Low level error: 0×0 File: ‘aeWrapHelpers.h’ Line: ‘264′

The legacyExchangeDN would therefore be:

 /o=TARGET/ou=First Administrative Group/cn=Recipients/cn=Ewan.Millington

 

Run MFCMAPI

 Select Logon and Display Store Table

  

When prompted, select to create a new MAPI profile

 

Create the MAPI Profile for a failing user to test the logon

 

When entering the Mailbox name, do NOT use the alias or Auto-Discover, use the legacyExchangeDN. This is because our software uses the legacyExchangeDN path of the user to logon to the mailbox making it a fully correct test.

 You should receive a result of success

  

Open the MAPI Mailbox with MFCMAPI

 Selecting the profile name on ‘Choose Profile’ will open the MAPI profile of this user. The Store of the mailbox should now be displayed, WITHOUT any errors or pop-ups. Double-click on the Mailbox store to open this store.

This should now display the Inbox store fully, as below

  

Step Two: Confirm Service Account Group Membership

 By default, Domain Admins and Enterprise Admins Groups have the Send-As & Receive-As permissions denied. These permissions are required for the Quest Service Account to logon to user mailboxes. As shown below, the membership is incorrect. Therefore you must remove the user object from membership  Domain Admins AND Enterprise Admins.

  

Step Three: Confirm Exchange Org Permissions

 Exchange permissions should be assigned to the entire Exchange Organisation root Exchange Organisation Name, and then propagated down. In some occasions for security reasons, security is assigned to each individual Exchange Store for more granularity. In any scenario you should always confirm permissions against a store, this is because permissions may not be propagated from the root configuration down to the store. The location for which these are assigned are shown below:

  

Open ADSIEDIT Configuration Container

 

Open the security of the Mail Store

 If you seen any denies please remove them, and as in Step Two, please remove the Service Account from the Domain Admins and Enterprise Admins Built-in Groups as these auto-deny the required permissions.

Confirm Effective Permissions

 Select the Advanced button and then the ‘Effective permissions’ tab, using the Quest Service Account, in our case, ‘qmmex’. All the options should be ticked, and if they are not, the product will not work, we cannot logon to the user mailboxes and the pre-requisites have not been met.

 

What if Send-as / Receive-as permissions are denied?

 ·         The Service Account is a member of Domain Admin or Enterprise Admins so this membership should be removed; Or

·         Permissions are denied at one of the levels below, so each level should be checked to confirmed permissions have propagated, these levels are:

  

·         The last possible reason is that a GPO restriction is enable prevent permissions of send-as / receive-as rights for the Service Account

  

Step Four: Discussion of Scenarios and typical reasons for failure

 The Logon failure occurs for all users

 

·         Most likely the service account has send-as / receive-as rights denied;

·         The service account is a member of Domain Admins or Enterprise Admins

·         Name resolution is not working. DNS and NETBIOS should be confirm between all servers involved in the migration (Quest & Exchange)

·         The Exchange server is unavailable or down

 

 The logon failure occurs for a limited number of users

 ·         The mailbox is hidden from the GAL. See the following solution: https://support.quest.com/SUPPORT/index?page=solution&id=SOL22596

·         The LegacyExchangeDN of the user object has a trailing whitespace. Please see the following solution: https://support.quest.com/SUPPORT/index?page=solution&id=SOL45625

Why logon to the System Attendant?

Quest Migration Manager for Exchange uses the System Attendant Mailbox and requires access to this mailbox during the synchronization of data. To have access denied to this mailbox can be fairly common. Typical errors which can be displayed within the logs files of Quest Agent’s are:

 

11/9/2007 11:27:19 AM    CSession::Logon    TraceMsg    4800    Logging on to the mailbox ‘/o=ORG/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=SERVER/cn=Microsoft System Attendant’ (Server: ‘SERVER’, user: ‘domain\account’).

11/9/2007 11:27:19 AM    CSession::Logon Error   -2147221231     The information store could not be opened. - MAPI_E_LOGON_FAILED (MAPI 1.0)  Low level error: 0×0 File: ‘aeWrapHelpers.h’ Line: ‘279′

11/9/2007 11:27:19 AM    CSession::Logon    Error    -2147221219    The attempt to log on to the Microsoft Exchange Server computer has failed. - MAPI_E_FAILONEPROVIDER (Microsoft Exchange Server Information Store)  Low level error: 0×0 File: ‘aeWrapHelpers.h’ Line: ‘264′

11/9/2007 11:27:19 AM    CSession::Logon    Error    -2147221219    The attempt to log on to the Microsoft Exchange Server computer has failed. - MAPI_E_LOGON_FAILED (Microsoft Exchange Server Information Store)  Low level error: 0×0 File: ‘aeWrapHelpers.h’ Line: ‘257′ 

 

Where is the System Attendant Mailbox?

 

There is a System Attendant mailbox for every mail store on every Exchange server. It can be viewed from the Exchange server as shown below. If this mailbox cannot be viewed, you should run clean-up agent and refresh the view in order to display the mailbox.

  

The mailbox is secondary visible via the Microsoft Exchange System object OU of Active Directory, as shown below. The Quest Service account requires Full Control over this entire OU. It is only visible by selecting advanced features from the View menu option.

  

How do I logon to the System Attendant Mailbox?

 Logon to Windows

 First logon to a machine,that has Outlook installed, as the Quest Service account credentials, and in domain of either source or target depending on where the error is being received. With Quest Mail Source (MSA) Agent, you should use the source domain, for the mail Target Agent (MTA) you should use the respective target domain. In this scenario we will use the Target domain to troubleshoot an error in the Mail Target Agent.

  

Obtain the LegacyExchangeDN (LEDN) of the System Attendant Mailbox

 To obtain the LEDN of the System Attendant Mailbox by using ADSIEDIT, see below

We can see above that the LEDN value is the following:

 /o=TARGET/ou=First Administrative Group/cn=Configuration/cn=Servers/cn=2KDC2/cn=Microsoft System Attendant

 Open Outlook to create a new profile

 Run Outlook and create a new profile for the System Attendant Mailbox

 On the Email Accounts screen, specify the target Exchange server and for the System Attendant mailbox and for the user name, enter the LEDN obtained from using ADSIEDIT

   

You should now receive confirmation of this profile creation

  

After which outlook will load. If you have permissions, this will load correctly, as shown below.

  

Download MFCMAPI

 MFCMAPI can be downloaded from the following location:

 http://www.microsoft.com/downloads/details.aspx?FamilyID=55FDFFD7-1878-4637-9808-1E21ABB3AE37&displaylang=en

 Run MFCMAPI

 

Select Logon and Display Store Table

  

 Select the profile you previously created

  

The stores should now be displayed, without any errors or notifications. Double click on the Mailbox store.

  

This should now display the mail store fully.

  

You may think why have we just not used MFCMAPI, and why have we run Outlook then run MFCMAPI. The reason for this is because MFCMAPI cannot resolve the LEDN of the System Attendant Mailbox. So the profile must be created within Outlook, then by loading MFCMAPI the mailbox is then viewable.

 

Please see the following document on how to troubleshoot permission based errors that are returned through Quest products. Namely Migration Manager for Exchange and other tool which require full mailbox access and/or no denies on accounts:

Troubleshooting Exchange Permissions