Why "Admin by Request" Doesn't Work for D365 F&O UDE Setup — and How to Resolve Local Admin on Entra-Joined Developer Workstations

One of the most common friction points when setting up a D365 F&O Unified Development Environment (UDE) on a corporate laptop is the local admin requirement. Microsoft's documentation states it clearly — persistent local administrator rights are required on the developer machine. What's less obvious is why temporary JIT elevation tools fail, and what the right resolution looks like in an enterprise context.

What the UDE Setup Actually Does to Your Machine

When Visual Studio connects to Dataverse and triggers UDE setup, it kicks off an automated multi-stage pipeline:

Downloads PackagesLocalDirectory.zip (several GB) from the cloud environment
Downloads the cross-references database (.bak file)
Downloads and installs the F&O Visual Studio extension (VSIX)
Unzips the metadata to a local folder
Restores the .bak file into (localdb)\MSSQLLocalDB
Creates symlinks mapping custom metadata to PackagesLocalDirectory
Closes and automatically reopens Visual Studio
Completes extension registration on VS restart

This entire process takes approximately 2 hours. Each stage is a separate spawned process, and several stages happen after VS auto-restarts.

Why Admin by Request (and Similar JIT/PAM Tools) Fail

Tools like Admin by Request, CyberArk EPM, BeyondTrust, and Ivanti operate by sandboxing elevation for a single process or timed session. There are four specific reasons this is incompatible with UDE setup:

1. Elevation Is Scoped to a Single Process — Not a Chain

Admin by Request's App Elevation mode elevates the initiating process only. When VS closes and relaunches automatically mid-setup (which it does, by design), the relaunched VS instance is no longer running under the elevated token. Background processes that continue after the restart lose their admin context immediately.

This is the exact failure developers report: Admin by Request reports the install as "successful", but VS keeps showing "Please wait for the update to complete" indefinitely — because the post-restart registration steps ran without admin rights.

2. The Setup Outlasts JIT Time Windows

Most Admin by Request configurations grant 1-hour sessions. The UDE metadata download and extension setup takes 2+ hours. Even the Admin Session (full session elevation) mode with a 2-hour window is risky, because:

VS auto-close/reopen breaks the session continuity
Network issues can cause the download to restart from scratch
The org security app may interrupt the Dataverse connection mid-download

3. PowerShell Execution Policy Requires Machine-Level Change

Before any PowerShell provisioning can run, corporate execution policies (enforced by GPO) typically block script execution. The fix requires:

Set-ExecutionPolicy Unrestricted -Scope LocalMachine

This modifies a machine-level registry key, not a per-session setting. Admin by Request can grant a sandboxed elevated PowerShell window, but the execution policy change needs to persist across sessions and user accounts — which requires writing to HKLM, not HKCU. Even with a full admin session, the change may not persist correctly depending on how the sandbox is implemented.

4. LocalDB Service Registration and Symlink Creation

Restoring the cross-reference database into (localdb)\MSSQLLocalDB requires admin rights on the LocalDB service. Creating symlinks (which map custom metadata folders into PackagesLocalDirectory) requires SeCreateSymbolicLinkPrivilege — which is granted to local admins but not to temporarily elevated processes in a sandbox.

Diagnosing Your Current Admin Status

Check whether you are local admin right now

Open a normal (non-elevated) PowerShell and run:

whoami /groups | findstr "Administrators"

If BUILTIN\Administrators appears with Enabled — you are local admin. If it's absent or shows Disabled — you are not.

Also check who is in the Administrators group on your machine:

net localgroup Administrators

Check your device join type

dsregcmd /status

Look at the Device State section:

Result	Meaning
`AzureAdJoined: YES` + `DomainJoined: NO`	Pure Entra joined — cleanest path, Intune/Entra policy applies directly
`AzureAdJoined: YES` + `DomainJoined: YES`	Hybrid joined — GPO and Intune may conflict, IT needs to use the correct policy path

Understanding the User Identity field in dsregcmd

The User Identity field in the SSO State section of dsregcmd /status shows the UPN of the currently authenticated Entra identity — normally your work email. If it shows something other than a UPN (e.g. a local account name like blablalocaladmin), this likely indicates a pre-configured privileged local account that IT has already created on your machine for exactly this purpose. Check whether it exists and is active:

net user blablalocaladmin
net localgroup Administrators

If it appears in the Administrators group — IT has already done the setup. You just need to request the password.

The AzureAdJoined: YES Misconception

Being Entra joined describes how the device is enrolled — it says nothing about your user account's local rights. These are separate:

Device join status — machine registration with Microsoft identity platform
Local administrator membership — which accounts have admin rights on that specific device

On a freshly Entra-joined device, only the account that physically performed the join (usually IT during provisioning) gets automatic local admin. Your standard work account is a normal user unless someone explicitly adds it to the local Administrators group.

Being a Global Administrator in Entra ID also does not grant local admin — Global Admin is a cloud-level permission for managing Microsoft 365 resources, entirely separate from Windows device-level permissions.

Resolution Options (in Priority Order)

Option 1 — IT Adds Your Account as Permanent Local Admin (Best)

On a pure Entra-joined device (AzureAdJoined: YES, DomainJoined: NO), your IT admin can:

Via Entra admin centre: Entra ID → Devices → Device settings → Manage Additional local administrators on all Microsoft Entra joined devices → Add your account

Via Intune: Endpoint Security → Account Protection → Local User Group Membership policy → add your UPN, scoped to your device

After policy applies, sign out fully and back in. Verify with whoami /groups.

What to tell IT:

"I'm setting up a D365 F&O Unified Development Environment. Microsoft's documentation explicitly requires persistent local administrator rights — the setup involves multi-stage background processes including LocalDB restore, VSIX extension installation, and symlink creation that span 2+ hours across multiple process chains. Temporary JIT elevation tools are insufficient for this. Please add my account yuriy@company.com to the local Administrators group on device [hostname] via Intune or Entra policy."

Get your hostname with: hostname

Option 2 — Use the Pre-Existing Local Admin Account (If IT Already Created One)

If dsregcmd /status shows an unexpected value in User Identity that looks like a local account name rather than a UPN, IT may have already provisioned a privileged account for you. Confirm:

net localgroup Administrators
net user blablalocaladmin

If it's there and active, simply ask IT for the password (or a reset). Then:

For PowerShell setup steps: Right-click PowerShell → Run as Administrator → enter .\blablalocaladmin credentials (the .\ prefix is essential — it tells Windows to look in the local SAM database, not Entra)

For Visual Studio: Shift + right-click → Run as different user → enter .\blablalocaladmin credentials. When VS prompts to connect to Dataverse, enter your own Entra credentials (yuriy@company.com) — not the local admin ones. This is the critical handoff: local admin handles the install, your identity handles the cloud authentication.

For PowerShell modules — install machine-wide, not per-user:

# In elevated PowerShell (as local admin):
Set-ExecutionPolicy Unrestricted -Scope LocalMachine
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -Scope AllUsers

Using -Scope LocalMachine and -Scope AllUsers ensures these settings apply to your normal account too — you won't need the admin account for day-to-day development.

Option 3 — Microsoft Dev Box

Sidesteps the entire problem. Dev Box provisions a cloud VM pre-configured with admin rights for the session user. Suitable when corporate device policies cannot be relaxed and IT is unwilling to grant local admin.

Option 4 — Admin by Request Full Session Mode (Last Resort)

If Admin by Request is non-negotiable, use Admin Session (full session elevation) rather than App Elevation, with a minimum 4-hour window. Pre-validate that:

The org security app won't block the Dataverse connection mid-setup
Set-ExecutionPolicy Unrestricted -Scope LocalMachine succeeds and persists after the session ends
You are prepared to retry if VS auto-restart breaks the session

This is the most fragile option and is not recommended for production developer onboarding.

Credential Prompt Format Reference

When entering credentials in UAC prompts or "Run as different user":

Format	Resolves against	Use when
`.\blablalocaladmin`	Local machine SAM	Local admin account — always use this prefix
`MACHINENAME\blablalocaladmin`	Local machine SAM	Alternative to `.\` — equivalent
`yuriy@company.com`	Entra ID	Your normal work account
`blablalocaladmin` (no prefix)	Ambiguous — may try Entra first	Avoid — can cause auth failures on Entra-joined devices

Once Setup Is Complete — Ongoing Admin Requirements

The good news: once UDE is fully set up, day-to-day X++ development does not require local admin. You open VS normally as yourself, connect to Dataverse with your Entra credentials, and deploy models via the pipeline. Admin rights were only needed for the one-time workstation setup.

The only scenarios where admin rights are needed again:

Updating the F&O VS extension after a version upgrade
Reinstalling or reconfiguring LocalDB
Changing PowerShell execution policies
Installing new VS workloads or components