Strengthening Azure File Sync security with Managed Identities
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! PierreAzure File Sync: A Practical, Tested Deployment Playbook for ITPros.
This post distills that 10‑minute drill into a step‑by‑step, battle‑tested playbook you can run in your own environment, complete with the “gotchas” that trip folks up, why they happen, and how to avoid them. But first... Why Use Azure File Sync? Hybrid File Services: Cloud Meets On-Prem Azure File Sync lets you centralize your organization’s file shares in Azure Files while keeping the flexibility, performance, and compatibility of your existing Windows file servers. You can keep a full copy of your data locally or use your Windows Server as a fast cache for your Azure file share. This means you get cloud scalability and resilience, but users still enjoy local performance and familiar protocols (SMB, NFS, FTPS). Cloud Tiering: Optimize Storage Costs With cloud tiering, your most frequently accessed files are cached locally, while less-used files are tiered to the cloud. You control how much disk space is used for caching, and tiered files can be recalled on-demand. This enables you to reduce on-prem storage costs without sacrificing user experience. Multi-Site Sync: Global Collaboration Azure File Sync is ideal for distributed organizations. You can provision local Windows Servers in each office, and changes made in one location automatically sync to all others. This simplifies file management and enables faster access for cloud-based apps and services. Business Continuity and Disaster Recovery Azure Files provides resilient, redundant storage, so your local server becomes a disposable cache. If a server fails, you simply add a new server to your Azure File Sync deployment, install the agent, and sync. Your file namespace is downloaded first, so users can get back to work quickly. You can also use warm standby servers or Windows Clustering for even faster recovery. Cloud-Side Backup Note: Azure File Sync is NOT a backup solution.... But, you ca reduce on-prem backup costs by taking centralized backups in the cloud using Azure Backup. Azure file shares have native snapshot capabilities, and Azure Backup can automate scheduling and retention. Restores to the cloud are automatically downloaded to your Windows Servers. Seamless Migration Azure File Sync enables seamless migration of on-prem file data to Azure Files. You can sync existing file servers with Azure Files in the background, moving data without disrupting users or changing access patterns. File structure and permissions remain intact, and apps continue to work as expected. Performance, Security, and Compatibility Recent improvements have boosted Azure File Sync’s performance (up to 200 items/sec), and it now supports Windows Server 2025 and integrates with Windows Admin Center for unified management. Managed identities and Active Directory-based authentication are supported for secure, keyless access. Real-World Use Cases Branch Office Consolidation: Multiple sites, each with its own file server, can be consolidated into a central Azure File Share while maintaining local performance. Business Continuity: Companies facing threats like natural disasters use Azure File Sync to improve server recovery times and ensure uninterrupted work. Collaboration: Organizations leverage Azure File Sync for fast, secure collaboration across locations, reducing latency and simplifying IT management. The Quick Troubleshooting TL;DR Insufficient permissions during cloud endpoint creation → “Role assignment creation failed.” You need Owner or the Azure File Sync Administrator built‑in role; Contributor isn’t enough because the workflow must create role assignments. Region mismatches → Your file share and Storage Sync Service must live in the same region as the deployment target. Wrong identity/account → If you’re signed into the wrong tenant or account mid‑portal (easy to do), the wizard fails when it tries to create the cloud endpoint. Switch to the account that actually has the required role and retry. Agent/version issues → An old agent on your Windows Server will cause registration or enumeration problems. Use the latest agent and consider auto‑upgrade to stay current. Networking & access keys → Ensure access keys are enabled on the storage account and required outbound URLs/ports are allowed. Operational expectations → Azure File Sync runs on a roughly 24‑hour change detection cycle by default; for DR drills or immediate needs, trigger change detection via PowerShell. And remember: File Sync is not a backup. Back up the storage account. End‑to‑End Deployment Playbook 1) Prerequisites (don’t skip these) Storage account supporting SMB 3.1.1 (and required authentication settings), with access keys enabled. Create your Azure file share in the same region as your File Sync deployment. Establish a clear naming convention Windows Server for the File Sync agent (example: Windows Server 2019) Identity & Access: Assign either Owner or Azure File Sync Administrator (a least‑privilege built‑in role designed specifically for this scenario). Contributor will let you get partway (storage account, Storage Sync Service) but will fail when creating the cloud endpoint because it can’t create role assignments. 2) Lay down the cloud side In the Azure portal, create the file share in your chosen storage account/region. Create a Storage Sync Service (ideally in a dedicated resource group), again ensuring the region is correct and supported for your needs. 3) Prep the server On your Windows Server, install the Azure File Sync agent (latest version). During setup, consider enabling auto‑upgrade; if the server is down during a scheduled upgrade, it catches up on the next boot, keeping you current with security and bug fixes. Register the server to your Storage Sync Service (select subscription, resource group, and service). If you have multiple subscriptions, the portal can occasionally hide one, PowerShell is an alternative path if needed. 4) Create the sync topology In the Storage Sync Service, create a Sync Group. This is the container for both cloud and server endpoints. Under normal conditions, the cloud endpoint is created automatically when you select the storage account + file share. If you hit “role assignment creation failed” here, verify your signed‑in account and role. Switching back to the account with the proper role resolves it; you can then recreate the cloud endpoint inside the existing Sync Group. Add a server endpoint: pick the registered server (it must show up in the drop‑down, if it doesn’t, registration isn’t complete) and the local path to sync. 5) Cloud tiering & initial sync behavior Cloud tiering keeps hot data locally and stubs colder data to conserve space. If you disable cloud tiering, you’ll maintain a full local copy of all files. If enabled, set the Volume Free Space Policy (how much free space to preserve on the volume) and review recall policy implications. Choose the initial sync mode, merge existing content or overwrite. 6) Ops, monitoring, and DR notes Change detection cadence is approximately 24 hours. For DR tests or urgent cutovers, run the change detection PowerShell command to accelerate discovery of changes. Backups: Azure File Sync is not a backup. Protect your storage account using your standard backup strategy. Networking: Allow required outbound ports/URLs; validate corporate proxies/firewalls. Monitoring: Turn on the logging and monitoring you need for telemetry and auditing. 7) Performance & cost planning Evaluate Provisioned v2 storage accounts to dial in IOPS/throughput to your business needs and gain better pricing predictability. It’s a smart time to decide this up front during a new deployment. 8) Identity options & least privilege You can also set up managed identities for File Sync to reduce reliance on user principals. If you do use user accounts, ensure they carry the Azure File Sync Administrator role or Owner. Keep the agent updated; it’s basic hygiene that prevents a surprising number of issues. 9) Quotas & capacity troubleshooting Hitting quota problems? Revisit your Volume Free Space Policy (cloud tiering) and recall policy. Sometimes the answer is simply adding a disk or increasing its size as data patterns evolve. Key Benefits for Infra Teams Hybrid file services without forklift: Keep your existing Windows file servers while centralizing data in Azure Files, adding elasticity and resiliency with minimal disruption . Right‑sized capacity on‑prem: Cloud tiering preserves local performance for hot data and trims cold data footprint to stretch on‑prem storage further. Operational predictability: Built‑in auto‑upgrade for the agent and a known change detection cycle, with the ability to force change detection for DR/failover testing. Least‑privilege by design: The Azure File Sync Administrator role gives just the rights needed to deploy/manage sync without over‑provisioning. Performance on your terms: Option to choose Provisioned v2 to meet IOPS/throughput targets and bring cost clarity. Available Resources What is Azure File Sync?: https://learn.microsoft.com/azure/storage/file-sync/file-sync-introduction Azure Files: More performance, more control, more value for your file data: https://azure.microsoft.com/blog/azure-files-more-performance-more-control-more-value-for-your-file-data/ Azure File Sync Deployment Guide: https://learn.microsoft.com/azure/storage/file-sync/file-sync-deployment-guide Troubleshooting documentation : https://learn.microsoft.com/troubleshoot/azure/azure-storage/files/file-sync/file-sync-troubleshoot Azure File Sync “copilot” troubleshooting experience: https://learn.microsoft.com/azure/copilot/improve-storage-accounts Next Steps (Run This in Your Lab) Verify roles: On the target subscription/resource group, grant Azure File Sync Administrator (or Owner) to your deployment identity. Confirm in Access control (IAM). Create the file share in the same region as your Storage Sync Service. Enable access keys on the storage account. Install the latest agent on your Windows Server; enable auto‑upgrade. Register the server to your Storage Sync Service. Create a Sync Group, then the cloud endpoint. If you see a role assignment error, re‑check your signed‑in account/role and retry. Add the server endpoint with the right path, decide on cloud tiering, set Volume Free Space Policy, and choose initial sync behavior (merge vs overwrite). Open required egress on your network devices, enable monitoring/logging, and plan backup for the storage account. Optionally evaluate Provisioned v2 for throughput/IOPS and predictable pricing before moving to production. If you’ve got a scenario that behaves differently in the field, I want to hear about it. Drop me a note with what you tried, what failed, and where in the flow it happened. Cheers! PierreUnlocking Private IP for Azure Application Gateway: Security, Compliance, and Practical Deployment
If you’re responsible for securing, scaling, and optimizing cloud infrastructure, this update is for you. Based on my recent conversation with Vyshnavi Namani, Product Manager on the Azure Networking team, I’ll break down what private IP means for your environment, why it matters, and how to get started. Why Private IP for Application Gateway? Application Gateway has long been the go-to Layer 7 load balancer for web traffic in Azure. It manages, routes, and secures requests to your backend resources, offering SSL offloading and integrated Web Application Firewall (WAF) capabilities. But until now, public IPs were the norm, meaning exposure to the internet and the need for extra security layers. With Private IP, your Application Gateway can be deployed entirely within your virtual network (VNet), isolated from public internet access. This is a huge win for organizations with strict security, compliance, or policy requirements. Now, your traffic stays internal, protected by Azure’s security layers, and only accessible to authorized entities within your ecosystem. Key Benefits for ITPRO 🔒 No Public Exposure With a private-only Application Gateway, no public IP is assigned. The gateway is accessible only via internal networks, eliminating any direct exposure to the public internet. This removes a major attack vector by keeping traffic entirely within your trusted network boundaries. 📌 Granular Network Control Private IP mode grants full control over network policies. Strict NSG rules can be applied (no special exceptions needed for Azure management traffic) and custom route tables can be used (including a 0.0.0.0/0 route to force outbound traffic through on-premises or appliance-based security checkpoints). ☑️ Compliance Alignment Internal-only gateways help meet enterprise compliance and data governance requirements. Sensitive applications remain isolated within private networks, aiding data residency and preventing unintended data exfiltration. Organizations with “no internet exposure” policies can now include Application Gateway without exception. Architectural Considerations and Deployment Prerequisites To deploy Azure Application Gateway with Private IP, you should plan for the following: SKU & Feature Enablement: Use the v2 SKU (Standard_v2 or WAF_v2). The Private IP feature is GA but may require opt-in via the EnableApplicationGatewayNetworkIsolation flag in Azure Portal, CLI, or PowerShell. Dedicated Subnet: Deploy the gateway in a dedicated subnet (no other resources allowed). Recommended size: /24 for v2. This enables clean NSG and route table configurations. NSG Configuration: Inbound: Allow AzureLoadBalancer for health probes and internal client IPs on required ports. Outbound: Allow only necessary internal destinations; apply a DenyAll rule to block internet egress. User-Defined Routes (UDRs): Optional but recommended for forced tunneling. Set 0.0.0.0/0 to route traffic through an NVA, Azure Firewall, or ExpressRoute gateway. Client Connectivity: Ensure internal clients (VMs, App Services, on-prem users via VPN/ExpressRoute) can reach the gateway’s private IP. Use Private DNS or custom DNS zones for name resolution. Outbound Dependencies: For services like Key Vault or telemetry, use Private Link or NAT Gateway if internet access is required. Plan NSG and UDRs accordingly. Management Access: Admins must be on the VNet or connected network to test or manage the gateway. Azure handles control-plane traffic internally via a management NIC. Migration Notes: Existing gateways may require redeployment to switch to private-only mode. Feature registration must be active before provisioning. Practical Scenarios Here are several practical scenarios where deploying Azure Application Gateway with Private IP is especially beneficial: 🔐 Internal-Only Web Applications Organizations hosting intranet portals, HR systems, or internal dashboards can use Private IP to ensure these apps are only accessible from within the corporate network—via VPN, ExpressRoute, or peered VNets. 🏥 Regulated Industries (Healthcare, Finance, Government) Workloads that handle sensitive data (e.g., patient records, financial transactions) often require strict network isolation. Private IP ensures traffic never touches the public internet, supporting compliance with HIPAA, PCI-DSS, or government data residency mandates. 🧪 Dev/Test Environments Development teams can deploy isolated environments for testing without exposing them externally. This reduces risk and avoids accidental data leaks during early-stage development. 🌐 Hybrid Network Architectures In hybrid setups where on-prem systems interact with Azure-hosted services, Private IP gateways can route traffic securely through ExpressRoute or VPN, maintaining internal-only access and enabling centralized inspection via NVAs. 🛡️ Zero Trust Architectures Private IP supports zero trust principles by enforcing least-privilege access, denying internet egress, and requiring explicit NSG rules for all traffic—ideal for organizations implementing segmented, policy-driven networks. Resources https://docs.microsoft.com/azure/application-gateway/ https://learn.microsoft.com/azure/application-gateway/configuration-overview https://learn.microsoft.com/azure/virtual-network/network-security-groups-overview https://learn.microsoft.com/azure/virtual-network/virtual-network-peering-overview Next Steps Evaluate Your Workloads: Identify apps and services that require internal-only access. Plan Migration: Map out your VNets, subnets, and NSGs for a smooth transition. Enable Private IP Feature: Register and deploy in your Azure subscription. Test Security: Validate that only intended traffic flows through your gateway. Final Thoughts Private IP for Azure Application Gateway is an improvement for secure, compliant, and efficient cloud networking. If you’re an ITPRO managing infrastructure, now’s the time check out this feature and level up your Azure architecture. Have questions or want to share your experience? Drop a comment below. Cheers! PierreShielded VM Template Creation in a Hyper-V Guarded Fabric
To set up a shielded virtual machine template on a Hyper-V guarded fabric, you need to prepare a secure environment (Host Guardian Service, guarded hosts) and then create a BitLocker-protected, signed template disk. This document assumes that all Windows Server instances used are running Windows Server 2022 or Windows Server 2025. Prerequisites and Environment Setup Host Guardian Service (HGS): Deploy an HGS cluster (typically 3 nodes for high availability) in a separate Active Directory forest dedicated to HGS. For production, HGS should run on physical (or highly secured) servers, ideally as a three-node cluster. Ensure the HGS servers have the Host Guardian Service role installed and are up to date with software updates. Attestation Mode: TPM-Based: Ensure that HGS is configured for TPM-trusted attestation. In TPM mode, HGS uses each host’s TPM 2.0 identity (EKpub) and measured boot sequence to verify the host’s health and authenticity. This requires capturing each Hyper-V host’s TPM identifier and establishing a security baseline: TPM 2.0 and Boot Measurements: On each Hyper-V host, retrieve the TPM’s public endorsement key (EKpub) and add it to the HGS trust store (e.g. using Get-PlatformIdentifier on the host and Add-HgsAttestationTpmHost on HGS). HGS will also require a TPM baseline (PCR measurements of the host’s firmware/boot components) and a Code Integrity (CI) policy defining allowed binaries. Generate these from a reference host and add them to HGS so that only hosts booting with the approved firmware and software can attest successfully. Host Requirements: Each guarded host (Hyper-V host) must meet hardware/OS requirements for TPM attestation. This includes TPM 2.0, UEFI 2.3.1+ firmware with Secure Boot enabled, and support for IOMMU/SLAT (for virtualization-based security). On each host, enable the Hyper-V role and install the Host Guardian Hyper-V Support feature (available in Datacenter edition). This feature enables virtualization-based protection of code integrity (ensuring the host hypervisor only runs trusted code), which is required for TPM attestation. (Test this configuration in a lab first as VBS/CI can affect some drivers). Guarded Fabric Configuration: Join Hyper-V hosts to the fabric domain and configure networking so that guarded hosts can reach the HGS servers (set up DNS or DNS forwarding between the fabric domain and HGS domain). After setting up HGS and adding host attestation data, configure each Hyper-V host as a guarded host by pointing it to the HGS cluster for attestation and key retrieval (using Set-HgsClientConfiguration to specify the HGS attestation and key protection URLs and any required certificates). Once a host attests successfully, it becomes an authorized guarded host able to run shielded VMs. HGS will release the necessary decryption keys only to those hosts that pass health attestation. Step 1: Create and Configure the Template VM (Gen 2) Prepare a Generation 2 VM: On a Hyper-V host (it can be a regular host or even a non-guarded host for template creation), create a new Generation 2 virtual machine. Generation 2 with UEFI is required for Secure Boot and virtual TPM support. Attach a blank virtual hard disk (VHDX) for the OS. Install Windows Server on this VM using standard installation media. Partition and File System Requirements: When installing the OS on the template VM, ensure the VHDX is initialized with a GUID Partition Table (GPT) and that the Windows setup creates the necessary partitions: there should be at least a small System/EFI boot partition (unencrypted) and the main OS partition (which will later be BitLocker-encrypted). The disk must be a basic disk (not dynamic within the guest OS) and formatted with NTFS to support BitLocker. Using the default Windows setup on a blank drive typically meets these requirements (the installer will create the EFI and OS partitions automatically on a GPT disk). Configure the OS: Boot the VM and perform any baseline configuration needed. Do not join this VM to any domain and avoid putting sensitive data on it as it should be a generic base image. Apply the latest Windows Updates and install any required drivers or software that should be part of the template OS (e.g. common management agents). Ensuring the template OS is fully updated is important for a reliable shielding process. Enable Remote Management: Because shielded VMs can only be managed remotely (no console access), consider configuring the template to enable Remote Desktop and/or PowerShell WinRM, and ensure the firewall is configured accordingly. You may also install roles/features that many VMs will need. However, do not configure a static IP or unique machine-specific settings in this template as those will be supplied via an answer file during provisioning. Step 2: Generalize the VM with Sysprep Run Sysprep: In the VM, open an elevated Command Prompt and run: C:\Windows\System32\Sysprep\Sysprep.exe /oobe /generalize /shutdown Choose “Enter System Out-of-Box Experience (OOBE)”, check “Generalize”, and set Shutdown option to “Shutdown” if using the GUI. This strips out machine-specific details and prepares the OS for first-boot specialization. The VM will shut down upon completion. Do Not Boot After Sysprep: Leave the VM off after it shuts down. The OS on the VHDX is now in a generalized state. Do not boot this VM again (doing so will boot into OOBE and break its generalized state). At this point you have a prepared OS disk (the VHDX) ready for sealing. (Optional) Backup the VHDX: It’s a good idea to make a copy of the sysprep’ed VHDX at this stage. After the next step (sealing the template), the disk will be BitLocker-encrypted and cannot be easily modified. Keeping an unencrypted copy allows you to easily update the template image in the future if needed. Step 3: Protect and Seal the Template Disk (Shielded Template Wizard) Next, seal the template VM’s OS disk using the Shielded VM Template Disk Creation process. This will encrypt the disk (preparing it for BitLocker) and produce a signed catalog so that the disk’s integrity can be verified later. Install Shielded VM Tools: On a machine with GUI (this can be a management server or even Windows 11 with RSAT), install the Shielded VM Tools component. On Windows Server, use PowerShell: Install-WindowsFeature RSAT-Shielded-VM-Tools -IncludeAllSubFeature (and reboot if prompted). This provides the Template Disk Wizard (TemplateDiskWizard.exe) and PowerShell cmdlets like Protect-TemplateDisk. Obtain a Signing Certificate: Acquire a certificate to sign the template disk’s Volume Signature Catalog (VSC). For production, use a certificate issued by a trusted CA that both the fabric administrators and tenants trust (e.g. an internal PKI or a certificate from a mutually trusted authority). The certificate’s public key will be referenced later by tenants to trust this template. (For a lab or demo, you can use a self-signed cert, but this is not recommended for production.) Import the certificate into the local machine’s certificate store if it’s not already present. Launch the Template Disk Wizard: Open Template Disk Wizard (found in Administrative Tools after installing RSAT, or run TemplateDiskWizard.exe). This wizard will guide you through protecting the VHDX: Certificate: Select the signing certificate obtained in the previous step. This certificate will be used to sign the template’s catalog. Virtual Disk: Browse to and select the generalized VHDX from Step 2 (the sysprep’ed OS disk). Signature Catalog Info: Provide a friendly name and version for this template disk (e.g. Name: “WS2025-ShieldedTemplate”, Version: 1.0.0.0). These labels help identify the disk and version to tenants. Proceed to the final page and Generate. The wizard will now: o Enable BitLocker on the OS volume of the VHDX and store the BitLocker metadata on the disk (but it does not encrypt the volume yet as encryption will finalize when a VM instance is provisioned with this disk). o Compute a cryptographic hash of the disk and create a Volume Signature Catalog (VSC) entry (which is stored in the disk’s metadata) signed with your certificate. This ensures the disk’s integrity can be verified; only disks matching this signed hash will be recognized as this template. Wait for the wizard to finish (it may take some time to initialize BitLocker and sign the catalog, depending on disk size). Click Close when done. The VHDX is now a sealed template disk. It’s marked internally as a shielded template and cannot be used to boot a normal VM without going through the shielded provisioning process (attempting to boot it in an unshielded way will likely cause a blue screen). The disk’s OS volume is still largely unencrypted at rest (encryption will complete when a VM is created), but it’s protected by BitLocker keys that will be released only to an authorized host via HGS. Extract the VSC File (for Tenant Use): It’s recommended to extract the template’s Volume Signature Catalog to a separate file. This .vsc file contains the disk’s identity (hash, name, version) and the signing certificate info. Tenants will use it to authorize this template in their shielding data. Use PowerShell on the RSAT machine: Save-VolumeSignatureCatalog -TemplateDiskPath "C:\path\WS2022-ShieldedTemplate.vhdx" -VolumeSignatureCatalogPath "C:\path\WS2022-ShieldedTemplate.vsc" This saves the .vsc file separately. Share this .vsc with the VM owners (tenants) or have it available for the shielding data file creation in the next step. Alternatively to the wizard, you can use PowerShell: after installing RSAT, run Protect-TemplateDisk -Path <VHDX> -Certificate <Cert> -TemplateName "<Name>" -Version <X.Y.Z.W> to seal the disk in one step. The wizard and PowerShell achieve the same result. Step 4: Create the Shielding Data File (PDK) A shielding data file (with extension .pdk) contains the sensitive configuration and keys required to deploy a shielded VM from the template. This includes the local administrator password, domain join credentials, RDP certificate, and the list of guardians (trust authorities) and template disk signatures the VM is allowed to use. For security, the shielding data is created by the tenant or VM owner on a secure machine outside the fabric, and is encrypted so that fabric admins cannot read the contents. Prerequisites for Shielding Data: Obtain the Volume Signature Catalog (.vsc) file for the template disk (from Step 3) to authorize that template. If the VM should use a trusted RDP certificate (to avoid man-in-the-middle when connecting via RDP), obtain a certificate (e.g. a wildcard certificate from the tenant’s CA) to include. This is optional; if the VM will join a domain and get a computer certificate or if you’re just testing, you may skip a custom RDP certificate. Prepare an unattend answer file or have the information needed to create one (admin password, timezone, product key, etc.). Use the PowerShell function New-ShieldingDataAnswerFile to generate a proper unattend XML for shielded VMs. The unattend will configure the VM’s OS on first boot (e.g. set the Administrator password, optionally join a domain, install roles, enable RDP, etc.). Ensure the unattend enables remote management (e.g. turn on RDP and firewall rules, or enable WinRM) because console access is not available for shielded VMs. Also, do not hardcode any per-VM values in the unattend that should differ for each instance; use placeholders or plan to supply those at deployment time. Creating the .PDK file: On a secure workstation (not on a guarded host) with RSAT Shielded VM Tools installed, launch the Shielding Data File Wizard (ShieldingDataFileWizard.exe). This tool will collect the needed info and produce an encrypted PDK file. Owner and Guardian Keys: First, set up the guardians. “Guardians” are certificates that represent who owns the VM and which fabrics (HGS instances) are authorized to run it. Typically: The Owner Guardian is a key pair that the tenant/VM owner possesses (the private key stays with the tenant). Create an Owner guardian (if not already) via the wizard’s Manage Local Guardians > Create option. This generates a key pair on your machine. Give it a name (e.g. “TenantOwner”). The Fabric Guardian(s) correspond to the HGS of the hosting fabric. Import the HGS guardian metadata file provided by the hoster (this is an XML with the HGS public key, exported via Export-HgsGuardian on the HGS server). In the wizard, use Manage Local Guardians > Import to add the hoster’s guardian(s) (for example, “Contoso HGS”). For production, you might import multiple datacenter guardians if the VM can run in multiple cloud regions, include each authorized fabric’s guardian. After adding, select all the guardian(s) that represent fabrics where this VM is allowed to run. Also select your Owner guardian (the wizard may list it separately). This establishes that the VM will be owned by your key and can only run on hosts approved by those fabric guardians. Template Disk (VSC) Authorization: The wizard will prompt to add Volume ID Qualifiers or trusted template disks. Click Add and import the .vsc file corresponding to the template disk prepared in Step 3. You can usually choose whether the shielding data trusts only that specific version of the template or future versions as well (Equal vs. GreaterOrEqual version matching). Select the appropriate option based on whether you want to allow updates to the template without regenerating the PDK. This step ensures the secrets in the PDK will only unlock when that specific signed template disk is used. Unattend and Certificates: Provide the answer file (Unattend.xml) for the VM’s specialization. If you created one with New-ShieldingDataAnswerFile, load it here. Otherwise, the wizard may have a simplified interface for common settings (depending on version, it may prompt for admin password, domain join info, etc.). Also, if using a custom RDP certificate, import it at this stage (so the VM will install that cert for remote desktop). Create the PDK: Specify an output file name for the shielding data (e.g., MyVMShieldingData.pdk) and finish the wizard. It will create the .pdk file, encrypting all the provided data. The Owner guardian’s private key is used to encrypt secrets, and the Fabric guardian’s public key ensures that HGS (holding the corresponding private key) is needed to unlock the file. The PDK is now ready to use for provisioning shielded VMs. (You can also create PDKs via PowerShell with New-ShieldingDataFile for automation.) Note the PDK is encrypted such that only the combination of the owner’s key and an authorized fabric’s HGS can decrypt it. Fabric admins cannot read sensitive contents of the PDK, and an unauthorized or untrusted host cannot launch a VM using it. Keep the PDK file safe, as it contains the keys that will configure your VM. Step 5: (Optional) Prepare a Shielding Helper VHDX In some scenarios, especially if you need to convert an existing VM into a shielded VM or if you are not using SCVMM for provisioning, a Shielding Helper disk is used. The Shielding Helper is a special VHDX containing a minimal OS that helps encrypt the template disk and inject the unattend inside a VM without exposing secrets to the host. SCVMM can automate this, but if you need to do it manually or for existing VMs, prepare the helper disk as follows: Create a Helper VM: On a Hyper-V host (not necessarily guarded), create a Gen 2 VM with a new blank VHDX (do not reuse the template disk to avoid duplicate disk IDs). Install a supported OS (Windows Server 2016 or higher, a Server Core installation is sufficient) on this VM. This VM will be temporary and its VHD will become the helper disk. Ensure you can log into it (set a password, etc.), then shut it down. Initialize the Helper Disk: On a Hyper-V host with RSAT Shielded VM Tools, run the PowerShell cmdlet: Initialize-VMShieldingHelperVHD -Path "C:\VMs\ShieldingHelper.vhdx" This command should point to the VHDX of the helper VM. This injects the necessary provisioning agent and settings into the VHDX to make it a shielding helper disk. The VHDX is modified in-place (consider making a backup beforehand). Do Not Boot the Helper VM Again: After initialization, do not start the helper VM from Step 1. The VHDX is now a specialized helper disk. You can discard the VM’s configuration. Only the VHDX file is needed going forward. Reuse for Conversions / Non-VMM Deployments: For manually shielding an existing VM, you would attach this helper VHDX to the VM and use PowerShell (e.g. ConvertTo-ShieldedVM or a script) to encrypt the VM’s OS disk using the helper. The helper boots in place of the VM’s OS, uses the PDK to apply BitLocker and the unattend to the OS disk, then shuts down. The VM is then switched to boot from its now-encrypted OS disk with a virtual TPM. (Note: Each initialized helper VHDX is typically one-time-use for a given VM; if you need to shield multiple VMs manually, create or copy a fresh helper disk for each to avoid BitLocker key reuse). Step 6: Prepare the Template Disk and PDK on the Host Copy the VHDX and PDK: Transfer the sealed template .vhdx and the .pdk file to the Hyper‑V host (or a cluster shared volume if the host is part of a Hyper‑V cluster). For example, place them in C:\ShieldedVM\templates\ on the host. This ensures the host can read the files during VM provisioning. Verify File Trust: (Optional) Double-check that the template disk’s signature is recognized by the tenant’s shielding data. The template’s .vsc file (volume signature catalog) should have been used when creating the PDK, so the PDK will “trust” that specific template hash. Also verify that the HGS guardian in the PDK matches your fabric’s HGS public key. These must align, or the VM provisioning will be rejected by HGS. Note: The PDK is encrypted and cannot be opened by the fabric admin as it’s designed so that only HGS (and the VM owner) can decrypt its contents. The host will use it as-is during provisioning. Make sure you do not modify or expose the PDK’s contents. PowerShell to finalize the shielded VM setup. Set up the key protector on the existing VM. For a clean process, you can use New-ShieldedVM on the guarded host: New-ShieldedVM -Name "Finance-App1" ` -TemplateDiskPath "C:\ShieldedVM\Templates\WS2025-ShieldedTemplate.vhdx" ` -ShieldingDataFilePath "C:\ShieldedVM\Templates\TenantShieldingData.pdk" -Wait This single command will create a new VM named “Finance-App1” using the specified template disk and shielding data file. It automatically configures the VM’s security settings: attaches a vTPM, injects the Key Protector (from the PDK) into the VM’s security settings, and attaches the shielding helper disk to boot and apply the unattend. The -Wait flag tells PowerShell to wait until provisioning is complete before returning. Note: Ensure the VM name is unique in your Hyper-V inventory. The New-ShieldedVM cmdlet requires the GuardedFabricTools module and will fail if the host isn’t a guarded host or if guardians are not properly configured. It uses the host’s configured HGS connection to request keys when provisioning. If your shielding data’s unattend file included placeholders for unique settings (for example, a static IP address, custom computer name, etc.), you can supply those values with the -SpecializationValues parameter on New-ShieldedVM. This takes a hashtable mapping the placeholder keys to actual values. For instance: $specVals = @{ "@ComputerName@" = "Finance-App1" "@IP4Addr-1@" = "10.0.0.50/24" "@Gateway-1@" = "10.0.0.1" } New-ShieldedVM -Name "Finance-App1" -TemplateDiskPath C:\ShieldedVM\Templates\WS2025-ShieldedTemplate.vhdx ` -ShieldingDataFilePath C:\ShieldedVM\Templates\TenantShieldingData.pdk -SpecializationValues $specVals -Wait This would replace placeholders like @ComputerName@ in the unattend with “Finance-App1”, etc. Use this only if the unattend (inside the PDK) was set up with such tokens. In many cases, the shielding data might already contain all required settings, so specialization values are optional. Step 7: Monitoring Provisioning and First Boot Once the shielded VM deployment is initiated (either by WAC or PowerShell), the provisioning process begins on the guarded host. This process is automatic and involves several stages behind the scenes: The host registers a new Key Protector for the VM (containing the VM’s BitLocker key, sealed to the VM’s virtual TPM and the fabric’s HGS). It then contacts the HGS. HGS verifies the host’s health (attestation) and, if the host is authorized and healthy, releases the key protector to the host. The VM is initially started using a temporary shielding helper OS (often a small utility VHD). This helper OS boots inside the new VM and uses the unattend file from the PDK to configure the main OS disk. It injects the administrator password, domain or network settings, enables RDP/WinRM, and then finalizes BitLocker encryption of the VM’s OS volume using the VM’s vTPM. This encryption locks the OS disk so it can only be decrypted by that VM’s vTPM (which in turn is only released by HGS to trusted hosts). When specialization is complete, the VM will shut down automatically. This shutdown is a signal that provisioning is finished. The helper disk is then automatically detached, and the VM is now fully shielded. As an administrator, you should monitor this process to know when the VM is ready: In Windows Admin Center’s VM list, you may see the VM’s state change (it might show as “Off” or “Stopped” after the provisioning shutdown). You may not get a detailed status in WAC during provisioning. Refresh the view to see if the VM has turned off after a few minutes. Using PowerShell, you can query the status: run Get-ShieldedVMProvisioningStatus -VMName <Name> on the guarded host to check progress. This cmdlet shows stages or any errors during provisioning. (If the provisioning fails, the cmdlet or Hyper-V event logs will show error details. Common causes include guardian mismatches or unattend errors.) Once the VM has shut down indicating success, you can proceed to start it normally. In WAC, select the VM and click Start (or use Start-VM -Name <Name> in PowerShell). The VM will boot its now-configured OS. On first boot, it will go through final OS specialization (the standard Sysprep specialize/pass completion). Step 8: Post-Deployment Access and Management Your new VM is now running as a shielded VM. Key points for management: Limited Host Access: Because it’s shielded, the Hyper-V host admin cannot view the VM’s console or use PowerShell Direct on this VM. In WAC (or Hyper-V Manager), if you try to connect to the VM’s console, it will be blocked (you might see a black screen or an error). This is expected as shielded VMs are isolated from host interference. All management must be done through the network. Accessing the VM: Use the credentials set in the unattend/PDK to log on to the VM via Remote Desktop (RDP) or another remote method (e.g. PowerShell Remoting). Ensure the VM is connected to a network and has an IP (via DHCP or the unattend’s settings). The unattend should have enabled RDP or WinRM as configured earlier. For example, if the PDK joined the VM to a domain, you can RDP with a domain account; if not, use the local Administrator and the password from the shielding data. Verify Shielded Status: In WAC’s inventory, the VM should show as a generation 2 VM with a TPM. You can confirm it’s shielded by checking VM’s Security settings (they will show that the VM is using a Key Protector and is shielded, often the UI will have those options greyed-out/enforced). You can also use PowerShell: Get-VMSecurity -VMName <Name>. It should show Shielded: True and list the Key Protector ID, etc. Routine Management: You can manage the VM (start/stop/reset) in WAC like any other VM. Backups, replication, etc., should be done with shielded VM-compatible methods (e.g. use Hyper-V checkpoints or backup APIs as the VM’s disks are encrypted but manageable through Hyper-V). Fabric admins cannot alter the VM’s settings that would compromise its security (for instance, you cannot remove the vTPM or turn off shielding without the VM owner’s consent). Further Reading: Install HGS in a new forest | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-install-hgs-default Guarded fabric and shielded VMs | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-and-shielded-vms-top-node Capture TPM-mode information required by HGS | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tpm-trusted-attestation-capturing-hardware Guarded host prerequisites | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-guarded-host-prerequisites Review HGS prerequisites | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-prepare-for-hgs Create a Windows shielded VM template disk | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-create-a-shielded-vm-template Shielded VMs for tenants - Creating shielding data to define a shielded VM | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tenant-creates-shielding-data Shielded VMs - Preparing a VM Shielding Helper VHD | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-vm-shielding-helper-vhdUsing OSConfig to manage Windows Server 2025 security baselines
OSConfig is a security configuration and compliance management tool introduced as a PowerShell module for use with Windows Server 2025. It enables you to enforce security baselines, automate compliance, and prevent configuration drift on Windows Server 2025 computers. OSConfig has the following requirements: Windows Server 2025 (OSConfig is not supported on earlier versions) PowerShell version 5.1 or higher Administrator privileges OSConfig is available as a module from the PowerShell Gallery. You install it using the following command Install-Module -Name Microsoft.OSConfig -Scope AllUsers -Repository PSGallery -Force If prompted to install or update the NuGet provider, type Y and press Enter. You can verify that the module is installed with: Get-Module -ListAvailable -Name Microsoft.OSConfig You can ensure that you have an up-to-date version of the module and the baselines by running the following command: Update-Module -Name Microsoft.OSConfig To check which OSConfig cmdlets are available, run: Get-Command -Module Microsoft.OSConfig Applying Security Baselines OSConfig includes predefined security baselines tailored for different server roles: Domain Controller, Member Server, and Workgroup Member. These baselines enforce over 300 security settings, such as TLS 1.2+, SMB 3.0+, credential protections, and more. Server Role Command Domain Controller Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/DomainController -Default Member Server Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer -Default Workgroup Member Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/WorkgroupMember -Default Secured Core Set-OSConfigDesiredConfiguration -Scenario SecuredCore -Default Defender Antivirus Set-OSConfigDesiredConfiguration -Scenario Defender/Antivirus -Default To view compliance from a PowerShell session, run the following command, specifying the appropriate baseline: Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer | ft Name, @{ Name = "Status"; Expression={$_.Compliance.Status} }, @{ Name = "Reason"; Expression={$_.Compliance.Reason} } -AutoSize -Wrap Whilst this PowerShell output gets the job done, you might find it easier to parse the report by using Windows Admin Center. You can access the security baseline compliance report by connecting to the server you’ve configured using OSConfig by selecting the Security Baseline tab of the Security blade. Another feature of OSConfig is drift control. It helps ensure that the system starts and remains in a known good security state. When you turn it on, OSConfig automatically corrects any system changes that deviate from the desired state. OSConfig makes the correction through a refresh task. This task runs every 4 hours by default which you can verify with the Get-OSConfigDriftControl cmdlet. You can reset how often drift control runs using the Set-OSConfigDriftControl cmdlet. For example, to set it to 45 minutes run the command: Set-OSConfigDriftControl -RefreshPeriod 45 Rather than just using the default included baselines, you can also customize baselines to suit your organizational needs. That’s more detail that I want to cover here, but if you want to know more, check out the information available in the GitHub repo associated with OSConfig. Find out more about OSConfig at the following links: https://learn.microsoft.com/en-us/windows-server/security/osconfig/osconfig-overview https://learn.microsoft.com/en-us/windows-server/security/osconfig/osconfig-how-to-configure-security-baselinesStep-by-Step Guide: How to setup conditional access reauthentication policy for PIM?
Once a user is authenticated through Entra ID, they remain signed in as long as the session is valid—even if they close and reopen the browser. However, in scenarios involving sensitive tasks or high-risk operations, it’s beneficial to require reauthentication. Forcing a fresh sign-in adds an extra layer of security by reducing the risk of session hijacking and token replay attacks. It also prevents attackers from maintaining persistence across services and devices, limiting their ability to move laterally within the environment. A common example is when a user elevates their permissions to a higher-privileged role using Entra ID Privileged Identity Management (PIM). By leveraging Conditional Access reauthentication policies, we can require users to reauthenticate before gaining privileged access—adding an important layer of security. In this blog post, I’ll Walk through how to configure this policy step by step. High-Level Configuration Tasks The following steps outline the configuration process for enforcing reauthentication using Conditional Access and Privileged Identity Management (PIM): Create an Authentication Context in Conditional Access. Update Entra ID Privileged Identity Management (PIM) to associate the relevant role with the Authentication Context. Create a Conditional Access policy that enforces reauthentication based on the defined context. Step 1: Create an Authentication Context Authentication Context allows you to define a label that represents a specific authentication requirement (e.g., MFA, compliant device, reauthentication). This label can be referenced in PIM configurations and Conditional Access policies. To create an Authentication Context: Sign in to the Microsoft Entra admin center. Navigate to Protection > Conditional Access > Authentication context. Click + New authentication context. 4.In the creation pane, provide a Name and Description for the context. 5. Click Save to create the context. Step 2: Update PIM Configuration In this setup, the Security Administrator role is already managed via Privileged Identity Management (PIM). For more information on configuring PIM roles, refer to the official documentation: 🔗 Configure Microsoft Entra PIM The next step is to associate the previously created Authentication Context with the PIM role to enforce conditional access policies during role activation. To update PIM with Authentication Context: Sign in to the Microsoft Entra admin center. Navigate to Identity Governance > Privileged Identity Management, and select the role you want to modify (in this example, Security Administrator). Click on Settings. 4. In the Role settings pane, select Edit. 5. Under the On activation, require section, choose Microsoft Entra Conditional Access authentication context. 6. From the dropdown menu, select the Authentication Context you created earlier. 7. Click Update to save and apply the changes. Step 3: Create a Conditional Access Policy to Enforce Reauthentication The final step is to create a Conditional Access policy that forces reauthentication whenever a user activates a privileged role protected by the authentication context. To create the Conditional Access policy: Sign in to the Microsoft Entra admin center. Navigate to Protection > Conditional Access. Click + Create new policy. In the policy creation pane: o Provide a meaningful name for the policy. o Under Users, select the users or groups this policy should apply to. o Under Target resources, choose Authentication context, and then select the context you created earlier. Go to the Session section and configure Sign-in frequency to Every time. This setting ensures that users are prompted for reauthentication each time the context is invoked. Enable the policy by toggling On, then click Create to finalize it. Testing the Configuration With all the required configurations in place, the next step is to test the Conditional Access reauthentication policy in action. I signed in to the Azure portal using a user account that is eligible for the Security Administrator role. Navigating to PIM > My roles > Eligible assignments, I located the Security Administrator role and clicked Activate. At this stage, a message appears on the activation page: "A Conditional Access policy is enabled and may require additional verification. Click to continue." No further action can be taken on this screen until this prompt is addressed, so I clicked the link as instructed. As expected, I was prompted to reauthenticate, in line with the policy we configured. After successfully reauthenticating, I was redirected back to the role activation page, where I could now enter the required justification and additional details. Clicking Activate completed the role activation process successfully. ✅ This confirms that the Conditional Access policy enforcing reauthentication is working as intended for PIM role activation. This concludes the blog post. I hope it has provided you with a clear understanding of how to configure and enforce Conditional Access reauthentication for Privileged Identity Management roles using Authentication Context.Understanding the Windows Server Event Log
What is the Event Log? Each event log records events that happen on the Windows Server computer. Examining the events in these logs can help you trace activity, respond to events, and keep your systems secure. Configuring these logs properly can help you manage the logs more efficiently and use the information that they provide more effectively. Windows Server saves event log files as XML files that can be reported on and managed as part of a collective reporting schema. There are several additional log providers and categories that you can monitor. Event Viewer is the tool most people use to interact with their event logs. Event viewer tracks information in a number of logs termed the “Windows Logs”, which include the application, security, setup, system, and forwarded event logs. Application. The application log records events logged by applications and services running on the system. Events in this Windows log are classified as error, warning, or information, depending on the severity of the event. An error is a significant problem, such as loss of data. A warning is an event that is not necessarily significant but might indicate a possible future problem. An information event describes the successful operation of a program, driver, or service. Security. This Windows log contains security-related events, which are called "audit events," and are described as successful or failed, depending on the event, such as whether a user's attempt to log on to Windows was successful. Setup. This Windows log records events related to installing programs and services on the computer. Computers that are configured as domain controllers have additional logs displayed in this category. System. This Windows log records system events that are sent by Windows and Windows system services, and are classified as error, warning, or information. Forwarded Events. This Windows log records events are forwarded to this log by other computers. Event log forwarding is a built in technology that allows you to centralize your event logs on a single computer. It’s pretty basic compared to dedicated telemetry tools like System Center Operations manager or your favorite third party alternative. Applications and Services Logs. Each application or service installed on the computer probably has an individual log. These logs store events from a single application or service rather than events that might have systemwide impact. This category of logs includes four subtypes for which the application or service can provide events: Admin, Operational, Analytic, and Debug logs. Admin. Events that are found in the Admin channels indicate a problem and a well-defined solution that an administrator can act on. An example of an admin event is an event that occurs when an application fails to connect to a printer. These events are either well documented or have a message associated with them that gives the reader direct instructions of what must be done to rectify the problem. Operational. Events that are found in the Operational channels are used for analyzing and diagnosing a problem or occurrence. They can be used to trigger tools or tasks based on the problem or occurrence. An example of an operational event is an event that occurs when a printer is added or removed from a system. Analytic. Events that are found in the Analytic channels aid in performance evaluations and troubleshooting. These events are published in high volume, so they should only be enabled and logged for limited amounts of time as part of a diagnostic process. They describe program operation and may indicate problems that cannot be handled by user intervention. Debug. Events that are found in the Debug channels can be used by developers when troubleshooting issues with their programs. You should Note that Both Analytic and Debug logs are hidden and disabled by default. To use these logs: Start Event Viewer Click the View menu, and then select Show Analytic and Debug Logs to make these logs visible. Then select the Analytic or Debug log that you want to enable and on the Action menu, click Properties. On the properties dialog box, select Enable logging and click OK. Each of these logs has attributes, such as maximum log size, access rights for each log, and retention settings and methods, each of which can be defined in the appropriate Event Log section in Group Policy. Event Log Settings You can configure the event log settings in the following locations within the Group Policy Management Console: Computer Configuration\Administrative Templates\Windows Components\Event Log Service\ Subordinate folders exist for the following event logs by default: Application Security Setup System The same set of policy settings is available for each event log. The Setup folder has an additional policy setting that allows logging to be turned on. The following sections describe the options and issues for configuring event log settings for better system management and security. Maximum log size (KB) The maximum log size policy setting specifies the maximum sizes of the log files. An individual setting may be specified for each of the Application, Security, Setup, and System event log channels. The user interfaces of both the Local Group Policy Editor and the Microsoft Management Console Event Viewer snap-in allow you to enter values as large as 2 terabytes. If this setting is not configured, event logs have a default maximum size of 20 megabytes. Although there is no simple equation to determine the best log size for a particular server, you can calculate a reasonable size by multiplying the average event size by the average number of events per month, assuming that you back your logs up on a monthly schedule. The average event takes up about 500 bytes within each log, and the log file sizes must be a multiple of 64 KB. If you can estimate the average number of events that are generated each day for each type of log in your organization, you can determine a good size for each type of log file. For example, if your file server generates 5,000 events per day in its Security log and you want to ensure that you have at least four weeks of data available at all times, you should configure the size of that log to about 70 MB (calculated as 500 bytes * 5000 events per day * 28 days = 70,000,000 bytes). Then check the servers occasionally over the following four weeks to verify that your calculations are correct and that the logs retain enough events for your needs. Event log size and log wrapping should be defined to match the business and security requirements that you determined when you designed your organization's security plan. You can set a maximum log size value of between 1024 and 2,147,483,647 kilobytes in multiples of 64 kilobytes. That's an approximate maximum log file size of 2 TB if you're feeling relaxed about the amount of storage you have. Microsoft’s current recommendation for how to configure this setting is 4GB. The approximate maximum events per second that can be recorded is over 300,000. From a practical perspective if you're thinking about log files that big, you should be using a tool like Azure Monitor or Systems Center Operations Manager to query and analyze your event data. If you were mucking around with log files that size in event viewer, you’re probably going to run into some issues. Log File Location The Control the location of the log file policy allows you to configure where event logs are written. By default event log files are located in the %WinDir%\System32\Winevt\Logs folder. You can move these logs manually or by using policy. To move the event log files to a specified folder, follow these steps: Open Event Viewer. Right-click the log that you want to configure, and then select Properties. In the Log path box, type the desired location for the event log, and then select OK. This change takes effect immediately. However, the events that were already logged are still saved in the previous location. If you relocate the event log files to an unavailable disk, the events will be lost. If you significantly increase the number of objects to audit in your organization and if you enabled the Audit: Shut down system immediately if unable to log security audits setting, there is a risk that the Security log will reach its capacity and force the computer to shut down. If such a shutdown occurs, the computer is unusable until an administrator clears the Security log. To prevent such a shutdown, you can disable the Audit: Shut down system immediately if unable to log security audits setting. Log Access Policies The following default log access rights are enforced: Log Access Policy Application and Setup logs All authenticated users can write/read/clear the log. System log Only system software and administrators can write or clear the log. Any authenticated user can read events from it. Security log Only system software and administrators can read or clear the log. The Log Access Policy setting determines which user accounts have access to log files and what usage rights are granted. Individual setting may be specified for each of the Application, Security, Setup, and System event log channels. This policy requires you use Security Descriptor Definition Language (SDDL) to identify security principals rather than just selecting a user or group. This makes it a lot more cumbersome to use than it should be. Enabling this policy allows you to enter a security descriptor for the log file. The security descriptor controls who can read, write, or clear the event log. Control Event Log Behavior The Control Event Log behavior when the log file reaches its maximum size policy setting controls Event Log behavior when the log file reaches its maximum size. If you enable this policy setting and the "Retain old events" policy setting is enabled, the Event Log file is automatically closed and renamed when it is full. A new file is then started. When this policy setting is disabled and a log file reaches its maximum size, new events overwrite old events in the same log file. If this policy setting is enabled and a log file reaches its maximum size and the Retain Old Events policy is not enabled, new events are not written to the log and are lost. Backup log automatically when full The "backup log automatically when full" policy setting controls Event Log behavior when the log file reaches its maximum size and takes effect only if the Retain old events policy setting is enabled. If you enable this policy setting and the Retain old events policy setting is enabled, the Event Log file is automatically closed and renamed when it is full. A new file is then started. If you disable this policy setting and the Retain old events policy setting is enabled, new events are discarded and the old events are retained. When this policy setting is not configured and the Retain old events policy setting is enabled, new events are discarded and the old events are retained. You should archive logs to an external location at scheduled intervals and you ensure that the maximum log size is large enough to accommodate the interval. Alternatively use a monitoring solution that ingests and archives logs in an external location. Summary The event logs record events that happen on the computer. Examining the events in these logs can help you trace activity, respond to events, and keep your systems secure. Configuring these logs properly can help you manage the logs more efficiently and use the information that they provide more effectively. Ensure that you configure log file policies so that log file size is appropriate and that important event log data is not overwritten or goes unlogged.
