Configure a log analytics workspace to collect Window Server Event log, IIS and performance data.
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/overviewDeploy and configure an Azure Application Gateway for load balancing and website protection.
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
NUMA Problems after In-Place Upgrade 2022 to 2025
We have updated several Hyper-V hosts with AMD Milan processors from Windows 2022 to Windows 2025 using the in-place update method. We are encountering an issue where, after starting about half of the virtual machines, the remaining ones fail to start due to a resource shortage error. The host's RAM is about 70% free. We can only get them to start by enabling the "Allow Spanning" configuration, but this reduces performance, and with so many free resources, this shouldn't be happening. Has anyone else experienced something similar? What has changed in 2025 to cause this issue? The error is: Virtual machine 'R*****2' cannot be started on this server. The virtual machine NUMA topology requirements cannot be satisfied by the server NUMA topology. Try to use the server NUMA topology, or enable NUMA spanning. (Virtual machine ID CA*****3-ED0E-4***4-A****C-E01F*********C4). Event ID: 10002 <EventRecordID>41</EventRecordID> <Correlation /> <Execution ProcessID="5524" ThreadID="8744" /> <Channel>Microsoft-Windows-Hyper-V-Compute-Admin</Channel> <Computer>HOST-JLL</Computer>Hyper-V Virtual TPMs, Certificates, VM Export and Migration
Virtual Trusted Platform Modules (vTPM) in Hyper-V allow you to run guest operating systems, such as Windows 11 or Windows Server 2025 with security features enabled. One of the challenges of vTPMs is that they rely on certificates on the local Hyper-V server. Great if you’re only running the VM with the vTPM on that server, but a possible cause of issues if you want to move that VM to another server. In this article I’ll show you how to manage the certificates that are associated with vTPMs so that you’ll be able to export or move VMs that use them, such as Windows 11 VMs, to any prepared Hyper-V host you manage. When a vTPM is enabled on a Generation 2 virtual machine, Hyper-V automatically generates a pair of self-signed certificates on the host where the VM resides. These certificates are specifically named: "Shielded VM Encryption Certificate (UntrustedGuardian)(ComputerName)" "Shielded VM Signing Certificate (UntrustedGuardian)(ComputerName)". These certificates are stored in a unique local certificate store on the Hyper-V host named "Shielded VM Local Certificates". By default, these certificates are provisioned with a validity period of 10 years. For a vTPM-enabled virtual machine to successfully live migrate and subsequently start on a new Hyper-V host, the "Shielded VM Local Certificates" (both the Encryption and Signing certificates) from the source host must be present and trusted on all potential destination Hyper-V hosts. Exporting vTPM related certificates. You can transfer certificates from one Hyper-V host to another using the following procedure: On the source Hyper-V host, open mmc.exe. From the "File" menu, select "Add/Remove Snap-in..." In the "Add or Remove Snap-ins" window, select "Certificates" and click "Add." Choose "Computer account" and then "Local Computer". Navigate through the console tree to "Certificates (Local Computer) > Personal > Shielded VM Local Certificates". Select both the "Shielded VM Encryption Certificate" and the "Shielded VM Signing Certificate." Right-click the selected certificates, choose "All Tasks," and then click "Export". In the Certificate Export Wizard, on the "Export Private Key" page, select "Yes, export the private key". The certificates are unusable for their intended purpose without their associated private keys. Select "Personal Information Exchange - PKCS #12 (.PFX)" as the export file format. Select "Include all certificates in the certification path if possible". Provide a strong password to protect the PFX file. This password will be required during the import process. To perform this process using the command line, display details of the certificates in the "Shielded VM Local Certificates" store, including their serial numbers. certutil -store "Shielded VM Local Certificates" Use the serial numbers to export each certificate, ensuring the private key is included. Replace <Serial_Number_Encryption_Cert> and <Serial_Number_Signing_Cert> with the actual serial numbers, and "YourSecurePassword" with a strong password: certutil -exportPFX -p "YourSecurePassword" "Shielded VM Local Certificates" <Serial_Number_Encryption_Cert> C:\Temp\VMEncryption.pfx certutil -exportPFX -p "YourSecurePassword" "Shielded VM Local Certificates" <Serial_Number_Signing_Cert> C:\Temp\VMSigning.pfx Importing vTPM related certificates To import these certificates on a Hyper-V host that you want to migrate a vTPM enabled VM to, perform the following steps: Transfer the exported PFX files to all Hyper-V hosts that will serve as potential live migration targets. On each target host, open mmc.exe and add the "Certificates" snap-in for the "Computer account" (Local Computer). Navigate to "Certificates (Local Computer) > Personal." Right-click the "Personal" folder, choose "All Tasks," and then click "Import". Proceed through the Certificate Import Wizard. Ensure the certificates are placed in the "Shielded VM Local Certificates" store. After completing the wizard, verify that both the Encryption and Signing certificates now appear in the "Shielded VM Local Certificates" store on the new host. You can accomplish the same thing using PowerShell with the following command: Import-PfxCertificate -FilePath "C:\Backup\CertificateName.pfx" -CertStoreLocation "Cert:\LocalMachine\Shielded VM Local Certificates" -Password (ConvertTo-SecureString -String "YourPassword" -Force -AsPlainText) Updating vTPM related certificates. Self signed vTPM certificates automatically expire after 10 years. Resetting the key protector for a vTPM-enabled VM in Hyper-V allows you change or renew the underlying certificates (especially if the private key changes). Here are the requirements and considerations around this process: The VM must be in an off state to change security settings or reset the key protector The host must have the appropriate certificates (including private keys) in the "Shielded VM Local Certificates" store. If the private key is missing, the key protector cannot be set or validated. Always back up the VM and existing certificates before resetting the key protector, as this process can make previously encrypted data inaccessible if not performed correctly. The VM must be at a supported configuration version (typically version 7.0 or higher) to support vTPM and key protector features. To save the Current Key Protector: On the source Hyper-V host, retrieve the current Key Protector for the VM and save it to a file. Get-VMKeyProtector -VMName 'VM001' | Out-File '.\VM001.kp' To reset the key protector with a new local key protector: Set-VMKeyProtector -VMName "<VMNAME>" -NewLocalKeyProtector This command instructs Hyper-V to generate a new key protector using the current local certificates. After resetting, enable vTPM if needed: Enable-VMTPM -VMName "<VMNAME>" It is important to note that if an incorrect Key Protector is applied to the VM, it may fail to start. In such cases, the Set-VMKeyProtector -RestoreLastKnownGoodKeyProtector cmdlet can be used to revert to the last known working Key Protector. More information: Set-VMKeyProtector: https://learn.microsoft.com/en-us/powershell/module/hyper-v/set-vmkeyprotectorDeploying Windows Servers in an Azure Availability Set
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
Windows 11 automatically restarting after install security Update — With GPO and WSUS.
Hi everyone, I’m facing a strange behavior with Windows 11 devices that receive updates through WSUS and are fully managed via Group Policy. Here’s the scenario: We have a GPO configured as follows: -Configure Automatic Updates → 4 (Auto download and schedule the install) -Scheduled installation every day at 10:00 -Install during automatic maintenance → disabled -Active Hours configured -Turn off auto-restart for updates during active hours → Enabled -Update deadlines set to 0 (to avoid any forced restart) -No other restart-related policies set in the domain Even with this configuration, after updates are installed, Windows 11 shows the following message: “Your organization manages update settings. We will restart and install this update at X minutes.” And then the device automatically restarts, even when: -a user is logged in -it is outside Active Hours -deadlines are disabled -no-auto-restart is enabled This behavior does not happen on Windows 10 — only on Windows 11.
2025-10 Cumulative Update for Windows Server 2019 (KB5066586) Undoes Update on Reboot
We have a Windows Server 2019 Standard which will not install the 2025-10 Cumulative Update for Windows Server 2019 (KB5066586) update. The installation part goes fine, but when the server is rebooted to finalize the update, it goes into "Undoing changes". Then it reboots again, and I am back where I started. The error code is 0x8007000d. I have done the following to debug this: Ran System File Checker sfc /scannow. No errors found. DISM /Online /Cleanup-Image /ScanHealth. No errors found. Ran Windows Update Troubleshooter. No errors found. Shut down Windows Update services. Renamed SoftwareDistribution and Catroot2 folders. Restarted services. No change. Ran ScanDisk. No errors found. Disabled antivirus. No change. Ran Disk Cleanup and manually deleted additional temp files. No change. Checked Event Viewer. Only error is Event 20 which is a failure of the Windows Update Agent. I am out of ideas. If anyone has some, I would much appreciate the help. I am out of ideas.
SystemSettings. exe on Windows server 2025 crashes after installing Xbox game
I installed the Microsoft App Store on Windows Server and installed Minecraft. However, entering the system>display>graphics tab in the settings will cause the settings to crash.I tested both Bedrock and Java and found this issue. I think any Xbox game in the Microsoft Store should be able to reproduce this issue. + System - Provider [ Name] Application Error [ Guid] {a0e9b465-b939-57d7-b27d-95d8e925ff57} EventID 1000 Version 0 Level 2 Task 100 Opcode 0 Keywords 0x8000000000000000 - TimeCreated [ SystemTime] 2025-12-04T08:55:23.2042032Z EventRecordID 27146 Correlation - Execution [ ProcessID] 10988 [ ThreadID] 20000 Channel Application Computer WIN-JSD290TH0EL - Security [ UserID] S-1-5-21-868965638-952098041-1598110278-1002 - EventData AppName SystemSettings.exe AppVersion 10.0.26100.7019 AppTimeStamp f88449de ModuleName Windows.Gaming.Preview.dll ModuleVersion 10.0.26100.7019 ModuleTimeStamp 8e7f4dfa ExceptionCode c0000005 FaultingOffset 000000000003aadd ProcessId 0x1230 ProcessCreationTime 0x1dc64fbb631455a AppPath C:\Windows\ImmersiveControlPanel\SystemSettings.exe ModulePath C:\Windows\System32\Windows.Gaming.Preview.dll IntegratorReportId f2340132-82be-40d6-9c76-ec8fcbb9d19e PackageFullName windows.immersivecontrolpanel_10.0.8.1000_neutral_neutral_cw5n1h2txyewy PackageRelativeAppId microsoft.windows.immersivecontrolpanel
WINGET is not recognized as a commandlet on win 2k19 server fresh setup
I have setup a new win2k19, I followed the instructions Install-PackageProvider -Name NuGet -Force | Out-Null Install-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery | Out-Null Repair-WinGetPackageManager When I try anu winget command I get winget is not recognized as a commandlet
