It’s my technical reflection on how bringing AI into the standard CLI changes the way we think, troubleshoot, and move fast all without leaving the tools we already trust.

The Philosophy: Human-in-the-Loop, Not Autopilot

What makes Copilot CLI interesting isn’t that it “knows commands.” Plenty of cheat sheets and snippets do. The difference is intent translation.

You don’t start with syntax; you start with what you want to achieve. Yep! Natural Language . Instead of switching contexts, you stay in the terminal and ask a plain-language question:

“What's on my calender today?”

Copilot CLI translates that intent into a concrete shell command. You review it, run it, and learn from it. That loop — human intent → machine suggestion → human judgment — is the real productivity win.

My Experience

Almost at the end of January, I started exploring GitHub Copilot CLI. Special thanks to Scott Hanselman for the sparking the Copilot Energy. It has fundamentally reshaped how I think about AI as a companion. I love the CLI; I love doing async tasks, juggling multiple things, and getting into flow. Copilot CLI scaled that flow for me. I felt 5x more productive on many day-to-day tasks.

Why is it a game changer? For me, two things stood out: the WorkIQ integration and the ability to execute shell commands safely and intelligently (including Azure CLI). I can ask Copilot CLI to review a wiki PR with my custom prompts, summarize changes, or even prepare suggested edits then run commands to apply or validate them. Add skills.md based custom skills to the mix, and the entire ballgame changes.

Practical Wins

• Intent-first command generation: Ask for results in plain language; get polished, reviewable commands back.

• Faster context switching: No more flipping between terminal and browser — the terminal becomes the workspace and the instructor.

• Native integrations: WorkIQ, Azure CLI, and extension points mean Copilot CLI can be part of existing pipelines and workflows.

• Custom skills and agents: Configure skills.md or use agent squads (see Brady Gaster’s Squad) to automate multi-step workflows tailored to your team.

For example, you can configure WorkIQ with custom skills to summarize your team’s conversations, prioritize what’s important, or create work items in Azure DevOps — provided you have az devops installed and configured. That unlocks meaningful automation across roles: developers, QA, sales, and even non-technical folks can leverage the same interface for meeting prep, monitoring, or lightweight automation.

Resources and Community Picks

• Squad (agent orchestration) — a fun way to scale agent-based workflows.

• A practical guide to customizing Copilot and agents — great starting point for deeper customization.

My buddy Nish Anil has some brilliant walkthroughs on customizing agents; if you want to tailor Copilot CLI to your daily routine, his guide is a great place to start.

Who Benefits?

Almost everyone. Copilot CLI can help you iterate faster, reproduce fixes, automate tedious tasks, meeting prep, summarizing materials, monitoring dashboards, drafting emails or standing up simple automations all without memorizing complex command sequences.

If you haven’t tried GitHub Copilot CLI yet, give it a shot. Configure a couple of skills, link your WorkIQ, and try translating a real daily task into an intent. You might be surprised how quickly it becomes a trusted thinking partner. If this post resonated, please like or share it with others and expect more updates: I’m working on new CLI skills that might help you get even more out of the tool.

Start small. Keep the human in the loop. The terminal you love just got a thinking partner.

If you’re a .NET developer and want to see your app running on an iPhone simulator quickly, the real work isn’t writing code — it’s getting .NET, Xcode, and the iOS simulator properly aligned.

When I started, I used Microsoft’s official MAUI first app tutorial as the baseline:
https://dotnet.microsoft.com/en-us/learn/maui/first-app-tutorial/intro

This post focuses on the practical macOS setup + troubleshooting so your first build actually works — especially if you hit workload errors like I did.

Install .NET SDK (no Homebrew)

curl -LO https://dot.net/v1/dotnet-install.sh
chmod +x dotnet-install.sh
./dotnet-install.sh
dotnet --info

Install MAUI workload (the correct way)

If you try installing maui-ios and see:

Workload installation failed: Workload ID maui-ios is not recognized.

That’s expected in many setups. The right approach is to install the maui workload (it brings iOS pieces with it):

dotnet workload install maui
dotnet workload list

If you still have issues:

dotnet workload update
dotnet workload repair

Install Xcode + Simulator Runtime

1. Install Xcode from the App Store

2. Open Xcode once and accept the license

3. Install command line tools:

xcode-select --install

4. Install an iOS simulator runtime:

• Xcode → Settings → Platforms → install an iOS runtime

• Launch Simulator once to confirm it works

Fix Xcode location (common build breaker)

Check current path:

xcode-select -p

Set it explicitly:

sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
xcodebuild -version

Verify:

xcodebuild -version

🚀 Create Your First MAUI iOS App

Now the fun part.

Create the project

dotnet new maui -n MauiTestApp
cd MauiTestApp

Restore:

dotnet restore

List Available iOS Simulators

xcrun simctl list devices

Look for something like:

iPhone 15 (Booted)
iPhone 15 Pro (Shutdown)

Run on iOS Simulator

Boot Simulator (if needed):

open -a Simulator

Build + run:

dotnet build -t:Run -f net8.0-ios

Stream iOS Simulator logs (super useful for “blank screen” issues)

xcrun simctl spawn booted log stream --style compact --level debug --predicate 'eventMessage CONTAINS[c] "<your message>"'

Replace <your message> with a keyword you log from your app.

If Build Fails

90% of the time:

• Xcode path wrong

• Simulator runtime missing

• Workload not installed

Check:

dotnet workload list
xcode-select -p
xcodebuild -version

🔍 Viewing iOS Logs (Pro Debugging Tip)

When app runs but something silently fails:

xcrun simctl spawn booted log stream --style compact --level debug --predicate 'eventMessage CONTAINS[c] "<your message>"'

Replace <your message> with a string you log inside your MAUI app.

This is extremely useful for:

• Blank screens

• Startup crashes

• Dependency injection failures

• Native iOS interop issues

Closing Thoughts

MAUI iOS development is smooth once the toolchain is aligned:

• .NET SDK

• MAUI workload

• Xcode installed

• Correct xcode-select path

• Simulator runtime available

Once those are validated, building and running from terminal becomes predictable and reliable.

Treat your environment like infrastructure. Verify it once. Then focus on your app.

Today we’ll unpack one of the most overlooked but critical steps in plugin development: code signing. Whether you’re testing locally with a self-signed certificate or preparing for production with a trusted authority, this guide walks you through both paths, so your plugins stay secure and compliant across every environment.

Update 12/10/2025 - I went ahead and updated the Microsoft Official documentation with some of this guidance. You can read here.

🧭 What You’ll Learn

• Creating and managing your signing certificate

• Generating the correct subject identifier

• Packaging and signing your plugins

• Registering everything cleanly with Dataverse

• A bonus recommendation on automating certificate signing

💡 Tip: Treat your signing certificate like a secure document. Keep it private, protected, and backed up safely.

1️⃣ Creating Your Digital Certificate

Every plugin needs a verifiable identity. The certificate is your plugin’s fingerprint.
Here’s a sample PowerShell script to create a self-signed certificate for development and testing:

Official Example: https://learn.microsoft.com/en-us/powershell/module/pki/new-selfsignedcertificate?view=windowsserver2025-ps#example-3.

$params = @{
    Type = ‘Custom’
    Subject = ‘E=yourcompany@domain.com,CN=Your Company’
    TextExtension = @(
        ‘2.5.29.37={text}1.3.6.1.5.5.7.3.4’,
        ‘2.5.29.17={text}email=administrator@yourcompany.com’ )
    KeyAlgorithm = ‘RSA’
    KeyLength = 2048
    SmimeCapabilities = $true
    CertStoreLocation = ‘Cert:\CurrentUser\My’
}
New-SelfSignedCertificate @params

🏢 For Production Environments
The PowerShell script above works well for development and testing scenarios. However, for production deployments, it’s important to use a certificate issued by a trusted and managed certificate authority rather than relying on a self-signed certificate.

2️⃣ Building the Subject Identifier (The Tricky Part)

These value ties your certificate, tenant, and environment together. You’ll need:

• Azure Tenant ID

• Dataverse Environment ID

• Certificate Subject

Here’s a reusable PowerShell helper function:

function Get-SubjectIdentifier {
    param(
        [Parameter(Mandatory=$true)][string]$TenantId,
        [Parameter(Mandatory=$true)][string]$EnvironmentId,
        [Parameter(Mandatory=$true)][string]$Subject
    )

    $bytes = [Guid]::Parse($TenantId).ToByteArray()
    $encodedTenant = [Convert]::ToBase64String($bytes).TrimEnd(’=’).Replace(’+’,’-’).Replace(’/’,’_’)
    $encodedSubject = [System.Web.HttpUtility]::UrlEncode($Subject)

    return “/eid1/c/pub/t/$encodedTenant/a/qzXoWDkuqUa3l6zM5mM0Rw/n/plugin/e/$EnvironmentId/i/$encodedSubject/s/$encodedSubject”
}

3️⃣ Packaging and Signing

Now, time to seal the deal.

Package your plugin:

nuget spec YourPlugin.dll
nuget pack YourPlugin.nuspec

Sign it with your certificate:

nuget sign YourPlugin.nupkg `
    -CertificatePath plugin-signing.pfx `
    -CertificatePassword “YourSecretPassword” `
    -Timestamper http://timestamp.digicert.com

Timestamping ensures your signature remains valid even after your certificate expires.

🔥 If you want to automate your certificate generation and integrate signing into your DevOps or GitHub Actions pipeline, I highly recommend reading Scott Hanselman’s blog on Automatically Signing a Windows EXE with Azure Trusted Signing, dotnet sign, and GitHub Actions.
The same concepts apply directly to Dataverse plugin signing and help you shift from manual PFX handling to a secure, cloud-based signing workflow.

4️⃣ Registering / Update Managed Identity with Dataverse

To understand how to create or update the identity record with the correct attributes, read:

🧩 Goodbye Secrets — Using Managed Identity in Dataverse Plugins. https://blogs.apurvghai.com/p/goodbye-secrets-using-managed-identity

Finally, here’s the flow:

🔍 Troubleshooting Quick Wins

Certificate not recognized

• Verify that the subject identifier is encoded correctly.

• Make sure the tenant ID was converted using Base64URL (no padding, no “+” or “/”).

• Confirm that the subject extracted from the certificate matches what you passed during registration.

Signing errors during nuget sign

• Ensure the certificate includes Digital Signature and Code Signing key usages.

• Check that the certificate is valid (not expired or missing private key).

• If using a PFX, confirm the password is correct and the file contains the full chain.

Plugin package won’t load in Dataverse

• Verify the NuGet package is signed and timestamped.

• Ensure the certificate (or managed identity entry) is registered in the Plugin Package table.

• Check the Dataverse plugin trace logs for “signature validation” errors.

Subject identifier rejected by CLI or Dataverse

• Confirm tenant and environment IDs are correct GUIDs.

• Validate encoding by regenerating with the script (Python or PowerShell).

• Ensure no accidental spaces or hidden characters were added when copying.

✅ Best Practices Checklist

• Use descriptive certificate subjects (e.g., “CN=Plugin Signing – Prod”)

• Store certs in Azure Key Vault, not on local disks

• Document your identifiers for each environment

• Always use a trusted timestamp server

• Automate these steps in your DevOps pipeline

🧠 Additional Resources

• Dataverse Plugin Registration Docs

• Power Platform CLI Reference

• Azure Managed Identity + Dataverse Plug-in Integration

🌟 Taking time to properly sign your code builds trust — for your environment, your team, and your future self.

Happy building, and see you in the traces! 🚀

You’re not alone. One expires—buried deep in config or environment settings—and suddenly, you’re firefighting downtime. You patch it, it works… until the next time.

There’s a better way: Managed Identity (MI) with Federated Identity Credentials (FIC). No secrets. No rotation. No surprises.

Let me show you how to set it up—step by step.

⚙️ What You’ll Need

• Azure subscription (for creating a User Managed Identity — UMI)

• Dataverse environment where your plugin or Custom API runs

• System Administrator role (to create Managed Identity records)

• Entra ID App Registration (to hold the FIC)

• XrmToolBox with the REST Builder plugin (to simplify record creation)

📘 Reference: Microsoft Learn — Set up Managed Identity in Dataverse

🪪 Step 1: Create a User Managed Identity in Azure

Run:

az identity create --name dataverse-plugin-mi --resource-group my-rg

Note down:

• Client ID

• Object ID

• Tenant ID

You’ll use them in Dataverse next.

🗂️ Step 2: Register the Managed Identity in Dataverse

I find XrmToolBox → REST Builder much easier to work with :)

1. Connect to your Dataverse environment

2. Open Dataverse REST Builder → choose POST/CREATE → entity name managedidentity.

3. Select the columns and provide the values as below:

{
  "applicationid" : "<applicationId, or ClientId on Entra", //I recommend using User Managed Identity
  "credentialsource" : "2" // Managed client,
  "subjectscope" : "1" // You can use devOnlyScope usually you would use EnvironmentScope
  "tenantid" : "provide your tenant Id"
}

4. Click Execute → the record is created

💡 REST Builder automatically handles OAuth headers.

I always recommend reviewing the EntityType Schema. Here’s the link for ManagedIdentity Table.

To learn how to use Dataverse Rest Builder, review the project website. Personally, I love XrmToolbox because of how easy it is to use. But you can always create records using Power Platform CLI.

If you are planning to use Power Platform CLI, do make sure to setup authentication. That will make it easier to interact with CLI. Here’s the link for pac auth command.

🔗 Step 3: Add a Federated Identity Credential (FIC)

The FIC links Microsoft Entra ID, your plugin, and the Managed Identity.

You can:

• Add it manually in the Azure Portal → App Registration → Certificates & Secrets → Federated Credentials

• Or automate it with PowerShell:

az ad app federated-credential create `
  --id <app-registration-client-id> `
  --parameters fic.json

⚙️ Automate FIC Creation (optional)

param(
    [string]$AppId,
    [string]$TenantId,
    [string]$subjectIdentifier,
    [string]$Name = “dataverse-fic”
)
az login
$json = @”
{
  “name”: “$Name”,
  “issuer”: “https://sts.windows.net/$TenantId/”,
  “subject”: $subjectIdentifier,
  “audiences”: [”api://AzureADTokenExchange”]
}
“@
$tmp = New-TemporaryFile
$json | Out-File $tmp
az ad app federated-credential create --id $AppId --parameters @$tmp
Remove-Item $tmp

Run once per environment. Example fic.json that you can create and use with Azure CLI.

Here’s the official documentation to understand the Subject Identifier.

{
  "name": "dataverse-fic",
  “issuer”: “https://login.microsoftonline.com/{tenantID}/v2.0”,
  “subject”: “<generate subject identifier>”,
  “audiences”: [”api://AzureADTokenExchange”]
} 

🚨 Heads-up: the next post dives into plugin signing with NuGet—don’t miss it.

🧩 Step 4 – Associate the Managed Identity Record with Your Plugin Assembly or Package

At this point you have:

1. A User Managed Identity in Azure

2. A Managed Identity record in Dataverse (created in Step 2)

3. A plugin assembly already registered

But Dataverse still doesn’t know which plugin assembly should use which managed identity.

We’ll do this with XrmToolBox → REST Builder.

What we’re doing

We will send:

• PATCH/UPDATE /api/data/v9.0/pluginassemblies(<PluginAssemblyId>)

• Body:

{
  “managedidentityid@odata.bind”: “/managedidentities(<ManagedIdentityGuid>)”
}

That single PATCH is what turns on managed identity for that plugin. Follow the steps below:

• Open XrmToolBox and connect to your Dataverse environment.

• Open REST Builder.

• In the top, select:

  • Method: UPDATE

  • URL / Entity: pluginassemblies(<PluginAssemblyId>)

• To get <PluginAssemblyId>:

  • Use REST Builder first with a GET pluginassemblies?$select=pluginassemblyid,name to find it.

• In the Body section, you will see below once your have provided your managed identity ID:

{
  “managedidentityid@odata.bind”: “/managedidentities(<ManagedIdentityGuid>)”
}

• Replace <ManagedIdentityGuid> with the GUID of the managed identity record you created in Step 2. (You can get this the same way — GET managedidentities?$select=managedidentityid in REST Builder, or just run that in your browser if you are logged in to the organization.)

• Click Execute.

• If the PATCH succeeds, your plugin assembly now has a managed identity bound to it.

🧠 Step 5: Use IManagedIdentityService in Your Plugin or Custom API

Now your plugin can request a token for any external API securely.

var miService = (IManagedIdentityService)serviceProvider.GetService(typeof(IManagedIdentityService));
var token = await miService.GetAccessTokenAsync(”https://api.coolapi.com/.default”);
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(”Bearer”, token);

That’s it! No secrets, no rotation.

📊 Step 6: Monitor the Flow

Plugin Trace Logs

• Enable “All” logging under Plugin Trace Settings.

• Add logger calls like logger.LogInformation(”Requesting token...”);

• Filter for YourPluginType to confirm activity

I highly recommend enabling application insights. You can read more about it here.

Application Insights

• Enable dependency tracking

• Use a Kusto query like:

dependencies
| where target contains “api.coolapi.com”
| order by timestamp desc

Two entries (login.microsoftonline.com and your API) mean token and call both succeeded.

🧰 Troubleshooting

FIC missing → Token request fails → Create FIC in App Registration
FIC mismatch → 401 or null token → Ensure subject matches the requirements.
Unauthorized → Wrong audience → Use https://api.coolapi.com/.default
External API denied → Token works but API rejects → Grant the UMI permissions in Azure or Easy Auth.

🧠 Check Microsoft Entra ID AD → Sign-in Logs → filter by App Registration to see failed token exchanges.

🧪 Behind the Scene

🚨 Quick Checklist

• Managed Identity record exists in Dataverse

• Audience is api://AzureADTokenExchange

• Plugin trace shows token retrieval

• External API returns 200 OK

• App Insights shows dependency telemetry

🧾 Summary

1️⃣ Create User Managed Identity in Azure.
2️⃣ Register it in Dataverse (via REST Builder).
3️⃣ Add Federated Credential in App Registration.
4️⃣ Use IManagedIdentityService for token access.
5️⃣ Monitor with trace logs and/or App Insights.
6️⃣ Troubleshoot with FIC and Azure logs.

🎯 Final Thoughts

Most tutorials end when the code compiles.
In production, the real success is visibility — knowing when the token request worked and when it didn’t.

By combining:

• Microsoft’s official setup steps

• XrmToolBox REST Builder for speed

• Application Insights for observability

• Clear FIC troubleshooting patterns

…you’ll build secure, secretless integrations that actually last.

💬 Enjoyed this guide? Subscribe for more Power Platform deep dives — covering Dataverse extensibility, telemetry, and real-world supportability engineering.

The other day, I hit a pothole. Nothing unusual there. We’ve all been there. But right after that bump, my windshield washer fluid light lit up on the dashboard. It wasn’t a big deal at first, until I noticed something else.

That light was now blocking my trip meter. And for some reason, that really bugged me.

So what’s the obvious thing to do?

Just add more windshield fluid, right? That’s probably what most people would try. But that’s not what I did.

Curiosity First

Before jumping into a fix, I wanted to understand what was actually going on. That’s where real troubleshooting begins.

• Was the washer fluid actually low?

• Were the wipers still working?

• Was there still water in the reservoir?

• And why on earth would hitting a pothole cause this in the first place?

That question stuck with me. Something didn’t add up. I started thinking maybe it wasn’t the fluid at all. Maybe it was a sensor. Maybe a connector came loose from the impact. Could I reach it? Could I fix it myself?

A Hands-On Investigation

So I did what any curious person would do. I got under the car to take a look.

Sure enough, I found the sensor. But like most car parts, it wasn’t exactly easy to get to. I would have to remove the underbody mat to see more clearly, and that meant dealing with those tiny plastic pins that tend to snap unless you’ve got extras. I didn’t have any on hand.

I took a good look at the sensor and its wiring. Everything looked intact, although the reservoir was slightly cracked. I tried adjusting the connector wire a bit. Still, I topped off the fluid just in case. Nothing changed. The light stayed on.

At that point, I was pretty confident the sensor had gone bad. Maybe it was already wearing out and the pothole just gave it a final nudge. Either way, it wasn’t reading correctly.

So I went to a local shop and had them disconnect it for now. The light disappeared and I got my trip meter back.

More Than Just a Fix

Here’s the thing. I didn’t actually fix the root issue. But I understood what caused it. And that was enough.

For me, the value wasn’t in pouring more fluid or replacing the sensor right away. It was in breaking down the problem and thinking it through step by step. That’s what good troubleshooting looks like.

It’s not about throwing a quick fix at the issue. It’s about asking the right questions, ruling things out, testing a few theories, and getting to the root of what’s really going on.

The Takeaway

Whether it’s a broken build, a leaky pipe, or a warning light on your dashboard, the mindset is the same.

Start by being curious. Not rushed.
Don’t assume. Investigate.

Because when you take the time to understand the problem, the solution usually finds its way to you.

Next time something goes wrong, don’t just fix it. Ask why it happened in the first place. That one question can open up a whole new way of seeing the world — and maybe even make you enjoy the problem-solving process a little more.

That’s something I’ve learned again and again—in code, in systems, and even in everyday life. The instinct to pause, observe, and go deeper is what separates a quick patch from a real resolution.

A Tech Example

Your build pipeline fails. Maybe your .NET project doesn’t compile on Azure DevOps. The natural instinct is to think, “It must be a cloud agent issue.” But wait—does it fail on your local machine too?

If not, the issue isn’t your code. It’s something about the hosted environment. If it does fail locally, now you’re on to something. Could it be a missing package, a bad path, a wrong version of the SDK?

You start peeling layers. You recreate the steps. You mimic the environment. You compare logs, configurations, build parameters. You go step by step.

That’s troubleshooting. It’s not about rushing to the answer—it’s about understanding the system, its state, and where it diverges from what you expect.

A Real-World Example

Let’s say your kitchen sink is pooling water. First reaction? Go buy some chemical drain cleaner and dump it in. But that’s not troubleshooting—that’s trial-and-error with a price tag.

Instead, stop and ask: Why is the water pooling? Where’s the trap? Is it blocked? What’s the principle of how this pipe system works?

You take a wrench. You place a bowl underneath. You loosen the trap. You inspect. Maybe it’s food scraps or grease buildup. You clean it, reassemble, test—and now you not only solved it, but you understand how it works. You’ve learned something.

That’s what matters. Not just solving, but understanding.

Be Methodical

When you’re troubleshooting anything, it’s critical to be methodical. Start with a few simple questions:

• What exactly is the problem?

• When did it start happening?

• What changed?

• Can I isolate it? Can I reproduce it?

You don’t panic. You don’t jump to the most complex fix. You walk through it. You verify assumptions. You understand.

Because once you understand a system—really understand it—the solution often reveals itself. It’s not magic. It’s not guesswork. It’s clarity.

The Mindset

This mindset—to troubleshoot, to explore, to be curious—applies to everything. A flaky Wi-Fi connection. A sudden drop in app performance. A teammate who seems off.

It all starts with a willingness to go one level deeper, to ask, what’s really going on here?

If you want to go far—in engineering, in leadership, in life—learn to go one step forward. Don’t rush past the problem. Sit with it. Study it.

Understanding is the path. Curiosity is the spark.

What Does Troubleshooting Mean to Me?

For me, troubleshooting is so much more than just following a manual. It’s about getting curious, digging deep into problems, asking questions others might not think of, and trying to understand why things work—or why they suddenly stop working.

Whether it’s a technical issue at work, a warning light in my car, or a stubborn kitchen sink, I like to approach every challenge with curiosity, a clear method, and a refusal to settle for quick fixes.

About This Series

This post is the beginning of a new series where I’ll share how I think, solve, debug, and yes, sometimes even make mistakes. I want this to be for everyone—whether you work in technology or just enjoy the satisfaction of figuring things out.

What You Can Expect

Here’s what I’ll be writing about:

• Real-world tech debugging stories, including some from systems you might use every day

• Everyday problems at home that I’ve solved (and what I learned along the way)

• The mindset that turns frustration into fascination

No fluff. No clickbait. Just honest stories and practical strategies about one of the most valuable skills out there: troubleshooting.

Stay tuned, and let’s explore and solve mysteries together, one problem at a time.

That’s where Federated Identity Credentials (FIC) come to the rescue! This feature in Microsoft Entra ID (formerly AAD) lets your applications authenticate to Azure resources without needing to store any secrets or certificates. It’s a game-changer for improving security and reducing operational headaches.

Deep dive on FIC in Microsoft Learn →

What is a Federated Identity Credential?

In our case, it’s about trusting a workload (like a managed identity) to authenticate as a specific AAD app registration. Instead of using a secret or certificate, the workload presents a token to AAD, which verifies the trust and issues an access token for the app registration.

This means your application, now armed with this new access token, can authenticate to other Azure resources without a hitch. It’s a secure, seamless, and secret-free way to manage your app’s identity.

Our Scenario: Ditching Secrets with a Managed Identity

Let’s walk through a practical example of how to implement this. We’ll use a User-Assigned Managed Identity (UAMI) to federate with an Azure App Registration. This UAMI will then be assigned to an Azure App Service, allowing our application to authenticate to other Azure resources.

Here’s the flow we’ll set up:

• Create an App Registration: This will be the main identity of our application.

• Add a Federated Credential: We’ll add a FIC to the app registration, linking it to our UAMI.

• Assign the UAMI to the App Service: The App Service will now use the UAMI.

Now, let’s dive into the details.

Step 1: Create an App Registration

First, you’ll need an App Registration in your Azure Active Directory. This is the application’s identity. Give it a name, and that’s it! No need to create any secrets or certificates here.

Step 2: Add the Federated Identity Credential

This is where the magic happens. Navigate to your App Registration, go to the Certificates & secrets blade, and click on the Federated credentials tab. Here, you’ll add a new credential.

• Scenario: Select Azure services

• Service: Choose Managed identity

• Managed identity: Select the User-Assigned Managed Identity you want to federate with.

Step 3: Assign the Managed Identity to the App Service

Now, go to your App Service, navigate to the Identity blade, and select the User assigned tab. Add the same UAMI you used in the previous step.

That’s it! Your App Service is now configured to use the UAMI, which has a federated trust with your App Registration.

How the Authentication Flow Works

Now that everything is set up, let’s understand the flow:

1. When your application running on the App Service needs to authenticate, it uses the User-Assigned Managed Identity.

2. The UAMI requests a token from Azure AD, which verifies its identity.

3. The UAMI then uses a special token as an assertion to acquire a new access token for the App Registration. This is the core of the federated identity.

4. Your application, now holding the App Registration’s access token, can securely call other Azure services or APIs that are configured to accept this identity.

This entire process happens seamlessly behind the scenes, without your application ever needing to handle or store a secret.

The Code: DefaultAzureCredential to the Rescue

The best part? The Azure SDKs are designed to handle this complexity for you! Your application will automatically detect that it’s running in an environment with a managed identity and use it to authenticate.

Here’s a simple C# code snippet that shows how easy it is to authenticate to Azure Key Vault using IManagedIdentityApplication:

    using Microsoft.Identity.Client;
    using System.Threading.Tasks;
    using System;

    // This is the Client ID of the App Registration with the Federated Credential.
    string appRegClientId = “YOUR_APP_REGISTRATION_CLIENT_ID”;
    // This is the Tenant ID of your Azure Active Directory.
    string tenantId = “YOUR_TENANT_ID”;
    // This is the Client ID of the User-Assigned Managed Identity.
    string managedIdentityClientId = “YOUR_MANAGED_IDENTITY_CLIENT_ID”;
    // The scope of the token you want to acquire (e.g., for Microsoft Graph).
    string[] scopes =
    {
        “https://graph.microsoft.com/.default” //YOUR_KEY_VAULT_URI
    };
    // 1. Explicitly create the ManagedIdentityId object for the user-assigned identity.
    ManagedIdentityId managedIdentityId = ManagedIdentityId.WithUserAssignedClientId(managedIdentityClientId);
    // 2. Create the IManagedIdentityApplication using the builder and the managedIdentityId object.
    IManagedIdentityApplication miApp = ManagedIdentityApplicationBuilder.Create(managedIdentityId).Build();
    // 3. Define a function to generate the client assertion AND pass within WithClientAssertionMethod as Async Func
    // 4. Use ConfidentialClientApplicationBuilder to create the client with the assertion.
    IConfidentialClientApplication app = ConfidentialClientApplicationBuilder.Create(appRegClientId).WithTenantId(tenantId).WithClientAssertion(async (AssertionRequestOptions options) =>
    {
        AuthenticationResult miResult = await miApp.AcquireTokenForManagedIdentity(”api://AzureADTokenExchange”).ExecuteAsync();
        return miResult.AccessToken;
    }).Build();
    try
    {
        // 5. Acquire the token for the desired scope using the confidential client.
        AuthenticationResult finalResult = await app.AcquireTokenForClient(scopes).ExecuteAsync();
        Console.WriteLine($”Token acquired successfully! Token length: {finalResult.AccessToken.Length}”);
    }
    catch (MsalException ex)
    {
        Console.WriteLine($”Error acquiring token: {ex.Message}”);
    }

Important: You need to replace “YOUR_MANAGED_IDENTITY_CLIENT_ID” with the Client ID of your User-Assigned Managed Identity and “YOUR_KEY_VAULT_URI” with your Key Vault URI.

Learn more about ClientAssertion Function here

A Final Word

Adopting Federated Identity Credentials with Managed Identities is a significant step towards a more secure and maintenance-free application lifecycle. You can say goodbye to those outages about expired credentials and hello to a more robust and reliable process.

For more in-depth information, be sure to check out the Microsoft Learn documentation on Federated Identity Credentials! 📚

Happy coding! ✨

Have you ever struggled with documentation? What if I told you that you could build a professional-looking docs site without writing a single line of code? Enter DocFX, a powerful tool that transforms Markdown and YAML into a structured, searchable, and beautifully rendered documentation site.

Getting Started

Before diving in, let’s grab our power tools:

• PowerShell for command-line execution

• DocFX for site generation

• Markdown/YAML for content structuring

• Azure DevOps or GitHub Repos (optional) for version control

Step-by-Step Guide

• Install DocFx using PowerShell, or Dotnet commands.

dotnet tool install docfx --global
docfx init -q

• Customize Your Configuration Modify docfx.json to define content sources, templates, and metadata.

{
    “build”: {
        “content”: [
            {
                “files”: [
                    “*.{md,yml}”,
                    “**/*.{md,yml}”
                ]
            }
        ],
        “resource”: [
            {
                “files”: [
                    “.attachments/**”,
                    “images/**.{ico,png}”,
                    “*.{ico,png}”,
                    “scripts/**.{js}”,
                    “web.config”
                ]
            }
        ],
        “globalMetadata”: {
            “_appTitle”: “apurvghai.com”,
            “_appLogoPath”: “images/logo.png”,
            “_appFaviconPath”: “favicon.ico”,
            “_enableSearch”: true,
            “_enableNewTab”: true,
            “_gitContribute”: {
                “repo”: “https://github.com/<yourrepoUrl>”,
                “branch”: “master”
            },
            “_appFooter”: “Built using DocFx”
        },
        “template”: [
            “default”,
            “templates/material”
        ],
        “postProcessors”: [
            “ExtractSearchIndex”
        ],
        “force”: true,
        “dest”: “docs”,
        “globalMetadataFiles”: [],
        “fileMetadataFiles”: [],
        “markdownEngineName”: “markdig”,
        “noLangKeyword”: false
    }
}

• Organize Your Files Structure your folders to align with your documentation needs.

- firstDocFxSite
- images
- src
 - AnotherFolder
   - Sub-Article-1.md
   - Article-1.md
   - Getting-Started.md
 - docfx.json
 - index.md
 - toc.yml

• Create a Table of Contents (TOC) Define navigation using toc.yml for seamless browsing.

• Add following content into your root\toc.yml

- name: apurvghai.com 
  href: something.md

• Add following content into your root\src\toc.yml

    - name: Intro 
      href: ../index.md 
    - name: Getting Started 
      href: Getting-Started.md 
    - name: Article 1 
      href: Article-1.md 
      items: 
        - name: Sub-Article-1.md 
          href: AnotherFolder/Sub-Article-1.md 

• Build & Preview Locally Run:

docfx docfx.json --serve --force

Build using Azure DevOps Pipelines

For advanced users looking to automate website deployment to Azure, configuring a release pipeline with YAML offers a streamlined approach.

By leveraging Azure DevOps Pipelines, you can set up a fully automated workflow that builds, validates, and deploys your DocFX-generated site effortlessly.

Below is a YAML pipeline snippet that can be used to build the site, particularly useful for a Pull Request build.

- task: AzureCLI@2
  inputs:
    scriptType: ‘pscore’
    scriptLocation: ‘inlineScript’
    inlineScript: |
      # Install the tool
      dotnet tool install docfx --global
      
      docfx docfx.json --build --warningAsErrors true

Let your documentation speak for itself—securely, automatically, and effortlessly.

In this article, we’ll explore how to integrate with the Power BI REST API, focusing on authentication and programmatic access. Whether you’re a developer, data analyst, or IT professional, this guide will help you take the right steps to connect securely to the Power BI service. The concepts here are language-agnostic, so you can adapt them to your preferred programming environment.

Prerequisites

Before you begin, ensure you have the following:

• Postman (for testing API requests)

• Basic understanding of OAuth2

• Access to the Azure Portal

Step 1: Register an Application in Azure and Assign Permissions

To interact with the Power BI API, you must first register an application in Azure Active Directory and grant it the necessary permissions.

• Register your application:
  Follow the official Microsoft guide to register your app.

• Assign API permissions:
  The permissions you need depend on the API endpoints you intend to use. For example, to query workspaces, assign either Workspace.ReadWrite.All or Workspace.Read.All.

  You can find a complete list of Power BI API permissions here.

Note:
Most Power BI API permissions require delegated access.

Step 2: Obtain an Access Token Using Postman

You can authenticate using either the Authorization Code flow or Client Credentials. For demonstration, we’ll use Postman with the Resource Owner Password Credentials (ROPC) grant type.

Request:

POST https://login.microsoftonline.com/<your-tenant-id>/oauth2/token
Body (x-www-form-urlencoded):
    grant_type: password
    username: <your-username>
    password: <your-password>
    client_id: <your-application-id>
    client_secret: <your-client-secret>
    resource: https://analysis.windows.net/powerbi/api
    scope: Workspace.Read.All User.Read

Once you send the request, you’ll receive an access token.

Tip:
If you use ADAL libraries, the grant_type=password flow is not supported. Instead, use the User Credential class.

Use the access token to make authorized API calls.

Example API Call:

GET https://api.powerbi.com/v1.0/myorg/admin/groups?$top=1
Headers:
    Authorization: Bearer <your-access-token>

Sample Response:

{
  “@odata.context”: “http://wabi-us-central-a-primary-redirect.analysis.windows.net/v1.0/myorg/admin/$metadata#groups”,
  “@odata.count”: 2,
  “value”: [
    {
      “id”: “F769F2BB-9825-4B11-8705-998FAF1F8B22”,
      “isReadOnly”: false,
      “isOnDedicatedCapacity”: false,
      “capacityMigrationStatus”: “”,
      “type”: “Workspace”,
      “state”: “Active”,
      “name”: “Sample Workspace”
    }
  ]
}

Step 3: Authenticate Using PowerShell (Non-Interactive / Service Principal)

For server-to-server scenarios, use an Azure Service Principal for non-interactive authentication.

Prerequisites

• Create a client secret for your Azure application.
  How to create a service principal

• Enable service principal access in Power BI:

  • Go to the Power BI Admin Portal.

  • Navigate to Tenant Settings.

  • Enable “Allow service principal to use Power BI APIs”.

  • Add your app to the required security group.

  Read more about using service principals with Power BI

• Authorize your app to access workspaces:
  Use the Power BI PowerShell module to assign roles.

Example PowerShell Script

# Install Power BI Module (if not already installed)
Install-Module MicrosoftPowerBIMgmt.Workspaces

# Login interactively
Login-PowerBI

# Service Principal Object ID
$SPObjectId = ‘36......’

# Get the workspace
$pbiWorkspace = Get-PowerBIWorkspace -Name “<Name of workspace>”

# Confirm workspace details
Write-Host $pbiWorkspace

# Add Service Principal as Admin or Member
Add-PowerBIWorkspaceUser -Id $pbiWorkspace.Id -AccessRight Admin -PrincipalType App -Identifier $SPObjectId

Step 4: Test Your Integration

You can now test your setup using the following PowerShell script, which demonstrates how to obtain a token and trigger a dataset refresh:

# Login to Azure CLI
az login

# Retrieve secret from Azure Key Vault
$secretData = az keyvault secret show --vault-name ‘<your-keyvault-name>’ --name ‘<your-secret-name>’ | ConvertFrom-Json | Select value

$ClientId = “<Your Client ID/ApplicationId>”
$ClientSecret = $secretData.value
$loginURL = “https://login.microsoftonline.com”
$tenantdomain = “<your-tenant-domain>”
$scope1 = “https://analysis.windows.net/powerbi/api/.default”
$clientSecret = (ConvertTo-SecureString $ClientSecret -AsPlainText -Force)
$msal = Get-MsalToken -clientID $ClientId -clientSecret $clientSecret -tenantID $tenantdomain -Scopes $scope1
$accessToken = $msal.AccessToken

# Prepare headers
$AuthHeader = @{
  ‘Content-Type’  = ‘application/json’
  ‘Authorization’ = “Bearer $($accessToken)”
}

# Set Power BI API URL
$URI = “https://api.powerbi.com/v1.0/myorg/groups/<YourGroupId>/datasets/<YourDataSetId>/refreshes”

# Trigger dataset refresh
Invoke-RestMethod -Uri $URI -Headers $AuthHeader -Method POST

Conclusion

With these steps, you should be able to authenticate and interact with the Power BI REST API programmatically, whether using Postman, PowerShell, or your preferred programming language. If you have any questions or want to share your experience, feel free to leave a comment!

Happy coding!

The Shift to Substack

Today marks an exciting new chapter in my blogging journey. I’m officially moving to substack, complete with a custom domain and all the bells and whistles that come with it.

The Blog Archive: A Treasure Trove of Knowledge

I’m not porting most my posts over, except few. Most of my previous work lived on MSDN, and when Microsoft transitioned those to Microsoft Learn, they found a new home here. While Dynamics has evolved quite a bit since then, there are still some gems in that archive that remain relevant today. If you’re passionate about CRM development, OAuth authentication, Web API integrations, and more, I hope you find the archive useful.

What’s Next?

This shift doesn’t mean I’m slowing down. Quite the opposite — I’m excited to bring fresh insights, new experiments, and deeper technical explorations to Substack. If you’ve followed my journey so far, I promise to keep delivering content that keeps you engaged, learning, and experimenting right alongside me.

To all my fellow technical programmers out there — here’s to the next phase. Let’s build, break, and learn together. 🚀