I spent today in a session with our external SQL Advisor; we have been working on provisioning a set of SQL Servers in Microsoft Azure. These servers will be using SQL Server TDE, which is a total database encryption system. I will not go into details of how this works, or what the setup is; however I will explain a problem we had in the hope that someone else will read this article and not spend an entire day trying to work out the cause!

Key with name ‘SOME_KEY_NAME’ does not exist in the provider or access is denied. Provider error code: 2058. (Provider Error - No explanation is available, consult EKM Provider for details)

The above error message was presented to us when we tried to create the asymmetric key for the server. According to the official set of error codes, error 2058 does not exist! What really confused us is that we had three other servers connect without a problem; those servers were created last year. The fourth problem server was only created this month; can you see where I am going with this?

It turns out that there is a bug in the February 2018 release of the SQL Server Connector for Microsoft Azure Key Vault that was released that month (version 15.0.300.96). We had used a previous release of the installed on the first three servers.

How to fix Error 2058

The Feb release contains a requirement for a new registrary key; nothing has the rights to create that key (SQL Engine, connector, or the DLLs). The, unfortunately, the workaround is to create the following registry key:

In the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft node create a key “SQL Server Cryptographic Provider”

Once you have created the key grant full permissions on the key to the account which runs the SQL Engine Service. You should now be able to access the key vaults and create your keys.

Or of course, you could do what we did, and use the old version of the installer (patching is a problem for future me).

The header image for this post was provided on unsplash.com by Thomas Kvistholt, thank you Thomas!

Read more

As most .NET developers will know there is a Path.Combine() method in System.IO which can be used to (you guessed it) combine two file paths. Unfortunately, it sucks; it sucks bad.

As you can see it functions just as you would expect in the first three lines; but it sucks on the last three. Why would Microsoft not implement a path separator check; adding or removing the separator where applicable? A very good question in my opinion; so I have my own implementation.

using System;
using System.IO;
using System.Linq;

public static class Pathy {
	public static string Combine(string path1, params string[] paths) {
		return paths.Aggregate(path1, Combine);
	}
	
	private static string Combine(string path, string path2) {
		char spliter = Path.DirectorySeparatorChar;
		
		if (path == null) {
			throw new ArgumentException("Base path can not be null", nameof(path));
		}
		
		if (path2 == null) {
			throw new ArgumentException("Sub path can not be null", nameof(path2));
		}
		
		path = path.Trim().TrimEnd(spliter);
		path += spliter;
		path += path2.Trim().TrimStart(spliter);
		
		return path;
	}
}

Pathy.Combine() takes two or more paths in the same way that Path.Combine() does and correctly merges them based on the default Path.DirecotrySeperatorChar as used by the current environment.

Feel free to use and abuse this bit of code; it is provided with no warranty or guarantees. You can also find it on  GitHub.

The header image used on this page was provided for free by Mike Enerio via unsplash.com thanks Mike!

Read more

The domain you have tried to access is currently held by me; this is a holding page. You have either seen this because the site is not currently active, or is undergoing maintanance.

Only the following sites should direct here, if you are seeing this for another site please let me know!

• https://awesome-books.co.uk
• https://chorlton.xyz

Thank you for your visit!

Read more

::CLOUDFLARE_ERROR_1000S_BOX::

Read more