Archive task on remote server reports error, although it is running

[bjorn_b]

Kind of a cryptic heading perhaps, but here is a desription:

The solution consists of

• 2 EV Servers (non-clustered)
• 1 SQL (clustered)
• 2 Exchange clusters

1 EV server archives from 1 Exchange Server (The other arvhices obviously from the other)
SQL port number is not default; communicates on port 1488

From EVServer #2, we can see status on services and tasks on both EVServer #1 and #2, and synchronize mailboxes on both EVServers

From EVServer #1, we can see status on services on both EVServers, but the Exchange Mailbox Task on EVServer#2 is reporting “Error”. When we try to synchronize this task on EVServer #2 from #1, we are asked to start the task, and then we get this error: Failed to start the Exchange Mailbox Task on ‘Exchange02’. Reason: The parameter is incorrect.

The strange thing is that everything works like a charm from the other EVServer (synchronizing on both servers).

The only error I can find in the event logs that I feel can be linked to this situation is this one “The computer 'Internet' preference item in the 'M_BMC_Discovery {080F836E-9CCB-4F32-9D87-772782FA9256}' Group Policy object did not apply because it failed with error code '0x80070005 Access is denied.' This error was suppressed.”

See drawing for setup.

[R_Meeker]

run a Dtrace on archivetask process while synching one speciifc mailbox. post the result here if it isn't pages.

What results do you get form this

--Begin

use enterprisevaultdirectory

select *

from archivingretrievaltask

--End

[Rob_Wilcox1]

You may also want to DTRACE:

MMC

DirectoryService

[JesusWept3]

another thing, if you go to the Vault Admin Console on EVServer1 and you open up "Services" for EVServer2, dont suppose the Task Controller Service also shows as Error as well does it?

[bjorn_b]

When I detrace MMC, I get this error: 

12:30:01.109 [9740] (mmc) <9296> EV:H VaultCoCreateInstanceEx: An error occurred - RequestedServerName = [EVSERVER02], UsedServerName = [146.2.248.73], hrCCI = [0x80070057], hrResultsQI = [0x80004005], NumTried = [6], bLocalMachine = [False]

12:30:01.109 [9740] (mmc) <9296> EV:M TaskControllerAction: (error) : The parameter is incorrect.

JW2: Actually No, but I have this error in my eventlog: DCOM got error "2147942487" from the computer <IP-ADDRESS> when attempting to activate the server:

{3342DB60-B74A-11D1-9E4B-0000F8789EA8}

I made a post about this in May as well, but noone actually came up with an idea what this might have been. I am able to ping the aliases for both servers from both servers.

[bjorn_b]

JW2: Actually, you answered my former thread as well: https://www-secure.symantec.com/connect/forums/archive-task-state-not-shown-directory-server

Obviously some connectivity issues

[Rob_Wilcox1]

Are you all set then now bjorn?

[bjorn_b]

No, since the other thread wasn't solved either.

[Rob_Wilcox1]

Have a look in the registry, and see what :

{3342DB60-B74A-11D1-9E4B-0000F8789EA8}

Equates to.

Also is this all the same domain, same vault service account, etc, etc?

[bjorn_b]

The registry entry equates to lots of Enterprise Vault ExchangeArchivingAgentQueue

All is in the same domain and same VSA.

[KarlW]

Stupid question - I assume the IP address used [146.2.248.73]in VaultCoCreateInstanceEx is the IP address for EVSERVER02?

Also shot in the dark - have you tried resetting the VSA password (via the VAC) to get all the DCOM permissions updated on both EV servers.

-Karl

[bjorn_b]

Yes, the IP address is for EVSERVER02

No, I have not tried resetting the VSA password via VAC. I do have a support case for this right now as well, but I could note it as an action to perform during that case :)

[bjorn_b · Accepted solution]

The case was solved together with support.

We found out that EVServer1 replied with IPv6 address locally (i.e. when we tried to ping EVServer1 from EVServer1). Even though the network card did use IPv4 externally, this server was reluctant to give up it's new and cool IP :)

We did some registry hacks described in: http://support.microsoft.com/kb/929852

And now it works like a charm.

Apparently 

Bjørn Erik

[Rob_Wilcox1]

Interesting - and a good find.

Hopefully the Support person will create a technote to cover the issue.

[bjorn_b]

i think we was both a little bit surprised, to be honest :)