As some of you might have seen earlier this month, I tweeted my excitement at the fact that the Azure Stack HCI 20H2 preview included a newly rebuilt SConfig utility, written in PowerShell! Incase you missed it, #AzureStackHCI includes a completely re-written version of SConfig! The best part? It's written in #PowerShell, so why not start extending it? :D I spent a couple of minutes and added a little extra menu for my own use#MVPBuzz #AzSHCI pic.
So you’ve set up an Azure Stack HCI Cluster and everything’s running great, but there is this nagging feeling in the back of your mind. It’s a hybrid setup, with some type of flash cache sitting in front of spinning disk, and you start to wonder how hard you’re pushing that cache, and how long it will last. Thankfully with Windows Server 2019, there are many in-built tools and commands to help work out just that!
DFS Replication (DFS-R) is a fantastic tool in any sysadmins belt when it comes to creating highly redundant and scalable file shares. And yet anyone who has used it, knows that monitoring it can be difficult at the best of times. Windows Server 2012 introduced several Powershell commands for DFS-R which help discover partnerships and their status, however none of them test replication end-to-end. So here are the goals I get out to achieve with Powershell:
AzureStack is a fantastic appliance, with a massively simplified patch and lifecycle policy thanks to a lot of hard work from Microsoft and the OEMs delivering it. But even with all that, to ensure the best experience when updating AzureStack, you should always apply the available hotfixes in-between updates. At some point, you may find you’ve fallen more than one update behind and need to catch up. Finding all the right hotfixes and updates requires reading each of the release notes for prerequisites.
Overview While spending a lot of time on the Storage Spaces Direct Slack group, one thing that comes up, again and again, is patching of S2D Clusters, and what is the best way to do it. For this blog series, I’m going to break down the patching best practices into 2 separate scenarios: Offline Patching Using Cluster Aware Updating Offline Patching Offline patching is a pretty common scenario when patching S2D Clusters, and in my mind it is used for 2 reasons, catching up on multiple months of patching where there are known issues, and planned patching in a small window with an outage.
Storage Spaces Direct (S2D) is an incredibly powerful technology, and makes up a huge part of the new AzureStack HCI Solution, however performing maintenance on it can catch out new players. One of the biggest causes of failures while performing maintenance on S2D hosts and clusters, is that the hosts haven’t been correctly put into maintenance mode, so I set out to simplify the process with 3 new functions. The 3 activities I’ve targeted with these functions are enabling and disabling maintenance mode on a host correctly, and checking the current state of a host or cluster.
After my previous article about the wonders of the new Azure Update Management Extension for SCVMM 2019, some of you might have been thinking that it was all well and good that VMM now automates the installation and configuration of the Azure Monitor Log Analytics Agent (MMA) for you when deploying new VMs, but what about all those existing servers out there? Well unfortunately out of the box, Microsoft doesn’t provide a single installer UI that can target multiple machines, unless you’ve also got SCOM deployed and have configured it’s OMS integration as well.
Microsoft products are showing a clear theme these days, and the System Center Suite is no acception, hybrid scenarios and cloud augmentation. And while there are those that see this as just a way to drive Azure adoption, this doesn’t need to be a bad thing. In this article, I’m going to cover how to take advantage of Azure Update Management, using the new Extension in System Center Virtual Machine Manager 2019.
As some of you would have seen, I spent some time last week getting familiar with Linux Containers on Windows Server 2019, and I thought I would share what I did to get it all up and running. Warning: Linux Containers using Hyper-V Isolation is still a work in progress. See here for details Steps Prerequisites Install Docker EE Enable Linux Container Support Deploy a Linux Container (Optional) Install Docker Compose (Optional) Enable Remote Management of Docker Engine Prerequisites To get started, you’ll need to have the following in place:
One of the handy functions built into Powershell, is the ability to preview what would happen if you run a command. This could be as simple as wanting to make sure that your Remove-Item actually deletes the write files, or that Set-ADUser changes the right attribute. Hand in hand with -WhatIf is -Confirm, it will prompt you for high risk actions and confirm if you really want to perform the action, like deleting an AD user account.