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