In-place upgrade possibility planned for Windows Server 2025 Datacenter Azure Edition ?
There is currently no official ISO for Windows Server Datacenter: Azure Edition that supports setup.exe /auto upgrade for in-place upgrades. Azure Update Manager does not support OS version upgrades for Azure Edition through optional features. Is anyone aware of a supported workaround?
Active Directory Unable to reset user passwords
I am managing a Windows Server 2025 Active Directory environment with client machines. I created a test user and enabled the option “User must change password at next logon.” I then provided a temporary password to the user, expecting them to get the prompt to change it on first login. However, when the user attempts to change the password, they receive the error: “The user must change password before signing in.” My goal is that when I provide a temporary password to a user: They get the prompt to change the password at next logon. When they change it, it should not throw the “user must change password before signing in” error. I need guidance on how to achieve this so users can reset their passwords successfully.A New Platform Management Group & Subscription for Security in Azure landing zone (ALZ)
At the start of 2025, during the January 2025 ALZ Community Call, we asked everyone for their feedback, via these discussions on our GitHub repo: 1898 & 1978 , on the future of Microsoft Sentinel in the Azure landing zone (ALZ) architecture as we were receiving feedback that it needed some changes and additional clarity from what ALZ was deploying and advising then. We have now worked with customers, partners, and internal teams to figure out what we should update in ALZ around Microsoft Sentinel and Security tooling and have updated the ALZ conceptual architecture to show this. What did ALZ advise and deploy before, by default? Prior to these updates ALZ advised the following: The central Log Analytics Workspace (LAW) in the Management Subscription should Be used to capture all logs, including security/SIEM logs The Microsoft Sentinel solution (called Security) should be installed upon this LAW also And in the accelerators and tooling it deployed, by default: The central Log Analytics Workspace (LAW) in the Management Subscription with the Microsoft Sentinel solution installed Microsoft Sentinel had no additional configuration apart from being installed as a solution on the central LAW What are the changes being made to ALZ from today? Based on the feedback from the GitHub discussions and working with customers, partners and internal teams we are making the following changes: A new dedicated Security Management Group beneath the Platform Management Group A new dedicated Security Subscription placed in the new Security Management Group Nothing will be deployed into this subscription by ALZ by default. This allows: Customers & partners to deploy and manage the Microsoft Sentinel deployment how they wish to The 31-day 10GB/day free trial can be started when the customer or partner is ready to utilise it No longer deploy the Microsoft Sentinel solution (called Security) on the central LAW in the Management Subscription This allows for separating of operational/platform logs from security logs, as per considerations documented in Design a Log Analytics workspace architecture The changes have only been made to our ALZ CAF/MS Learn guidance as of now, and the changes to the accelerators and implementation tools will be made over the coming months 👍 These changes can be seen in the latest ALZ conceptual architecture snippet below The full ALZ conceptual architecture can be seen here on MS Learn. You can also download a Visio or PDF copy of all the ALZ diagrams. What if we have already deployed ALZ? If you have already deployed ALZ and haven't tailored the ALZ default Management Group hierarchy to create a Security Management Group then you can now review and decide whether this is something you'd like to create and align with. While not mandatory, this enhancement to the ALZ architecture is recommended for new customers. The previous approach remains valid; however, feedback from customers, partners, and internal teams indicates that using a dedicated Microsoft Sentinel and Log Analytics Workspace within a separate security-focused Subscription and Management Group is a common real-world practice. To reflect these real-world implementations and feedback, we’re evolving the ALZ conceptual architecture accordingly 👍 Closing We hope you benefit from this update to the ALZ conceptual architecture. As always we welcome any feedback via our GitHub Issues
GA: Enhanced Audit in Azure Security Baseline for Linux
We’re thrilled to announce the General Availability (GA) of the Enhanced Azure Security Baseline for Linux—a major milestone in cloud-native security and compliance. This release brings powerful, audit-only capabilities to over 1.6 million Linux devices across all Azure regions, helping enterprise customers and IT administrators monitor and maintain secure configurations at scale. What Is the Azure Security Baseline for Linux? The Azure Security Baseline for Linux is a set of pre-configured security recommendations delivered through Azure Policy and Azure Machine Configuration. It enables organizations to continuously audit Linux virtual machines and Arc-enabled servers against industry-standard benchmarks—without enforcing changes or triggering auto-remediation. This GA release focuses on enhanced audit capabilities, giving teams deep visibility into configuration drift and compliance gaps across their Linux estate. For our remediation experience, there is a limited public preview available here: What is the Azure security baseline for Linux? | Microsoft Learn Why Enhanced Audit Matters In today’s hybrid environments, maintaining compliance across diverse Linux distributions is a challenge. The enhanced audit mode provides: Granular insights into each configuration check Industry aligned benchmark for standardized security posture Detailed rule-level reporting with evidence and context Scalable deployment across Azure and Arc-enabled machines Whether you're preparing for an audit, hardening your infrastructure, or simply tracking configuration drift, enhanced audit gives you the clarity and control you need—without enforcing changes. Key Features at GA ✅ Broad Linux Distribution Support 📘 Full distro list: Supported Client Types 🔍 Industry-Aligned Audit Checks The baseline audits over 200+ security controls per machine, aligned to industry benchmarks such as CIS. These checks cover: OS hardening Network and firewall configuration SSH and remote access settings Logging and auditing Kernel parameters and system services Each finding includes a description and the actual configuration state—making it easy to understand and act on. 🌐 Hybrid Cloud Coverage The baseline works across: Azure virtual machines Arc-enabled servers (on-premises or other clouds) This means you can apply a consistent compliance standard across your entire Linux estate—whether it’s in Azure, on-prem, or multi-cloud. 🧠 Powered by Azure OSConfig The audit engine is built on the open-source Azure OSConfig framework, which performs Linux-native checks with minimal performance impact. OSConfig is modular, transparent, and optimized for scale—giving you confidence in the accuracy of audit results. 📊 Enterprise-Scale Reporting Audit results are surfaced in: Azure Policy compliance dashboard Azure Resource Graph Explorer Microsoft Defender for Cloud (Recommendations view) You can query, export, and visualize compliance data across thousands of machines—making it easy to track progress and share insights with stakeholders. 💰 Cost There’s no premium SKU or license required to use the audit capabilities with charges only applying to the Azure Arc managed workloads hosted on-premises or other CSP environments—making it easy to adopt across your environment. How to Get Started Review the Quickstart Guide 📘 Quickstart: Audit Azure Security Baseline for Linux Assign the Built-In Policy Search for “Linux machines should meet requirements for the Azure compute security baseline” in Azure Policy and assign it to your desired scope. Monitor Compliance Use Azure Policy and Resource Graph to track audit results and identify non-compliant machines. Plan Remediation While this release does not include auto-remediation, the detailed audit findings make it easy to plan manual or scripted fixes. Final Thoughts This GA release marks a major step forward in securing Linux workloads at scale. With enhanced audit now available, enterprise teams can: Improve visibility into Linux security posture Align with industry benchmarks Streamline compliance reporting Reduce risk across cloud and hybrid environmentsCan't RDP when in protected users group 2 domains no trust
I have the following issue and have read a lot about people with similar issues, but not quite the same setup as we have. We are working with 2 domains. I call them Domain A and B. So Domain A is our own domain, with our own DC and servers. Domain B is a shared setup for our customers. We all are working with our mailto:email address removed for privacy reasons accounts to gain access to servers from our customers. All customer servers are member of Domain B All admin accounts are members of protected users. When i am logged in to our management server, that is a member of domain A i cannot RDP with my mailto:email address removed for privacy reasons account to whatever server from our customers. When i am in the office, we can access domain B from our personal laptops who are only Entra ID joined. From our personal laptops we can RDP to the servers of the customers in Domain B with the mailto:email address removed for privacy reasons accounts. Strange thing is: not all admin accounts have this issue (at the same time) Issue is resolved spontaniously My first question is, do i need to have a domain trust between Domain A and Domain B Both the domains have higher domain functional level then 2012 R2. I have communication between my management machine in Domain A to the domain controllers of Domain B. Not only ping, but also KDC, DNS, LDAP, etc. Our domain controller in Domain A does not have communication to Domain B.Designing for Certainty: How Azure Capacity Reservations Safeguard Mission‑Critical Workloads
Why capacity reservations matter now Cloud isn’t running out of metal, but demand is compounding and often spikes. Resource strain shows up in specific regions, zones, and VM SKUs, especially for popular CPU families, memory-optimized sizes, and anything involving GPUs. Seasonal events (retail peaks), regulatory cutovers, emergency response, and bursty AI pipelines can trigger sudden surges. Even with healthy regional capacity, a single zone or a specific SKU can be tight. Capacity reservations acknowledge this reality and make it designable instead of probabilistic. Root reality: Capacity is finite at the SKU-in-zone granularity, and demand arrives in waves. Risk profile: The risk is not “no capacity in the cloud,” but “no capacity for this exact size in this exact place at this exact moment.” Strategic move: Reserve what matters, where it matters, before you need it. What capacity means in practice Think of three dimensions: region, zone, and SKU. Your workload’s SLO ties to all three. Region: The biggest pool of resources. It gives you flexibility but doesn’t guarantee availability in a specific zone. Zone: This is where fault isolation happens and where you’ll often feel the pinch first when demand spikes. SKU: The specific type of machine you’re asking for. This is usually the tightest constraint, especially for popular sizes like Dv5, Ev5, or anything with GPUs. Azure Capacity Reservations let you lock capacity for a specific VM size at the regional or zonal scope and then place VMs/scale sets into that reservation. Pay‑as‑you‑go vs capacity reservations vs reserved instances Attribute Pay‑as‑you‑go Capacity Reservations Reserved Instances Primary purpose Flexibility, no commitment Guarantee availability for a VM size Reduce price for steady usage What it guarantees Nothing beyond current availability Capacity in region/zone for N of a SKU Discount on matching usage (1‑ or 3‑year term) Scope Region/zone at runtime, best‑effort Bound to region or specific zone Billing benefit across scope rules Commitment None Active while you keep it (on‑demand) Term commitment (1 or 3 years) Key clarifications Capacity reservations ≠ discount tool: They exist to secure availability. You pay while the reservation is active (even if idle) because Azure is holding that capacity for you. Reserved Instances ≠ capacity guarantee: They reduce the rate you pay when you run matching VMs, but they don’t hold hardware for you. Together: Use Capacity Reservations to ensure the VMs can run; use Reserved Instances to lower the cost of the runtime those VMs consume. This is universal, not just Azure Every major cloud faces the same physics: finite hardware, localized spikes, SKU-specific constraints, and growth in high-demand families (especially GPUs). AWS offers On‑Demand Capacity Reservations; Google Cloud offers zonal reservations. The names differ; the pattern and the need are the same. If your architecture depends on “must run here, as this size, and right now,” you either design for capacity or accept availability risk. When mission‑critical means “reserve it” If failure to acquire capacity breaks your SLO, treat capacity as a dependency to engineer, not a variable to assume. High-stakes cutovers and events: Examples: Black Friday, tax deadlines, trading close, clinical batch windows. Action: Pre‑reserve the exact SKU in the exact zones for the surge window. HA across zones: Goal: Survive a zone failure by scaling in active zones. Action: Consider keeping extra capacity in each zone based on your failover plan, whether that’s N+1 or matching peak load, depending on active/active vs. active/passive. Change windows that deallocate/recreate: Risk: If a VM is deallocated during maintenance, it might not get the same placement when restarted. Action: Associate VMs/VMSS with a capacity reservation group before deallocation. Fixed‑SKU dependencies: Signal: Performance needs, licensing rules, or hardware accelerators that lock you into a specific VM family. Action: Reserve by SKU. If possible, define fallback SKUs and split reservations across them. Regulated or latency‑sensitive workloads: Constraint: Must run in a specific zone or region due to compliance or latency. Action: Prefer zonal reservations to control both locality and availability. How reserved instances complement capacity reservations Two-layer strategy: Layer 1: Availability: Capacity reservations ensure your compute can be placed when needed. Layer 2: Economics: Reserved Instances (or Savings Plans) apply a pricing benefit to the steady‑state hours you actually run. Practical pairing: Steady base load: Cover with 1/3‑year Reserved Instances for maximum savings. Critical surge headroom: Hold with Capacity Reservations; if the surge is predictable, you can still layer partial RI coverage aligned to expected utilization. Dynamic burst: Leave as pay‑as‑you‑go or use short‑lived reservations during known windows. FinOps hygiene: Coverage ratios: Track RI coverage and capacity reservation utilization separately. Rightsizing: Align reservations to the SKU mix you truly run; shift or cancel idle capacity reservations quickly. Chargeback: Attribute the cost of “insurance” (capacity) to the workloads that require the SLO, separate from the cost of “fuel” (compute hours). Conclusion In today’s cloud landscape, resilience isn’t just redundancy; it’s about assured access to the exact resources your workload demands. Capacity Reservations remove uncertainty by guaranteeing placement, while Reserved Instances drive cost efficiency for predictable use. Together, they form a strategic duo that keeps mission‑critical services running smoothly under any demand surge. Build with both in mind, and you turn capacity from a risk into a controlled asset.
Announcing Public Preview for Azure Service Groups!
What are Service groups? Service Groups are a new resource container enabling management and observability scenarios where flexibility in hierarchy and membership is needed. Service Groups are tenant level resources so they can have members across the tenant but do not interfere or use tenant-wide RBAC or Policy abilities. Key Features Low Privilege Management: Service Groups are designed to operate with minimal permissions, ensuring that users can manage resources without needing excessive access and appealing to multiple personas. Access to a Service Group does not grant role-based access control or policy inheritance to its members. Flexible and Varying Hierarchies: Azure resources and scopes, from anywhere in the tenant, can become members of one or multiple service groups. Additionally, Service Groups can be nested providing the ability to have multiple hierarchy structures, i.e. Cost Center, Product, Organization, and more! Monitoring Capabilities: From your application to infrastructure health, Azure Monitor features (such as Health Models) are now available to help you troubleshoot, investigate, and monitor your Service Group. When should I use them? Service Groups should be leveraged in scenarios where resources sprawl across existing containers making it difficult to monitor and manage them. This is commonly found in scenarios needing to model application hierarchy, company services and workloads. Service Groups cannot be used as a deployment scope nor to manage Policy nor RBAC. Try it out! Quickly start with Service Groups using REST API or Azure Portal! For more information on Service Groups, please visit aka.ms/servicegroups. FAQ Do Service Groups replace existing Azure groups? No, Service Groups have been designed to work in parallel with existing Azure Groups. For a comparison of existing scopes, please review the scenario comparison documentation. Who can create Service Groups? Anyone with a valid Azure user account in a Microsoft Entra directory can leverage Service Groups! Why are Service Groups tenant level? Service Groups are tenant level so they can have membership from across the tenant. However, unlike pre-existing tenant level resources (i.e, Management Groups), Service Groups do not have grant users' tenant wide access. Share Your Feedback You can reach our team by email at azureservicegroups@microsoft.com.
