Errors recalling emails from Public Folder favorites

[Tifosa]

Hi All,

I've just found the strangest problem which i'm hoping someone here has come across before.

We have a large amount of public folder data of which a lot of it is archived. Our users have some of these folders add to their Outlook 2007 pubic folder favorites.

The problem we seem to have is anyone running the Outlook add-in V8 can recall from PF favorites, while anyone running the V9 client cannot.

I've tested this with my account (was running V8) and everything recall find. I updated to V9 (EV 9.0.2.1061.0.dcom) and now get the error "The selected item could not be restored"

This only appears to effect users (of which there are thousands) running V9.

I cannot find any reference to this on the net. Has anyone here had the same issue?

Regards

T

[JesusWept3]

OK so the best thing to do would be to get a client trace of the EV8 client getting the item and an EV9 client getting the item and playing spot the difference to see where it might be falling over.

Just as a matter of interest, what version of the EV Server are you using? and if you go to the actual location of the email you're trying to open as opposed to the favorites or search folders etc, does it open?

Also that message, are you trying to restore the item or just simply open it?

[Rob_Wilcox1]

hmm, I'd also be keen to look at the trace(s).

[Rob_Wilcox1]

FWIW I just tried an 8 SP 5 client, and a 9.0.3 client, both using Outlook 2007, and I can retrieve and restore archived items from an Exchange 2003 public folder from both types of 'favourite' in Outlook 2007.

[Tifosa]

Thanks guys... I'm running the dtrace now and will post any errors found.. 

I'm thinking this is a new problem, as we've had EV9 SP2 for over 18 months now and the clients have had v9 since around May/June last year and this is the first question over this. So i'm thinking something has changed or an update has caused this.

So far we have 4 users all compaining over this, but other people i've tested this with have the same issue.

For the previous comment; When we try the recall the error occurs straight away and the email does not open at all.. If we recall directly through public folders it opens and recalls without issue. This happens on both the end-user and through our EV service account

[Rob_Wilcox1]

Can you post a screenshot of where you are trying to recall from, and indicate whether it is a retrieval, ie double click, or, restore (highlighting the item, and clicking restore from the EV toolbar).

It would also be worth while collecting a CLIENT trace, at the same time as a DTRACE.

[Tifosa]

Hi Rob, see attached for screenshots.

When you say a CLIENT trace, are you talking about increasing the logging level to 'Maximum Tracking'?

[Rob_Wilcox1]

Yep I'm talking about increasing to maximum (and restarting Outlook) - just whilst you test of course.

It would also be interesting to know what permissions exist on the public folder, can you get a screenshot of that?

[Tifosa]

See attached log of the client logging turned to maximum

The restores were attempted through the PF favourites and all failed. Time - around 10.:48 / 10:49

There are a few errors in the. The main one appears to be below;

ActionRestore<class ECETraits,struct BackendDCOMTraits>::OnAction: Error (COM): 0x8004010F

I've also dtraced the recalls directly through PF's. No errors found in those logs.

When I dtrace on the EV servers when recalling through favourites, nothing gets logged (and I mean nothing, a 1KB file), so it's not reaching the servers

The problem appears to be client side

[Tifosa]

In this case of testing, I am the Owner of everything under PF''s. We have a universal security group which all our admins are members of, including the main EV service account.

Our end-users have rights between Publishing Author and Owner (these are not custom permissions). All of them can recall directly in PF's.

When I test on our EV servers (logged on as the service account) we get the same errors

[Rob_Wilcox1]

Okay, I will take a look at the trace this afternoon, and see if I can see anything obvious leading to the error code.  I spotted that also.

[Rob_Wilcox1 · Accepted solution]

Unfortunately I've not figured out exactly the cause, but the issu is related to the bit of trace that you highlighted already:

02/02/2012 10:48:39.614[6024]: DCOMRestore::RestoreItems: 0x0
02/02/2012 10:48:39.615[6024]: HTTPRestore::RestoreItems
02/02/2012 10:48:39.615[6024]: HTTPBackend::MarkItemsAndInitiateAction: 0x0
02/02/2012 10:48:39.615[6024]: DesktopCommon::CanUseFolder: 0x0
02/02/2012 10:48:39.736[6024]: ~DesktopCommon::CanUseFolder: 0x8004010F
02/02/2012 10:48:39.737[6024]: ~HTTPBackend::MarkItemsAndInitiateAction: 0x8004010F
02/02/2012 10:48:39.737[6024]: ~HTTPRestore::RestoreItems
02/02/2012 10:48:39.738[6024]: ~DCOMRestore::RestoreItems: 0x0

In my environment, I see:

02/02/2012 14:35:41.107[3252][L]: DCOMRestore::RestoreItems: 0x0
02/02/2012 14:35:41.109[3252][L]: HTTPRestore::RestoreItems
02/02/2012 14:35:41.110[3252][L]: HTTPBackend::MarkItemsAndInitiateAction: 0x0
02/02/2012 14:35:41.112[3252][L]: DesktopCommon::CanUseFolder: 0x0
02/02/2012 14:35:41.132[3252][L]: ~DesktopCommon::CanUseFolder: 0x0
02/02/2012 14:35:41.134[3252][L]: HTTPRestore::UserConfirmedAction
02/02/2012 14:35:41.140[3252][L]: DesktopCommon::GetWindowsNumVersion: 0x0
02/02/2012 14:35:41.142[3252][M]:     Windows Version = 501
02/02/2012 14:35:41.143[3252][L]: ~DesktopCommon::GetWindowsNumVersion: 0x0
02/02/2012 14:35:42.601[3252][L]: ~HTTPRestore::UserConfirmedAction
02/02/2012 14:35:42.602[3252][L]: BackendHTTPImpl::GetTimestamp: 0x0
02/02/2012 14:35:42.604[3252][L]: DesktopCommon::ConvertFileTimeToISO8601: 0x0
02/02/2012 14:35:42.606[3252][L]: ~DesktopCommon::ConvertFileTimeToISO8601: 0x0
02/02/2012 14:35:42.608[3252][L]: ~BackendHTTPImpl::GetTimestamp: 0x0
02/02/2012 14:35:42.609[3252][L]: BackendHTTPImpl::RestoreItemMarker::HandleItem: 0x0
02/02/2012 14:35:42.614[3252][L]: CItemMarker::MarkRestoreMe: 0x0
02/02/2012 14:35:42.620[3252][M]:      Marking for restore: asd
02/02/2012 14:35:42.630[3252][L]: ~CItemMarker::MarkRestoreMe: 0x0

The function CanUseFolder walks up from the current folder to find a folder in the message store that contains an EV 'hidden message' which indicates the EV server information, and some policy type information.

The failure code means either a property doesn't exist, that we're looking for, or the folder itself (ie the parent) doesn't exist.

Unfortunately it's not possible to determine which of those two it is, nor on which folder the issue is, ie the folder that you're doing the restore in, or one of the higher up folders.  In order to get that information I think a debug binary would be necessary.

Before pointing you in the direction of Symantec Support, a couple of final questions :

Which of the folders in your screenshot is a public folder target?  Is it the subfolder where you are trying to do the restore, or is it the one higher up called 'General' .. or is it not shown in that screenshot at all?

Is this or any of the higher up folders replicated to other public folder servers?

The odd bit, which I can't quite get my head around is why it works when you go in to the folder itself, unless, ahhmm hhmmmm maybe....  maybe the PF target (which would contain the hidden message) is higher up that 'General'.  It could be that when we are working our way up, the 'parent' of 'General' is turning out to be 'favourites' rather than the 'real' parent.

In fact I'm 87.6% sure :) that is the cause.

I'm repro'ing that now using the following structure :-

Johno <- my target

   Yellow .. a subfolder

      Jink ..  a sub subfolder

I've added YELLOW to the favourites, and trying to restore an item which is Jink.

[Rob_Wilcox1]

Okay, so I tested it... and that is the cause, at least in my environmnet.

Can you confirm the same?

If you confirm, there are then two courses of action :-

a/  You contact Support, raise a case, and reference this forum post for information.  The Support Engineer can also contact me to discuss if they need to.  A technote will likely be created, which you can subscribe to, so that if/when the issue is addressed (a future service pack I imagine) you will find out by virtue of the subscription.

b/ I raise a bug internally, but, there won't be a technote, and you won't know if/when it gets fixed as easily (you'd have to look at the release notes per service pack vehicle).

[Tifosa]

Thanks for your help Rob, much appreciated...

In our environment unfortunately public folders has become heavily used by our users, so our file tree is excessive...

We have about 70 top level folders (all of which have their own EV targets), which under each has many subfolders and then it could be a further 3 or 3 deep. Some folders are 6 or 7 deep

\Main1 < own EV target

   \Business1 < subfolder

      \Projects1 < sub subfolder

         \ProjectNumber < sub sub subfolder

            \abcd < sub sub sub subfolder

               \efgh < sub sub sub sub subfolder

         \ProjectNumber

         \ProjectNumber

\Main2 < own EV target

   \Business2

      \Projects2

\Main3 < own EV target

etc...

I think you could be right about it thinking that 'Favourites' is the top level folder. The real question is why has this started to happen in v9 while it worked in v8

I'm going through the latest rounds of MS updates that may have been installed over the last few months to see if anyone of those might have an effect on it

[Rob_Wilcox1]

To follow then ...

People are adding folders like this, as a favourite?

 \ProjectNumber < sub sub subfolder

i.e. they're not adding the very top level folder which is your PF target?

Now I've got a repro of the issue, with 9.0.3 Client, I'll go back and see whether I can reproduce it on an 8 SP 5 client.  It'll take a me a little while (but still today) as I'm in the middle of something else.

[Tifosa]

Correct Rob. As some of our main folders have 100's of GB's of data in them, we don't allow them to add the top level folders to favourites

They only add either the one folder it self or the one above

I've only managed to test this with v8 (which worked), v9.0.1 and v9.0.2 (both failed). I do not have a client for v9.0.3 to test with

I'll raise a support case with Symantec as I think it would be helpful for other people who may be experiencing a similar issue

[Rob_Wilcox1]

(You should also find that you can't manually archive items) -< just an FYI

[Kai_Schröer]

Hi!

Rob, your answer is marked as a solution, but what is the solution? We have a customer with the same problem and a similar environment.

Is there a known bug in EV 9.0.2?

Thanks!

:)

[TonySterling]

I believe the solution referred to was to contact support.

[Kai_Schröer]

@Tony: Yes... Possible, but I am hoping that Rob or Tifosa know in the meanwhile a better solution than to open a incident... ;)