Error 80190190 Entra Join Device
Yesterday we could enroll devices fine until about 10am. After that we can no longer complete an Entra join on a corporate laptop. It gives an error code of 80190190. In the logs it shows the device registered/enrolls then shows a removal less than a minute later. Successfully joined device using account type Successfully deleted the device with identifier
Conditional Access and -Online Device registration error
So there was an Issue creating new discussions yesterday and I ended up with a discussion with Heading only. :) We're using the Get-WindowsAutopilotInfo.ps1 script with the -Online switch to register our Entra Joined Devices, and the process is being blocked by Conditional Access. The sign-in logs point to Microsoft Graph Command Line Tools (App ID: 14d82eec-204b-4c2f-b7e8-296a70dab67e) as the blocker. Microsoft Support suggested whitelisting several apps, but unfortunately, that hasn’t resolved the issue—likely because the device doesn’t have the compliant state during online registration. We’re currently evaluating whether a dedicated service account with scoped permissions for Autopilot enrollment might be a workaround. Would be great to hear if anyone else has found a reliable solution.Entra Group Source of Authority CONVERSION: Enabling Cloud-First Identity Management
As organizations modernize their identity infrastructure, Microsoft Entra’s Group Source of Authority (SOA) Conversion feature enables a granular migration of group management from on-premises AD to Microsoft Entra ID without disabling sync or rearchitecting the entire directory. What Is Group Source of Authority? Group SOA defines where a group object is mastered either in on-prem AD or in Entra ID. With SOA conversion, administrators can selectively convert AD-synced groups into cloud-native groups, making them editable and governable directly in Entra ID. Permissions Required To perform SOA conversion, the following Microsoft Entra roles and Graph API permissions are required: Hybrid Administrator: Required to call Microsoft Graph APIs to read and update SOA of groups. Application Administrator or Cloud Application Administrator: Required to grant user consent to the app or Graph Explorer. Graph API Permission Scope: Group-OnPremisesSyncBehavior.ReadWrite.All must be granted to the app calling the onPremisesSyncBehavior endpoint. Prerequisites Before initiating SOA conversion, ensure the following: Licensing Microsoft Entra Free or Basic license is sufficient. Sync Clients Microsoft Entra Connect Sync: Minimum version 2.5.76.0 Microsoft Entra Cloud Sync: Minimum version 1.1.1370.0 Group Eligibility Groups must not be mail-enabled or tied to Exchange on-premises (DLs or MESGs). If provisioning back to AD is planned, change group scope to Universal. How to Convert Group SOA from AD to Entra Here’s a simplified step-by-step guide: Identify Target Groups Use Entra Admin Center or Graph Explorer to list synced groups. Confirm they are not Exchange-dependent. Grant Permissions Use Graph Explorer or your app registration to grant Group-OnPremisesSyncBehavior.ReadWrite.All. Execute SOA Conversion If we see Group1, which is in scope of conversion is synchronized from on-prem. Execute the below from Graph Explorer to convert “Group1” to cloud managed PATCH https://graph.microsoft.com/beta/groups/{group-id}/OnPremisesSyncbehavior { "isCloudManaged": true } We can verify the change by executing below query on Graph API Explorer This marks the group as cloud-managed. AD sync will stop honoring changes to this group. Validate Conversion Confirm blockOnPremisesSync = true in the Entra Admin Center. Use audit logs to verify the change. Apply Governance Apply lifecycle policies, access reviews, and provisioning rules using Entra ID Governance. Use Cases: Migrating from On-Prem to Cloud Use Case 1: Retiring Legacy AD Groups Scenario: A customer has migrated all mailboxes to Exchange Online and no longer needs certain AD groups. Solution: Convert those groups to cloud-native Entra ID groups and delete them from AD, reducing footprint and simplifying governance. Use Case 2: Governing On-Prem Apps from the Cloud Scenario: A customer uses AD security groups to secure on-prem apps (e.g., Kerberos-based apps). Solution: Convert the group SOA to Entra ID, apply governance policies, and use Group Provision to AD to sync cloud-managed groups back to AD. Use Case 3: Migrating DLs and MESGs to Cloud Scenario: A customer wants to migrate all distribution lists and mail-enabled security groups to the cloud. Solution: Convert SOA to Entra ID, recreate mail-enabled groups in Exchange Online, and decommission AD-based mail groups. Use Case 4: Enabling Access Reviews Scenario: A federal customer wants to run access reviews on group memberships but the groups are AD-synced. Solution: Convert SOA to Entra ID, enabling full access review capabilities and lifecycle workflows. Use Case 5: Hybrid Identity Cleanup Scenario: A customer is migrating from Entra Connect Sync to Cloud Sync and wants to clean up group sprawl. Solution: Use SOA conversion to move group management to the cloud, then decommission legacy sync rules and OUs. Strategic Impact Group SOA Conversion is more than a technical enhancement, it’s a strategic enabler for identity modernization. It supports: AD DS minimization: Shrinking on-prem footprint. Cloud-first governance: Centralized access control and lifecycle management. Phased migration: Avoiding disruption while modernizing.August 2025 Recap: Azure Database for PostgreSQL
Hello Azure Community, August was an exciting month for Azure Database for PostgreSQL! We have introduced updates that make your experience smarter and more secure. From simplified Entra ID group login to integrations with LangChain and LangGraph, these updates help with improving access control and seamless integration for your AI agents and applications. Stay tuned as we dive deeper into each of these feature updates. Feature Highlights Enhanced Performance recommendations for Azure Advisor - Generally Available Entra-ID group login using user credentials - Public Preview New Region Buildout: Austria East LangChain and LangGraph connector Active-Active Replication Guide Enhanced Performance recommendations for Azure Advisor - Generally Available Azure Advisor now offers enhanced recommendations to further optimize PostgreSQL server performance, security, and resource management. These key updates are as follows: Index Scan Insights: Detection and recommendations for disabled index and index-only scans to improve query efficiency. Audit Logging Review: Identification of excessive logging via the pgaudit.log parameter, with guidance to reduce overhead. Statistics Monitoring: Alerts on server statistics resets and suggestions to restore accurate performance tracking. Storage Optimization: Analysis of storage usage with recommendations to enable the Storage Autogrow feature for seamless scaling. Connection Management: Evaluation of workloads for short-lived connections and frequent connectivity errors, with recommendations to implement PgBouncer for efficient connection pooling. These enhancements aim to provide deeper operational insights and support proactive performance tuning for PostgreSQL workloads. For more details read the Performance recommendations documentation. Entra-ID group login using user credentials - Public Preview The public preview for Entra-ID group login using user credentials is now available. This feature simplifies user management and improves security within the Azure Database for PostgreSQL. This allows administrators and users to benefit from a more streamlined process like: Changes in Entra-ID group memberships are synchronized on a periodic 30min basis. This scheduled syncing ensures that access controls are kept up to date, simplifying user management and maintaining current permissions. Users can log in with their own credentials, streamlining authentication, and improving auditing and access management for PostgreSQL environments. As organizations continue to adopt cloud-native identity solutions, this update represents a major improvement in operational efficiency and security for PostgreSQL database environments. For more details read the documentation on Entra-ID group login. New Region Buildout: Austria East New region rollout! Azure Database for PostgreSQL flexible server is now available in Austria East, giving customers in and around the region lower latency and data residency options. This continues our mission to bring Azure PostgreSQL closer to where you build and run your apps. For the full list of regions visit: Azure Database for PostgreSQL Regions. LangChain and LangGraph connector We are excited to announce that native LangChain & LangGraph support is now available for Azure Database for PostgreSQL! This integration brings native support for Azure Database for PostgreSQL into LangChain or LangGraph workflows, enabling developers to use Azure PostgreSQL as a secure and high-performance vector store and memory store for their AI agents and applications. Specifically, this package adds support for: Microsoft Entra ID (formerly Azure AD) authentication when connecting to your Azure Database for PostgreSQL instances, and, DiskANN indexing algorithm when indexing your (semantic) vectors. This package makes it easy to connect LangChain to your Azure-hosted PostgreSQL instances whether you're building intelligent agents, semantic search, or retrieval-augmented generation (RAG) systems. Read more at https://aka.ms/azpg-agent-frameworks Active-Active Replication Guide We have published a new blog article that guides you through setting up active-active replication in Azure Database for PostgreSQL using the pglogical extension. This walkthrough covers the fundamentals of active-active replication, key prerequisites for enabling bi-directional replication, and step-by-step demo scripts for the setup. It also compares native and pglogical approaches helping you choose the right strategy for high availability, and multi-region resilience in production environments. Read more about the active-active replication guide on this blog. Azure Postgres Learning Bytes 🎓 Enabling Zone-Redundant High Availability for Azure Database for PostgreSQL Flexible Server Using APIs. High availability (HA) is essential for ensuring business continuity and minimizing downtime in production workloads. With Zone-Redundant HA, Azure Database for PostgreSQL Flexible Server automatically provisions a standby replica in a different availability zone, providing stronger fault tolerance against zone-level failures. This section will guide you on how to enable Zone-Redundant HA using REST APIs. Using REST APIs gives you clear visibility into the exact requests and responses, making it easier to debug issues and validate configurations as you go. You can use any REST API client tool of your choice to perform these operations including Postman, Thunder Client (VS Code extension), curl, etc. to send requests and inspect the results directly. Before enabling Zone-Redundant HA, make sure your server is on the General Purpose or Memory Optimized tier and deployed in a region that supports it. If your server is currently using Same-Zone HA, you must first disable it before switching to Zone-Redundant. Steps to Enable Zone-Redundant HA: Get an ARM Bearer token: Run this in a terminal where Azure CLI is signed in (or use Azure Cloud Shell) az account get-access-token --resource https://management.azure.com --query accessToken -o tsv Paste token in your API client tool Authorization: `Bearer <token>` </token> Inspect the server (GET) using the following URL: https://management.azure.com/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroup}}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{{serverName}}?api-version={{apiVersion}} In the JSON response, note: sku.tier → must be 'GeneralPurpose' or 'MemoryOptimized' properties.availabilityZone → '1' or '2' or '3' (depends which availability zone that was specified while creating the primary server, it will be selected by system if the availability zone is not specified) properties.highAvailability.mode → 'Disabled', 'SameZone', or 'ZoneRedundant' properties.highAvailability.state → e.g. 'NotEnabled','CreatingStandby', 'Healthy' If HA is currently SameZone, disable it first (PATCH) using API. Use the same URL in Step 3, in the Body header insert: { "properties": { "highAvailability": { "mode": "Disabled" } } } Enable Zone Redundant HA (PATCH) using API: Use the same URL in Step 3, in the Body header insert: { "properties": { "highAvailability": { "mode": "ZoneRedundant" } } } Monitor until HA is Healthy: Re-run the GET from Step 3 every 30-60 seconds until you see: "highAvailability": { "mode": "ZoneRedundant", "state": "Healthy" } Conclusion That’s all for our August 2025 feature updates! We’re committed to making Azure Database for PostgreSQL better with every release, and your feedback plays a key role in shaping what’s next. 💬 Have ideas, questions, or suggestions? Share them with us: https://aka.ms/pgfeedback 📢 Want to stay informed about the latest features and best practices? Follow us here for the latest announcements, feature releases, and best practices: Azure Database for PostgreSQL Blog More exciting improvements are on the way—stay tuned for what’s coming next!
How to add Metadata to Groups
Hello, I am getting quite frustrated with any kind of metadata in Entra ID especially on groups. I used to put a lot of information like product , responsible , location etc. in either the name or the description of a group but since this information is most of the time confusing and irrelevant for the members of the group, I wanted to come up with something better. Now it seems that for some reason Microsoft denies any kind of metadata in Entra ID to be added to most objects especially groups. Overall it seem Microsoft does not see value in providing tags similar to the ones in Azure to any object type in Entra ID and I wonder why is that? I checked out the new "Custom Security Attributes" feature, turns out, its only available for users and applications.... Then I thought we are using directory extensions on applications and users already, it would be useful to use on groups as well. Now according to the documentation groups are also supported, great. But then there is the limitation that you can not update mail enabled and distribution groups via Graph API 😡. Well majority of groups are mail enabled.... Now I am forced to use the EXO module which limits the possibility of automating this quite much (requires PowerShell) but even with this you can not set directory extensions. Why is this so bad by design? How can I add metadata to groups now? Cheers
Moving from MDT/WDS to Autopilot – Real-World Lessons, Wins & Gotchas
Hi all, We’ve been moving away from an ageing WDS + MDT setup and over to Windows Autopilot, and I thought I’d share a few key lessons and experiences from the journey. In case anyone else is working through the same transition (...or about to). Why the change? MDT was becoming unreliable, drivers/apps would randomly fail to install, WDS is on the way out, and we needed a more remote-friendly approach. We also wanted to simplify things for our small IT team and shift from Hybrid Azure AD Join to Azure AD Join only. We’re doing this as a phased rollout. I harvested existing device hashes using a script from a central server, and manually added machines that weren’t online at the time (most of which were just unused spares, we haven't introduced new hardware yet). If you want a copy of this auto-harvest, please see my next post, this script is useful as it'll just go off and import the hardware hashes into Intune, and can run against multiple computers at a time. (I will add the link to the post once made). Some of the biggest hurdles: • 0x80070002 / 0x80070643 errors (typically due to incomplete registration or app deployment failures) • Enrollment Status Page (ESP) hangs due to app targeting issues (user vs device) and BitLocker config conflicts • Wi-Fi setup with RADIUS (NPS) was complex, Enterprise Certificates and we're still using internal AD for authentication, so user accounts exist there and sync over to Azure. • Legacy GPOs had to be rebuilt manually in Intune, lots of trial and error • Some software (like SolidWorks) wouldn’t install silently via Intune, so I used NinjaOne to handle these, along with remediation scripts in Intune where needed We also moved from WSUS to Windows Autopatch, which improved update reliability and even helped with driver delivery via Windows Update. What’s gone well: Device provisioning is more consistent, updates are more reliable, build time per machine has dropped, and remote users get systems faster. It’s also reduced our reliance on legacy infrastructure. What I’m still working on: Tightening up compliance and reporting, improving detection/remediation coverage, figuring out new errors that may occur, and automating as much manual processes as possible. Ask me anything or share your own experience! I’m happy to help anyone dealing with similar issues or just curious about the move. Feel free to reply here or message me. Always happy to trade lessons learned, especially if you’re in the middle of an Autopilot project yourself. Cheers, Timothy Jeens
Adding connected organizations with powershell
Hi, When adding connected organizations using Powershell, the connected organization is added with auth type: OTP/Microsoft account. When adding the connected org using Entra portal, the org is correctly added as a Microsoft Entra ID tenant. Is there any way to add the org as a Microsoft Entra ID tenant programatically?
How to Properly Configure IIS Reverse Proxy for ASP.NET Core Applications Secured with Entra ID
If you’ve ever worked on an ASP.NET Core application protected with Entra ID, you might have encountered an issue where the backend server URL appears as the redirect URI instead of the IIS Reverse Proxy URL. This is because ASP.NET Core applications use the backend server’s hostname to generate the redirect URI. While this behavior is the default, it can be problematic. While you can work around this by manually setting the redirect URI to the ARR/IIS Reverse Proxy endpoint in your code as follows: builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme) .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd")); builder.Services.Configure<OpenIdConnectOptions>(options => { options.Events.OnRedirectToIdentityProvider = context => { context.ProtocolMessage.RedirectUri = "https://arr.local.lab"; return Task.FromResult(0); }; }); It isn’t the most elegant solution, especially in environments where configuration changes might often be required. Instead, using Forwarded Headers offers a cleaner, more scalable approach. In this post, I’ll walk you through how to resolve this issue using Forwarded Headers. ASP.NET Core provides a ForwardedHeaders Middleware , which reads headers such as X-Forwarded-Host and X-Forwarded-Proto. These headers replace values in HttpContext such as HttpContext.Request.Host and HttpContext.Request.Scheme. By passing these headers appropriately from IIS Reverse Proxy, we can resolve the redirect URI issue. But IIS reverse proxy or server farms doesn't send X-Forwarded-Host & X-Forwarded-Proto headers by default. You’ll need to configure IIS to include these headers using the URL Rewrite feature. To do so, follow these steps: Set Server Variables Open the URL Rewrite module in the IIS Manager Console and Select View Server Variables. Add following Server Variables: HTTP_X_Forwarded_Host HTTP_X_Forwarded_Proto Edit Inbound Rules Once Server Variables are added, select the concerned reverse proxy inbound rule and select Edit under Inbound rules in Actions Pane. Add the Server Variables to the inbound rule: Map HTTP_X_Forwarded_Host to {HTTP_HOST} Map HTTP_X_Forwarded_Proto to https Once IIS is configured to pass forwarded headers, the application needs to process them. Add ForwardedHeaders Middleware in your ASP.NET Core application and configure ForwardedHeadersOptions as follows: using Microsoft.AspNetCore.HttpOverrides; var builder = WebApplication.CreateBuilder(args); // Add services to the container. builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme) .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd")); builder.Services.AddAuthorization(options => { // By default, all incoming requests will be authorized according to the default policy. options.FallbackPolicy = options.DefaultPolicy; }); builder.Services.AddRazorPages() .AddMicrosoftIdentityUI(); builder.Services.Configure<ForwardedHeadersOptions>(options => { options.KnownProxies.Add(IPAddress.Parse("10.160.7.4")); // Reverse Proxy IP address options.ForwardedHeaders = ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedHost; }); var app = builder. Build(); app.UseForwardedHeaders(); // ForwardedHeaders Middleware // Configure the HTTP request pipeline. if (!app.Environment.IsDevelopment()) { app.UseExceptionHandler("/Error"); app.UseHsts(); } app.UseHttpsRedirection(); app.UseRouting(); app.UseAuthentication(); app.UseAuthorization(); app.MapStaticAssets(); app.MapRazorPages() .WithStaticAssets(); app.MapControllers(); app.Run(); Note: Order of the Middleware is important. Ensure ForwardedHeaders Middleware is called before any other middleware in the pipeline. Make sure to add the IP address of your ARR/IIS Reverse Proxy to the KnownProxies list. Alternatively, you can use KnownNetwork to set IP range. With these configurations, X-Forwarded-Host and X-Forwarded-Proto headers sent from IIS Reverse Proxy will replace the Host and Scheme in HttpContext. This ensures that the redirect URI correctly points to the IIS Reverse Proxy endpoint, resolving the issue seamlessly. Further Reading: Refer to these resources for more information: Configure ASP.NET Core to work with proxy servers and load balancers | Microsoft Learn Setting HTTP request headers and IIS server variables | Microsoft Learn IIS Server Variables | Microsoft Learn Hope this guide helps!
