VAW coexistance with Azure AD Connect

[nso-bryan]

Ran into a rather unique issue on a new server install a few weeks ago, and have been attempting to work with Microsoft on this. Our standard server rollout to SMB clients with a single server is VAW backing up to a NAS.

We installed a new server for a client, installed VAW and have been backing up successfully without issue. We then came upon the steps to begin migrating their email from a Web-Based/IMAP/SMTP solution to Office365. I secured an Office365 trial, got the domain setup and proceeded to install Azure AD Connect to sync users up to the cloud.

I'm greeted with the fantastic message that the synchronization service fails to install, and my only recourse is to "Retry", or bomb out - which then requires me to uninstall the application, perform a cleanup, and then reinstall and try again (My belief is the latest bastardization of Azure AD Connect was coded and released on Christmas eve). I'm instructed to review the event logs, which are nothing but a mere slap in the face, indicating that other events within the log likely contain my error, which of course they don't.

Luckly, Microsoft has buried the logs within the C:\ProgramData folder, so I begin the daunting retina-burning task of sifting through text. I stumble upon the following:

AzureActiveDirectorySyncEngine Information: 904 : An equal or higher version of Microsoft SQL Server Express LocalDB is already installed. Target version = 11.1.3000.0, Installed version = 11.3.6020.0

Based on my findings, Veeam utilizes a higher build of SQL LocalDB than what Azure AD Connect tries to install. I've verified this by running the individual MSI that is packaged within the Azure AD Connect package. Since the install ends in error, the DB instance for AzureAD Connect is never created, and thus the entire application is rendered useless.

I've been in talks with Microsoft on the issue, though getting in touch with the appropriate department that could actually solve the problem is like trying to milk a fish. Why M$ couldn't have trapped the through that a server may already utilize SQL 2012 LocalDB, grab the registry entries pertaining to the Instance Path and Executible Path, and utilize the LocalDB executable to create a new instance is....honestly, par for course for most of the software released by MS lately, IMHO.

The only thing I can think of at this point is to shutdown the LocalDB service, copy off the .MDF and .LDF files from C:\Windows\system32\config\systemprofile, uninstall Veeam, Install AD Connect, and then attempt to reinstall Veeam and somehow attach the database; although I'm unsure how much more work I'd be making for myself to make this successful.

In my opinion, this is not a Veeam issue, but a lack of thinking from Redmond in considering compatibility with other applications. However, I'm wondering if Veeam Engineers/Developers may have better friends at Microsoft than I may have - and perhaps can't kick them in the pants to look into this further.

Just wanted to share my experience. Have a great weekend and Veeam On!

[Mike Resseler]

Hi NSO-bryan,

One thing is for sure. This is not a fun thing to read. I hope at least you still had a good weekend and didn't spend the entire weekend trying to solve these things. From what I can remember of the installation of AD connect: there is a moment where you can perform an "advanced" setup and choose your own SQL server. I wonder if you could do that, and then point it to the localDB that VAW uses. That might fix the issue (Normally this is intended for connecting it to a full SQL server but you never know...)

[nso-bryan]

Hi Mike. Thanks for the reply.

No, I've definitely not spent my entire weekend on this, since I'm 99% sure I know exactly where the issue lies (on MS), and how to go about fixing it. (Azure AD connect should check the registry for existing LocalDB, grab the path to the executible, and perform the action to "create a new instance", and build Azure AD Connect database onto that instance). Getting Redmond to cooperate is the majority of the battle; so far my "technician's" suggestion is to install Azure AD Connect on another server. Unfortunately, as this client is an SMB, they have only one server, so this is not possible.

(Rant):
How can MS be pushing for SMBs to migrate to the cloud, when the tools provided require damn near a PHD to troubleshoot?
How can MS "assume" that no other software already exists on a server that may utilize features that AD Connect does, when moving clients to the cloud?
(/rant)

I did try the "use existing SQL Server" option in AD connect. Unfortunately that module is hard coded to utilize TCP connections only, which LocalDB does not support.

I'll continue to push via our Partnership with MS on the issue. If I make any headway, I'll update this thread.