EVPM PST ingest causes server reboot

[BlueBull]

Hi All,

I had this issue a week or 2 ago. I am ingestig 100's of PST files using EVPM. The process works very well.

However, it seems to fault on occasion, faulting EVConverterSandbox.exe. This creates a dump and the server is rebooted.

I have applied the 10.0.4 CHF3 to the environment which appeared to resolve the issue.

But after a while with ingesting more data, the issue reappeared.

In the INI script, I have reduced concurrent ConcurrentMigrations to 6 and the issue still occurs.

Has anyone seen this before? Is there a limit to the number of PST's you can ingest with EVPM in a respective run?

Regards,

[Rob_Wilcox1 · Accepted solution]

EVConverterSandbox is part of the 'indexing process', well in general terms it is (stuff goes through conversion so that it can be indexed).. so not specifically to do with EVPM or PST ingestion.

Random idea .. good if you have a test environment :)

Can you reproduce it in a test environment? If so.. what happens if you stop the indexing service?  All the items should get ingested, and there should be no crash/reboot. 

After that, you could start the indexing service, and see how it handles processing the backlog?  Maybe pushing with EVPM is hitting it too hard (I mean this shouldn't happen, because it should scale, but it's worth a try, I think)

[BlueBull]

I will give that a go. Thanks.

I have tried to reproduce in my lab but I just do not have the data load from a production environment.

[BlueBull]

Ok, I was unable to reproduce this issue in my lab. I then seup a batch of 515 PST files for ingestion with EVPM. I stopped the indexer service and started the ingestion. The ingestion completed 100% fine. I have now started the Indexer to catch up on the back-log and will report back soon.

How can we troubleshoot the indexer and try and sort out the reboot issue?

[BlueBull]

Just to give you another update. The Server config is as follows:

• VM
• 16 Cores
• 32GB memory

I have started the indexer now to cleanup the backlog. The machine is running at 100% CPU utilization and 95% memory. I noticed the slow increase when I was running the ingestion and indexing at the same time.

Currently only indexing is running. No archival. Is this normal?

[Rob_Wilcox1]

Archiving will only run when archiving is scheduled, right?

If you've ingested all of the PSTs, and indexing is now running flat out to index those items which were ingested then that it is likely to take a while.

I would suggest:

- If this works, and doesn't cause the crash. Maybe there is either an issue with the mix of PST ingest and Indexing at the same time, eg load, or data-content

- If this still causes a crash, then the issue is more likely something to do with the data

Either way around you'll need to get through to Backline or 'beyond' inside Symantec for assistance in figuring out what is tripping up the indexing engine.  NOTHING should be able to blue screen a machine, so you might also need to get involvement from Microsoft to capture dumps and have them analysed.