cancel
Showing results for 
Search instead for 
Did you mean: 

SearchFolderManager.exe Error 8004011d

Marcde
Moderator
Moderator
Partner    VIP    Accredited

Hi everyone, 

we are facing the mentioned error in one environment. Outlook 2013 installed on the server. Mailboxes on 2016 CU9. It does not matter if we execute it manually or with the powershell script. Tested for different mailboxes, all failing with Error 8004011d. Using a elevated command prompt and logged in as the VSA. The VSA does have full access to the mailboxes in question. No additional event in event logging. Archiving is working without any issues.

Dtrace: 

{CEVMAPILieModeLock::ReleaseNonExclusiveLock:#101} Released lock.

{HrMAPIOpenMsgStoreKvs:#59} Opened msg store [0x8004011d]

{CMailboxHelper::OpenMailbox:#324} Could not open message store: [0x8004011d]

 

 

RPC Client Access Log: 

client-software: SearchFolderManager.exe

operation: OwnerLogon

rpc-status: -2147221231 (rop::LogonFailed)

failures: RopHandler: Logon: [ConnectionFailedTransientException] Cannot open mailbox <MailboxDN>. -> [MapiExceptionLogonFailed] Unable to open message store. (hr=0x80040111, ec=-2147221231)  [diag::...

 

 Any idea what else to check?

 

Thanks and kind regards

Marc

 

PMCS GmbH & Co. KG - A Serviceware Company
www.serviceware.de
27 REPLIES 27

Marcde
Moderator
Moderator
Partner    VIP    Accredited

So it seems StepMonty and I do have different situations. I can confirm that full access is already present and that we are able to open a mailbox in question in Outlook on the ev server without any issues. A sync is working fine as well. 

 

 

PMCS GmbH & Co. KG - A Serviceware Company
www.serviceware.de

Hi Marcde09,

Before granting full access to the EV Service account, I ran the Get-Mailboxpermission against the problem mailbox, and it did show that it already had full mailbox permission.  I didn't appear under full access permssions under delegated permissoins within the Exchange Admin Centre though.

One thing I noticed were some 401 repsonses in the IIS logs on the Exchange 2016 server.  i searched for the IP of the EV Server.  Do you have anything showing up in those logs?

Regards,

Step.

So if your permissions look OK then I would look at the differences between how to tool is connecting to the user mailbox and how outlook is connecting. The tool uses RPC/HTTP as you will see from a DTRACE.

 

 

Enterprise Vault Senior Principal Engineer APJ

Hi Paul,

The Tool only works if I manually add the Vault Service Account as Full Access to the mailbox - Even though it already has this access (according by the output of the Get-MailboxPermission commadlet).

I've inherited EV, so I'm not sure what permissions were originally set.  But when I upgraded to EV 12, I did run the scripts provided in the installation folder.  I remember that a lot of the output said that the permissions were already set.

But EV Archiving/restoring etc all work fine without manually granting full access.  And as I said the output form Get-MailboxPermission says that the EV Service Account has full access - its just the tool that doesn't work?  A bit odd?

Marcde
Moderator
Moderator
Partner    VIP    Accredited

Hi Step,

We've got this issue in another environment as well where everything seemed to be the same as in the first environment except of not beeing able to open the mailbox in Outlook. Permissions were available and inherited (which is correct afaik). So we removed the full access permissions for the vsa and set it again after which it is working for this particular mailbox.

I am waiting for a confirmation if this is working in the first environment or not. Even if it's working i'll going to open a case to analyse this a bit more.

 

Kind Regards

Marc

PMCS GmbH & Co. KG - A Serviceware Company
www.serviceware.de

I am not sure what we as EV engineers can do for you here as we are kind of the victim. We are making a standard MAPI call tio open the mailbox and MAPI is saying nope no can do. So from an EV perspective we are using MS APIs and it is failing. This is also backed up by the fact that performing a pure exchange permission act resolves the problem. So IMO I would be asking MS why you need to do this. 

Why do you need to take off the permissions and put them back on for the exact same MAPI call to then work?

Enterprise Vault Senior Principal Engineer APJ

I agree that this appears to be a permissions issue.  The reason I'm looking at EV, is that I used the Scripts provided by Veritas to set these permissions.  It appears that the scripts provided by Veritas aren't setting the permissions correctly.  That said, I have inherited this setup so I'm unsure how the permissions were applied back in the older version of EV before I did the upgrade.  But I did run the scripts provided in the EV 12 setup to apply the permissions (and throttling policies).

The fact that someone else is also experiencing the same problem suggests that the permissions granted by the scripts are not enough for your SearchFolderManager tool to work (or to create a MAPI profile for Exchange 2016), but they do grant enough permissions for EV to archive and restore items?

Marcde
Moderator
Moderator
Partner    VIP    Accredited

Shame on me for not verifying this earlier but the VSA was a member of the Exchange Organization Administrators group. After removing it we can execute searchfoldermanager for all mailboxes without an issue so far.

Interestingly we had much more issues with archiving itself in other environments when the VSA was a member of the group and as archiving was pretty fine in this environment I did not think about that.

StepMonty, maybe something you could verify as well? 

Anyway thank you both for the hints.

Regards

Marc

 

PMCS GmbH & Co. KG - A Serviceware Company
www.serviceware.de