duplicate case issue

[AdamS]

I have a backup of a case that I'm having problems with so to get my client up and running I've loaded up the backup, added some sources and am now trying to make that available via connect for him to review, except I can't.

 

The connect case manager sees both the old case and the new backup as the same case, by that I mean they are displayed one above the other and I can't select them individually, they are both highlighted when I try and select one and I can only share the old corrupted case not the new backup.

 

I've tried renaming the old case to seperate them but no joy.

 

I know it's a Sunday but this guy has been wating for days to get at this data and I need to figure this out ASAP

 

ANyone seen this behaviour before?

 

Edit : I couldn't edit the title, its not so urgent anymore. Turns out the simple fix is to delete the case from TEAM manager (but make sure you don't tick the box to delete case data). Once it's gone from that list then Connect see's the correct file. Weird bug though and made me panic a bit

[AdamS]

Well it appeared to work but then when I loaded up the backup case it's not incredibly slow and unresponsive.

 

Failed to show 35 items correctly when I was trying to view them and now appears to have crashed my analysis machine (I was remoting in via team view).

 

I would select a particular type of file, audio in this instance and select 'search' the ball would appear and after clicking on that only about 16 items would show in the details pane with '...' appearing for the other 19, like it was trying to refresh the view only nothing more appeard. Then after a few mins lost remote connection and I can't re-establish.

 

My client commented that he was getting a few blue screens as well when trying to access via connect but I'm not sure how that could be caused by something happening on my connect host.

[ŁukaszBachman]

Hi Adam!

 

As to the duplicated case, I'll investigate it on Monday. I believe that is because two case have the same CASE ID (not the case name). I believe that this could be worked around by changing case id manually in case.xml file, but I'd have to talk to my colleagues  to learn if this won't have any negative impact (I think it won't).

 

As to the other issue - seeing JavaScript console logs and case logs could help to analyze what is going on.

 

Which version exactly are you using, by the way? 1.7.3 should load whole page of table results at once (1st request - fetch IDs, 2nd request - fetch all items metadata at once). Does this issue happens with Table View or List View? Did you try if the same happens while using the other view?

[AdamS]

This was occurring with table view, unfortunately I'm in the middle of trying to rescue this job so can't trouble shoot properly but as soon as I can I'll get some tsting and logs to send in

[ŁukaszBachman]

Ok, understood. I do suggest trying out the List View for those problematic items. Perhaps loading of those in the Items Table has caused some problems that might be avoided when looking at them in LV. Hard to say though, without logs analysis. Take your time and get back to us whenever you need.

[AdamS]

I think there is a much deeper underlying issue with this case as when I open the case now almost as soon as I select the 'location' facet it causes my computer to lock up (complete black screen) and forces me to reboot.

 

I'm reindexing the original 'clean' data that I know has no issues and we are ignoring the ZImbra OST/PST files to get them back up and running on Connect. I've been able to process the Zimbra files with Xways to confirm there is nothing we need there, however something in one of the files causes Intella some major grief.

 

I'd love to be able to send you the bad archive for you to try and duplicate but unfortuantely it's a highly sensitive matter and the client won't allow it, but any log files that may assist just let me know and I'll happily send them.

[ŁukaszBachman]

Ok, I'm glad you were able to work around the issue and get up the speed with your work.

 

We recently had a support ticket about Location Facet doing poorly upon initialization of a structure that contained around 2000 subfolders in it's root folder. Perhaps this is the same problem. Worst case scenario it should cause Browser to fail, but I can't see a reason that it could lead to any more severe problems with a PC, unless browser has crashed the whole system then.

This particular problem with Location Facet has been fixed already and will be included in the next release.

 

If you run into the same problem again, then please run Scanpst on this file and if it does not indicate any errors then index it in isolation. Then you can do a review in Desktop and Connect to see if either one of them has any issues with that data. If problem seems "general" then indexing logs could be helpful to us. If you think it's more about a single item, then it's original context (or less sensitive details) will be a helpful insight. In both cases, I suggest opening a ticket in our Support channel and we will analyze this as a bug.

[AdamS]

I think the large folder structure under the root folder was the issue here too. The OST file being quite large had thousands of emails, and when I extracted out the individual emails using the OST recovery tool it seemed to create a new folder for each email, something very weird anyway and there were thousands of folders.

 

Scan PST just froze when trying to work with this file as well.

 

When things get quiet and I have my new machine up and running I'll do some testing on this archive and see if I can get some meaningful data that may assist.

[ŁukaszBachman]

Ok, thanks! I'd suggest to wait a bit for the next release of Connect, before committing to this heavily, as the fix we applied already has greatly improved rendering speed of the Location Facet.