Veeam Office 365 backup, non-domain accounts, and UNC shares

Veeam recently went GA with their Backup for Microsoft Office 365 product, and like a lot of folks, I’ve been looking forward to it. I was fortunate enough to be involved with the beta, so I knew going into it that setup would not take long (just a couple of minutes really). What I didn’t test a heck of a lot of though were backup locations.

The Problem

By default, Veeam Backup for Microsoft Office 365 (VBfMO365 ?) will backup to local disk. That’s all fine and dandy, but I have a nice little repository that I want this stuff to sit on. I carved out a new data set for testing on my FreeNAS and tried pointing to a CIFS share from Veeam server. When I would navigate to the folder using Windows Explorer, I would be prompted for a username and password, which is as designed as I use local account authentication on the FreeNAS (versus something like Active Directory). But, whenever I tried to add the folder as the repository location, I would receive an error that ‘Folder does not exist‘. I fought with it for a couple of minutes and tried mapping the location as a mapped network drive. I then received the message that mapped network drives aren’t supported, but to use a UNC path!

Some quick Googling led me to this thread on the Veeam forums. The issue, as it turns out, is related to the fact that the Veeam Backup for Microsoft Office 365 (whew, a mouthful) has a service that runs as the Local System account. This account does not have access on my FreeNAS, nor should it as it is just local to the Veeam B&R server.

The Solution

To get around this, I needed an account on my FreeNAS box and on the Veeam B&R server that had the same username and same password. Keeping with best practices, I also did not want this to be a domain account, hence the reason to keep accounts local (versus putting it into Active Directory).

On the FreeNAS side, I set up a new account. If the Veeam B&R server is running Windows 8, 8.1, 10, 2012, 2012 R2, or 2016, then you may need to check off the ‘Microsoft Account’ checkbox. Also, make sure that your account and/or group will have read/write access to the data set where you repositories are going. In my case, I made a new ZFS data set, made sure the ‘wheel’ group had Read/Write access and assigned this new Veeam account to the ‘wheel’ group.

On the Windows end of things, you’ll want to create a new local user. Make sure that it has the same username and password as the account you just created on the FreeNAS. Once you have that done, pull up Windows’ services management, find the “Veeam Backup for Microsoft Office 365 Service”. Right, click and choose Properties, head over to the Log On tab and select ‘This account’. Enter the username and password and hopefully when you hit OK, it won’t complain about a password error. If it does, then you’ve made a typo. Once done, restart the service.

At this point, you are probably thinking that we are in the clear. I thought so, but then I found that I kept running into an error (note that it is sanitized to remove some info):

11/30/2016 7:00:16 PM :: Connecting to remote server failed with the following error message : 
[ClientAccessServer=BLUPRXXUS0000,BackEndServer=sx9pr00mb2000.namprd00.prod.outlook.com,
RequestId=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,TimeStamp=11/30/2016 7:00:46 PM] 
Access Denied For more information, see the about_Remote_Troubleshooting Help topic.

This was easily resolved by going back into the Office 365 Backup console, right-clicking on the organization, and choosing Edit. From there, log in with an Office 365 that has the required permissions and follow through the wizard. After that is done, your backups should be hitting the network location.