VPN was not configured successfully in Windows Server 2012 Essentials Experience

During a recent SBS 2003 to Windows Server 2012 r2 Essentials migration I was having a number of problems setting up anywhere access. The two problems that I was getting were:

  • Anywhere access to your server is blocked
  • VPN was not configured successfully

Windows Server Essentials Anywhere access - VPN was not configured successfully

I searched all over but couldn’t come up with anything useful and the dashboard.log file didn’t show anything useful, just the error:

ConnectivityCenter: RemoteAccessAnalyzer: VPN server deployment result: InstallationFailed

The ports 80 and 443 required for Remote Web Access and VPN were without doubt open but it seemed to me that the wizard always failed at the verification stage, so I figured that it must be seeing something different than I was picking up in my tests.

Now, this server has been configured with a custom domain name of remote.companydomain.com and externally this resolved no problems at all.

But if I tried to ping that address or use nslookup on the essentials server to resolve the external DNS address that had been assigned to the server it failed. Then I realized what was going on.

This system/customer is new to me and I had made the new essentials server a domain controller which also meant that it would have replicated DNS records from the source domain controller.

Although the internal domain name was companyname.local there was also a forward lookup zone for the main companyname.com address space, because the essentials server was rightly using itself as a DNS server it was unable to resolve remote.companyname.com using its own DNS forward lookup zone for the external domain as the record for remote.companyname.com had not been added.

So I had two choices, remove the forward lookup zone or add the remote.companyname.com address to it as an A record. It was obvious after a little investigation why the external domain name had been added to the active directory DNS, but the reason it was include it was no longer appropriate, so I deleted the whole zone.

I then restarted the DNS server and cleared the DNS cache from a command prompt with:

ipconfig /flushdns

and tried to resolve the external domain name again and this now resolved correctly.

So I once again tried to run the Windows Essentials Anywhere Access Wizard and it still failed with the exact same issue! Infuriating! .

It did show one less error this time though and I was down to “VPN was not configured successfully” only this time. This error took make ages to figure out though.

Fixing the VPN was not configured successfully error

I ended up looking through the CBS.LOG file in quite some detail and figured out what the problem was. Thanks to someone on this thread on technet for the inspiration to look there.

When the VPN is being enabled Windows Essentials attempts to setup a Windows Internal Database and in my case failed to do so due to a logon failure as it did not have the “Logon as a Service” privilege. Here is a sample of the log:

2014-08-29 23:04:32, Error CSI 00000001 (F) Logged @2014/8/29:22:04:32.768 : [ml:130{65},l:128{64}]"Attempting to start service {MSSQL$MICROSOFT##WID} synchronously"
[gle=0x80004005]
2014-08-29 23:04:32, Error CSI 00000002 (F) Logged @2014/8/29:22:04:32.893 : [ml:84{42},l:82{41}]"start service MSSQL$MICROSOFT##WID (1069)"
[gle=0x80004005]
2014-08-29 23:04:32, Error CSI 00000003@2014/8/29:22:04:32.893 (F) CMIADAPTER: Inner Error Message from AI HRESULT = HRESULT_FROM_WIN32(1069)
 [
[51]"The service did not start due to a logon failure.

Now I felt I was getting close to the source of the issue, light at the end of the tunnel (you have no idea how long I spent trying to figure this out).

The knowledge base article 2832204 from Microsoft explains how to make the appropriate group policy changes to stop this prevent the specific issue of being unable to start the MSSQL$MICROSOFT##WID service, which is actually the root cause of the wizard not being able to finish.

Here is a screenshot of how I the corrected group policy looked on the system I was working on:

Changing the logon as a service policy to resolve the error "VPN was not configured" on Windows Server Essentials Experience

After you have changed the policy run a quick “gpupdate” to make the new policy active and then try running the VPN wizard again, the wizard took a long time to complete but I was fairly confident it was going to work as I could see the SQL database becoming active in Task Manager:

Essentials Anywhere Access Creating a Windows Internal SQL Database

The wizard finally finished with success! I spent a long time trying to figure out the cause of this problem and I am so glad to see the back of it. I really hope this helps you if you are having the same issue.

How to use Microsoft (not Organizational) account with Add-AzureAccount

If you are trying to connect to Windows Azure with Powershell but you are not using an organisational account you may find that you are unable to connect as the browser based authentication window that collects your authentication details only offers you the possibility of using an organisational account.

My own problem was further compounded because my Microsoft account email address is the same email address as my own organisation account, I know other people have had the same problem and have been unable to connect.

Trying to connect to Azure Powershell with a Microsoft Account instead of an Organisational Account

 

As you can see above, there is no option not to use an organisational account and apparently no way around the problem.

There does seem to be no way in the current version to connect to Azure Powershell using a username/password combination of a Microsoft account. But you can connect using the certificate method, which is arguably a bit easier anyway.

Follow the instructions on this page:

http://azure.microsoft.com/en-us/documentation/articles/install-configure-powershell/

For me this added my account as a subscription, not an account. Running the Get-AzureSubscription cmdlet verified my account had been imported.

I was then able to continue and run any cmdlets as normal.