Error 906 installing AADConnect

Ran into an issue recently implementing Azure Active Directory Connect as a client. This is the same client and machine as a previous post (Connectivity issues with MSOL PowerShell), where we found that disabling TLS 1.0 required us to force TLS 1.2 on .Net 4.x.

The basic install went off ok, then we got into configuring, and ran into this at the Install Required Components screen:

A check of the ApplicationEvent Log revealed a number of error messages:

Error    12/18/2017 10:58:30 AM    AzureActiveDirectorySyncEngine    906    None

SynchronizationServiceSetupTask:Enable LocalDB Instance – Caught unexpected exception. Details System.InvalidOperationException: LocalDB powershell operation failed on ADSync Bootstrap service: Enable-ADSyncBootstrapLocalDBInstance

The key is the last one in the group of five:

Error    12/18/2017 10:58:30 AM    ADSyncBootstrap    906    None

EnableADSyncBootstrapLocalDBInstance: Error while attempting to enable local db instance. Details: Microsoft.Azure.ActiveDirectory.Client.Framework.ProcessExecutionFailedException: Exception: Execution failed with errorCode: 1.

Details: Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : Encryption not supported on the client.

This lead us to realize that the version of SQL Express 2012 is RTM, and a quick check revealed that SQL anything 2012 doesn’t support TLS 1.2 without a much newer version of the SQL Native Client. (

Download the latest sql native client here.

The method that worked for me was to do the base install of AAD Connect, then cancel and install the SQL Native Client. Once that has been completed, the configuration of AAD Connect can continue normally.

Connectivity issues with MSOL PowerShell

Recently encountered an issue with a client where we were unable to connect to the O365 or Azure PowerShell after installing the required prerequisites.


  • Install .Net 4.x using the method of your choice.
  • Install the 64-bit version of the Microsoft Online Services Sign-in Assistant: Microsoft Online Services Sign-in Assistant for IT Professionals RTW.
  • Install the 64-bit version of the Microsoft Azure Active Directory Module for Windows PowerShell with these steps:
    • Open the Azure Active Directory Connection web page.
    • In Files in Download at the bottom of the page, click Download for the AdministrationConfig-V1.1.166.0-GA.msi file, and then install it.

So in every case before this one, after installing the above components, running Connect-MsolService and entering the appropriate credentials gets you to O365/Azure PowerShell.

This time it didn’t.

The error returned:

PS C:\Users\<redacted>\Desktop> connect-msolservice

connect-msolservice : Authentication Error: Unexpected authentication failure.

At line:1 char:1

+ connect-msolservice

+ ~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : OperationStopped: (:) [Connect-MsolService], Exception

+ FullyQualifiedErrorId : System.Exception,Microsoft.Online.Administration.Automation.ConnectMsolService

We spent a fair amount of time troubleshooting this, and ultimately determined that the root cause was that the client had disabled TLS 1.0, not just for the browser, but for the entire computer. First time we’ve seen it done to the entire machine in the wild. Turning TLS 1.0 back on was not an option from a security perspective, so we needed to sort out how to overcome it.

.Net interacts with AAD Powershell by default using TLS 1.0, so if TLS 1.0 is disabled, no joy.

Forcing .Net to use TLS 1.2 requires a registry change, which can be accomplished through PowerShell (Administrative login):

# set strong cryptography on 64 bit .Net Framework (version 4 and above)

Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319’ -Name ‘SchUseStrongCrypto’ -Value ‘1’ -Type DWord

# set strong cryptography on 32 bit .Net Framework (version 4 and above)

Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319’ -Name ‘SchUseStrongCrypto’ -Value ‘1’ -Type DWord

Restart the computer, and everything is right with the world.

IIS Crypto

I recently ran across of a neat little tool for identifying and managing machine-level crypto settings.


Some of you may already be familiar with it, but it’s a lightweight portable tool (No installation required) for getting and setting security protocols (SSL.x, TLS.x), ciphers (RC.x-AES.x), hashes (MD5-SHA512) and key exchanges (Diffie, PKCS, ECDH).

Many of us are used to disabling older protocols, ciphers and hashes at the browser level, but recently security organizations are starting to disable them at the machine level. It used to be you had to go into the registry to hard-disable them, this tool still does that, but in a much prettier way.



URL Safety

Let’s say someone you know sends you a link to something. Do you click on it? The correct answer should be NO!

It might be legitimate, it might not be. So how do you figure it out without picking up the phone or texting?

Well, you can mouseover it, and see what the actual URL is, versus the text printed on the screen. That does imply that you understand how to read and interpret what the URL means, which can be tough even for professionals.

Or you use a URL checking service.

Among the more popular are

Now if you want to be ultra, ultra safe, don’t even click on my links, do a search for “URL safety checking” using your favorite search engine, and pick from one of the above companies. There are many out there, the above are the ones I trust the most.

Be safe everyone!

So you want to change the NIC on your Azure VM to static? lots of bad info out there. Here’s what worked for me

In my continuing journey towards mastering Azure, I started working on building out an AD in Azure on Azure VMs.  NOT Azure AD, but an AD in Azure for building out federation.  First problem I can into was turning a regular VM into a DC.  Naturally I tried to set a static IP on the NIC, and promptly lost control of the VM.  At that point it was easier to destroy the VM and provision a new one, and figure out how to make the IP static.

There is a ton of help out there on how to do it, mostly in classic, NOT resource group Azure.  Most of what I did find didn’t work, but eventually I cobbled together the right way to get it done.

My little PowerShell script

$VNname = “Test-vnet-1”
$RGname = “Default”
$NICname = “test-dc-12345”

$nic=Get-AzureRmNetworkInterface -Name $nicname -ResourceGroupName $rgname
$nic.IpConfigurations[0].PrivateIpAllocationMethod = “Static”
$nic.IpConfigurations[0].PrivateIpAddress = “” (whatever IP is correct for your defined subnet.)
Set-AzureRmNetworkInterface -NetworkInterface $nic

It took about 60 seconds, and you will lose RDP to the VM.  You will also lose RDP to the VM is you statically configure the DNS.  Just restart the VM in the Azure portal and go forward.

Moving my MSDN subscription to a new tenant in Azure

I recently was provisioned an MSDN subscription by my employer, and being an Azure noob, I managed to associate it with the main tenant of my employer.  I was the account owner of the subscription, but had no privileges in the main tenant.  It took a bit of work to get it moved, mostly because the initial instructions I received from Azure support were crap.

Why does it matter?  It matters because I want to do things with Azure AD, security, IAM, etc., and neither I nor my employer want me messing with the production tenant.

I had tried to create a new tenant off of my work email address, but couldn’t get the subscription moved.  Eventually created a new tenant with a completely separate email account, and started doing AAD, ADFS, etc.  Then I found I couldn’t do MFA without a subscription, and getting that pesky MSDN subscription moved became a priority.

I reached back out to Azure support, and got a much more detailed response on how to change the subscription.  (Since I had first talked to two other folks at my employer about changing the subscription, and been told they had been through the same experience as me, and finally cajoled MS into just doing it for them.)


The instructions are as follows, scrubbed of identifying information:

Subscription name: Visual Studio Enterprise – MPN  

Subscription ID: <msdn subscription id>

Account Admin: <my work email> (Authentication: Work or School Account)

Service Admin: <my work email>  (Authentication: Work or School Account)

Current Directory: <my company directory> (Tenant Id: <my company tenant id>)

Desired Directory: <my lab tenant> (Tenant Id: <my lab tenant id>)

 As per my understanding, you wish to move the subscription id: <msdn sub id> from directory <my company directory> (Tenant Id: <my company tenant id>) to <my lab tenant> (Tenant Id: <my lab tenant id>).

 Please follow the below steps to change directory of the subscription.

 Step a : Kindly make sure that the service administrator is a Microsoft account /Personal (< account used to create lab tenant>). Only a service administrator with a Microsoft account will be able to change the directory.

 ·        Login into using <my work email> (Authentication: Work or School Account).

·        Click on the “Account” tab. 

·        Click on the “Subscriptions” tab. 

·        Select the subscription for which you want to change the Service-Administrator. 

·        Click on “Edit Subscription Details”. 

·        Here you will find the option to change the Service-Administrator to (< account used to create lab tenant>

 Step b : Kindly make sure that the service administrator < account used to create lab tenant> has been added as the global administrator of the directory <my lab tenant> (Tenant Id: <my lab tenant id>) required. If not, kindly contact the current global administrator to add the account .

 Step c: login to the management portal at as the service administrator .

-Click on Settings

-Click on Edit Directory .

-You will be able to change the directory of the subscription .

 That’s it.  It took closing out of all browsers and re-authenticating, but it worked.



ADFS and Server 2016 error 364

I’m been working on learning ADFS, and also recently upgraded my home lab to Windows Server 2016.  I ran across an interesting problem today, where after installing ADFS, I was unable to test the functionality by going to the internal testing page after what appeared to be a successful install.  A successful install as defined by reviewing the app logs under the event viewer.

The URL to test the functionality is: https://adfs.<your domain name>/adfs/ls/idpinitiatedsignon.aspx.

It should return this:

Unfortunately for me if returned this instead:

After a little Binging, I discovered that in Windows Server 2016, it doesn’t enable the testing function by default.

If you want to find out what state it’s in, you need to use PowerShell:

That attribute needs to be set to true to return the right response to the URL.

You need to run the following command to get it enabled:

Now you can go back to the original URL, refresh the page, and you should see this:

Almost a year of solar!

Well, it’s been close to a year, and we’ve had a good experience with solar.  We’ve generated about 6.5 megawatts of power, and Should net around 1 megawatts purchased from the power company.

We currently pay about $11.50 a month to be connected to the grid, and the current bill has us using a net of 103 kw, which is the first time in almost nine months we’ve been a consumer of electricity.  It’s really tough to figure out the exact number, because the billing system of our local power system is so old it can’t figure out the net metering on it’s own, and someone has to manually calculate it and update our bill.

In the end, we don’t have to think about it, it pretty much takes care of itself.  It’s interesting to geek out and watch the meter outside, but this time of year I’m sad to report it’s moving in the wrong direction.  At least it’s only another month to the solstice.

The Solar equation for me

So this morning I was talking to a colleague who is interested in solar, and I reran my numbers on the cost/benefit of solar.

Cost of the system $19993.08 (Let’s round to $20k for the sake of simplicity.)

30% federal tax credit shaves that to $14k.

10 year loan on 14k at 2.99% interest is about $135.

We average about $90ish electric monthly.  Assuming electric rates rise at around 5% a year, we’ll be paying around $154 for the same electric usage in 10 years.

In short, it means that the cost of the system pays for itself in about 8 years.  This doesn’t account for one other factor, Solar Renewable Energy Credits (SREC).  There is a program where you get one credit per year for every 1000kW you generate.  My system should generate 7 SRECs per year.  utilities buy SRECs to meet renewable energy minumums, and there is a commodity trading market for SRECs.  Unfortunately here in Ohio, we can only sell our SRECs on the Ohio or Pennsylvania markets, where prices for SRECs are very low. ($6 and $10, respectively.)  By contrast, Massachusetts and New Jersey SRECs sell for $200 or more.  If we sell in the PA market, that’s $70 a year, so over 10 years $700, or 5% of the cost of the system.

The Solar Experience

So we signed up for solar a few months ago, and it finally got installed last week.  (Just under the wire for the 2016 solar tax credit.)

We got a couple of bids, and ended up choosing YellowLite, based out of Cleveland.  The rep I worked with was not a very good salesperson, which was perfect, because Ezequiel is very much a technical guy that happens to do both sales and tech.  When I say he wasn’t a good salesperson, I say it from the perspective that I hate sales people, and Ezequiel was more concerned with answering my questions and figuring out what the best possible system would be for us.  (It didn’t hurt that he proposed a system that was the same size as his competitors, but with American-made panels AND  at a lower overall cost.)  Needless to say, his approach spoke to me, and he spent about an hour on the roof, measuring,calculating, etc.  The overall price didn’t hurt either.  (20k, before the 30% federal tax credit.)

The system is 21 285 watt Mono Solarworld panels, just about 6kW in generating capacity, with a SolarEdge inverter.  The installation took a little longer than expected, and required a little troubleshooting, but wasn’t really significant in terms of inconveniencing us.

Today marks the beginning of generation.  The system generated 19.86kW, and the outside electric meter rolled back from 779 to 768.