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.

Friday, October 5, 2012

NFS in android- why isn't this built in?

This seems like such a no brainer- right now using fileshares with android devices tends to be fairly painful, even with utilities such as astro, es file explorer, etc.

Why? Because none of those let you actually mount filesystems.

You want to view/use a file on a network share, you have to copy it to your device, work on it and then copy it back. That's such a waste, especially considering how long linux has had access to smbmount, nfsmount and the like. And they are so easy to setup. I mean, incredibly easy. But yet for an android device, this is a nightmare of rooting, installing apps (not that I've got anything against CIFS manager mind you, except that you've got to root your device to use it, and it's got to be running CM7), and running a gauntlet of compatibility issues.

NFS/SMB read capabilities are right there at the OS level, literally compiling in NFS support for the kernel is a check box or switch during compile time, and it takes pretty much no effort to supply. Not giving us this ability means that device storage built into our devices is getting wasted needlessly. Filesharing is a common every day solution for a lot of things, and even in the home user market no less. Network attached storage is even an option now on some routers- so the technology is being made easily available.

By including this is in the stock android deployments, we could get much easier use from our devices, and it would be yet another step to making BYOD less of a headache for system's administrators- ie, the data your users are using is still locked on the fileserver, and not on their devices.