Thanks for the replies.
Have you tried to exclude the CRF directory with wildcards from the backup?
Thanks!
No... but the issue is there, when there aren't even any backup jobs created. I don't see how this will do anything?
1) If you make syre all the writers are stable and then run a Full backup job against ONLY the Exchange information store and no other selections do you see the same problem - if this works test a system state backup on it's own against the same server.
Hmmm.. no i haven't tried this, but i don't think this will make any difference to the ASP.NET errors that are clearly using all the system resources. BESERVER.EXE Uses a constant 14% CPU, and i believe this is because of the contant accessing of the CRF folder.
2) if not using DLO then I would recomend uninstalling it (at very least you should do it as it being installed will block an upgrade to a newer BE version (as the newer ones no longer contain DLO
Afraid that's not possible, DLO is not untickable during the installation or during repair on BE 2010.
Sadly upgrading backup Exec isn't possible as the customer will not go for it, when it was working just a couple of months ago.
Thanks again