Today, the Az.Sql module would not load on my machine when attempting to manually fail over a SQL Managed Instance with this error: module could not be loaded I followed the advice of the error message and tried to import the module to get further information. module is already loaded Hmmm 🤔 I decided to uninstall the Azure PowerShell from my machine using the Windows 10 Settings App. Looks like an old version.

Hugo is great Even though I’m late to the party, having not blogged for a while (see my older posts here), I came across a bug in Hugo today. To get a little bit more performance from my site I decided to use the --minify option in the hugo command for the production build on netlify’s build server in netlify.toml as you can see here. My navbar didn’t have icons in it before, and I thought it would look nicer with some icons added.

Built with Hugo I’ve moved away from Wordpress as it was getting bloated, complicated to manage and expensive to host. I wanted something that was fast easy to use cheap to host source controlled I can now write blog posts in markdown in vscode and then push my changes to GitHub which lets me have a history, I can edit from anywhere by pulling and pushing from any machine, even my phone.

On a client site recently a question was asked about the file share witness in a SQL Server failover cluster on-premises, and where to put it if you only have two sites. As always, it depends! Let’s look at some scenarios. Bear in mind that use of the Azure Cloud Witness requires Windows Server 2016 or later. Topology 1 Three node cluster with 2 nodes at primary and 1 at disaster recovery (DR) Most people want high availability at their “primary site” and are happy to have standalone capability at the business continuity (DR) site.

If you have an environment where you need to lock down Sentry One as much as possible, then this article should help. It is well known that the Sentry One service account needs to be a member of the Local Administrators group in each server it monitors, and also a member of the sysadmin role for each SQL Server instance. At the moment this is still a requirement, but if you can live without the Windows metrics, then you could run Sentry One in Limited Mode which will only gather SQL Server specific metrics.

You run performance tests as well as functional tests when deploying new code changes to SQL Server, right? Not many people do, I think you should, and this article will show you how to do it by harnessing an existing performance tool, rather than writing your own monitoring infrastructure from scratch. Any good performance monitoring tool that records information to a database will do fine, and we prefer to use Sentry One.

In February 2018, myself and Paul Anderton gave a presentation on how to correlate database deployments with performance issues within the context of a DevOps pipeline. We used Sentry One as our monitoring tool in a Performance Test environment so that we could catch badly performing deployments before they got to production and caused havoc. If you would like to see the recorded video, then you can download it from here: http://info.

I primarily work in Visual Studio 2017 and Visual Studio Code, using VS2017 for SSDT work, and VS Code for pretty much everything else. VS code is highly configurable, and as it’s a rainy Sunday, I thought I’d share my settings with you in case you are interested. A few colleagues at work have asked me what extensions and settings I have so, here they are as of Feb 2018.

Overview Sentry One is a great tool for monitoring many servers. For new installations, it can be a bit of a bind to add your existing servers into the tool to be monitored. I have written a PowerShell module to make this much easier and to validate that servers that you thought were being monitored, are in fact monitored. There is full documentation for the module in the Sentry One user guide which explains how to use the functions within it, but a brief explanation is shown below.

I was at a client site recently and implemented Sentry One for them, a great monitoring system for SQL Server. It proved challenging because some servers were in a DMZ on a separate network and domain and some servers were in the same domain. All servers connected via a router and were firewalled off from each other with only the minimum ports open required for them to fully function and communicate.