From My Perspective as a Microsoft Azure Hybrid MVP – Two Decades in Microsoft Hybrid & HCI

I write this blog as a longtime Microsoft advocate with two decades of hands-on experience—from early Hyper-V in 2008 to today’s Azure Local. This series aims to highlight the potential of Windows Server Failover Clustering (WSFC) as a viable alternative for organizations transitioning away from VMware, especially in light of Broadcom’s acquisition. While I value Azure’s Cloud and Hybrid offerings, I believe Microsoft’s current messaging overlooks WSFC’s capabilities in providing cost-effective, high-availability solutions. Through this blog, I intend to shed light on WSFC’s strengths and advocate for its consideration in modern IT infrastructures.

• Introduction
• Azure Local (formerly Azure Stack HCI)
  • Key characteristics and features
  • Azure Local Use cases
• Traditional WSFC with External SAN/NAS Storage
  • Key characteristics and features
  • Traditional WSFC Use cases
• Windows Server Failover Clustering with Storage Spaces Direct (S2D)
  • Key characteristics and features
  • WSFC with S2D Use cases
• Comparative Analysis of the Three Solutions
  • Comparison Matrix
  • Azure Local – Pros and Cons
  • Traditional WSFC + SAN – Pros and Cons
  • WSFC + Storage Spaces Direct – Pros and Cons
• Industry and Workload Considerations
  • Industry Examples
  • Workload Examples
• Optional Azure Integration for WSFC (SAN or S2D) Clusters
• Decision Framework – Choosing the Right Approach
• Conclusion

Introduction

In modern Windows infrastructure, there are multiple strategies for building highly available clusters. This content, originally published as a blog, was adapted into a presentation for a session at MMS MOA 2025, To Windows Server or Not: The Clustering Question, where the PowerPoint version is available. The session compares three key solutions side-by-side: Azure Local (Azure Stack HCI), Windows Server Failover Clustering with External Storage (traditional 3-tier architecture using SAN/NAS), and Windows Server Failover Clustering with Storage Spaces Direct (S2D). We explore the technical architecture of each, their pros and cons, and strategic considerations. Key factors like cost, scalability, performance, hardware needs, manageability, cloud integration, licensing, and best-fit use cases are analyzed with comparison tables for clarity. A dedicated section on demo scenarios is included to showcase strengths and differences in a lab environment. Finally, we provide a decision framework to guide choosing the right approach based on an organization’s needs.

With Azure Arc-enabled servers, many of us are already familiar with the ability to establish SSH connections to these machines. If this is news to you, here’s something exciting: you can SSH into Windows machines that have been onboarded to Azure Arc! Now, I can imagine security professionals having a moment of concern—yes, you read that right: SSH access to Windows machines onboarded with Azure Arc is possible.

Here’s an even bigger revelation: this applies not only to on-premises machines but also to Azure Arc-enabled servers running on other cloud platforms like AWS and GCP. However, before panic sets in, let me assure you that this functionality is secure and well-architected for safe usage. (Although I’ll admit, I’m not the security expert breaking out in a cold sweat right now!)

They say peanut butter and chocolate are better together, but have you ever heard anyone say AWS and Azure are better together? How about having a centralized solution to manage both your AWS and Azure resources seamlessly?

Well, I have something exciting to share. It’s not chocolate and peanut butter, but it will definitely make managing resources across a multicloud environment much easier. Let me introduce you to the Multicloud Connector enabled by Azure Arc.

There are several key differences when deploying an Azure Stack HCI Cluster using a premier solution like Dell’s APEX Cloud Platform for Microsoft Azure versus using an integrated system. For detailed information about Azure Stack HCI solution categories, please visit Azure Stack HCI Solutions.

One notable difference is the use of a service principal in the cluster deployment for APEX and the necessary Azure roles that need to be assigned. In contrast, integrated systems require deployment through Microsoft Cloud, either via the portal or ARM Templates. When using the portal method, the deploying account must have the appropriate Azure roles assigned. With the ARM Template method, a service principal is required, but the deployment process will assign the necessary roles to that service principal. While access to run the ARM template is still required, the template will handle the rest of the role assignments.

There are several methods to deploy an Azure Stack HCI OS Image. You can use solutions like System Center Configuration Manager (SCCM/ConfigMgr), Microsoft Deployment Toolkit (MDT), Windows Deployment Services (WDS), or other Infrastructure as Code (IaC) tools like Terraform and Ansible, with the appropriate configurations. Additionally, Canonical offers a solution called MAAS (Metal-As-A-Service).

Throughout my career, I’ve generally preferred Microsoft solutions for deploying Microsoft Operating Systems, favoring tools like MDT and WDS. However, my current company isn’t a Microsoft-centric environment. Instead, they use Terraform and Ansible for IaC, which I’m not very experienced with, but I’m open to learning.

With most my blogs, they all start with me trying to do something I have done in the past and have forgotten or with something I have never had to do and now need to do it. So, is the case with this blog. I have never had to worry about establishing an ssh connection to a Linux VM in Azure via Azure Bastion until today.

I want to start this blog by showing how to connect via Bastion using the Azure Portal first. Then move on to how to establish the connection using a native client on our local machine via Azure Bastion.

I drink the Microsoft Kool-aid and have for many years. What you may not know is years ago, many years ago, I use to drink the Vmware Kool-aid and would attend VMUGs and was certified for VMware. This was about the version 4 days when vSphere was fairly new and there wasn’t much more to Vmware than vCenter and ESXi servers. I jumped ship to the dark side, mainly because I started working with SMS 2003 and Configuration manager 2007 after a little bit of time working with Altiris Deployment Server and Notification Server. Yes, I am that old. This was pre-Symantec days of Altiris as well. However, Symantec bought them and I also got certified as something or something with Symantec. I forget, but I still have an awesome chess set from Symantec with all the piece being a server rack or something in a data center except for the pawns, they are old CRT monitors.

The 12 Days of Azure Arc-Mas: A Festive Journey Through Azure’s Hybrid and Multi-Cloud Capabilities

I counted down to the end of the year, and was excited to bring you a special gift: “The 12 Days of Azure Arc-Mas.” This series was inspired by the classic carol “The Twelve Days of Christmas,” with a tech twist that celebrates the gifts Azure Arc delivers to IT professionals each day. This was a fun series that was very high level. Depending on my response I may dig deeper into sections later this year.

Celebrating Success: The 12th Day of Azure Arc-Mas

On the twelfth day of Arc-mas, our Azure journey culminates in a grand celebration of achievements. Azure Arc has played a pivotal role in transforming how organizations manage their hybrid and multi-cloud environments, and today, we share these triumphs.

The Beat of Progress: Twelve Drums Celebrating 🥁

Azure Arc’s story is one of innovation, efficiency, and operational excellence. As we celebrate the victories of the past, we are excited to share the real-world impacts and success stories that have been made possible through this powerful tool.