Monday, October 8, 2012

ESEUTIL, Unitrends UEB and my own stupidity

So I just recently got a copy of the Unitrends Enterprise Backup appliance for vmware installed and licensed over the weekend. Now me being me, I just had to try and dive in head first. Couldn't get a lot of things working, but I did get exchange backups working- which is a massive plus in my book.

So, verified the backup, and it cleared my exchange logs- yay! Talk about making me happy. Until a nagging voice at the back of my mind reminded me of recent experiences with backup exec (and the fact that there's no corresponding restore exec). A restore was needed! So I went through the process- but I wanted to restore only a single mailbox. Talk about a nail biter- as I'm going through the options, I created the restore share by selecting my mail db backup, selecting the option of "Next (Select Files/Items)" and...
Waiting. 16GB db plus about 30GB in log files- takes awhile. Cool thing is, this restores to a local samba share, which you then access from your exchange box.

Which is where the stupid on my part comes in- you'll see it soon.
So, I check the db and start trying to bring it to a clean shutdown state- (for those of you who don't know how to do this, check out this blog: ExchangeServerPro, excellent write up!) when I started running into trouble- my db checked the way I expected it to, my log files were good, however during the recovery phase...

Operation terminated with error -1032 (JET_errFileAccessDenied, Cannot access file, the file is locked or in use)

And it doesn't tell me which file. Of course, since I'm such a genius, I decide that it must mean the db is locked... nope, db's not locked.

Oh! right, the samba share is read-only! Why didn't I realize this sooner?
So I move the db to a directory I've got read/write access to, and it's all good, right?

Oh hell no.

Operation terminated with error -1032 (JET_errFileAccessDenied, Cannot access fi le, the file is locked or in use) exchange 2010

Now, I get a bit irritated and throw handle and process explorer (both from sysinternals, good stuff!) only to find out that db is never locked. In fact, the restore process gets to ~90% before failing without ever opening a log file or the db!

WTF?

Well, turns out that the log directory needs to be read/write accessible too... something I would've figured out almost 10 minutes sooner had I just checked the event logs for the ESE errors...

So, while the samba mount is cool, it's not as useful as I had hoped. But it does make it easier to get at the files and use the standard microsoft tools for manipulating the files (powershell, robocopy, xcopy and all the rest)

Problem solved, files copying, face red with shame.
Hopefully this sheds a bit of light on the problem in case anyone else is as dense as I can be.

No comments:

Post a Comment