rss.livelink.threads-in-node

The Microsoft Azure Infra Summit 2026 Schedule Is Live.

Pierre_Roman — Thu, 23 Apr 2026 19:08:05 GMT

Hello Folks,

I promised the full agenda would drop soon. Today’s the day. The schedule is locked in, the approved sessions are on the board, and I want to walk you through what three days of deep-technical, engineering-led Azure content looks like.

A quick refresher before we get into the content: this event is free, it’s virtual, and it’s built by engineering for engineering. Most sessions are at the L300–L400 level, which means we’re skipping the marketing slide and getting straight to the architecture, the gotchas, and the “here’s what actually happens in production” stories you came for.

We’re starting at 8:00 AM Pacific each day and running solid technical content through the afternoon. You can still register here (https://aka.ms/MAIS-reg)

We organized the three days around the pillars our community keeps coming back to, Build, Operate, and Optimize. Day 1 leans into Build so you leave the keynote with momentum, Day 2 bridges Build into Operate (where most of us actually spend our workdays), and Day 3 is pure Optimize, resiliency, cost, performance, and networking, before we close things out.

The full 3-day agenda (all times Pacific) Online Schedule Here

Day 1, Tue, May 19 · BUILD	Day 2, Wed, May 20 · BUILD + OPERATE	Day 3, Thu, May 21 · OPTIMIZE + Closing
8:00 KEYNOTE: Welcome & Azure Infrastructure Vision	8:00, Build and Optimize a Data Lakehouse for Unified Data Intelligence	8:00, Achieving Zonal Resiliency in Azure Infrastructure
9:00, Build a Sovereign Private Cloud with Azure Local	8:45, Designing Azure Networks That Scale: From Small Deployments to Enterprise-Grade	8:30, Architecting Resilient Azure Platforms: Durable Functions, Cosmos DB, and DR by Design
9:45, The Azure Deployment Agent: How AI Turns a Prompt into a Production-Ready Workload	9:30, From Alert to Resolved: Building a Self-Healing Azure Platform with SRE Agent	9:00, Optimizing EDA & HPC Pipelines on Azure: High-Performance Shared Storage with Azure NetApp Files
10:15, ALZ IaC Accelerator: Deploy Your Azure Platform Landing Zone with IaC	10:15, Agentic Migrations & Modernization	9:30, Elastic SAN for AVS Datastores: Best Price-Performance External Storage
11:00, Building Secure, Well-Architected Azure Workloads by Default with Azure Verified Modules and GitHub Copilot	10:45, Simplifying File Share Management and Control for Azure Files	10:00, Premium SSD v2 Disk: Best Price-Performance Block Storage for VMs and Containers
11:45, Best Practices for Infrastructure as Code CI/CD on Azure	11:30, Marketplace Image Protection: Safeguarding Workloads Through Patching and Graceful Deprecation	10:45, Optimizing File Storage for AI and Cloud-Native Workloads on Azure
12:30, Modern Ingress for AKS: Introducing Application Gateway for Containers (AGC)	12:00, Operating Hybrid at Scale: Real-World Azure Arc Patterns for Governance, Security, and Cost Control	11:30, Cut Storage Costs, Boost ROI: Optimizing Your Storage TCO on Azure Object Storage
13:15, End-to-End Security on AKS Using Azure Application Gateway for Containers with Managed Cilium	12:45, Run At-Scale On-Premises and Cloud Assessments and Migrations to Azure Storage	12:15, How to Build Resilient Networks Using Azure Networking, What’s New in Azure Software Load Balancing
14:00, Deployment Stacks: Getting Started	13:30, Modernize VDI with Azure Files and Entra Cloud-Native Identities	13:00, AKS Networking at Scale, CNI, Security, and Multi-Cluster Networking with Accelerated Performance
14:30, Accelerating Automated VM Image Pipelines with Azure Image Builder and Azure Compute Gallery	14:15, Operating Azure Backup at Scale: Day-2 Excellence for IaaS, PaaS, and Storage Workloads	13:45, Kubenet Deprecation, Futureproofing AKS IPAM and Dataplane Configurations
	15:00, Troubleshooting Kubernetes Networking with an AI Diagnostic Assistant	14:15, Implement Zero-Tolerance Downtime Web Apps with Azure Front Door
		14:45, Closing: Azure Infrastructure Applied Skills and Certifications

What to do right now

Block your calendar, May 19, 20, and 21, 8:00 AM PT start each day. Check out www.azureinfrasummit.com for more information.
Register, it’s free.
Pick your sessions, the online schedule has ICS files for each session. Build your personal track across Build, Operate, and Optimize.
Bring your team, the agenda is deliberately wide: platform engineers, SREs, storage folks, network folks, AKS operators, IaC builders, and backup/DR owners will all find their sessions.

We put a lot of work into making sure every slot earned its place, these are engineering-delivered, production-grounded, no-fluff sessions. The speakers are the people shipping the features you’re using in Azure.

Can’t wait to see you online May 19–21.

Until then,

Cheers!

Pierre Roman

Internet Information Services Learning Path

OrinThomas — Tue, 14 Apr 2026 21:08:36 GMT

Internet Information Services (IIS) is the modular web server and application platform that first shipped as an optional add-on for Windows NT 3.51 in 1995, evolving from basic HTTP and FTP services into a full-featured web stack tightly integrated with Windows Server and Client operating systems. Today, IIS remains a core component of Windows Server and client editions, used to host legacy and modern web applications, APIs, and services in on-premises and hybrid environments alongside newer cloud-native options.

The following training modules on Microsoft Learn provide you with a structured curriculum to learn how to manage and maintain Internet Information Services. It's relevant to almost all supported versions of IIS, but also includes coverage of some functionality that is available with Windows Server 2025.

The modules in this learning path are as follows:

Deploy and configure Internet Information Services. Understand how to configure, administer, and validate an IIS installation on Windows Server.
Configure Internet Information Services websites and applications. Create and configure websites, web applications, and virtual directories in IIS.
Manage Internet Information Services. Scripting bulk configuration changes, watching worker processes for signs of trouble, or run health checks to keep your IIS environment running reliably.
Secure and harden Internet Information Services. Authentication, authorization, and other security best practices to protect the server and websites.
Troubleshoot and optimize IIS performance. Learn how to troubleshoot IIS problems with logs, tracing, and performance counters, then apply tuning changes to improve reliability and throughput.

The Administer Internet Information Services learning path collects all these modules together, providing you with a comprehensive guide to managing and maintaining Internet Information Services.

Join us at Microsoft Azure Infra Summit 2026 for deep technical Azure infrastructure content

Pierre_Roman — Thu, 09 Apr 2026 19:02:44 GMT

Microsoft Azure Infra Summit 2026 is a free, engineering-led virtual event created for IT professionals, platform engineers, SREs, and infrastructure teams who want to go deeper on how Azure really works in production. It will take place May 19-21, 2026. This event is built for the people responsible for keeping systems running, making sound architecture decisions, and dealing with the operational realities that show up long after deployment day.

Over the past year, one message has come through clearly from the community: infrastructure and operations audiences want more in-depth technical content. They want fewer surface-level overviews and more practical guidance from the engineers and experts who build, run, and support these systems every day. That is exactly what Azure Infra Summit aims to deliver.

All content is created AND delivered by engineering, targeting folks working with Azure infrastructure and operating production environments.

Who is this for: IT professionals, platform engineers, SREs, and infrastructure teams
When: May 19-21, 2026 - 8:00 AM–1:00 PM Pacific Time, all 3 days
Where: Online Virtual
Cost: Free
Level: Most sessions are advanced (L300-400).
Register here: https://aka.ms/MAIS-Reg

Built for the people who run workloads on Azure

Azure Infra Summit is for the people who do more than deploy to Azure. It is for the people who run it. If your day involves uptime, patching, governance, monitoring, reliability, networking, identity, storage, or hybrid infrastructure, this event is for you. Whether you are an IT professional managing enterprise environments, a platform engineer designing landing zones, an Azure administrator, an architect, or an SRE responsible for resilience and operational excellence, you will find content built with your needs in mind.

We are intentionally shaping this event around peer-to-peer technical learning. That means engineering-led sessions, practical examples, and candid discussion about architecture, failure modes, operational tradeoffs, and what breaks in production. The promise here is straightforward: less fluff, more infrastructure.

What to expect

Azure Infra Summit will feature deep technical content in the 300 to 400 level range, with sessions designed by engineering to help you build, operate, and optimize Azure infrastructure more effectively. The event will include a mix of live and pre-recorded sessions and live Q&A.

Throughout the three days, we will dig into topics such as:

Hybrid operations and management
Networking at scale
Storage, backup, and disaster recovery
Observability, SLOs, and day-2 operations
Confidential compute
Architecture, automation, governance, and optimization in Azure Core environments
And more…

The goal is simple: to give you practical guidance you can take back to your environment and apply right away. We want attendees to leave with stronger mental models, a better understanding of how Azure behaves in the real world, and clearer patterns for designing and operating infrastructure with confidence.

Why this event matters

Infrastructure decisions have a long tail. The choices we make around architecture, operations, governance, and resilience show up later in the form of performance issues, outages, cost, complexity, and recovery challenges. That is why deep technical learning matters, and why events like this matter.

Join us

I hope you will join us for Microsoft Azure Infra Summit 2026, happening May 19-21, 2026.

If you care about how Azure infrastructure behaves in the real world, and you want practical, engineering-led guidance on how to build, operate, and optimize it, this event was built for you.

Register here: https://aka.ms/MAIS-Reg

Cheers!

Pierre Roman

Overview of Azure Workload Modernization

OrinThomas — Mon, 16 Mar 2026 00:44:27 GMT

Azure workload modernization generally means shifting from traditional deployment options, such as running a workload within a VM, to more cloud native components, such as functions, PaaS services, and other cloud architecture components.

Shift from VMs to PaaS and Cloud-Native Services: By replatforming to services like Azure App Service for web apps, managed databases (e.g. Azure SQL Database), or container platforms (e.g. Azure Kubernetes Service (AKS)), you offload infrastructure management to Azure. Azure handles patches, scaling, and high availability, so your team can focus on code and features. (Learn more: https://learn.microsoft.com/azure/app-modernization-guidance/plan/plan-an-application-modernization-strategy#iaas-vs-paas)
Immediately Leverage Azure’s Built-in Capabilities: You can light up Azure’s ecosystem features for security, compliance, monitoring, and more. For example, without changing any code you can enable Azure Monitor for telemetry and alerting, use Azure’s compliance certifications to meet regulatory needs, and turn on governance controls. Modernizing a workload is about unlocking things like auto-scaling, backup/DR, and patch management that will be handled for you as platform features. (See: https://learn.microsoft.com/azure/well-architected/framework/platform-automation)
Treat Modernization as a Continuous Journey. Modernizing isn’t a single “big bang” rewrite, it’s an ongoing process. Once on Azure, plan to iteratively improve your applications as new services and best practices emerge. Implement DevOps pipelines (CI/CD) to regularly deliver updates and refactor parts of the system over time. This allows you to adopt new Azure capabilities (such as improved instance types, updated frameworks, or new managed services) with minimal disruption. By continually integrating improvements – from code enhancements to architecture changes – you ensure your workloads keep getting more efficient, secure, and scalable. (See: https://learn.microsoft.com/azure/app-modernization-guidance/get-started/application-modernization-life-cycle – continuous improvement approach)
Use Containers and Event-Driven Architectures to Evolve Legacy Apps: Breaking apart large, tightly-coupled applications into smaller components can drastically improve agility and resilience. Containerize parts of your app and deploy them to a managed orchestrator like Azure Kubernetes Service (AKS) for better scalability and fault isolation. In an AKS cluster, each microservice or module runs independently, so you can update or scale one component without impacting the whole system. In addition, consider introducing serverless functions (via Azure Functions) or event-driven services for specific tasks and background jobs. These approaches enable on-demand scaling and cost efficiency – Azure only runs your code when triggered by events or requests. Adopting microservices and serverless architectures helps your application become more modular, easier to maintain, and automatically scalable to meet demand. (Learn more: https://learn.microsoft.com/azure/architecture/guide/architecture-styles/microservices and https://learn.microsoft.com/azure/azure-functions/functions-overview)
Modernize Security and Identity: Update your application’s security posture to align with cloud best practices. Integrate your apps with Microsoft Entra ID for modern authentication and single sign-on, rather than custom or legacy auth methods. This provides immediate enhancements like multi-factor authentication, token-based access, and easier user management across cloud services. Additionally, take advantage of Azure’s global networking and security services, for example, use Azure Front Door to improve performance for users worldwide and add a built-in Web Application Firewall to protect against DDoS and web attacks. By using cloud-native security services (such as Azure Key Vault to manage app secrets and certificates, or Microsoft Defender for Cloud for threat protection), you can significantly strengthen your workload’s security while reducing the operational burden on your team. (See: https://learn.microsoft.com/entra/identity/intro and https://learn.microsoft.com/azure/frontdoor/front-door-overview)

Azure Migration Challenges (and how to resolve them)

OrinThomas — Thu, 05 Mar 2026 06:28:52 GMT

Moving workloads to Azure is rarely plug-and-play. Here are some workarounds for challenges organizations encounter when planning and executing migrations.

Server Migration

Legacy OS & Software Compatibility
- Old, out-of-support operating systems may not run in Azure or may perform poorly.
- Tightly coupled apps tied to specific hardware or OS versions are hard to replicate.
Fix: Run compatibility assessments early. Upgrade or patch the OS before migrating, or refactor the workload to run on a supported OS.

Performance Sizing
- On-prem VMs may rely on fast local SSDs or low-latency network links you won't get by default in Azure.
- Undersizing means poor performance; oversizing means wasted spend.
Fix: Use Azure Migrate's performance-based recommendations to right-size your VMs.

Network & Identity Integration
- Migrated servers still need to communicate with on-prem resources and authenticate users.
- Splitting app servers and auth servers across environments breaks things fast.
Fix: Design network topology & identity infrastructure before you move anything. Move workloads that have interdependencies together.

Governance & Cloud Sprawl
- On-prem controls (naming conventions, equipment tags) don't automatically follow you to the cloud.
- Spinning up resources with a click leads to sprawl.
Fix: Set up Azure Policy from day one. Enforce tagging, naming, and compliance rules as part of the migration project—not after.

Skills Gaps
- On-prem server experts aren't automatically fluent in Azure operations.
Fix: Invest in cloud operations training before and during the migration.

Database Migration

Compatibility
- Not every database engine or version maps cleanly to an Azure equivalent.
Fix: Run the Azure Data Migration Assistant early to verify feature and functionality support.

Post-Migration Performance
- Performance depends on the hosting ecosystem; what worked on-prem may not translate directly.
Fix: Revisit indexing and configuration after migration. Use SQL Intelligent Insights and Performance Recommendations for tuning guidance.

Choosing the Right Service Tier
- Azure offers elastic pools, managed instances, Hyperscale, and sharding—picking wrong may be costly.
Fix: Profile your workload with your DBA and use Azure Migrate's Database Assessment for sizing suggestions.

Security Configuration
- User logins, roles, and encryption settings must migrate with the data.
Fix: Map every layer of your on-prem security configuration and implement corresponding controls post-migration.

Data Integrity
- Data types, constraints, and triggers must come over intact with zero loss or corruption.
Fix: Use reliable migration tools, test multiple times, and validate row counts and key constraints. Plan cutover during low-usage windows and always have a rollback plan.

Application Migration

Legacy App Complexity
- Custom and legacy apps carry years of accumulated config files, hard-coded paths, IP addresses, and environment-specific logging.
- Each app can feel like its own mini migration project.
Fix: Use Azure Migrate's app dependency analysis to map what each app needs before you touch it.

Dependency Conflicts
- Apps may depend on specific framework versions, libraries, or OS features that aren't available or supported in Azure.
Fix: Identify and resolve dependency gaps early. Consider containerizing or refactoring apps to isolate them from environment differences.

Scale of Effort
- Dozens or hundreds of apps, each with unique characteristics, create a massive manual workload.
Fix: Automate everything you can. Use porting assistants and batch migration tooling to reduce repetitive tasks.

Key Takeaway

Start assessments early, automate aggressively, set up governance from day one, and train your team before the move—not after. The most likely cause of a migration failure comes from skipping the prep work.

Managed Instance on Azure App Service: What IT/Ops Teams Need to Know

ViniciusApolinario — Mon, 09 Mar 2026 18:15:29 GMT

Azure App Service has long been one of the most reliable ways to run web apps on Azure, giving teams a fully managed platform with built‑in scaling, deployment integration, and enterprise‑grade security. But for organizations that need more control, expanded flexibility, or the ability to run apps that have additional dependencies, the new Managed Instance on Azure App Service (preview) brings a powerful new option.

Vinicius Apolinario recently sat down with Andrew Westgarth, Product Manager for Azure App Service to talk through what Managed Instances are, why they matter, and how IT/Ops teams can take advantage of the new capabilities.

What Managed Instances Bring to the Table

Managed Instances (MI) deliver the App Service experience you know with added flexibility for additional scenarios. You get the same PaaS benefits—patching, scaling, deployment workflows—but with the control typically associated with IaaS.

Some of the highlights we discussed:

App Service and Managed Instance on Azure App Service — What are the main differences and what scenarios MI is focusing on.
Consistent App Service experience — Same deployment model, same runtime options, same operational model.
App service experience for different audiences — How IT/Ops teams can leverage MI and what does it mean for development teams.

Features IT/Ops Teams Will Appreciate

Beyond the core architecture, MI introduces capabilities that make day‑to‑day operations easier:

Configuration (Install) Script — A new way to customize the underlying environment with scripts that run during provisioning. This is especially useful for installing dependencies, configuring app and OS settings, installing fonts, or preparing the environment for the workload.
RDP Access for Troubleshooting — A long‑requested feature that gives operators a secure way to RDP into the instance for deep troubleshooting. Perfect for diagnosing issues that require OS‑level visibility.

Learn more about Managed Instance on Azure App Service (preview):

Documentation: https://aka.ms/AppService/ManagedInstance
Hands On Lab: https://aka.ms/managedinstanceonappservicelab
Blog: https://aka.ms/managedinstanceonappservice
Ignite session: https://ignite.microsoft.com/en-US/sessions/BRK102

Foundry Local Web UI for IIS

OrinThomas — Sun, 01 Mar 2026 20:32:31 GMT

If you've been exploring local AI with Microsoft Foundry Local, you've learned that running a chatbot frontend on Windows Server or Windows Client that you can access over the network comes with a challenging set of dependencies.

FoundryLocalWebUI is a simple, self-contained web frontend for Foundry Local that runs on IIS, works on both Windows Server and Windows Client, and uses common Windows ecosystem components.

You can find the project on GitHub: https://github.com/itopstalk/FoundryWebUI

Here is an explanatory video here: https://youtu.be/IGWNhSQziZI

FoundryLocalWebUI is a lightweight web application designed to be hosted on IIS, which is already available to Windows Server and can be enabled on Windows Client with a few clicks. There is no need to install a separate web server, worry about a package manager, or spin up a Windows Subsystem for Linux environment.

FoundryLocalWebUI is an experimental proof of concept. It doesn't support multiple users and just provides basic chatbot functionality. It's suitable if:

You're evaluating Foundry Local and want a quick, no-fuss frontend to test models through a browser rather than the command line.
You want to keep your deployment footprint small and your dependencies minimal.
You're running Windows Client and want a local chat interface without the overhead of heavier solutions.

The setup process is intentionally straightforward.

Make sure that Git is installed:

winget install --id Git.Git -e --accept-source-agreements --accept-package-agreements

Clone the repo and run the installer (you'll have to use set-executionpolicy to allow the PowerShell script to run)

cd C:\Projects 
git clone https://github.com/itopstalk/FoundryWebUI.git FoundryLocalWebUI 
cd FoundryLocalWebUI 

# Windows Server 2025: 
.\Install-FoundryWebUI.ps1 

# Windows 10/11: 
.\Install-FoundryWebUI-Desktop.ps1

Full setup details are in the GitHub repo, and the walkthrough video covers the process end to end if you'd rather follow along visually.

This is still early days for the project, and I'd love to hear from the community. Local AI is becoming a real option for organizations that need to keep data on-premises and maintain control over their infrastructure.

Spin up a WS 2025 eval edition VM and give it a go.

Migration, Modernization & Agentic Tools

OrinThomas — Wed, 25 Feb 2026 22:21:32 GMT

This video covers Migration, Modernization, and Agentic tools. Agentic tools introduce autonomy, continuous optimization, and context‑aware decision‑making into the migration lifecycle. Instead of treating migration as a one‑time lift‑and‑shift, they operate as ongoing systems that:

Discover and map environments dynamically
Recommend modernization paths based on real telemetry
Automate execution steps end‑to‑end
Continuously validate, optimize, and remediate after landing in Azure

This shifts migration from a project to a self‑improving system.

This video provides an overview of new tools in Azure Copilot and GitHub Copilot that you can use when migrating and modernizing. These tools provide the following benefits:

Agents can classify workloads into migrate/modernize/rebuild patterns based on performance, code structure, and operational signals.
Agents can execute migration waves automatically—copying data, validating cutovers, sequencing dependencies, and rolling back if needed.
Agentic tools can continuously tune cost, performance, resiliency, and security posture using telemetry and policy-driven actions.
Agentic tools can ensure governance is embedded into the migration engine—ensuring workloads land compliant, secure, and aligned with enterprise standards.
Autonomous discovery and automated execution remove weeks of manual effort.
Parallelized migration waves become safe because the system understands dependencies.
Automated validation reduces human error during cutover.
Refactoring recommendations are grounded in code and performance analysis.
Agentic tools keep optimizing cost, security, and resilience—closing the loop between migration and operations.

Automating Large‑Scale Data Management with Azure Storage Actions

1Nataraj — Wed, 25 Feb 2026 20:41:33 GMT

Azure Storage customers increasingly operate at massive scale, with millions or even billions of items distributed across multiple storage accounts. As the scale of the data increases, managing the data introduces a different set of challenges.

In a recent episode of Azure Storage Talk, I sat down with Shashank, a Product Manager on the Azure Storage Actions team, to discuss how Azure Storage Actions helps customers automate common data management tasks without writing custom code or managing infrastructure.

This post summarizes the key concepts, scenarios, and learnings from that conversation. Listen to the full conversation below.

The Problem: Data Management at Scale Is Hard

As storage estates grow, customers often need to:

Apply retention or immutability policies for compliance
Protect sensitive or important data from modification
Optimize storage costs by tiering infrequently accessed data
Add or clean up metadata (blob index tags) for discovery and downstream processing

Today, many customers handle these needs by writing custom scripts or maintaining internal tooling. This approach requires significant engineering effort, ongoing maintenance, careful credential handling, and extensive testing, especially when operating across millions of item across multiple storage accounts.

These challenges become more pronounced as data estates sprawl across regions and subscriptions.

What Is Azure Storage Actions?

Azure Storage Actions is a fully managed, serverless automation platform designed to perform routine data management operations at scale for:

Azure Blob Storage
Azure Data Lake Storage

It allows customers to define condition-based logic and apply native storage operations such as tagging, tiering, deletion, or immutability, across large datasets without deploying or managing servers. Azure Storage Actions is built around two main concepts:

Storage Tasks

A storage task is an Azure Resource Manager (ARM) resource that defines:

The conditions used to evaluate blobs (for example, file name, size, timestamps, or index tags)
The actions to take when conditions are met (such as changing tiers, adding immutability, or modifying tags)

The task definition is created once and centrally managed.

Task Assignments

A task assignment applies a storage task to one or more storage accounts. This allows the same logic to be reused without redefining it for each account.

Each assignment can:

Run once (for cleanup or one-off processing)
Run on a recurring schedule
Be scoped using container filters or excluded prefixes

Walkthrough Scenario: Compliance and Cost Optimization

During the episode, Shashank demonstrated a real-world scenario involving a storage account used by a legal team.

The Goal

Identify PDF files tagged as important
Apply a time-based immutability policy to prevent tampering
Move those files from the Hot tier to the Archive tier to reduce storage costs
Add a new tag indicating the data is protected
Move all other blobs to the Cool tier for cost efficiency

The Traditional Approach

Without Storage Actions, this would typically require:

Writing scripts to iterate through blobs
Handling credentials and permissions
Testing logic on sample data
Scaling execution safely across large datasets
Maintaining and rerunning the scripts over time

Using Azure Storage Actions

With Storage Actions, the administrator:

Defines conditions based on file extension and index tags
Chains multiple actions (immutability, tiering, tagging)
Uses a built-in preview capability to validate which blobs match the conditions
Executes the task without provisioning infrastructure

The entire workflow is authored declaratively in the Azure portal and executed by the platform.

Visibility, Monitoring, and Auditability

Azure Storage Actions provides built-in observability:

Preview conditions allow customers to validate logic against a subset of blobs before execution
Azure Monitor metrics track task runs, targeted objects, and successful operations
Execution reports are generated as CSV files for each run, detailing:
- Blobs processed
- Actions performed
- Execution status for audit purposes

This makes Storage Actions suitable for scenarios where traceability and review are important.

Common Customer Use Cases

Shashank shared several examples of how customers are using Azure Storage Actions today:

Financial services: Applying immutability and retention policies to call recordings for compliance
Airlines: Cost optimization by tiering or cleaning up blobs based on creation time or size
Manufacturing: One-time processing to reset or remove blob index tags on IoT-generated data

These scenarios range from recurring automation to one-off operational tasks.

Getting Started and Sharing Feedback

Azure Storage Actions is available in over 40 public Azure regions.

To learn more, check out:

Azure Storage Actions product page: https://azure.microsoft.com/en-us/products/storage-actions
Azure Storage Actions public documentation: https://learn.microsoft.com/en-us/azure/storage-actions/storage-tasks/storage-task-quickstart-portal
Azure Storage Actions pricing page: https://azure.microsoft.com/en-us/pricing/details/storage-actions/

For questions or feedback, the team can be reached at: storageactions@microsoft.com

JSON Web Token (JWT) Validation in Azure Application Gateway: Secure Your APIs at the Gate

Pierre_Roman — Fri, 19 Dec 2025 03:03:06 GMT

Hello Folks!

In a Zero Trust world, identity becomes the control plane and tokens become the gatekeepers.

Recently, in an E2E conversation with my colleague Vyshnavi Namani, we dug into a topic every ITPro supporting modern apps should understand: JSON Web Token (JWT) validation, specifically using Azure Application Gateway.

In this post we’ll distill that conversation into a technical guide for infrastructure pros who want to secure APIs and backend workloads without rewriting applications.

Why IT Pros Should Care About JWT Validation

JSON Web Token (JWT) is an open standard token format (RFC 7519) used to represent claims or identity information between two parties.

JWTs are issued by an identity provider (Microsoft Entra ID) and attached to API requests in an HTTP Authorization: Bearer <token> header. They are tamper-evident and include a digital signature, so they can be validated cryptographically.

JWT validation in Azure Application Gateway means the gateway will check every incoming HTTPS request for a valid JWT before it forwards the traffic to your backend service.

Think of it like a bouncer or security guard at the club entrance: if the client doesn’t present a valid “ID” (token), they don’t get in. This first-hop authentication happens at the gateway itself. No extra custom auth code is needed in your APIs. The gateway uses Microsoft Entra ID (Azure AD) as the authority to verify the token’s signature and claims (issuer/tenant, audience, expiry, etc.).

By performing token checks at the edge, Application Gateway ensures that only authenticated requests reach your application. If the JWT is missing or invalid, the gateway could deny the request depending on your configuration (e.g. returns HTTP 401 Unauthorized) without disturbing your backend. If the JWT is valid, the gateway can even inject an identity header (x-msft-entra-identity) with the user’s tenant and object ID before passing the call along⁹. This offloads authentication from your app and provides a consistent security gate in front of all your APIs.

Key benefits of JWT validation at the gateway:

Stronger security at the edge: The gateway checks each token’s signature and key claims, blocking bad tokens before they reach your app.
No backend work needed: Since the gateway handles JWT validation, your services don’t need token‑parsing code. Therefore, there is less maintenance and lower CPU use.
Stateless and scalable: Every request brings its own token, so there’s no session management. Any gateway instance can validate tokens independently, and Azure handles key rotation for you.
Simplified compliance: Centralized JWT policies make it easier to prove only authorized traffic gets through, without each app team building their own checks.
Defense in depth: Combine JWT validation with WAF rules to block malicious payloads and unauthorized access.

In short, JWT validation gives your Application Gateway the smarts to know who’s knocking at the door, and to only let the right people in.

How JWT Validation Works

At its core, JWT validation uses a trusted authority (for now it uses Microsoft Entra ID) to issue a token. That token is presented to the Application Gateway, which then validates:

The token is legitimate
The token was issued by the expected tenant
The audience matches the resource you intend to protect

If all checks pass, the gateway returns a 200 OK and the request continues to your backend. If anything fails, the gateway returns 403 Forbidden, and your backend never sees the call. You can check code and errors here:

JSON Web Token (JWT) validation in Azure Application Gateway (Preview)

Setting Up JWT Validation in Azure Application Gateway

The steps to configure JWT validation in Azure Application Gateway are documented here:

JSON Web Token (JWT) validation in Azure Application Gateway (Preview)

Use Cases That Matter to IT Pros

Zero Trust
Multi-Tenant Workloads
Geolocation-Based Access
AI Workloads

Next Steps

Identify APIs or workloads exposed through your gateways.
Audit whether they already enforce token validation.
Test JWT validation in a dev environment.
Integrate the policy into your Zero Trust architecture.
Collaborate with your dev teams on standardizing audiences.

Resources

Azure Application Gateway JWT Validation
- https://learn.microsoft.com/azure/application-gateway/json-web-token-overview
Microsoft Entra ID App Registrations
- https://learn.microsoft.com/azure/active-directory/develop/quickstart-register-app
Azure Application Gateway Documentation
- https://learn.microsoft.com/azure/application-gateway/overview
Azure Zero Trust Guidance
- https://learn.microsoft.com/security/zero-trust/zero-trust-overview
Azure API Management and API Security Best Practices
- https://learn.microsoft.com/azure/api-management/api-management-key-concepts
Microsoft Identity Platform (Tokens, JWT, OAuth2
- https://learn.microsoft.com/azure/active-directory/develop/security-tokens
Using Curl with JWT Validation Scenarios
- https://learn.microsoft.com/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow#request-an-access-token

Final Thoughts

JWT validation in Azure Application Gateway is a powerful addition to your skills for securing cloud applications.

It brings identity awareness right into your networking layer, which is a huge win for security and simplicity. If you manage infrastructure and worry about unauthorized access to your APIs, give it a try. It can drastically reduce the “attack surface” by catching invalid requests early.

As always, I’d love to hear about your experiences. Have you implemented JWT validation on App Gateway, or do you plan to? Let me know how it goes! Feel free to drop a comment or question.

Cheers!

Pierre Roman

Anatomy of an Outage: How Microsoft focuses on Transparency during and post incident

Rick_Claus — Tue, 16 Dec 2025 20:23:38 GMT

Outages happen—no matter the hyperscale provider, no matter the architecture. What separates resilient organizations from the rest is how quickly they detect issues, how effectively they communicate, and how well they learn from the inevitable. I had the opportunity to co-present a session on the topic of how Microsoft communicates during outages and what YOU can do to be more proactive on how your Azure based infra is weathering the storm. Tajinder Pal Singh Ahluwalia and I pulled back the curtain on how Microsoft handles major incidents—from the first customer impact signal to the deep‑dive retrospectives that follow. Our session, “Anatomy of an outage and evolving our culture towards transparency,” was an updated version of a popular session from previous Microsoft Ignites that offered crucial lessons for infrastructure teams everywhere.

The Five Pillars of Transparent Outage Communication

Azure’s communications framework is built on five principles: speed, accuracy, discoverability, parity, and transparency. These pillars guide every notification and public update during an incident. As Tajinder emphasized, transparency isn’t a PR stance—it’s the backbone of operational maturity. Customers deserve to know what failed, why it failed, and how they can prevent similar issues in their environments.

A key enabler is Azure’s AI‑driven AIOps engine, Brain, an internal tool which automates initial incident notifications. Today, 90% of Azure services deliver alerts within 10 minutes, with the remainder guaranteed within 60. Speed is not optional at hyperscale. It’s table stakes.

Why Azure Service Health Should Be Non‑Negotiable

Shockingly, only 20–30% of Azure subscriptions actively use Azure Service Health—yet it’s the single most important tool for understanding how outages affect your specific workloads. Rather than relying on generic “is Azure down?” websites, Service Health gives you:

Tailored incident visibility
Granular scoping across subscriptions, resource groups, and services
Historical alerting and automation hooks
Integration points for SMS, Teams, webhooks, logic apps, and more

Docs & Resources:

Azure Service Health overview: https://learn.microsoft.com/azure/service-health/overview
Create & manage service health alerts: https://learn.microsoft.com/azure/service-health/alerts-activity-log-service-notifications
Training: Intro to Azure Service Health https://learn.microsoft.com/en-us/training/modules/intro-to-azure-service-health

What to expect: Three stages of an incident - Before, During, and After an Outage

Before: Strengthen Your Signals

We recommend layering multiple monitoring sources:

Azure Service Health for platform issues
Azure Resource Health for per‑resource diagnostics
Scheduled Events for planned maintenance
Azure Monitor for performance and dependency telemetry

This is also where architectural resiliency comes into play—availability zones, VM scale sets, redundancy options, ASR, and backup. Not every workload needs every capability, but every critical workload needs intentional design.

Docs:

Azure “Well Architecture Framework”: https://learn.microsoft.com/azure/well-architected/
Reliability engineering guidance and documentation: https://learn.microsoft.com/en-us/azure/reliability/overview

During: Communicating at Cloud Scale

When incidents hit, Azure focuses on scale, equity, and signal clarity. Everyone—from the smallest tenant to Fortune 50 companies—receives the same information at the same time. Support tickets aren’t required for SLA credit; they're reserved for cases where the symptoms don’t match published impact.

Azure Status Page: https://status.azure.com
(Don’t forget – Azure Service Health alerts always arrive faster so use both.)

What to do during an Azure Service Outage: https://learn.microsoft.com/azure/reliability/incident-response

After: Learning Without Blame

Post‑incident reviews (PIRs) are published within:

3 days for major incidents
14 days for smaller multi‑service events

These reviews have evolved into narrative, timeline‑driven analyses—focused not on blaming a “root cause,” but on mapping cascading dependencies and mitigation actions. Azure also hosts Azure Incident Response (AIR) livestreams featuring engineering leads talking through exactly what happened.

PIR & AIR resources:

Post Incident Review history: https://azure.status.microsoft/status/history/
AIR Videos (YouTube playlist): https://aka.ms/air/videos
Upcoming AIR schedule: https://aka.ms/air/upcoming

Final Thoughts

Infrastructure reliability isn’t just about designing resilient systems—it’s about understanding how your cloud provider detects, communicates, mitigates, and learns from failures. Azure’s maturing transparency culture, combined with tools like Azure Service Health and robust post‑incident processes, gives infrastructure teams the clarity they need to make informed operational decisions.

If there’s one takeaway, it’s this: GO CONFIGURE Azure Service Health today, and ensure the right people in your organization get the right signals at the right time. The next outage will happen. The question is whether you’ll be ready for it.

Configure a log analytics workspace to collect Window Server Event log, IIS and performance data.

OrinThomas — Fri, 12 Dec 2025 03:02:55 GMT

Configuring Azure Monitor with Log Analytics for IIS Servers

Azure Monitor combined with Log Analytics provides centralized telemetry collection for performance metrics, event logs, and application logs from Windows-based workloads. This guide demonstrates how to configure data collection from IIS servers using Data Collection Rules (DCRs).

Create the Log Analytics Workspace

Navigate to Log Analytics workspaces in the Azure portal
Select Create
Choose your resource group (e.g., Zava IIS resource group)
Provide a workspace name and select your preferred region
Select Review + Create, then Create

After deployment, configure RBAC permissions by assigning the Contributor role to users or service principals that need to interact with the workspace data.

Configure Data Collection Infrastructure

Create a Data Collection Endpoint:

Navigate to Azure Monitor in the portal
Select Data Collection Endpoints, then Create
Specify the endpoint name, subscription, resource group, and region (match your Log Analytics workspace region)
Create the endpoint

Create a Data Collection Rule:

Navigate to Data Collection Rules and select Create
Provide a rule name, resource group, and region
Select Windows as the platform type
Choose the data collection endpoint created in the previous step
Skip the Resources tab initially (you'll associate VMs later)

Configure Data Sources

Add three data source types to capture comprehensive telemetry:

Performance Counters:

On the Collect and Deliver page, select Add data source
Choose Performance Counters as the data source type
Select Basic for standard CPU, memory, disk, and network metrics (or Custom for specific counters)
Set the destination to Azure Monitor Logs and select your Log Analytics workspace

Windows Event Logs:

Add another data source and select Windows Event Logs
Choose Basic collection mode
Select Application, Security, and System logs
Configure severity filters (Critical, Error, Warning for Application and System; Audit Success for Security)
Specify the same Log Analytics workspace as the destination

IIS Logs:

Add a final data source for Internet Information Services logs
Accept the default IIS log file paths or customize as needed
Set the destination to your Log Analytics workspace

After configuring all data sources, select Review + Create, then Create the data collection rule.

Associate Resources

Navigate to your newly created Data Collection Rule
Select Resources from the rule properties
Click Add and select your IIS servers (e.g., zava-iis1, zava-iis2)
Return to Data Collection Endpoints
Select your endpoint and add the same IIS servers as resources

This two-step association ensures proper routing of telemetry data.

Query Collected Data

After allowing time for data collection, query the telemetry:

Navigate to your Log Analytics workspace
Select Logs to open the query editor
Browse predefined queries under Virtual Machines
Run the "What data has been collected" query to view performance counters, network metrics, and memory data
Access Insights to monitor data ingestion volumes

You can create custom KQL queries to analyze specific events, performance patterns, or IIS log entries across your monitored infrastructure.

Find out more at: https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview

Deploy and configure an Azure Application Gateway for load balancing and website protection.

OrinThomas — Thu, 11 Dec 2025 04:30:38 GMT

Azure Application Gateway provides layer 7 load balancing with integrated Web Application Firewall (WAF) capabilities, enabling traffic distribution across backend servers while protecting against common web exploits like SQL injection and DDoS attacks. This guide walks through deploying an Application Gateway to front-end two Windows Server IIS instances in an availability set.

Network Infrastructure Configuration

The first step you need to take is to prepare your Azure network infrastructure for Azure Application Gateway deployment. You can do this by performing the following steps:

Create Application Gateway Subnet

Navigate to Virtual Networks and select your IIS VNet
Select Subnets > Add Subnet
Configure the subnet:

Name: app-GW-subnet
Starting address: 10.0.1.0 (or next available subnet range)
Leave other settings at defaults (no private endpoint policies or subnet delegation required)app-gateway-iis-vms-narrated-itopstalk.txt

Configure NSG Rules for Backend Traffic

Select the first IIS VM's Network Security Group
Create an inbound rule:

Source: Application Gateway subnet (10.0.1.0/24)
Service: HTTP
Provide priority and descriptive name

Repeat for the second IIS VM's NSG to allow traffic from the Application Gateway subnet on port 80app-gateway-iis-vms-narrated-itopstalk.txt

Application Gateway Deployment

Once the Azure network infrastructure is prepared, you can then deploy the application gateway and configure network traffic protection policies.

Basic Configuration

Search for Application Gateways in the Azure Portal
Click Create > Application Gateway
Configure basic settings:

Resource Group: Same as IIS VMs
Name: (e.g., ZAVA-app-GW2)
Region: Same as IIS VMs
Tier: Standard V2
IP Address Type: IPv4 only

Select Configure Virtual Network and choose the IIS VNet
Select the Application Gateway subnet created earlier
Create a new public IPv4 address for the gateway frontend.

Backend Pool Configuration

On the Backends page, select Add a backend pool
Provide a pool name
Add both IIS VM private IP addresses to the pool.

Routing Rule Configuration

On the Configuration page, select Add a routing rule
Configure the listener:

Provide a rule name
Create a listener with a descriptive name
Protocol: HTTP
Port: 80
Listener type: Basic

Configure backend targets:

Target type: Backend pool
Backend pool: Select the pool created in the previous step
Create new backend settings with port 80
Configure optional settings (cookie affinity, connection draining) as needed

Specify a priority for the routing rule
Complete the wizard to deploy the gatewayapp-gateway-iis-vms-narrated-itopstalk.txt

Verification and Testing

Navigate to Application Gateways and select your deployed gateway
Copy the Public IP Address from the overview page
Access the public IP in a browser and refresh multiple times to observe load balancing between IIS-1 and IIS-2
Navigate to Backend Pools to view backend health status for troubleshooting.

Web Application Firewall Protection

In your Application Gateway, navigate to Web Application Firewall
Select Create a web application firewall policy
Provide a policy name
Enable Bot Protection for enhanced security
Save the policy
Review the policy's Managed Rules to confirm OWASP Core Rule Set and bot protection rules are active.

The Application Gateway now distributes traffic across your IIS availability set while providing enterprise-grade security protection through integrated WAF capabilities.

Find out more at: https://learn.microsoft.com/en-us/azure/application-gateway/overview

Deploying Windows Servers in an Azure Availability Set

OrinThomas — Mon, 08 Dec 2025 03:58:12 GMT

Deploying Windows Servers in an Azure Availability Set

This guide demonstrates deploying Windows Server an Azure Availability Set for Windows Server IIS workloads.

An availability set logically groups virtual machines across fault domains and update domains within a single Azure data center. Fault domains provide physical hardware isolation (separate racks, power, and network switches), while update domains ensure Azure staggers platform maintenance, rebooting only one domain at a time with 30-minute recovery windows. VMs must be assigned to availability sets during creation and you cannot add existing VMs later.

Creating the First VM

Navigate to Azure Portal > Virtual Machines > Create
Create a new resource group (e.g., "Zava IIS")
Name the VM (e.g., "Zava IIS 1") and select region (e.g., East US 2)
Under Availability Options, select "Availability set" > Create New
Name the availability set and accept defaults (2 fault domains, 2 update domains)
Configure local admin account (avoid using "Administrator")
Select "No inbound ports" for security
Enable Azure Hybrid Benefit if you have existing Windows Server licenses
Verify Premium SSD is selected under Disks (required for 99.95% SLA)
Note the virtual network name for subsequent VMs
Under Management, disable automatic shutdown and hotpatch
Under Monitoring, disable boot diagnostics
Review and create the VMAvailability-Set-Audio-Pre-avatar.txt

Creating the Second VM

Return to Virtual Machines > Create
Use the same resource group
Name the second VM (e.g., "Zava IIS 2")
Select the existing availability set created in step 4 above
Match all settings from the first VM (admin account, no inbound ports, hybrid benefit, Premium SSD)
Ensure the VM connects to the same virtual network as the first VM
Disable auto shutdown, hotpatch, and boot diagnostics
Review and create

Ensure that the VMs are configured with Premium SSD to achieve the highest possible SLA of 99.999%.

In a future post, we’ll cover how to configure Azure Application Gateway to load balance traffic across computers in an availability set as well as protecting against DDoS and OWASP top 10 attacks

Learn more about Azure Availability Sets

Microsoft Entra Domain Services: Deploy, Join a VM, and Use Classic AD Tools

OrinThomas — Mon, 24 Nov 2025 20:26:02 GMT

Microsoft Entra Domain Services (Entra DS) provides you with the functionality of managed domain controllers in Azure. This allows you to domain-join Windows Server VMs, use Group Policy, and manage DNS on a specially prepared vNet subnet without deploying and patching your own DC VMs.

This post walks through:

• Preparing your virtual network

• Deploying Entra DS

• Configuring DNS

• Joining a Windows Server VM to the managed domain

• Using AD DS and Windows Server DNS tools from that VM

Prerequisites

• An Azure subscription.

• A Microsoft Entra tenant with a custom DNS domain verified (for example, zava.support). Entra DS uses this custom domain as the managed domain name.

• Permission to create resource groups, VNets, and Entra DS.

• Permission to manage Entra groups in the tenant (add administrators/configure RBAC).

Step 1 – Create a resource group and virtual network

1. Create a new resource group in your chosen region to hold all Entra DS resources and VMs.

2. Create a virtual network (for example, zava-entra-dsvn) in that resource group (for example, address space: 172.16.0.0/16 (or a range that fits your environment).

3. Add a subnet dedicated to the Entra DS domain controllers (for example, zava-entra-dc). This subnet will host the managed domain controller resources created by Entra DS and you won’t actually deploy VMs there.

Important Keep this DC subnet separate from your workload subnets. You can use NSGs, but avoid blocking Entra DS management traffic.

Step 2 – Add a workload subnet for VMs

1. In the same virtual network, create a second subnet (for example, zava-domain-vms) for domain-joined workloads such as IIS VMs. This special subnet is where you’ll deploy the Windows Server VM that joins the Entra DS domain.

Step 3 – Deploy Microsoft Entra Domain Services

In the Azure portal, create a new Microsoft Entra Domain Services managed domain by performing the following steps:

1. Select the resource group you created earlier.

2. Confirm the DNS domain name (for example, zava.support)—this comes from your Entra tenant’s custom domain.

3. Choose the region (same region as the virtual network).

4. Keep the default Enterprise SKU unless you have a specific need for another.

5. On the Networking page:

· Select the virtual network you created.

· Select the DC subnet for the managed domain controllers.

6. On the Administration page note that the AAD DC Administrators group (legacy name shown in the portal) is effectively the Domain Admins equivalent for the managed domain. Any user you add to this group in Entra becomes a domain admin in Entra DS.

7. Configure synchronization scope between Entra and Entra DS.

· All accounts (default) – synchronizes both cloud-only and synchronized users.

· Cloud-only accounts – useful when you’re already syncing on-prem identities and you only want specific cloud accounts in Entra DS.

8. Review the Security settings page. By default:

· NTLMv1 disabled.

· You can enable/disable NTLM password sync, or effectively disable NTLM entirely.

· RC4 encryption disabled by default.

· Kerberos armoring enabled by default.

· LDAP signing and LDAP channel binding enabled by default.

9. Review your configuration and create the Entra DS managed domain. Note after deployment, you cannot change:

• The managed domain DNS name

• Subscription

• Resource group

• Virtual network and subnet used by Entra DS

Step 4 – Fix virtual network DNS with Entra DS health checks

1. Once deployment completes, open the Entra DS resource and go to View health.

2. Run the health checks. If the diagnostic reports that the virtual network DNS servers are not set to the Entra DS managed DC IPs, select Fix to automatically configure the VNet’s DNS servers.

· In Entra DS, note the DNS server IPs (for example, 172.16.0.4 and 172.16.0.5).

· In the virtual network’s DNS settings, confirm these IPs are configured as custom DNS servers.

Tip Any VM in this virtual network that needs to join the managed domain must use these Entra DS DNS addresses.

Step 5 – Add administrators to the AAD DC Administrators group

1. In the Entra admin center, go to Groups > All groups and locate AAD DC Administrators.

2. Open the group and add your primary admin account (for example, prime@zava.support) and add a dedicated domain admin–style account (for example, adds.prime@zava.support) to be the primary administrator for the managed domain.

Important note: You’ll need to change the password of any Entra account you want to use in the managed AD DS domain after deploying Entra DS. This will configure password synchronization between Entra and Entra DS, allowing you to use the Entra account. If you don’t change the password, you’ll be unable to use the account with Entra DS even though it will function normally in other parts of Azure. This trips a lot of people up.

Step 6 – Create a Windows Server IaaS VM on the workload subnet

1. In the Azure portal, create a new Windows Server VM (for example, an IIS server):

1. Place it in the same resource group.

2. Select the virtual network you created earlier.

3. Attach it to the workload subnet (for example, zava-domain-vms).

4. Configure a local administrator account (for example, username prime with a strong password).

2. On the Management blade, note the option “Login with Microsoft Entra ID”:

1. This enables direct Entra login to the VM but does not join the VM to the Entra DS domain.

2. For this walkthrough, you’ll join the VM to Entra DS using classic domain join so don’t need to enable this option.

3. Complete the wizard and deploy the VM.

Step 7 – Connect to the VM and verify DNS

1. Once the VM is deployed, open the VM in the portal and select Connect > RDP.

1. Request a JIT RDP port opening if required.

2. Download the RDP file and open it with Remote Desktop Connection.

2. Sign in with the local administrator account you configured when deploying the VM and not your Entra account.

3. In the VM, open a command prompt and run:

ipconfig /all

1. Confirm that the DNS servers are the Entra DS managed IPs (for example, 172.16.0.4 and 172.16.0.5).

If DNS is wrong Double-check the VNet’s DNS settings and ensure the VM is attached to the correct virtual network and subnet, then restart the VM.

Step 8 – Join the VM to the Entra DS domain

1. On the VM, open Server Manager and select Local Server.

2. Next to Workgroup, select the workgroup name to open System Properties (Computer Name tab).

3. Select Change… and then:

· Under Member of, select Domain.

· Enter the Entra DS domain name (for example, zava.support).

4. When prompted for credentials, use an account that’s a member of AAD DC Administrators, such as adds.prime@zava.support, and enter the password.

5. When you receive the confirmation that the computer has joined the domain, restart the VM.

Step 9 – Sign in with an Entra DS domain account

1. After the VM restarts, reconnect via RDP using the VM’s public IP and:

· Username: your domain UPN (for example, adds.prime@zava.support).

· Password: the account’s password.

2. Confirm that you are signed in as a domain user in the Entra DS managed domain.

Step 10 – Use AD DS and DNS tools on the domain-joined VM

1. Install and open Active Directory Users and Computers (RSAT) on the VM.

· Browse the managed domain structure.

· Notice containers such as AADDC Computers, AADDC Users, and groups like Domain Admins that map back to Entra groups.

2. Create an organizational unit (OU), for example IIS Servers, to contain IIS VMs.

3. Open Group Policy Management and:

· Create a Group Policy Object targeting the IIS Servers OU.

· Link and configure settings as required (hardening, IIS config, etc.).

4. Open the DNS Manager console on the VM, which now connects to the Entra DS–managed DNS servers.

5. Create a new Host (A) record, for example:

· Name: iis3

· FQDN: iis3.zava.support

· IP address: the appropriate internal address.

6. Open a command prompt and verify DNS resolution with:

nslookup iis3.zava.support

• Confirm it returns the correct IP address.

Entra DS gives you familiar AD capabilities—domain join, Group Policy, and DNS—without the overhead of running and maintaining your own DC VMs in Azure.

You can find out more at: https://learn.microsoft.com/en-us/entra/identity/domain-services/overview

Getting Started with Windows Admin Center Virtualization Mode

OrinThomas — Sun, 23 Nov 2025 02:23:06 GMT

Getting Started with Windows Admin Center Virtualization Mode

Windows Admin Center (WAC) Virtualization Mode is a new, preview experience for managing large Hyper-V virtualization fabrics—compute, networking, and storage—from a single, web-based console. It’s designed to scale from a handful of hosts up to thousands, centralizing configuration and day-to-day operations.

This post walks through:

• What Virtualization Mode is and its constraints

• How to install it on a Windows Server host

• How to add an existing Hyper-V host into a resource group

Prerequisites and Constraints

Before you begin, note the current preview limitations:

• The WAC Virtualization Mode server and the Hyper-V hosts it manages must be in the same Active Directory domain.

• You cannot install Virtualization Mode side-by-side with a traditional WAC deployment on the same server.

• Do not install Virtualization Mode directly on a Hyper-V host you plan to manage.

– You can install it on a VM running on that host.

• Plan for at least 8 GB RAM on the WAC Virtualization Mode server.

For TLS, the walkthrough assumes you have an Enterprise CA and are deploying domain-trusted certificates to servers, so browsers automatically trust the HTTPS endpoint. You can use a self signed certificate, but you’ll end up with all the fun that entails when you use WAC-V from a host on which the self signed cert isn’t installed. Given the domain requirements of WAC-V and the hosts it manages, going the Enterprise CA method seemed the path of least resistance.

Step 1 – Install the C++ Redistributable

On your Windows Server 2025 host that will run WAC Virtualization Mode:

1. Open Windows Terminal or PowerShell.

2. Use winget to search for the VC++ redistributable:

powershell

winget search "VC Redist"

3. Identify the package corresponding to “Microsoft Visual C++ 2015–2022 Redistributable” (or equivalent).

4. Install it with winget, for example:

powershell

winget install "Microsoft.VC++2015-2022Redist-x64"

This fulfills the runtime dependency for the WAC Virtualization Mode installer.

Step 2 – Install Windows Admin Center Virtualization Mode

1. Download the installer

1. Download the Windows Admin Center Virtualization Mode installer from the Windows Insider Preview location provided in the official documentation. Save it to a local folder on the WAC host.

2. Run the setup wizard

1. Double-click the downloaded binary.

2. Approve the UAC prompt.

3. In the Welcome page, proceed as with traditional WAC setup.

3. Accept the license and choose setup type

1. Accept the license agreement.

2. Choose Express setup (suitable for most lab and PoC deployments).

4. Select a TLS certificate

1. When prompted for a TLS certificate:

1. Select a certificate issued by your Enterprise CA that matches the server name.

2. Using CA-issued certs ensures all domain-joined clients will trust the site without manual certificate import.

5. Configure PostgreSQL for WAC

1. Virtualization Mode uses PostgreSQL as its configuration and state database.

2. When prompted:

1. Provide a strong password for the database account WAC will use.

2. Record this securely if required by your org standards.

6. Configure update and diagnostic settings

1. Choose how WAC should be updated (manual/automatic).

2. Set diagnostic data preferences according to your policy.

7. Complete the installation

1. Click Install to deploy:

1. The WAC Virtualization Mode web service

2. The PostgreSQL database instance

2. When installation completes, click Finish.

Step 3 – Sign In to Virtualization Mode

1. Open a browser on a domain-joined machine and browse to the WAC URL (for example, https://wac-vmode01.contoso.internal).

2. Sign in with your domain credentials that have appropriate rights to manage Hyper-V hosts (for example, DOMAIN\adminuser).

3. You’ll see the new Virtualization Mode UI, which differs significantly from traditional WAC and is optimized for fabric-wide management.

Step 4 – Create a Resource Group

Resource groups help you logically organize Hyper-V servers you’ll manage (for example, by site, function, or cluster membership).

1. In the Virtualization Mode UI, select Resource groups.

2. Click Create resource group.

3. Provide a name, such as Zava-Nested-Vert.

4. Save the resource group.

You now have a logical container ready for one or more Hyper-V hosts.

Step 5 – Prepare the Hyper-V Host

Before adding an existing Hyper-V host:

1. Ensure the host is:

1. Running Hyper-V and reachable by FQDN (for example, zava-hvA.zavaops.internal).

2. In the same AD domain as the WAC Virtualization Mode server.

2. Temporarily open File and Printer Sharing from the Hyper-V host’s firewall to the WAC Virtualization Mode server:

1. This is required for initial onboarding.

2. After onboarding, you can re-lock firewall rules according to your security baseline.

Step 6 – Add a Hyper-V Host to the Resource Group

1. In the WAC Virtualization Mode UI, go to your resource group.

2. Click the ellipsis (…) and choose Add resource.

3. On the Add resource page, select Compute (you’re adding a Hyper-V server, not a storage fabric resource).

4. Enter the Hyper-V host’s FQDN (for example, zava-hvA.zavaops.internal).

5. Confirm the host resolves correctly and proceed.

Configure Networking Template

1. On the Networking page, assign fabric roles to NICs using the network template model:

1. Each NIC can be tagged for one or more roles:

1. Compute

2. Management

3. Storage

2. In a simple, single-NIC lab scenario, you may assign Compute, Management, and Storage all to Ethernet0.

3. All three roles must be fully assigned across available adapters before you can proceed.

Configure Storage

1. On the Storage page, specify the storage model:

1. For an existing host using local disks, choose Use existing storage.

2. In future, you can select SAN or file server storage when those options are available and configured in your environment.

Configure Compute Properties

1. On the Compute page, configure host-level defaults:

1. Enable or disable Enhanced Session Mode.

2. Set the maximum concurrent live migrations.

3. Confirm or update the default VM storage path.

2. Review the configuration, click Next, then Submit.

3. The Hyper-V host is registered into the resource group and becomes manageable via Virtualization Mode.

Step 7 – Verify Host and VM Management

With the host onboarded:

1. Open the resource group and select the Hyper-V host.

2. You’ll see a streamlined view similar to traditional WAC, with nodes for:

1. Event logs

2. Files

3. Networks

4. Storage

5. Windows Update

6. Virtual Machines

3. To validate functionality, create a test VM:

1. Go to Virtual Machines → Add.

2. Provide a VM name (for example, WS25-temp).

3. Set vCPUs (for example, 2).

4. Optionally enable nested virtualization.

5. Select the appropriate virtual switch.

6. Click Create, then attach an ISO or existing VHDX and complete OS setup.

▶️ Public Preview: https://aka.ms/WACDownloadvMode

▶️ Documentation: https://aka.ms/WACvModeDocs

Azure File Sync with ARC... Better together.

Pierre_Roman — Wed, 22 Oct 2025 19:35:53 GMT

Hello Folks!

Managing file servers across on-premises datacenters and cloud environments can be challenging for IT professionals. Azure File Sync (AFS) has been a game-changer by centralizing file shares in Azure while keeping your on-premises Windows servers in play. With AFS, a lightweight agent on a Windows file server keeps its files synced to an Azure file share, effectively turning the server into a cache for the cloud copy. This enables classic file server performance and compatibility, cloud tiering of cold data to save local storage costs, and capabilities like multi-site file access, backups, and disaster recovery using Azure’s infrastructure. Now, with the introduction of Azure Arc integration for Azure File Sync, it gets even better. Azure Arc, which allows you to project on-prem and multi-cloud servers into Azure for unified management, now offers an Azure File Sync agent extension that dramatically simplifies deployment and management of AFS on your hybrid servers.

In this post, I’ll explain how this new integration works and how you can leverage it to streamline hybrid file server management, enable cloud tiering, and improve performance and cost efficiency.

You can see the E2E 10-Minute Drill - Azure File sync with ARC, better together episode on YouTube below.

Azure File Sync + Azure Arc: Better Together

Azure File Sync has already enabled a hybrid cloud file system for many organizations. You install the AFS agent on a Windows Server (2016 or later) and register it with an Azure Storage Sync Service. From that point, the server’s designated folders continuously sync to an Azure file share. AFS’s hallmark feature is cloud tiering, older, infrequently used files can be transparently offloaded to Azure storage, while your active files stay on the local server cache. Users and applications continue to see all files in their usual paths; if someone opens a file that’s tiered, Azure File Sync pulls it down on-demand. This means IT pros can drastically reduce expensive on-premises storage usage without limiting users’ access to files. You also get multi-site synchronization (multiple servers in different locations can sync to the same Azure share), which is great for branch offices sharing data, and cloud backup/DR by virtue of having the data in Azure. In short, Azure File Sync transforms your traditional file server into a cloud-connected cache that combines the performance of local storage with the scalability and durability of Azure.

Azure Arc comes into play to solve the management side of hybrid IT. Arc lets you project non-Azure machines (whether on-prem or even in other Clouds) into Azure and manage them alongside Azure VMs. An Arc-enabled server appears in the Azure portal and can have Extensions installed, which are components or agents that Azure can remotely deploy to the machine.

Prior to now, installing or updating the Azure File Sync agent on a bunch of file servers meant handling each machine individually (via Remote Desktop, scripting, or System Center). This is where the Azure File Sync Agent Extension for Windows changes the game.

Using the new Arc extension, deploying Azure File Sync is as easy as a few clicks. In the Azure Portal, if your Windows server is Arc-connected (i.e. the Azure Arc agent is installed and the server is registered in Azure), you can navigate to that server resource and simply Add the “Azure File Sync Agent for Windows” extension. The extension will automatically download and install the latest Azure File Sync agent (MSI) on the server. In other words, Azure Arc acts like a central deployment tool: you no longer need to manually log on or run separate install scripts on each server to set up or update AFS. If you have 10, 50, or 100 Arc-connected file servers, you can push Azure File Sync to all of them in a standardized way from Azure – a huge time saver for large environments. The extension also supports configuration options (like proxy settings or automatic update preferences) that you can set during deployment, ensuring the agent is installed with the right settings for your environment

Note: The Azure File Sync Arc extension is currently Windows-only. Azure Arc supports Linux servers too, but the AFS agent (and thus this extension) works only on Windows Server 2016 or newer. So, you’ll need a Windows file server to take advantage of this feature (which is usually the case, since AFS relies on NTFS/Windows currently).

Once the extension installs the agent, the remaining steps to fully enable sync are the same as a traditional Azure File Sync deployment: you register the server with your Storage Sync Service (if not done automatically) and then create a sync group linking a local folder (server endpoint) to an Azure file share (cloud endpoint). This can be done through the Azure portal, PowerShell, or CLI. The key point is that Azure Arc now handles the heavy lifting of agent deployment, and in the future, we may see even tighter integration where more of the configuration can be done centrally. For now, IT pros get a much simpler installation process – and once configured, all the hybrid benefits of Azure File Sync are in effect for your Arc-managed servers.

Key Benefits for IT Pros: Azure File Sync + Azure Arc

Centralized Management
- Azure Arc provides a single control plane in Azure to manage file services across multiple servers and locations. You can deploy updates or new agents at scale and monitor status from the cloud—reducing overhead and ensuring consistency.
Simplified Deployment
- No manual installs. Azure Arc automates Azure File Sync setup by fetching and installing the agent remotely. Ideal for distributed environments, and easily integrated with automation tools like Azure CLI or PowerShell.
Cost Optimization with Cloud Tiering
- Offload rarely accessed files to Azure storage to free local disk space and extend hardware life. Cache only hot data (10–20%) locally while leveraging Azure’s storage tiers for lower TCO.
Improved Performance
- Cloud tiering keeps frequently used files local for LAN-speed access, reducing WAN latency. Active data stays on-site; inactive data moves to the cloud—delivering a smoother experience for distributed teams.
Built-In Backup & DR
- Azure Files offers redundancy and point-in-time recovery via Azure Backup. If a server fails, you can quickly restore from Azure. Multi-site sync ensures continued access, supporting business continuity and cloud migration strategies.

Getting Started with Azure File Sync via Arc

Prepare Azure Arc and Servers
- Connect Windows file servers (Windows Server 2016+) to Azure Arc by installing the Connected Machine agent and onboarding them. Refer to Azure Arc documentation for setup.
Deploy Azure File Sync Agent Extension
- Install the Azure File Sync agent extension on Arc-enabled servers using the Azure portal, PowerShell, or CLI. Verify the Azure Storage Sync Agent is installed on the server. See Microsoft Learn for detailed steps.
Complete Azure File Sync Setup
- In the Azure portal, create or open a Storage Sync Service. Register the server and create a Sync Group to link a local folder (Server Endpoint) with an Azure File Share (Cloud Endpoint). Configure cloud tiering and free space settings as needed.
Test and Monitor
- Allow time for initial sync. Test file access (including tiered files) and monitor sync status in the Azure portal. Use Azure Monitor for health alerts.
Explore Advanced Features
- Enable options like cloud change enumeration, NTFS ACL sync, and Azure Backup for file shares to enhance functionality.

Resources and Next Steps

For more info and step-by-step guidance, check out these resources:

Microsoft Learn – Azure File Sync Agent Extension on Azure Arc: Official documentation on installing and managing the AFS agent via Azure Arc.
Azure File Sync Documentation: Comprehensive docs for Azure File Sync, including deployment guides, best practices, and troubleshooting.
Azure Arc Documentation: Learn how to connect servers to Azure Arc and manage extensions. This is useful if you’re new to Arc or need to meet prerequisites for using the AFS extension.

You, as an IT Pro, can provide your organization with the benefits of cloud storage – scalability, reliability, pay-as-you-go economics – while retaining the performance and control of on-premises file servers. All of this can be achieved with minimal overhead, thanks to the new Arc-delivered agent deployment and the powerful features of Azure File Sync.

Check it out if you have not done so before. I highly recommend exploring this integration to modernize your file services.

Cheers!

Pierre Roman

Requesting and Installing an SSL Certificate for Internet Information Server (IIS)

OrinThomas — Thu, 09 Oct 2025 20:16:21 GMT

Generate a Certificate Signing Request (CSR)

Generate the request using the Certificates snap-in in Microsoft Management Console (MMC).

Step 1: Open the Certificates Snap-In

Press Windows + R, type mmc, and press Enter.
Go to File > Add/Remove Snap-in.
Select Certificates and click Add.
Choose Computer account, then click Next.
Select Local computer and click Finish.
Click OK to close the Add/Remove window.

Step 2: Start the CSR Wizard

In the left pane, expand Certificates (Local Computer).
Right-click Personal and select:

All Tasks → Advanced Operations → Create Custom Request

Step 3: Configure the Request

On the Certificate Enrollment page, click Next.
Select Proceed without enrollment policy and click Next.
On the “Certificate Information” page, expand Details and click Properties.
On the General tab:

Enter a friendly name, e.g., WS25-IIS Certificate.

On the Subject tab:

Under Subject name, choose Common Name.
Enter the fully qualified domain name (FQDN), e.g. ws25-iis.windowserver.info.
Click Add.
Under Alternative name, choose DNS.
Enter the same FQDN and click Add.

On the Extensions tab:

Under Key Usage, ensure Digital Signature and Key Encipherment are selected.
Under Extended Key Usage, add Server Authentication.

On the Private Key tab:

Under Cryptographic Provider, select
RSA, Microsoft Software Key Storage Provider.
Set Key size to 2048 bits.
Check Make private key exportable and
Allow private key to be archived.

Click Apply, then OK, and then Next.

Step 4: Save the Request

Choose a location to save the request file (e.g. C:\Temp).
Ensure the format is set to Base 64.
Provide a filename such as SSLRequest.req.
Click Finish.

You can open the file in Notepad to verify the Base64-encoded request text.

Submit the CSR to a Certification Authority

You can use an internal Windows CA or a public CA. The example below assumes a web enrollment interface.

Step 1: Open the CA Web Enrollment Page

Navigate to your CA’s enrollment site. If the server does not trust the CA, you may receive a warning. You'll need to or install the CA certificate as needed.

Step 2: Submit an Advanced Certificate Request

Select Request a certificate.
Choose advanced certificate request.
Open the CSR in Notepad, copy the Base64 text, and paste it into the request form.
Click Submit.

Step 3: Approve the Request (if required)

If your CA requires approval, sign in to the CA server and approve the pending request.

Step 4: Download the Issued Certificate

Return to the CA web enrollment page.
View the status of pending requests.
Locate your request and select it.
Choose the Base 64 encoded certificate format.
Download the certificate.
Save it to a known location and rename it meaningfully (e.g. WS25-IIS-Cert.cer).

Install the SSL Certificate

Double-click the .cer file to open it.
Click Install Certificate.
Choose Local Machine as the store location.
When prompted for the store, select:

Place all certificates in the following store
Choose Personal

Click Next, then Finish.
Confirm the success message by clicking OK.

The certificate is now imported and available for use by IIS.

Bind the Certificate in IIS

Step 1: Open IIS Manager

Open Server Manager or search for IIS Manager.
In the left pane, expand the server and select your website (e.g., Default Web Site).

Step 2: Add an HTTPS Binding

In the Actions pane, click Bindings.
In the Site Bindings window, click Add.
Select:

Type: https
Hostname: the FQDN used in the certificate (e.g., ws25-iis.windowserver.info)
SSL Certificate: choose the certificate you installed (e.g. WS25-IIS Certificate)

Click OK, then Close.

Test the HTTPS Connection

Open Microsoft Edge (or your preferred browser).
Browse to the site using https:// and the FQDN.

Example: https://ws25-iis.windowserver.info

Confirm you see the IIS default page (or your site’s content).
Click the padlock in the address bar:

Verify the certificate is valid.
Check the certificate details if desired.

If the page loads securely without warnings, the certificate is installed and bound correctly.

Strengthening Azure File Sync security with Managed Identities

Pierre_Roman — Wed, 08 Oct 2025 19:43:26 GMT

Hello Folks,

As IT pros, we’re always looking for ways to reduce complexity and improve security in our infrastructure. One area that’s often overlooked is how our services authenticate with each other. Especially when it comes to Azure File Sync.

In this post, I’ll walk you through how Managed Identities can simplify and secure your Azure File Sync deployments, based on my recent conversation with Grace Kim, Program Manager on the Azure Files and File Sync team.

Why Managed Identities Matter

Traditionally, Azure File Sync servers authenticate to the Storage Sync service using server certificates or shared access keys. While functional, these methods introduce operational overhead and potential security risks. Certificates expire, keys get misplaced, and rotating credentials can be a pain.

Managed Identities solve this by allowing your server to authenticate securely without storing or managing credentials. Once enabled, the server uses its identity to access Azure resources, and permissions are managed through Azure Role-Based Access Control (RBAC).

Using Azure File Sync with Managed Identities provides significant security enhancements and simpler credential management for enterprises. Instead of relying on storage account keys or SAS tokens, Azure File Sync authenticates using a system-assigned Managed Identity from Microsoft Entra ID (Azure AD). This keyless approach greatly improves security by removing long-lived secrets and reducing the attack surface.

Access can be controlled via fine-grained Azure role-based access control (RBAC) rather than a broadly privileged key, enforcing least-privileged permissions on file shares. I believe that Azure AD RBAC is far more secure than managing storage account keys or SAS credentials. The result is a secure-by-default setup that minimizes the risk of credential leaks while streamlining authentication management.

Managed Identities also improve integration with other Azure services and support enterprise-scale deployments. Because authentication is unified under Azure AD, Azure File Sync’s components (the Storage Sync Service and each registered server) seamlessly obtain tokens to access Azure Files and the sync service without any embedded secrets.

This design fits into common Azure security frameworks and encourages consistent identity and access policies across services. In practice, the File Sync managed identity can be granted appropriate Azure roles to interact with related services (for example, allowing Azure Backup or Azure Monitor to access file share data) without sharing separate credentials. At scale, organizations benefit from easier administration. New servers can be onboarded by simply enabling a managed identity (on an Azure VM or an Azure Arc–connected server) and assigning the proper role, avoiding complex key management for each endpoint. Azure’s logging and monitoring tools also recognize these identities, so actions taken by Azure File Sync are transparently auditable in Azure AD activity logs and storage access logs.

Given these advantages, new Azure File Sync deployments now enable Managed Identity by default, underscoring a shift toward identity-based security as the standard practice for enterprise file synchronization. This approach ensures that large, distributed file sync environments remain secure, manageable, and well-integrated with the rest of the Azure ecosystem.

How It Works

When you enable Managed Identity on your Azure VM or Arc-enabled server, Azure automatically provisions an identity for that server. This identity is then used by the Storage Sync service to authenticate and communicate securely.

Here’s what happens under the hood:

The server receives a system-assigned Managed Identity.
Azure File Sync uses this identity to access the storage account.
No certificates or access keys are required.
Permissions are controlled via RBAC, allowing fine-grained access control.

Enabling Managed Identity: Two Scenarios

Azure VM

If your server is an Azure VM:

- Go to the VM settings in the Azure portal.
- Enable System Assigned Managed Identity.
- Install Azure File Sync.
- Register the server with the Storage Sync service.
- Enable Managed Identity in the Storage Sync blade.

Once enabled, Azure handles the identity provisioning and permissions setup in the background.

Non-Azure VM (Arc-enabled)

If your server is on-prem or in another cloud:

- First, make the server Arc-enabled.
- Enable System Assigned Managed Identity via Azure Arc.
- Follow the same steps as above to install and register Azure File Sync.

This approach brings parity to hybrid environments, allowing you to use Managed Identities even outside Azure.

Next Steps

If you’re managing Azure File Sync in your environment, I highly recommend transitioning to Managed Identities. It’s a cleaner, more secure approach that aligns with modern identity practices.

✅ Resources

📚 https://learn.microsoft.com/azure/storage/files/storage-sync-files-planning
🔐 https://learn.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview
⚙️ https://learn.microsoft.com/azure/azure-arc/servers/overview
🎯 https://learn.microsoft.com/azure/role-based-access-control/overview

🛠️ Action Items

Audit your current Azure File Sync deployments.
Identify servers using certificates or access keys.
Enable Managed Identity on eligible servers.
Use RBAC to assign appropriate permissions.

Let me know how your transition to Managed Identities goes. If you run into any snags or have questions, drop a comment.

Cheers!

Pierre

Installing a Standalone Root Certificate Authority & Web Enrollment on Windows Server 2025

OrinThomas — Tue, 07 Oct 2025 23:18:11 GMT

In this post learn how to deploy a standalone root Certificate Authority (CA) on a Windows Server 2025 machine that is not joined to Active Directory. Also learn how to configure the web enrollment interface so clients can request certificates using a browser.

A standalone root CA is useful when:

You only need certificates trusted by a limited set of machines.
You don’t want to obtain certificates from a commercial provider.
You’re preparing an offline root CA scenario (covered separately).

Install Active Directory Certificate Services (Standalone Root CA)

1. Open Server Manager.
2. Select Manage then Add Roles and Features.
3. Choose Role-based or feature-based installation.
4. Select the local server.
5. Check Active Directory Certificate Services.
6. Click Add Features when prompted.
7. Click Next through the wizard until the **Role Services** page.
8. Select Certification Authority only.
9. Click Install and wait for completion.

Configure the Certification Authority

1. In Server Manager, click the notification flag.
2. Select Configure Active Directory Certificate Services.
3. Enter credentials.
4. On Role Services, ensure Certification Authority is selected.
5. For Setup Type, select Standalone CA.
6. Choose Root CA on the CA Type page.
7. Select Create a new private key.
8. Increase the key length to 4096 and accept the other defaults.
9. Accept the default CA name (or customize if desired).
10. Keep the default certificate validity period (5 years).
11. Accept the default database locations.
12. Confirm the configuration and allow it to complete.
13. Open the Certification Authority console from Tools to verify the CA was created.

Create an SSL Certificate for Web Enrollment

The CA certificate itself doesn’t include subject alternative names (SANs), so you need a separate SSL certificate for the website otherwise web enrollment will throw errors.

1. Open PowerShell and switch to the root directory.
2. Create and enter a temp folder.
3. Use Notepad to create servercert.inf with details such as:

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject="CN=ws25-sa-ca"
KeyLength=2048
KeySpec=1
KeyUsage=0xA0
MachineKeySet=TRUE
ProviderName="Microsoft RSA SChannel Cryptographic Provider"
RequestType=PKCS10
FriendlyName="IIS Server Cert"

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=ws25-sa-ca"
; Add more if needed, e.g., _continue_ = "& " for additional DNS names

4. Save the file.
5. Run certreq -new specifying the INF file and output a .req file.

certreq -new C:\temp\servercert.inf C:\temp\servercert.req

6. Submit the request:

* Run `certreq -submit` with the request file.

certreq -submit -attrib "CertificateTemplate:WebServer" C:\temp\servercert.req C:\temp\servercert.cer

* Select the standalone CA when prompted.
* The request will show as **Pending**.
7. Open the Certification Authority console.
8. Under Pending Requests, right-click the request and select All Tasks → Issue.
9. Retrieve the certificate:

* Use `certreq -retrieve` with the request ID and output a `.cer` file.

certreq -retrieve 2 C:\temp\servercert_issued.cer

10. Install the issued certificate with `certreq -accept` or by double-clicking.

certreq -accept C:\temp\servercert_issued.cer

Install the Web Enrollment Feature

1. Open Add Roles and Features again in Server Manager.
2. Click Next until the Server Roles page.
3. Expand Active Directory Certificate Services.
4. Select Certification Authority Web Enrollment.
5. Click Next and proceed. This also installs IIS automatically.
6. When finished, click Close.
7. Run Configure Active Directory Certificate Services again.
8. Select Certification Authority Web Enrollment and click Configure.

Bind the SSL Certificate in IIS

1. Open IIS Manager.
2. Select Default Web Site.
3. In the Actions pane, choose Bindings.
4. Click Add.
5. Set Type to https.
6. Enter the server’s hostname.
7. Select the SSL certificate you issued earlier (e.g., `IIS serviceert`).
8. Click OK and close IIS Manager.

Access the Web Enrollment Page

1. Open a browser.
2. Navigate to:
`https://<your-server-name>/certsrv`
Example:
`https://WS25-SA-CA/certsrv`
3. The Certificate Enrollment web interface should now load securely.