06-27-2011 06:45 AM
Kind of a cryptic heading perhaps, but here is a desription:
The solution consists of
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.
Solved! Go to Solution.
06-29-2011 07:43 AM
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
06-27-2011 07:48 AM
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
06-27-2011 07:56 AM
You may also want to DTRACE:
MMC
DirectoryService
06-27-2011 10:27 AM
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?
06-28-2011 03:45 AM
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]
06-28-2011 03:48 AM
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
06-28-2011 04:04 AM
Are you all set then now bjorn?
06-28-2011 04:11 AM
No, since the other thread wasn't solved either.
06-28-2011 04:25 AM
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?
06-28-2011 04:45 AM
The registry entry equates to lots of Enterprise Vault ExchangeArchivingAgentQueue
All is in the same domain and same VSA.
06-28-2011 08:25 AM
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
06-28-2011 11:57 PM
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 :)
06-29-2011 07:43 AM
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
06-29-2011 11:07 AM
Interesting - and a good find.
Hopefully the Support person will create a technote to cover the issue.
07-06-2011 02:32 AM
i think we was both a little bit surprised, to be honest :)