Azure Stack Blog articles

We're moving!

Cosmos_Darwin — Mon, 25 Nov 2024 15:59:06 GMT

Hello friends,

Last week at Microsoft Ignite 2024 we introduced Azure Local, cloud infrastructure for distributed locations enabled by Azure Arc. Azure Local is an exciting new chapter for adaptive cloud. It replaces Azure Stack HCI and adds important new options like lower-cost edge devices (preview) and disconnected operations (preview). There is no action required for existing Azure Stack HCI customers: you'll transition seamlessly to Azure Local.

If you haven’t already, check out the announcement blog.

Azure Local is powered by Azure Arc, so it makes sense to unite the Tech Community blogs. Going forward, we’ll use the Azure Arc blog for Azure Local. We’ll migrate all the old content from the Azure Stack blog soon, to ensure that nothing is lost.

On behalf of the team, I want to say a heartfelt thank you for all your enthusiasm, comments, and questions over the years. In the last decade, we’ve published more than 100 posts on this Azure Stack blog, and you’ve read them more than 1.3 million times! Technological progress is a journey with no end, but what really matters is the friends we made along the way. <3

Now… go follow the Azure Arc blog! We’re excited to keep the party going over there.

- Cosmos and the Azure Local team

Public Preview of Azure Migrate from VMware to Azure Stack HCI

Shriramnat — Tue, 01 Oct 2024 18:06:26 GMT

Today, we are thrilled to announce the public preview of the Azure Migrate functionality to migrate VMs from VMware to Azure Stack HCI, a significant enhancement in our cloud migration capabilities that seamlessly extends to the edge, in line with our adaptive cloud approach.

Seamless Migration with Azure Migrate

The core of this release lies within the integration of Azure Migrate with our adaptive cloud framework, facilitating a smooth transition of Virtual machines from VMware to Azure Stack HCI. Azure Migrate is a proven solution used by numerous organizations to move on-premises workloads to Azure, and now, it extends its capabilities to support Azure Stack HCI as well.

Key Benefits of Azure Migrate for VMware to HCI

Agent-less Replication: Migrate your virtual machines without the need for installing agents inside the VMs, simplifying the process and reducing the risk of disruptions.
Configure your workload during Migration: Azure Migrate provides the ability to reconfigure the properties of your VMs such as CPU, RAM and more directly from the migration experience.
No workload impact during replication: Azure Migrate uses technologies such as LEDBAT++ to optimize the network traffic and ensure reliable transfer from source to target. It also interacts directly with the vCenter APIs to copy the disks in the background. This means your workload n VMware will continue to run with no disruption during the copy process.
Data stays on premises: The VMs being migrated go directly from the VMware infrastructure to the Azure Stack HCI infrastructure without going through the cloud. This allows you to stay in control of your data and ensure compliance.
Minimal Cutover Time: Designed to minimize downtime, our migration solution ensures a quick and efficient cutover to Azure Stack HCI, maintaining business continuity.

Why Choose Azure Stack HCI for VMware Workloads?

Migrating to Azure Stack HCI offers numerous advantages that can transform your IT infrastructure:

Enhanced Performance: Experience faster application performance with cutting-edge hardware and optimized configurations.
Scalability: Effortlessly scale your infrastructure to meet growing demands without sacrificing performance.
Integrated Azure Services: Seamlessly integrate with Azure services such as Azure Backup, Azure Site Recovery, and Azure Security Center to enhance disaster recovery and security.
Simplified Management: Utilize centralized management tools to monitor and manage your HCI environment with ease.
Cost Efficiency: Optimize resource utilization and reduce operational costs through efficient management.

Adaptive Cloud: The Future of IT Infrastructure

The adaptive cloud approach shifts organizations from a reactive posture to one of proactive evolution. By building resilience into their operational models, businesses can optimize resource usage and mitigate security and business risks before they manifest. This approach ensures that organizations can anticipate and act upon changes in market trends, customer needs, and technological advancements ahead of time, fostering continuous improvement and innovation (Microsoft Azure).

Get Started Today!

We invite you to explore the transformative benefits of Azure Migrate support for VMware to Azure Stack HCI migrations and are looking forward to assisting you at every step, ensuring a smooth and successful migration.

Visit the Azure Migrate documentation page to learn more and begin your journey. For more information, contact your Microsoft account representative. We look forward to helping you achieve your cloud migration goals!

Shriram

Sneak peek at new Azure edge infrastructure at Hannover Messe 2024

Cosmos_Darwin — Mon, 22 Apr 2024 19:31:20 GMT

Written by Cosmos Darwin, Principal Group Manager on the Azure Edge & Platform team

This week is Hannover Messe 2024, the world’s biggest industrial trade fair. Microsoft is there, including members of the Azure Stack team, showcasing how the Microsoft Cloud enables end-to-end manufacturing solutions that help securely connect people, assets, and business processes, empowering organizations to be more resilient.

Near the center of our booth, you can watch a robotic assembly line put together battery parts. The line features standard OT assets from our partner Rockwell Automation and shows how an adaptive cloud approach together with open standards like OPC UA can accelerate industrial transformation. Azure IoT Operations enabled by Azure Arc flows data from the production line into Microsoft Fabric, enabling real-time monitoring and analysis in the cloud.

And if you look closer, you may spot an exciting new infrastructure solution hosting it all:

Caption: Glimpse the new Azure edge infrastructure at the Hannover Messe 2024 expo.

Hardware for the industrial edge

As organizations adopt new OT technologies like Azure IoT Operations, which runs on Kubernetes, a core challenge for IT is to provide an appropriate computing infrastructure at the edge to support it. They need an infrastructure solution that’s easy to deploy, easy to manage at-scale across many locations, and that provides all the capabilities needed to deliver the applications, like managed Kubernetes and enterprise-grade resiliency. Most important of all, it needs to work in an edge setting like a factory floor, where neither the environmental factors nor the budget can accommodate a rack of servers.

For these kinds of situations, our team is working to extend Azure edge infrastructure to smaller form factor devices: edge/industrial PCs. The demo at Hannover Messe runs on three Lenovo ThinkEdge SE30s, an exemplar of this new category. These devices are great: they’re rugged, affordable, and they provide just the right amount of capability for this application, with an Intel Core™ i5 vPro® processor and 16 GiB of memory each.

Caption: Lenovo ThinkEdge SE30 is a great example of the edge/industrial PC device category.

Optimized low-footprint architecture

To make the most of limited resources, this new infrastructure solution blends familiar elements of Azure Stack HCI with some exciting new approaches. Azure Linux is used as the host operating system, and then the Azure Kubernetes Service is used to turn those machines into a Kubernetes cluster. The result is Kubernetes running directly on bare metal, with no virtualization at all. The whole infrastructure solution is deployed and operated from Azure cloud.

Caption: Solution architecture uses Azure Linux and AKS on bare metal to minimize footprint.

(Equivalently, for a more familiar experience, you could also run Windows IoT Enterprise as the host operating system with AKS Edge Essentials virtualized on top. We’re all one engineering team here in Azure, so we won’t be offended – pick whichever OS you prefer!)

Managed from the cloud – demo!

Beyond the on-device architecture, the core promise of adaptive cloud is a unified control plane to manage the whole solution, from apps to infrastructure. Check out this short demo to see how the Azure resource manager (ARM) and Azure Portal can be used with this new edge infrastructure: the solution is presented by a native ARM resource; its configuration is pushed from the cloud to enable repeatability and infrastructure-as-code; integration with management services like Azure Monitor is seamless; and you can even drill down into Kubernetes resources with just a few clicks.

Get ready to try it yourself

For now, this new edge infrastructure solution is a technology demonstration, but we’ve been pleasantly surprised how well it works. We plan to start previews later this year. If you’re interested, sign up now to be among the first to get early access. And in the meantime, watch this space for more news about all things edge infrastructure, from hyperconverged servers to edge/industrial PCs.

❤️

- Cosmos

Apply critical update for Azure Stack HCI VMs to maintain Azure verification

Kim_Lam — Tue, 13 Aug 2024 17:23:38 GMT

Update 2 (2024 August 13): Versions updated in below lists. 7D update was released on 2024 July 25 and 8B update on 2024 August 13.

Update (2024 June 24): There are additional certificates that will be added to upcoming (July/August 2024) updates to VMs. Until those updates are pushed out, customers may see Azure verification and activation issues. This will not affect the functionality of your workloads and the activation errors will no longer persist once the VMs are updated. Please stay tuned for the respective update for the respective workload.

Azure verification for VMs on Azure Stack HCI makes it possible for Azure-exclusive benefits to work outside of the cloud and in on-premises and edge environments. These benefits include Azure Virtual Desktop for Azure Stack HCI, Windows Server Datacenter: Azure Edition, Extended Security Updates (ESUs) for SQL and Windows Server Virtual Machines (VMs) on Azure Stack HCI, and Azure Policy guest configuration. To keep these workloads continuing to function, periodic updates are required to maintain their security and functionality.

Update Azure Stack HCI VMs

Recently, Microsoft rolled out critical updates for Azure verification for VMs on Azure Stack HCI, and we strongly recommend current users to apply these latest cumulative updates for continued, seamless functionality of your Azure benefits on Azure Stack HCI VMs. The latest VM updates are as follows:

Azure Virtual Desktop for Azure Stack HCI
- Windows 11 multi-session, 7D/8B update (22H2+ KB5040527, 21H2 KB5041592)
- Windows 10 multi-session, 7D update (KB5040525)

Windows Server Datacenter: Azure Edition
- Windows Server 2022, 8B update (KB5041160)

Extended Security Updates (ESUs) on Azure Stack HCI
- Windows Server 2008, June 2024 SSU (KB5039341)
- Windows Server 2008 R2, June 2024 SSU (KB5039339)
- Windows Server 2012, July 2024 SSU (KB5040570)
- Windows Server 2012 R2, July 2024 SSU (KB5040569)
- For full details, see Latest Servicing Stack Updates

Azure Stack HCI VMs can be updated using a variety of methods including Windows Update, Azure Update Manager, Windows Server Update Services, or System Center Virtual Machine Manager. Please note that not all OSes are supported with Azure Update Manager, see Azure Update Manager support matrix.

We recommend that these VMs updates be completed by as soon as possible to avoid possible impact to your current workloads and licensing of these Azure benefits. If you do not update your Azure Stack HCI VMs to the latest version as noted above, you may see issues with the Azure verification and licensing of Azure Stack HCI VMs. Please update the VMs at that time and reach out to Microsoft Support if there are further questions or issues.

This update is not critical if you are not using the Azure benefits enabled by Azure verification of Azure Stack HCI VMs.

Update Azure Stack HCI Azure Marketplace VM Images

If you’re using Azure Marketplace VM images, we also recommend updating pre-existing Azure Marketplace VM images on your Azure Stack HCI cluster to the latest versions. The updated VM images are available now on Azure Marketplace and for update in the Azure Portal.

More Information

For full details on updates, please see Azure verification for VMs - Azure Stack HCI.

For more information regarding why this update is recommended, please review this Tech Community blog for more details on updates to Azure verification.

Logical Networks in Azure Portal for HCI: Setting the Stage for Software Defined Networking

cindywan — Wed, 20 Mar 2024 16:49:42 GMT

At this past Microsoft Ignite 2023, we officially announced the public preview of logical networks in Azure Portal for Azure Stack HCI. Logical networks, also called LNETs, are traditional VLAN-based networks. You may have noticed that this construct was previously called virtual networks in Azure Portal. After all, if you compare the Azure Stack HCI experience to Azure, a virtual machine always gets connected to a virtual network; so, why is it necessary to bring in logical networks to Azure Portal for HCI?

In Azure, everything is virtualized, and any customer who is trying to onboard their workloads onto Azure is doing it all on a virtual network. However, there are customers in Azure Stack HCI who want to put their applications either on a completely virtualized network or on a physical network. In order to create that differentiation, we have introduced logical networks to represent your physical networks.

It's important to note that in a few months, logical networks will give you the ability to provision network security groups on your logical networks in the same way you can provision them on your virtual networks on Azure. While currently you can attach a virtual machine to a logical network, you will later get the capability to not only provision network security groups to secure your VMs even though they are sitting on regular VLANs but also create and manage software load balancers with SDN logical networks. All of these policies will be software-defined with no changes needed on the physical network.

Now, you may be wondering how you can provision your Azure-style virtual networks through Azure Portal for HCI… do not worry, because virtual networks are coming soon! The virtual networks that we will be bringing in later this year will function in the same way virtual networks in Azure are currently used.

Ultimately, launching logical networks on Portal was needed to bring our north star of SDN virtual networks which will be coming in late 2024. Logical network support through the Portal is an essential part of the SDN journey in Azure Stack HCI, as it allows you to start using SDN with VLANs that you are already familiar with. With logical network support in Azure Portal, you can experience how SDN can provide value to your workloads before moving on to virtual networks and therefore be able to integrate SDN more seamlessly into your networks.

Please check out the demo below showing the logical network experience in Azure Portal. In this demo, Azure Stack HCI Senior PM Varun Lakshmanan demonstrates how to create a static and dynamic logical network as well as how to provision a virtual machine on a logical network in Azure Portal for HCI.

We are so excited to finally bring in logical networks, and we hope you can reap the benefits of LNETs in the Azure Portal experience for HCI. Please look forward to additional security benefits added to LNETs with network security groups as new SDN capabilities are added later this year. As always, please feel free to give us feedback on your SDN experience by emailing sdn_feedback@microsoft.com. We hope to continue improving our product and your experience in any way we can!

Introducing Azure Virtual Desktop workload in Azure Stack HCI Sizer!

Kushmeen_Kambow — Wed, 13 Mar 2024 12:22:35 GMT

Earlier in February 2024, we announced the general availability of Azure Virtual Desktop for Azure Stack HCI which extends the capabilities of the Microsoft Cloud to your datacenters and edge locations . Today, we are happy to announce that ‘Azure Virtual Desktop’ is now available as a new workload category in Azure Stack HCI sizer! It enables customers to efficiently plan and size Azure Virtual Desktop deployments on Azure Stack HCI by calculating no. of VM required, suggest per VM configuration and what hardware to purchase.

Azure Stack HCI Sizer

Azure Stack HCI Sizer is a web-based comprehensive tool to assist organizations in accurately estimating hardware requirements for their Azure Stack HCI deployments.

Azure Virtual Desktop for Azure Stack HCI

Bringing the benefits of Azure Virtual Desktop and Azure Stack HCI together, Azure Virtual Desktop for Azure Stack HCI lets organizations securely run virtualized desktops and apps on-premises at the edge or in their datacenter. For organizations with data residency requirements, latency-sensitive workloads, or those with data proximity requirements.

Getting Started

The sizer allows you to create multiple projects, thus reflecting your various business needs.
To plan your Azure Virtual Desktop workload on Azure Stack HCI, first go to the sizer tool and create a new project.

Step 1 of the sizer asks you for Environmental preferences that will stay consistent across your projects, for example, Preferred system type, CPU family etc.

Step 2 of the sizer asks for your workloads. You can now select ‘Azure Virtual Desktop’ as a Workload category when you click on ‘Add workload’.
As soon as you select workload category as ‘Azure Virtual Desktop’, you can now provide information about your environment like:

Max. concurrency percentage i.e., maximum no. of users who will login concurrently
Session type i.e. Multi-session or Single session
Workload type i.e. Light, Medium, Heavy or Power workload.
(Learn more about session host sizing guidelines here)

Optionally, you can also plan a file share to manage user profiles.

Based on the above input parameters, Azure Virtual Desktop workload will calculate number of virtual machines required and will also minimum recommended VM configuration.
We strongly recommend that each customer to perform stress testing based on the apps required and update per VM configuration as needed.

Add the workload to the project and click on ‘Next’ to see what hardware has been suggested by the sizer based on HCI catalog.
At this stage, you’ve completed all the steps and can check out the results and see what hardware we recommend for your workloads. If you notice anything odd about your results, you can go back and edit your environmental preferences as well as your workloads from the results page. Our suggestion tells you the exact model, number of nodes and node level recommendations that would satisfy your needs. We also include utilization bars for CPU, memory and storage which show you resource consumption and help you understand how we arrived at our recommendation.

Conclusion

We are excited for the future of Azure Virtual Desktop for Azure Stack HCI as we keep building and transforming with our customers. We would love to hear your feedback and suggestions on this form.

Thank you!

Hyper-V VM Migration to Azure Stack HCI, version 23H2

KerimHanif — Mon, 12 Feb 2024 14:00:00 GMT

Written by Kerim Hanif, Senior Program Manager on the Azure Edge & Platform team

Azure Migrate is a unified platform that simplifies migration, modernization, and optimization of on-premises resources to Azure. We have been working very closely with Azure Migrate team to add more destinations for Azure Migrate like VMware and Hyper-V. Last year we launched the private preview of Hyper-V virtual machine (VM) migration with Azure Migrate, and today we are very happy to announce the public preview of this capability.

Note: VMware migration is currently in private preview. Please fill this form if you would like to be part of the private preview and help us build a high-quality migration capability.

What is new in this public preview?

This feature enables you to migrate your Windows and Linux VMs running on Hyper-V to Azure Stack HCI, version 23H2 clusters (GA as of Feb 1^st of this year). A wide range of source environments starting from Hyper-V on Windows Server 2012 R2 to Windows Server 2022 are supported.

This feature uses the agentless migration option of Azure Migrate. This means that you don't need any prep such as installing an agent on the source VMs. All you need are two appliances, one on the source, and one on the target.

While you can manage, monitor, and configure via the cloud (Azure Migrate), the data transfer between the source and the target is kept local.

All the migrated VMs are Arc-enabled by default. This means that the full power of Arc VM management is immediately available to you once the migration is complete.

Migrating variety of VMs (Windows and Linux) from Hyper-V to Azure Stack HCI

How to get started?

Make sure that you have an Azure Stack HCI cluster running version 23H2.
Create a migration project in Azure Migrate.
Discover the VMs on your source Hyper-V servers and clusters.
Select the VMs you want to migrate and start replicating them to the target Azure Stack HCI cluster (source VMs can continue running at this stage).
When ready, start the migration, and migrate your VMs with minimal downtime.
Track the progress from the Azure portal.

Where to learn more?

For more information and detailed steps, please visit the following links:

AKS enabled by Azure Arc is now available on Azure Stack HCI 23H2

guanghu_MS — Thu, 01 Feb 2024 17:03:20 GMT

Azure Kubernetes Service (AKS) allows you to run a managed Kubernetes solution at the edge wherever you need it, with built-in support for Linux and Windows containers and cloud integrated lifecycle management. We are thrilled to announce the general availability of Azure Kubernetes Service (AKS) for the newest Azure Stack HCI version, a key enabler of advancing hybrid cloud to adaptive cloud with Azure. This release represents the convergence of Kubernetes orchestration and Azure Stack HCI capabilities, offering a seamless and efficient experience for our users.

What’s new in AKS?

Based on our customers’ input, we have made several improvements and additions to AKS to keep enhancing the simplicity of operation and the efficiency of developers.

Simplified AKS infrastructure deployment and management

After installing and configuring Azure Stack HCI, without additional configuration steps. The AKS infrastructure components including the Arc Resource Bridge, Custom Location, and the Kubernetes Extension for the AKS Arc operator, are all deployed as part of the Azure Stack HCI deployment.

Screenshot: Azure Stack HCI portal view with Kubernetes cluster in resources and Get started.

In addition to the initial deployment, lifecycle management of AKS infrastructure follows the same approach as the other components on Azure Stack HCI through regular updates. The integration ensures that all AKS infrastructure components are automatically installed and updated with the validated recipes.

Cloud-based management of Kubernetes clusters and applications

Applying adaptive cloud principles enables you to easily provision and manage Kubernetes clusters in the Azure portal, directly from the AKS resource view, Azure CLI, or ARM templates for automation. You can also deploy your applications via ACR to manage your container images.

Screenshot: Create a Kubernetes cluster with Azure Arc via Azure Portal.

Unified resource model with rich Arc extensions support

Every AKS cluster provisioned through Azure Arc is automatically configured with the Kubernetes agents inside, enabling access to common arc connected Kubernetes extensions. Through supporting the new resource model, AKS delivers unified user experience and rich Arc extensions support, aligning with general Arc connected Kubernetes clusters.

Get Started Today

The new release of Azure Stack HCI is generally available today. Follow the deployment guide and visit the Azure portal to get started.

Learn more about AKS on Azure Stack HCI:

During the product preview phase, we received valuable feedback from our customers and partners. We appreciate the collaboration and are excited to invite you to join us on this transformative journey. You can tell us your feedback following this link. Together, we can shape the future of AKS, enabled by Azure Arc.

Azure Stack HCI version 23H2 is generally available

Cosmos_Darwin — Thu, 29 Feb 2024 18:02:27 GMT

Written by Cosmos Darwin, Principal PM Manager on the Azure Edge & Platform team

Today we’re announcing the general availability of Azure Stack HCI version 23H2, the latest cloud-managed edge infrastructure from Microsoft Azure.

First introduced a few months ago in preview, Azure Stack HCI version 23H2 brings adaptive cloud principles to the full stack. You can deploy and operate everything from hardware to applications using Azure Resource Manager and core Azure management services, unifying siloed teams around a common platform. New container-based apps run alongside existing VMs with Azure Kubernetes Service, and every workload is automatically Azure Arc enabled, making it easy to leverage cloud-based configuration, observability, and advanced security across all your resources.

Ready for production

General availability means that Azure Stack HCI version 23H2 is ready for production use. Based on preview feedback and internal measurement, version 23H2 deploys and updates more reliably than any prior version. Starting today, new deployments can use version 23H2 and receive production-level technical support from Azure Support. Whether you’re experiencing an issue or just have a question, our dedicated team of engineers are standing by and ready to help. Version 23H2 is now the default and is no longer labeled ‘Preview’ in Azure portal.

Screenshot: Use Azure Arc to provision and manage VMs on Azure Stack HCI.

General availability includes all the Azure Arc infrastructure needed to provision and manage workloads: the Arc Resource Bridge, Custom Location, and the new Azure Kubernetes Service powered by Azure Arc are all generally available today. Thank you to everyone who participated in the preview over the last two years. Your feedback has had a huge influence shaping the functionality that’s GA today, like role-based access control (RBAC), extensions support for VMs and Kubernetes, logical networks and storage paths management, and more.

Learn more about what’s new for Azure Kubernetes Service enabled by Azure Arc in their announcement blog post.

Azure Virtual Desktop for Azure Stack HCI

Today we’re also announcing the general availability of Azure Virtual Desktop for Azure Stack HCI. We’re committed to an adaptive cloud approach, empowering customers to leverage cloud technologies and services wherever they're needed. We’ll continue to bring the most popular Azure services to the edge with Azure Stack HCI.

Azure Virtual Desktop delivers remote desktops and applications anywhere and is the only cloud VDI solution fully optimized for Windows 11 and Windows 10 multi-session, which helps you improve productivity while keeping costs in check. Combining the benefits of Azure Virtual Desktop and Azure Stack HCI, this new Azure Virtual Desktop for Azure Stack HCI capability brings together the flexibility of an industry-leading cloud VDI service with the on-premises control you need to fit your unique business requirements. Whether you have regulatory compliance and data residency requirements, latency-sensitive workloads, or need to manage data gravity, Azure Virtual Desktop for Azure Stack HCI extends the capabilities of the Microsoft Cloud to your on-premises environment.

Watch the new how-to video from Microsoft Mechanics to see for yourself:

Learn more about features, pricing, and more in the Azure Virtual Desktop announcement blog post.

Choose turnkey solutions from your preferred vendor

We are pleased to partner with leading global vendors to deliver validated hardware-software solutions for Azure Stack HCI. Dell APEX Cloud Platform for Microsoft Azure, the first Premier Solution for Azure Stack HCI, will be available with version 23H2 next month. Integrated Systems including HPE ProLiant, Lenovo ThinkAgile, and those from DataON will also support version 23H2 in the coming months.

Azure Stack HCI version 23H2 supports a wide variety of hardware platforms, from the ultra-dense to the ultra-small. There are over 250 validated nodes from more than 25 solution partners worldwide in the Azure Stack HCI solutions catalog. This broad selection lets you choose the right hardware for your needs, from the partner who offers the best service and support in your region.

Sneak peek at what’s next

We are continuously investing to broaden what’s possible with Azure Stack HCI. Alongside version 23H2, today we’re also introducing several new previews:

Azure Migrate to Azure Stack HCI (preview). Use Azure Migrate to move VMs from an existing Hyper-V environment to Azure Stack HCI version 23H2. This feature uses Azure Migrate as the control plane, but the data transfer stays entirely on-premises. Support for VMware vCenter source environments is coming soon. Learn more

Microsoft Defender for Cloud for Azure Stack HCI (preview). In addition to workload protections for VMs and Kubernetes, Microsoft Defender for Cloud now offers built-in security recommendations covering your Azure Stack HCI version 23H2 infrastructure. Learn more

Azure Arc Overview for Azure Stack HCI (preview). Navigate to the Azure Stack HCI section in Azure Arc to see built-in dashboards summarizing all your Azure Stack HCI clusters. Get an at-a-glance view of alerts, updates, and more.

Screenshot: Manage Azure Stack HCI security in the Azure portal (preview).

You can try these preview features in the Azure portal with an Azure Stack HCI version 23H2 cluster. You don’t need to join the OS preview channel or install anything. We’re pausing the OS preview channel for the next few months: there won’t be new Azure Stack HCI builds. We encourage everyone to focus on version 23H2 and use the 60-day free trial for evaluation. We’ll share more about how to preview the next feature update, version 24H2, around mid-year. Watch this blog for that.

When to use version 22H2 (temporarily)

Azure Stack HCI version 23H2 is generally available and recommended for most new deployments, but it doesn’t yet cover 100% of the scenarios supported by version 22H2. Until it does, Microsoft will continue to offer and support both versions. If you need a scenario that’s not yet supported in version 23H2, you can deploy version 22H2 and then update to version 23H2 later when your scenario is supported.

Here are the most important limitations to know about:

Regional availability. Azure Stack HCI version 23H2 is available today in two cloud regions: East US and West Europe. More regions will be added quickly over the next few weeks. Eventually it will be available in all the same regions as version 22H2, including Azure China and Azure US Government. We are working hard to make all the features, like Arc-enabled VMs and AKS, available in those regions. [Update Feb 28th: region support for Australia East has been added.]

Stretch clustering. Azure Stack HCI version 23H2 is available today for “single room” deployments where all nodes are in the same room, connected to the same switch(es). It doesn’t yet support stretching the cluster between two rooms. We know that this scenario is critical for many customers, especially in manufacturing, and we are committed to providing multi-room high availability with Azure Stack HCI version 23H2, including key features like cloud-based deployment, updates, and VM provisioning. Development will take some time: we expect to share more details around mid-year. In the meantime, customers who require a stretch cluster should continue to deploy version 22H2.

System Center support. Our ambition with Azure Stack HCI and Azure Arc is to simplify and consolidate your operational experience so that you can manage everything, from infrastructure to VMs to Kubernetes, with a single control plane, the Azure Resource Manager, and a single pane of glass, the Azure portal. We’ve heard your feedback about how important this is, and we are committed to rapidly growing the capabilities of Azure Arc to achieve this vision. We also know that many customers have an existing investment in System Center that they prefer to leverage. In the coming months, System Center will add support for Azure Stack HCI version 23H2. We’re working on another blog post, together with the System Center team, to detail our long-term roadmap.

Please note that Azure Virtual Desktop only supports Azure Stack HCI version 23H2 presently.

Coming soon: update from 22H2 to 23H2

Azure Stack HCI will offer an in-place update from version 22H2 to version 23H2. This is our fourth annual release since launching as a subscription service, and we’re heartened by our customers’ success keeping Azure Stack HCI up to date: over 97% of clusters are running the latest version, 22H2.

This year’s update is the most advanced yet: every cluster will get the Azure Arc infrastructure, the Lifecycle Manager, and more during the update. Our highest priority is to ensure that the update is seamless, so we’re taking some extra time for testing. We expect to start offering the update to a few customers as soon as next month, gradually expanding to everyone over the course of the year. Thank you for your patience as we get this right.

Until the 23H2 update has been offered to everyone, we'll continue supporting version 22H2.

There is no end date for Azure Stack HCI version 22H2 servicing or support at this time.

Thank you!

On behalf of the team in Redmond, thank you for choosing Azure to power your edge infrastructure. And a very special thanks to our preview participants who helped us find and fix so many things these last few months! Looking ahead, Azure Stack HCI has an exciting roadmap of monthly updates. We are committed to continuing to make Azure Stack HCI better for everyone, from the datacenter to the edge.

Want to try Azure Stack HCI right away? Check out the refreshed HCIBox from Azure Arc Jumpstart. It’s the quickest way to get a dedicated Azure Stack HCI virtual sandbox inside an Azure subscription for evaluation and testing, with step-by-step instructions and no hardware needed.

Ready to deploy on hardware? Contact your preferred vendor or browse the solutions catalog.

❤️

- Cosmos

Possible MAC address assignment strategies for tenant VMs running on Stack-HCI environment

vaibhavkale — Fri, 02 Feb 2024 08:04:44 GMT

Azure Stack HCI is a hyperconverged infrastructure (HCI) cluster solution consists of windows servers (Hyper-V), Storage Spaces Direct, and Azure-inspired SDN. All clustered servers share common configurations and resources by leveraging the Windows Server Failover Clustering feature. A Windows Failover Cluster consists of multiple windows servers running in a cluster to provide high availability i.e. If one server node goes down, then another node takes over. We can create multiple VMs on the failover cluster. VMs can be connected to different tenant networks. In this case we need to make sure VM connected on network 'A' with static ip should persist same network configuration even if it gets migrated from one node to another within a cluster. This is possible by assigning static MAC/static IP for the VM. But how to get free and unique MAC to assign to VM, there are different ways to solve this problem. In this article we will discuss some of them with pros and cons. (Note: solutions discussed in this article are just to suggestions, can not be considered optimal solutions)

Before this, lets understand things required to create a tenant VM. To create tenant VM connected to tenant network in stack-hci following steps are performed.

1. VM network adapters created with static MAC addresses for the lifetime of the VM. (static MAC is required because If the MAC address changes during the VM lifetime, Network Controller cannot configure the necessary policy for the network adapter. Not configuring the policy for the network prevents the network adapter from processing network traffic, and all communication with the network fails )

2. Create a new network interface on network controller service(running on SDN) having same MAC and static IP assigned.

3. Associate created network adapter with network interface controller, to make vm gets tenant network connection.

Please refer the official document for more details why these steps are required.

Following are powershell commands to perform above steps logically.

# 1. vm creation with static MAC New-VM -Generation 2 -Name "MyVM" -Path "C:\VMs\MyVM" -MemoryStartupBytes 4GB -VHDPath "C:\VMs\MyVM\Virtual Hard Disks\WindowsServer2016.vhdx" -SwitchName "SDNvSwitch" Set-VM -Name "MyVM" -ProcessorCount 4 # Setting static MAC Set-VMNetworkAdapter -VMName "MyVM" -StaticMacAddress "00-11-22-33-44-55" # Creating network interface on networkcontroller with same mac/static IP $vnet = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceId "Contoso_WebTier" $vmnicproperties = New-Object Microsoft.Windows.NetworkController.NetworkInterfaceProperties $vmnicproperties.PrivateMacAddress = "001122334455" $vmnicproperties.PrivateMacAllocationMethod = "Static" $vmnicproperties.IsPrimary = $true $vmnicproperties.DnsSettings = New-Object Microsoft.Windows.NetworkController.NetworkInterfaceDnsSettings $vmnicproperties.DnsSettings.DnsServers = @("24.30.1.11", "24.30.1.12") $ipconfiguration = New-Object Microsoft.Windows.NetworkController.NetworkInterfaceIpConfiguration $ipconfiguration.resourceid = "MyVM_IP1" $ipconfiguration.properties = New-Object Microsoft.Windows.NetworkController.NetworkInterfaceIpConfigurationProperties $ipconfiguration.properties.PrivateIPAddress = "24.30.1.101" $ipconfiguration.properties.PrivateIPAllocationMethod = "Static" $ipconfiguration.properties.Subnet = New-Object Microsoft.Windows.NetworkController.Subnet $ipconfiguration.properties.subnet.ResourceRef = $vnet.Properties.Subnets[0].ResourceRef $vmnicproperties.IpConfigurations = @($ipconfiguration) New-NetworkControllerNetworkInterface –ResourceID "MyVM_Ethernet1" –Properties $vmnicproperties –ConnectionUri $uri $nic = Get-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId "MyVM_Ethernet1" #Do not change the hardcoded IDs in this section, because they are fixed values and must not change. # 3. Finally make association of vm network adapter with nic created in last step $FeatureId = "9940cd46-8b06-43bb-b9d5-93d50381fd56" $vmNics = Get-VMNetworkAdapter -VMName "MyVM" $CurrentFeature = Get-VMSwitchExtensionPortFeature -FeatureId $FeatureId -VMNetworkAdapter $vmNics if ($CurrentFeature -eq $null) { $Feature = Get-VMSystemSwitchExtensionPortFeature -FeatureId $FeatureId $Feature.SettingData.ProfileId = "{$($nic.InstanceId)}" $Feature.SettingData.NetCfgInstanceId = "{56785678-a0e5-4a26-bc9b-c0cba27311a3}" $Feature.SettingData.CdnLabelString = "TestCdn" $Feature.SettingData.CdnLabelId = 1111 $Feature.SettingData.ProfileName = "Testprofile" $Feature.SettingData.VendorId = "{1FA41B39-B444-4E43-B35A-E1F7985FD548}" $Feature.SettingData.VendorName = "NetworkController" $Feature.SettingData.ProfileData = 1 Add-VMSwitchExtensionPortFeature -VMSwitchExtensionFeature $Feature -VMNetworkAdapter $vmNics } else { $CurrentFeature.SettingData.ProfileId = "{$($nic.InstanceId)}" $CurrentFeature.SettingData.ProfileData = 1 Set-VMSwitchExtensionPortFeature -VMSwitchExtensionFeature $CurrentFeature -VMNetworkAdapter $vmNics } Get-VM -Name "MyVM" | Start-VM

To make sure VMs works fine even after migration in windows failover cluster, we need to assign static MAC and static IP. To get available and unique MAC is challenge here. We will see following ways to solve this problem with pros and cons.

Generating random MAC on node
Assign dedicated unique MAC address pool range for every Node in cluster and Generating free MAC from Node's MAC address range pool.
Get free MAC from Network controller service and use same on VM

Lets discuss each approach in detailed-

1. Generating random MAC on node

This is very simple approach, where we will generate random MAC and same will be used. It includes below steps:

Generate valid MAC on node, where we need to create VM(or new network interface).
Set same MAC on vm network adapter as static
Set same MAC on network interface along with static IP

Following is powershell script performs same above logical steps:

New-VM -Name $vm_name -MemoryStartupBytes $vm_memory -BootDevice VHD -VHDPath $image_path -Path $vm_data_path -Generation $vm_generation -SwitchName $switch_name Add-ClusterVirtualMachineRole -vmname $vm_name -Name $vm_name Start-Sleep -Seconds 3 ############## Random MAC address generation and assignment # script block for mac address assingment kept in retry block $mac_address = Retry-Command -ScriptBlock { # do something # found used in az-auto-setup #$mac_address=("{0:D12}" -f ( Get-Random -Minimum 0 -Maximum 99999 )) $mac_address = (0..5 | ForEach-Object { '{0:x}{1:x}' -f (Get-Random -Minimum 0 -Maximum 15), (Get-Random -Minimum 0 -Maximum 15) }) -join '-' write-host "Tring to set : $mac_address" Set-VMNetworkAdapter -VMName $vm_name -StaticMacAddress "$mac_address" write-host "Mac set succssfully: $mac_address" Start-Sleep -Milliseconds 500 Write-host $( Get-VMNetworkAdapter -VMName $vm_name ).MacAddress return $mac_address } write-host "Mac set succssfully: $mac_address" Write-host 'VM created..' ########################################################################## # network configuration starts here.. # you can refer for more info: https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/create-a-tenant-vm#prerequisites $vnet = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceId $vnet_name $vmnicproperties = New-Object Microsoft.Windows.NetworkController.NetworkInterfaceProperties # give same mac address below as created before.. $mac = -join($mac_address.split("-")).toupper() $vmnicproperties.PrivateMacAddress = $mac Write-host $mac $vmnicproperties.PrivateMacAllocationMethod = "Static" $vmnicproperties.IsPrimary = $true $vmnicproperties.DnsSettings = New-Object Microsoft.Windows.NetworkController.NetworkInterfaceDnsSettings #$vmnicproperties.DnsSettings.DnsServers = @("192.168.1.254", "8.8.8.8") $vmnicproperties.DnsSettings.DnsServers = $dns_server $ipconfiguration = New-Object Microsoft.Windows.NetworkController.NetworkInterfaceIpConfiguration $ipconfiguration.resourceid = $vm_name + "_IP1" $ipconfiguration.properties = New-Object Microsoft.Windows.NetworkController.NetworkInterfaceIpConfigurationProperties $ipconfiguration.properties.PrivateIPAddress = $ip_address $ipconfiguration.properties.PrivateIPAllocationMethod = "Static" $ipconfiguration.properties.Subnet = New-Object Microsoft.Windows.NetworkController.Subnet # do: programatically decide subnet full ref, or form path directly # $ipconfiguration.properties.subnet.ResourceRef = $vnet.Properties.Subnets[0].ResourceRef $ipconfiguration.properties.subnet.ResourceRef = "/virtualNetworks/" + $vnet_name + "/subnets/" + $subnet_name $vmnicproperties.IpConfigurations = @($ipconfiguration) $NIC_name = $vm_name + "_Eth1" New-NetworkControllerNetworkInterface -ResourceID $NIC_name -Properties $vmnicproperties -ConnectionUri $uri -Confirm:$false -force Write-host 'NIC config created..' Start-Sleep -Seconds 8 $nic = Get-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId $NIC_name ######################################################################### #Do not change the hardcoded IDs in this section, because they are fixed values and must not change. $FeatureId = "9940cd46-8b06-43bb-b9d5-93d50381fd56" $vmNics = Get-VMNetworkAdapter -VMName $vm_name $CurrentFeature = Get-VMSwitchExtensionPortFeature -FeatureId $FeatureId -VMNetworkAdapter $vmNics if ($CurrentFeature -eq $null) { $Feature = Get-VMSystemSwitchExtensionPortFeature -FeatureId $FeatureId $Feature.SettingData.ProfileId = "{$( $nic.InstanceId )}" $Feature.SettingData.NetCfgInstanceId = "{56785678-a0e5-4a26-bc9b-c0cba27311a3}" $Feature.SettingData.CdnLabelString = "TestCdn" $Feature.SettingData.CdnLabelId = 1111 $Feature.SettingData.ProfileName = "Testprofile" $Feature.SettingData.VendorId = "{1FA41B39-B444-4E43-B35A-E1F7985FD548}" $Feature.SettingData.VendorName = "NetworkController" $Feature.SettingData.ProfileData = 1 Add-VMSwitchExtensionPortFeature -VMSwitchExtensionFeature $Feature -VMNetworkAdapter $vmNics } else { $CurrentFeature.SettingData.ProfileId = "{$( $nic.InstanceId )}" $CurrentFeature.SettingData.ProfileData = 1 Set-VMSwitchExtensionPortFeature -VMSwitchExtensionFeature $CurrentFeature -VMNetworkAdapter $vmNics } Write-host 'finally applying setting..' Start-Sleep -Seconds 5 Get-VM -Name $vm_name | Start-VM

But this approach has following problems :

There is possibility that two vms running on same cluster may got same MAC and it may create MAC conflict issue after VM migration.
Some specific MAC range is not allowed to be assigned, in this case we need to keep retrying random generation, which is not good.
Very difficult to keep track of used MAC addresses.

So this method is not found reliable.

2. Assign dedicated unique MAC address pool range for every Node in cluster and Generating free MAC from Node's MAC address range pool.

We can preassign unique dedicated MAC address pool range to every node(hyper-v) in cluster, so whenever we need to create new network interface we will first get free MAC from the pool of node where vm will be running. Same MAC will be made static on vm network adapter and network interface followed by static ip. Following are logical steps need to perform:

1. Get free MAC from Node's MAC pool range.

2. Assign same static MAC on VM network adapter

3. Set same MAC on network interface along with static IP

Following is an example of MAC pool range distribution plan for 255 clusters, 16 hosts each: 00-15-5D-[c1][c2]-[h1][v1]-[v2][v3] field c1, c2: will indicate a cluster. 00 to FF : Max 255 clusters can be created. field h1 - will be for host/node identification in a cluster. 0 to F = max 16 hosts in a cluster. field v1,v2,v3 will be used for vms. 000 to FFF = 16*16*16 = total 4096 possible vms/network interfaces per node can be created.

But main challenge here is there is no api or command available to get free MAC from node pool. There is a workaround that to get MAC assigned from the pool, we need to create dummy network adapter with dynamic configuration and start vm for a moment to get free dynamic MAC assigned from node pool range. Then we need to stop vm and revert the change and using same MAC we need to create static one and same steps need to be followed. This is not good approach since this is just a workaround, where dummy resource need to create.

# creating new network adapter with dynamic MAC Add-VMNetworkAdapter -VMName $vm_name -SwitchName $switch_name -Name $adapter_name # starting and stopping vm to get free MAC from node pool Start-VM -VMName $vm_name; Stop-VM -VMName $vm_name -Force # reading assigned dynamic MAC $mac_address = (Get-VMNetworkAdapter -VMName $vm_name -Name $adapter_name).MacAddress # make same MAC as static Set-VMNetworkAdapter -VMName $vm_name -Name $adapter_name -StaticMacAddress $mac_address # rest steps are same for network interface creation

3. Get free MAC from Network controller service and use same on VM network adapter.

There is a dedicated centralized network controller service on every Stack-hci cluster, where we can setup global MAC address range pool at network controller service. When we create new network interface on network controller service with dynamic configuration, then it assign free MAC from the global free pool. It is very reliable solution since it is a centralized service. In this, we will follow below steps

Create a Network interface in Network controller service with dynamic MAC assignment config, to get assigned free MAC from global MAC range.
Read assigned MAC on network interface
Assign same MAC address to vm network adapter as static.

The following powershell commands perform above steps (Note: please use appropriate values in place of parameters):

# Creating network interface with dynamic MAC config on network controller $vmnicproperties = New-Object Microsoft.Windows.NetworkController.NetworkInterfaceProperties $vmnicproperties.PrivateMacAllocationMethod = "Dynamic" $vmnicproperties.IsPrimary = $true $vmnicproperties.DnsSettings = New-Object Microsoft.Windows.NetworkController.NetworkInterfaceDnsSettings $vmnicproperties.DnsSettings.DnsServers = $dns_server $ipconfiguration = New-Object Microsoft.Windows.NetworkController.NetworkInterfaceIpConfiguration $ipconfiguration.resourceid = $vm_name + "_IP1" $ipconfiguration.properties = New-Object Microsoft.Windows.NetworkController.NetworkInterfaceIpConfigurationProperties $ipconfiguration.properties.PrivateIPAddress = $ip_address $ipconfiguration.properties.PrivateIPAllocationMethod = "Static" $ipconfiguration.properties.Subnet = New-Object Microsoft.Windows.NetworkController.Subnet $ipconfiguration.properties.subnet.ResourceRef = "/virtualNetworks/" + $vnet_name + "/subnets/" + $subnet_name $vmnicproperties.IpConfigurations = @($ipconfiguration) $NIC_name = $vm_name + "_Eth1" New-NetworkControllerNetworkInterface -ResourceID $NIC_name -Properties $vmnicproperties -ConnectionUri $uri -Confirm:$false -force Write-host 'NIC config created..' Start-Sleep -Seconds 8 $nic = Get-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId $NIC_name # Read obtained free MAC from global pool $mac_address = $nic.Properties.PrivateMacAddress -replace '..(?!$)', '$&-' ###### Vm creation flow starts from here. We will set static MAC here New-VM -Name $vm_name -MemoryStartupBytes $vm_memory -BootDevice VHD -VHDPath $image_path -Path $vm_data_path -Generation $vm_generation -SwitchName $switch_name Add-ClusterVirtualMachineRole -vmname $vm_name -Name $vm_name Set-VMNetworkAdapter -VMName $vm_name -StaticMacAddress "$mac_address" write-host "Mac set succssfully: $mac_address"

Conclusion:

The third/last approach discussed in this article seems to be easy and more reliable, since we are consuming MAC from centralized network controller service. We will never face problem of MAC conflicts incase VMs get migrated from one node to another.

Note:

Approaches discussed in this article are to show possible MAC address assignment strategies, with some advantages and limitations. You can use any strategy as per your requirement.
However if you find some better way, you can experiment that as well.

Software Defined Networking: Multisite - A Tale of 2 SDN Sites

Samuel-Liu — Wed, 22 Nov 2023 22:56:00 GMT

It was the best of times, it was the worst of times, it was the age with SDN Layer 3 gateways between sites, it was the age of no Layer 2 connectivity, it was the epoch of a clunky policy management system, it was the season of Darkness – I never actually read “A Tale of Two Cities” as you can tell. However, I am here to tell you about this great new feature called MultiSite coming to Azure Stack HCI’s Software Defined Networking product in 23H2 that’s about to change everything… well, maybe not everything. It won’t change your morning routines or whether I’ll ever read “A Tale of Two Cities”, but for your networking needs, Multisite will provide you with native Layer 2 and Layer 3 connectivity for virtualized workloads spread across multiple locations. Additionally, it will also provide unified network policy management for your workloads thus eliminating the need to update policies when a workload VM moves from one location to another. This feature is now available with HCI 23H2 Public Preview and will GA with 23H2 GA.

Imagine this scenario, you have two Azure Stack HCI clusters, one in Norway and another one in California. In the past, to allow workload communication across the clusters, you would have to set up a SDN GRE gateway connection between them. With a GRE gateway, you had additional overhead as you had to provision another additional resource (SDN gateway VMs) for Layer 3 connectivity across physical sites while still ensuring availability for said gateway. Ultimately, with this configuration, you’re adding an extra hop in your data path. You would also have to manage all the IP and policy configurations between the clusters to ensure alignment in the case of migration or failover. The bottom line is that there would be additional complexity in your network design while also having additional operational costs, both in time and money.

Figure 1: SDN without multisite

With SDN Multisite, a lot of these hurdles and complexities have been removed. If you want to link the same two clusters together in one SDN ecosystem, then you will have to setup separate SDN infrastructure at each site and peer the two sites together. Peering here is very similar to virtual network peering, if you are familiar with that concept. Once peering is initiated and completed, your cluster will now have support for services such as stretch clustering, migrating workloads without the need for network changes, and many more!

Figure 2: Software Defined Networking with Multisite

As fantastic as this new feature is, it is still currently limited to 2 physical locations but don’t fret. Scaling out is on our roadmap!

Deployment Options

Prerequisites

Before you begin, please ensure the following prerequisites are met:

There must be underlying physical network (Provider Network) connectivity between two sites. Moreover, the Provider Network name must be the same on both sites.
TCP port 49001 must be permitted by firewalls for cross-cluster communication.
SDN must be installed on both sites separately, using SDN Express scripts or using Windows Admin Center. Hence, SDN infrastructure like Network Controller VMs, SLB MUX VMs and SDN Gateway VMs are unique to each site.
At least one of the two sites must not have any virtual networks and/or Network Security Groups (NSGs) and/or user defined routes configured.
The SDN MAC pool must not overlap between the two sites.
The IP pools for the logical networks (HNV PA, Public VIP, Private VIP, GRE VIP, L3) must not overlap between the two sites.

Step-By-Step

To setup multisite through Windows Admin Center, first click on the Network Controller tab in the extension column in Tools.

NOTE: You will need Windows Admin Center 2311 Preview version to install the SDN multisite feature. This can be downloaded here: Download Windows Server Insider Preview (microsoft.com)

2. From there, click on New to add a second site

3. Once you’ve clicked on New, another window will pop up asking for the following:

Name – The name of the second site
Network Controller REST Uri – REST URI of your second site
Cluster Name for New site – Cluster name of your second site
Network Controller VM name for new site – Any NC VM name of your secondary site
Network Controller VM name – NC VM for your primary site

4. Once you’ve entered all the fields, simply click on Submit and you’re all done

For those of you who enjoy a demo of the setup, I’ve included a link below to our Windows Admin Center deployment as well as step-by-step instructions.

Note: PowerShell video mentioned at the beginning of the demo will be posted soon

Since this feature is in public preview now, please refer to this link (Join the Azure Stack HCI preview channel - Azure Stack HCI | Microsoft Learn) to get instructions for access.

Next Up…

Last, but not least, if you’d like to learn more about this feature from deployment to removal, stay posted for our technical documentation coming out next month!

And if all else fails, feel free to reach out to our email sdn_feedback@microsoft.com to get our attention. We’d be more than happy to work with you on setup and to hear all the feedback you might have.

Accelerate edge deployments with cloud-managed infrastructure and Azure Stack HCI version 23H2

Cosmos_Darwin — Mon, 20 Nov 2023 21:16:44 GMT

Authored by Cosmos Darwin, Principal Group Manager, Azure Stack HCI

Today at Microsoft Ignite 2023 we’re announcing the public preview of Azure Stack HCI version 23H2. Azure Stack HCI is cloud-managed hyperconverged infrastructure that applies adaptive cloud principles to the full stack. With Azure Stack HCI, you can deploy and operate everything from hardware to applications using Azure Resource Manager and core Azure management services, unifying siloed teams around a common platform. New container-based applications can run alongside your existing virtual machines with Azure Kubernetes Service, and every workload is automatically Azure Arc enabled, making it easy to leverage cloud-based configuration, observability, and advanced security across all your resources.

Check out the demo to see what’s new:

Scale with the power of the cloud

In industries like retail, manufacturing, and healthcare, it’s common for physical operations to be spread across many edge locations. As digital transformation initiatives bring more computing into the store, factory, or clinic, managing the explosion of new technologies across thousands of locations can be overwhelming and expensive. Edge infrastructure that can be deployed quickly and managed centrally, with AI-enhanced tools that scale to thousands of resources, provides a powerful competitive advantage. With Azure Stack HCI version 23H2, core lifecycle operations like deployment, patching, configuration, and monitoring are performed entirely from the cloud, reducing the need for on-site tools and personnel.

Screenshot: Updating multiple Azure Stack HCI clusters with one click in Azure Update Manager.

Cloud-based deployment

Azure Stack HCI version 23H2 is easier to deploy at scale. When new machines arrive at an edge location, if the OS is preinstalled, on-site personnel can simply plug them in and establish the initial network connection to Azure Arc. Then, the rest of the infrastructure is deployed from the cloud, including cluster, storage, and networking configuration. This reduces the time and expertise required on-site to the bare minimum. You can use the Azure portal to create an Azure Stack HCI cluster or scale with an Azure Resource Manager (ARM) template that you can reuse repeatedly with unique parameters for each edge location. This infrastructure-as-code approach makes it easy to ensure that Azure Stack HCI is configured consistently at scale. Beginning with version 23H2, all Azure Stack HCI clusters are deployed from the cloud.

Cloud-based update management

Staying up to date is easier too. Azure Stack HCI version 23H2 introduces a new Lifecycle Manager that organizes all applicable updates into a single monthly package covering the OS, agents, services, and even drivers and firmware for participating hardware solutions. Lifecycle Manager ensures that your cluster always runs a software combination (or “recipe”) that has been validated by Microsoft and our partners, reducing the risk of update issues or incompatibilities. Update management for Azure Stack HCI clusters is integrated with Azure Update Manager, providing a unified tool for all your machines across the cloud and the edge. You can check for updates and select one or multiple clusters to apply with just a few clicks in the Azure portal. Updates are rolled out with cluster-aware updating, meaning that they are applied sequentially to each host with no downtime for apps or users. Beginning with version 23H2, all Azure Stack HCI clusters are updated from the cloud.

Cloud-based monitoring

Azure Monitor provides unified observability for apps and infrastructure across the cloud and the edge. This now includes logs, metrics, and alerts coverage for Azure Stack HCI version 23H2. There are over 60 standard Metrics available for Azure Stack HCI including processor and memory usage, storage performance, network bandwidth, and more. Azure Stack HCI health issues, like a failed disk or a misconfigured network port, surface as new platform Alerts that you can customize to trigger notifications or actions. And Azure Monitor Insights, powered by Data Collection Rules and Workbooks, provides pre-built views to help you monitor specific features and scenarios, like storage deduplication and compression.

Read the docs to learn more about What’s new in 23H2 (preview)

Central management for all your workloads

Most organizations find themselves managing a wide variety of applications: some container-based, others VM-based; some running in the cloud, others running at the edge. With Azure Arc and an adaptive cloud approach, you can leverage common tools and implement common operational practices across all your workloads, wherever they run. Azure Stack HCI version 23H2 provides all the Azure Arc infrastructure needed, set up automatically as part of deploying the host cluster, including the Arc Resource Bridge, Custom Location, and other agents and management components. This means that right out of the box, you’re ready to start provisioning Arc-enabled virtual machines, Azure Kubernetes Service clusters, and Azure Virtual Desktop session hosts.

Screenshot: Get started by deploying virtual machines, Kubernetes clusters, or Azure Virtual Desktop session hosts.

Virtual machines

Many critical workloads run as virtual machines. Azure Stack HCI version 23H2 provides general-purpose VMs with flexible sizing and configuration options to meet your application requirements. You can bring your own Linux or Windows custom images or conveniently access ones from the Azure Marketplace. Use Azure Arc to define storage paths and logical networks, with support for static IP assignment or DHCP. Every new VM created through Azure portal, CLI, or an ARM template is automatically configured with the Connected Machine Agent for guest management including VM extensions like Microsoft Defender, Azure Monitor, and Custom Script, enabling consistent management for all your machines across the cloud and the edge. You can create new VMs or sign up to preview the new integration with Azure Migrate to move VMs from VMware or Hyper-V to Azure Stack HCI. Azure Arc-enabled VM management will reach general availability (GA) with version 23H2.

Azure Kubernetes Service

New applications are increasingly packaged as container images. Azure Stack HCI version 23H2 provides the Azure Kubernetes Service, a managed Kubernetes solution that runs locally at the edge. Azure Kubernetes Service is set up automatically as part of deploying Azure Stack HCI and includes everything you need to start deploying container-based workloads, including Linux and Windows container host images and storage and networking drivers. Azure Kubernetes Service runs its control plane in the same Azure Arc Resource Bridge as general-purpose VMs and uses the same storage paths and logical networks. Every new Kubernetes cluster provisioned through Azure portal, CLI, or an ARM template is automatically configured with the Azure Arc Kubernetes agents inside to enable extensions like Microsoft Defender, Azure Monitor, and GitOps for application deployment and CI/CD.

Azure Virtual Desktop for Azure Stack HCI (preview)

Finally, Azure Stack HCI version 23H2 is ready to deploy virtualized desktops and apps. Azure Virtual Desktop is a desktop and app virtualization service with a cloud-hosted control plane managed by Microsoft. Azure Virtual Desktop provides the familiarity and compatibility of Windows 11 and Windows 10 with multi-session capabilities that increase density and reduce costs. With Azure Virtual Desktop for Azure Stack HCI, you can locate desktops and apps (session hosts) closer to users at the edge for lower latency, with optional GPU acceleration for demanding applications. Version 23H2 brings an updated public preview that offers host pool provisioning directly from Azure portal, simpler guest OS activation, and updated Marketplace images with Microsoft 365 apps preinstalled. Information about GA timing and pricing will be shared soon.

Learn more about the updated preview on the Azure Virtual Desktop blog.

Advanced security made easy

The cyber threat landscape is rapidly changing, with attacks becoming more sophisticated and persistent. As digital transformation leads to more apps and infrastructure at the edge, it’s critical for organizations to leverage advanced security and stay ahead of attackers. Azure Stack HCI version 23H2 makes this easy with strong security defaults, native integration with Microsoft Defender for Cloud, and the option to protect virtual machines with Trusted launch.

Screenshot: Option to select Trusted launch security type when creating VM in Azure Arc.

Secure by default

All new Azure Stack HCI version 23H2 clusters are deployed with a hardened security posture. Building on the Secured Core Server foundation, over 300 settings across the hypervisor, storage, and networking stack are applied with the Microsoft recommended values. This covers 100% of applicable settings in the Azure security baseline, an increase of 2x compared to version 22H2. This means you can deploy with confidence even if you’re not a security expert. Settings drift is detected and automatically corrected to maintain your intended posture over time. To protect against malware and ransomware, application control is automatically enforced with a Microsoft-provided base policy. You can allow additional host agents with supplemental policies, like this example provided by Veeam.

Integrated with Microsoft Defender for Cloud

Microsoft Defender for Cloud provides unified security tooling for all your resources across the cloud and the edge. In addition to workload protections for Kubernetes clusters and VMs, new built-in security recommendations provide coverage for your Azure Stack HCI infrastructure as part of the Cloud Security Posture Management plan. For example, if your hardware isn’t configured for Secure Boot, or if your clustered storage volumes aren’t encrypted, or if application control isn’t enabled, that information will appear prominently within the Microsoft Defender for Cloud portal. You can also conveniently see the protection status of your host cluster, nodes, and workloads together in one view. This makes it easy to audit and remediate your security posture at-scale, across 10s-1000s of edge locations. Sign up here to preview the new integration between Azure Stack HCI version 23H2 and Microsoft Defender for Cloud.

Trusted launch for Azure Arc-enabled virtual machines

Trusted launch is a security option that hardens VMs against firmware and boot loader attacks. Previously available only in Azure cloud, Trusted launch is now available at the edge with Azure Stack HCI version 23H2. You’ll see a new option to select the security type when provisioning an Arc-enabled VM through Azure portal, CLI, or an ARM template. With Trusted launch, the VM gets a virtual TPM that can be used to securely protect keys, certificates, and secrets, enabling applications like BitLocker. It also gets Secure Boot enabled by default. Trusted launch VMs support automatic failover and live migration: vTPM state is seamlessly preserved when the VM moves between nodes in the cluster. This is an important step in our journey to bring confidential computing to the edge.

Learn more about Trusted launch for Azure Arc VMs on the Security, Compliance, and Identity blog.

Get started today

Try the 23H2 preview

You can preview Azure Stack HCI, version 23H2 right now. Follow the deployment guide and visit the Azure portal to get started. To facilitate evaluation, the preview works with real or virtual hardware, as long as your environment meets the prerequisites.

Use 22H2 for production

Please note that version 23H2 is not yet supported for production use. As with any preview, there are some limitations and known issues. Production customers should continue to use version 22H2 for now. Jumpstart your deployment with a Premier Solution or browse the catalog to find hardware from your preferred vendor that meets your needs and budget.

Version 23H2 will become generally available (GA) in early 2024. We’ll announce it on this blog. It will initially be available for new deployments. Later in the year, most customers running Azure Stack HCI, version 22H2 will be able to update their cluster to version 23H2. The update will be available first to Premier Solutions and then more broadly. We’ll share more information about update availability and procedure soon.

Thank you

On behalf of the team in Redmond, thank you for your interest in Azure Stack HCI. We’re thrilled and humbled that so many of you have entrusted Azure to power your edge infrastructure, and we’re grateful for all your feedback over these last few years. We can’t wait to hear what you think of this latest release!

❤️

- Cosmos

AKS on Azure Stack HCI and Windows Server 2023-10-30 Update

waltero — Tue, 07 Nov 2023 01:37:32 GMT

We are pleased to announce that with this release we update the AKS HCI management cluster to Kubernetes version 1.26.6. This update enables us to set the basis for supporting futures versions of Kubernetes for your workload clusters. See the complete set of versions for each module in the GitHub release page.

Here is a description of what is included in this release:

Security Updates

Kubernetes CVE-2023-2728: Bypassing enforce mountable secrets policy imposed by the ServiceAccount admission plugin.

A security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using ephemeral containers. The policy ensures pods running with a service account may only reference secrets specified in the service account's secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with ephemeral containers.

Gogoprotobuf CVE-2021-3121: An issue was discovered in GoGo Protobuf before 1.3.2. plugin/unmarshal/unmarshal.go lacks certain index validation, aka the "skippy peanut butter" issue.

New Features

See a list of Kubernetes new features.

Bug Fixes

Azure Arc onboarding prechecks were improved to handle transitory restricted network bandwidth. When setting up AKS hybrid, the Azure Arc agents are on-boarded so that the deployment is projected to the user subscription in Azure. During this process there are several pre-checks run by the Arc agents, if there are network issues these tests may fail. This fix makes the pre-checks more resilient to network problems.
See a list of Kubernetes bug fixes.

As always, you can try AKS on Azure Stack HCI or Windows Server any time even if you do not have the hardware handy using our eval guide to set up AKS on a Windows Server Azure VM.

Once you have downloaded and installed the AKS on Azure Stack HCI or Windows Server Update – you can report any issues you encounter, follow our plans, and check out recently released updates through the AKS hybrid roadmap in GitHub.

We look forward to hearing from you all!

Cheers,

AKS Hybrid Team

Announcing the General Availability of Remote Support for Azure Stack systems

eleanorcohen — Thu, 27 Jul 2023 20:57:54 GMT

Effortless customer support is an enduring reason that organizations adopt public cloud. With Azure Stack Hub, Azure Stack Edge, and Azure Stack HCI, we’re extending the Azure support experience to edge infrastructure. Support requests for Azure Stack systems have always been managed through the Azure Portal and covered under your Azure support plan. Today we’re taking the next big step: remote support for all Azure Stack systems is now generally available!

With remote support, you can temporarily grant Microsoft Support engineers constrained access to your on-premises edge devices to gather logs and fix issues. By default, remote support is off. It’s easy to turn on and off, when needed. After creating an Azure support request, it's recommended to grant remote support access to enable Microsoft Support to resolve the issue as soon as possible. This takes just a few minutes in only a few steps. Once the support request is closed, you can just as easily turn off remote support access.

Why use remote support?

Remote support for Azure Stack systems provides benefits to both customers and Microsoft Support:

Improved time to resolution: eliminate the back-and-forth hassle of scheduling a call and gathering logs yourself.
Safe and secure: you can grant just-in-time (JIT) authenticated access and define the access level and duration for each incident. You can revoke access anytime.
Audited troubleshooting: Microsoft Support can only run Just Enough Administration (JEA) approved commands and everything they do is recorded for you to audit.
Free: Remote support is included in your Azure subscription at no additional cost. You can get remote support for both unregistered and registered Azure Stack HCI systems.

Version availability:

For Azure Stack Hub, remote support is available for version 2108 and later.
For Azure Stack Edge, remote support is available for version 2110 and later.
For Azure Stack HCI, remote support is available for version 22H2 and later.

Documentation to learn more and get started:

AKS on Azure Stack HCI and Windows Server 2023-07-10 Update

waltero — Thu, 13 Jul 2023 20:28:11 GMT

We are pleased to announce that with this release we bring the AKS HCI management cluster to Kubernetes version 1.25.7. This update enables us to set the basis for supporting futures versions of Kubernetes for your workload clusters. Here is a complete list of security updates that are included:

Security Updates

CVE-2023-2728: Bypassing enforce mountable secrets policy imposed by the ServiceAccount admission plugin. This security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using ephemeral containers.

CVE-2023-27561 CVE-2023-25809 CVE-2023-28642: Bump fix runc v1.1.4 -> v1.1.5

Fixed cgroup removal error when using runc binary >= 1.1.6.

runc through 1.1.4 had incorrect Access Control leading to Escalation of Privileges, related to libcontainer/rootfs_linux.go. An attacker if able to spawn two containers with custom volume-mount configurations, would be able to run any custom images.

CVE-2022-3162: Unauthorized read of Custom Resources

A security issue was discovered in Kubernetes where users authorized to list or watch one type of namespaced custom resource cluster-wide can read custom resources of a different type in the same API group they are not authorized to read.

CVE-2022-3172: Aggregated API server can cause clients to be redirected (SSRF)

A security issue was discovered in kube-apiserver that could allow an attacker controlled aggregated API server to redirect client traffic to any URL. This could lead to the client performing unexpected actions as well as leaking the client's credentials to third parties.There is no mitigation from this issue. Cluster admins should take care to secure aggregated API servers and should not grant access to mutate APIServices to untrusted parties.

CVE-2021-3121: An issue was discovered in GoGo Protobuf before 1.3.2. plugin/unmarshal/ unmarshal.go lacks certain index validation. This would allow modification of some system files or information and could have reduced performance or interruption in resource availability.

CVE-2023-32681: Requests has been leaking Proxy-Authorization headers to destination servers when redirected to an HTTPS endpoint, allowing a malicious actor to potentially exfiltrate sensitive information.

CVE-2023-29491: allows local users to trigger security-relevant memory corruption via malformed data in a terminfo database file that is found in $HOME/.terminfo

This release includes a few important bug fixes:

It fixes a bug at kube-apiserver start where APIService objects for custom resources could be deleted and recreated.
If kubeadm reset finds no etcd member ID for the peer it removes during the remove-etcd-member phase, it continues immediately to other phases, instead of retrying the phase for up to 3 minutes before continuing.
Kubeadm: fixed a bug where the static pod changes detection logic is inconsistent with kubelet
Fixed incorrect calculation for ResourceQuota with PriorityClass as its scope.
Fixed: the volume is not detached after the pod and PVC objects are deleted
Fixed missing delete events on informer re-lists to ensure all delete events are correctly emitted and using the latest known object state, so that all event handlers and stores always reflect the actual apiserver state as best as possible
Fixed: Route controller should update routes with NodeIP changed
Fixed a regression in the pod binding subresource to honor the metadata.uid precondition. This allows kube-scheduler to ensure it is assigns node names to the same instances of pods it made scheduling decisions for.
Kubelet: Fixed fs quota monitoring on volumes
Fixed data race in kube-scheduler when preemption races with a Pod update
Fixed a bug that caused to panic the apiserver when trying to allocate a Service with a dynamic ClusterIP and it has been configured with Service CIDRs with a /28 mask for IPv4 and a /124 mask for IPv6
Fixed a regression that the scheduler always goes through all Filter plugins.
Optimizing loadbalancer creation with the help of attribute Internal Traffic Policy: Local
Updates golang.org/x/net to fix CVE-2022-41717
Kube-apiserver: resolved a regression that treated 304 Not Modified responses from aggregated API servers as internal errors

As always, you can try AKS on Azure Stack HCI or Windows Server any time even if you do not have the hardware handy using our eval guide to set up AKS on a Windows Server Azure VM.

We look forward to hearing from you all!

Cheers,

AKS Hybrid Team

Minimize download size for offline download in AKS hybrid

jessicaguan — Thu, 01 Jun 2023 16:52:20 GMT

In the October release of AKS hybrid, we released offline download, a feature that allows you to pre-download the AKS hybrid images needed for deployment. Offline download enables installing and upgrading at edge locations with unreliable internet connection and allows you to perform security scans on the images before deploying. In the latest release, we have added the option of a minimum or full mode for offline download.

Based on your feedback, we are introducing a minimum and full mode feature to give you the option of minimizing your download size. Minimum mode downloads only the required images, the required Linux images, and the required Kubernetes version needed for an AKS hybrid deployment. Full mode is the default download mode and downloads all the images, including the Windows images. Minimum mode is a great option for you if:

1. Your bandwidth can only accommodate a smaller download size

2. You do not require Windows images i.e. you are only running Linux workloads

3. You do not have a specific Kubernetes version requirement

Check out the table below to see some key differences between the two download modes available.

	Full mode	Minimum mode
Images	All images - Linux and Windows images, all Kubernetes versions	Only required images -Linux image, one Kubernetes version
Download size	20 - 30 GB	2 - 3 GB
Download time	~80 minutes	~20 minutes

*Note: The download time is based on measuring in a test environment with 120 MB download speed. Your time may vary based on available bandwidth and latency.

Onsite install example steps

The following example will walk you through offline download in minimum mode, assuming that the AKS hybrid prerequisites are satisfied.

1. Check every physical node to see if all the requirements to install are satisfied.

Initialize-AksHciNode

2. Set the configurations to use minimum mode for deployment.

Set-AksHciConfig -offlineDownload $true -mode minimum -stagingShare c:\akshciimages -imageDir c:\clusterstorage\volume1\Images -workingDir c:\ClusterStorage\Volume1\ImageStore -cloudConfigLocation c:\clusterstorage\volume1\Config -vnet $vnet -cloudservicecidr "172.16.10.10/16"

3. (Optional) Check that offline download is enabled and the local path is correct.

Get-AksHciConfig | ConvertTo-Json

4. Log into Azure and configure the registration settings.

Set-AksHciRegistration -subscriptionId <sub_id> -resourceGroupName <resourcegroup_name>

5. Start the deployment.

Install-AksHci

Offsite install example steps

1. Set the offsite configuration.

Set-AksHciOffsiteConfig -version <version> -stagingShare <staging_share>

2. Download the images in minimum mode.

Get-AksHciRelease -mode minimum

3. Transfer the images onsite to where you will deploy.

4. Set the configurations onsite.

Set-AksHciConfig -offlineDownload $true -offsiteTransferCompleted $true -stagingShare c:\akshciimages -imageDir c:\clusterstorage\volume1\Images -workingDir c:\ClusterStorage\Volume1\ImageStore -cloudConfigLocation c:\clusterstorage\volume1\Config -vnet $vnet -cloudservicecidr "172.16.10.10/16"

5. (Optional) Check that offline download is enabled and the local path is correct.

Get-AksHciConfig | ConvertTo-Json

6. Log into Azure and configure the registration settings.

Set-AksHciRegistration -subscriptionId <sub_id> -resourceGroupName <resourcegroup_name>

7. Start the deployment.

Install-AksHci

You can use minimum mode to upgrade. To learn more about how to use offline download, check out the documentation here. For onsite scenarios, use Set-AksHciConfig to set offline download and use minimum download mode. For offsite scenarios use Set-AksHciOffsiteConfig to set the offsite configuration for offline download and Get-AksHciRelease to pre-download the images in minimum mode.

Useful links:

Try for free: https://aka.ms/AKS-HCI-Evaluate

Tech Docs: https://aka.ms/AKS-HCI-Docs

Issues and Roadmap: https://github.com/azure/aks-hci

Evaluate on Azure: https://aka.ms/AKS-HCI-EvalOnAzure

SDN installation simplified: VHDX download is finally here, ISO troubles removed!

AnirbanPaul — Wed, 31 May 2023 19:37:23 GMT

Forget about having to download the Azure Stack HCI ISO file and having to convert it to VHDX to use for Software Defined Networking (SDN) deployment, you can now directly download the Azure Stack HCI VHDX file from the Azure Stack HCI software download site: Azure Stack HCI Registration | Microsoft Azure. Once you fill in your details and click on Submit, you will see an option to download the Azure Stack HCI software. In the “Choose language” dropdown menu, select “English – VHDX” and click on “Download Azure Stack HCI” to download the VHDX file.

For context, SDN in Azure Stack HCI uses a VHDX file containing the Azure Stack HCI operating system (OS) as a source for creating the SDN infrastructure virtual machines (VMs). The version of the OS in your VHDX should match the version used by the Azure Stack HCI Hyper-V hosts. This VHDX file is used by all SDN infrastructure components (Network Controller, Software Load Balancer and Gateways).

Official documentation for this change can be found here: Deploy SDN using Windows Admin Center - Azure Stack HCI | Microsoft Learn

Thanks

Anirban

Building the future of Azure Stack HCI

Derek_Bogardus — Tue, 30 May 2023 17:17:45 GMT

Introduction

Our customers want a simple way to bring the power of the cloud into their real-world operations to transform their businesses. At Microsoft, our goal is to give businesses the ability to project Azure to wherever they need it, whether it be the cloud, a data center, or an edge location like a retail store.

However, we know operating even modern hybrid cloud environments can be a complex undertaking. An array of disparate tools and technologies acquired over time and space often leaves customers to stitch it all together themselves. Our aim is to reduce that complexity with Azure-consistent infrastructure that simplifies the ability to take advantage of cloud-native technologies at the edge.

As part of this ambitious vision, we are evolving our flagship hyperconverged infrastructure offering, Azure Stack HCI, towards an increasingly cloud-native posture that leverages Azure Arc to meet the ever-changing needs of our customers. The result is a solution for businesses that simplifies operations, and allows our customers to use the same tools, app models, and control planes uniformly regardless of where their data and applications reside.

How Microsoft delivers a seamless cloud to edge solution with Azure Stack HCI

Unified and consistent operations across environments

Edge deployments are streamlined into a simplified turnkey experience driven centrally from the cloud, which minimizes the need for on-prem IT expertise.
Updates are one-click for the entire technology stack, closing the seams between hardware, firmware, drivers, OS, and agents. All updates are comprehensively validated for compatibility, interoperability, and reliability.
Support is at the solution level, providing a single point of contact experience for hardware, software, and cloud components.

Simplified application modernization

Applications are developed once and deployed and managed equally across environments.
Azure Arc-enabled Azure features and services such as Azure Kubernetes Services, Azure Virtual Desktop, Azure Arc-enabled data services, and Azure Arc-enabled VM Management easily extend from the cloud to the edge.

Centralized governance

On-premises resources are easily accessed, managed, and governed centrally through the Azure Portal.
Infrastructure is continuously monitored to ensure it stays in a validated state.
Azure’s policy management, threat protection, and security controls extend to on-premises infrastructure.

Announcing Dell APEX Cloud Platform for Microsoft Azure

To simplify the inherent complexity of cloud to edge, the unique breadth and depth of our partners extends Microsoft’s cloud services and software into customers’ environments around the world. With one of our key partners, we recently announced the Dell APEX Cloud Platform for Microsoft Azure, the first Azure Stack HCI solution of its kind, delivering integration and capabilities beyond the Validated Nodes and Integrated Systems in the Azure Stack HCI portfolio today.

Dell APEX Cloud Platform for Azure is the result of extensive engineering collaboration between Microsoft and Dell. It natively integrates with Azure Arc and Azure Stack HCI to provide a turnkey experience to customers, including simplified deployment, seamless management, and orchestration capabilities for hyperconverged infrastructure deployments. Building on Dell’s track record of delivering market-leading integrated infrastructure solutions with extensive software-driven management and orchestration (M&O) automation, this comprehensive solution enables IT admins and operators to focus less on managing the day-to-day operational tasks and more on innovation and achieving desired business outcomes. This integration gives customers a consistent operational model to run their application and data services across datacenter and edge and manage on-premises resources from the Azure portal with consistent security and governance.

Conclusion

We are excited for what’s to come with Azure Stack HCI as we keep building and transforming with our customers. To learn more about Azure Stack HCI, visit our page on Microsoft Learn.

For more information on Dell APEX Cloud Platform for Microsoft Azure, please visit Dell’s solution brief.

Announcing the Public Preview of Azure Site Recovery with Azure Stack HCI

Shijo_Joy — Wed, 17 May 2023 22:04:13 GMT

In October 2021 we announced the support of Azure Site Recovery to protect virtual machines (VM) workloads on Azure Stack HCI. Based on customer feedback, we have improved the ASR agent deployment experience and now we are excited to announce the Public Preview of the new ASR agent deployment experience as an Arc extension.

What is Azure Site Recovery (ASR)?

ASR is an Azure service that helps ensure business continuity by keeping business apps and workloads running during outages. ASR replicates workloads running on physical and virtual machines from a primary site to a secondary location. When an outage occurs at your primary site, you fail over to a secondary location, and access apps from there. After the primary location is running again, you can fail back to it.

In case of an outage, you can failover your VM workloads from Azure Stack HCI to Azure and access your VMs on Azure. Once your Azure Stack HCI cluster is running again, you can failback the VM workloads to your Azure Stack HCI cluster.

What's new in Public Preview?

The ASR agent is now packaged as an Arc extension. From the Azure portal, you can deploy the ASR agent to the nodes of your Azure Stack HCI cluster as an Arc extension. If a node is added at a later point in time, the ASR agent will be automatically deployed to the newly added node, by virtue of it being an Arc extension. This reduces the overhead of needing to install the agent manually on every cluster node and simplifies the steps to prepare the infrastructure prior to protecting your VM workloads. Once the extension is installed, you can leverage the existing ASR flow to protect, failover and failback VMs.

There are a few prerequisites to deploy the ASR agent as an Arc extension to the nodes of your Azure Stack HCI cluster:

Azure Stack HCI cluster should be registered with Azure and Arc-enabled. If you registered your cluster on or after June 15, 2021, this happens by default. Otherwise, you'll need to enable Azure Arc integration.
The cluster must have Azure Stack HCI version 22H2 and the May 2023 cumulative update or later installed.
Enable managed identity on your Azure Stack HCI resource.

We've added a new "disaster recovery" item within the Azure Stack HCI resource on the Azure portal.

Selecting "Protect VM workloads" will take you to a two-card layout where you can select "Prepare infrastructure".

You can configure the vault, site and replication policy, right within the Azure Stack HCI resource without navigating elsewhere within the Azure portal. The agents will then get deployed to the nodes of the HCI cluster as an Arc extension. Try it out for yourself!

If you have any feedback, send it to asr_hci@microsoft.com.

Learn more about how you can use Azure Site Recovery to protect your VM workloads on Azure Stack HCI

Announcing the General Availability of Azure Monitor HCI Insights

saniya0307 — Tue, 16 May 2023 17:27:01 GMT

Introduction

Earlier in May 2022, we launched Azure Monitor HCI Insights for public preview. Based on customer feedback during the preview, we improved the performance of the workbooks and supported the new Azure Monitor Agent and are excited to announce General Availability (GA) of Azure Monitor HCI Insights.

What is HCI Insights?

Azure Stack HCI Insights is an interactive, fully integrated service which provides health, performance, and usage insights about Azure Stack HCI clusters that are connected to Azure and are enrolled in Azure Monitor. In Microsoft Azure, you can see all your resources in Azure portal and monitor them with Azure Stack HCI Insights.

There are some key benefits of using Azure Stack HCI Insights:

It’s managed by Azure and accessed from Azure portal, so it's always up to date, and there's no database or special software setup required.
Azure Monitor Agent uses managed identity to interact with Log analytics workspace which ensures secure communication. 
It's highly scalable, which means it is capable of loading more than 250 cluster information sets across multiple subscriptions at a time, with no boundary limitations on cluster, domain, or physical location.
It's highly customizable. The user experience is built on top of Azure Monitor workbook templates, where you can easily add/remove/edit visualizations and queries.
HCI Insights follows Pay-as-you-go model which means you pay only for the logs that are collected and they can be removed/edited as per user need.

What's new in GA?

The new, enhanced Azure Monitor HCI Insights uses the new improved Azure Monitor Agent and Data Collection Rule. These rules specify the event logs and performance counters that need to be collected and stores it in a Log Analytics workspace. Once the logs are collected, HCI Insights uses Azure Monitor Workbooks to provide deeper insights on the health, performance and usage of the cluster.

There are a few prerequisites for using Azure Stack HCI Insights:

Azure Stack HCI cluster should be registered with Azure and Arc-enabled. If you registered your cluster on or after June 15, 2021, this happens by default. Otherwise, you'll need to enable Azure Arc integration.
The cluster must have Azure Stack HCI version 22H2 and the May 2023 cumulative update or later installed.
Enable the managed identity for the Azure resource. For more information, see Enabled enhanced management.

Below is a screenshot of the Azure workbook displayed for multiple clusters.

You can click on the cluster name, and it will redirect you to the single cluster workbook template with a drill down view and more details as shown below:

Pre-defined workbook templates exist with default views to give you a head-start. You can switch between different tabs like Health, Servers, Virtual machines, and Storage. Each tab provides data and metrics about the cluster which is carefully designed keeping your needs in mind. Health data such as faults and resource status, performance data like IOPS and throughput, and usage data like CPU usage and memory usage are collected. Moreover, the rich visualizations make it easier to decipher the data and give a quick glance of useful insights. 

Additional data can be easily collected in the form of event logs or performance counters, and you can add it to the Data collection rule that was created while enabling monitoring for the cluster.   Once the data starts flowing, the user can use Azure workbooks to visualize the collected data. A workbook provides a set of visualizations like charts, graphs, grids, honeycomb, composite bar, maps etc. and it is very convenient to modify and alter. It allows you to pin the graphs to Azure dashboards which gives a holistic view of resource health, performance, and usage. It is also very easy to share the data by downloading this information in Excel and deriving useful insights. 

Customers also use logs and Insights workbook templates to create alerts. Some of the common alerts created by customers are if cluster node is down, and if CPU or memory usage exceeds set threshold. You can set up alerts for multiple clusters and integrate 3rd party solutions like PagerDuty to get notified. This will make sure that you take timely action and resources are healthy and performant.

Here is a video with more details.

Future plans 

This is just the beginning of Monitoring Insights for Azure Stack HCI. We plan to build additional workbook templates for new HCI features and essential monitoring capabilities. If you have feedback, please send it to  hcimonitoring@microsoft.com! 

For more detailed information, please visit our documentation for Single Cluster Insights and Multiple Cluster Insights .