Author: Manjunath

Need a long-lasting client secret for a non-production app? Here are two ways to create a secret that mimics no expiry — ideal for automation, CI/CD, or UAT setups.

✅ Option 1: Azure CLI

Use this for a quick and easy credential reset:

az ad app credential reset --id ********-****-****-****-************ --years 299 --append --display-name uat-automation-secret-longterm

• --years 299: Secret valid for ~299 years
• --append: Keeps existing secrets
• --display-name: Helps identify the secret

🔄 Option 2: Microsoft Graph API (addPassword)

You can also use Microsoft Graph’s addPassword endpoint for full control.

POST Request

POST https://graph.microsoft.com/v1.0/applications/{app-id}/addPassword
Authorization: Bearer <token>
Content-Type: application/json

Request Body

{
  "passwordCredential": {
    "displayName": "uat-automation-secret-longterm",
    "endDateTime": "2324-07-17T23:59:59Z"
  }
}

Tip: endDateTime is in UTC format. Set a far future date (e.g., 299 years ahead) to mimic “no expiry”.

⚠️ Security Reminder

• Use only in non-production scenarios
• Store secrets in Key Vault, not in code
• Prefer Managed Identity or Federated Credentials for production

Both methods are effective — choose the one that fits your environment or automation strategy.

If you’re integrating Azure Logic Apps Standard with a VNet and private endpoints, you may encounter this nasty error after deploying your app or modifying your networking configuration:

Access to the path ‘C:\home\data\Functions\secrets\Sentinels’ is denied.

Despite following Microsoft’s recommended steps, the issue may persist. In this post, I’ll break down the actual root causes, explain why the error happens, and offer a practical trick that can resolve it, especially after switching from public to private networking.

🔍 Root Cause

This error usually happens when:

• Your Logic App is moved from public access to a VNet-integrated private network.
• The storage account (used to host runtime content and secrets) has private endpoints enabled, but DNS or firewall rules aren’t set up properly.
• Deployment tools like ARM or Terraform don’t handle the WEBSITE_CONTENTOVERVNET setting correctly during creation.

✅ Microsoft Recommendations to Try First

1. Enable WEBSITE_CONTENTOVERVNET = 1 in Configuration settings of the Logic App.
2. Ensure the storage account has:
   • VNet access with correct subnet delegations
   • Private DNS zone linked to your VNet (file, blob, queue, table)
3. Enable “Allow storage account key access” in the storage account’s Configuration blade.
4. If using ARM or Terraform:
   • Separate your appSettings into a nested resource of type [Microsoft.Web/sites/config]

But here’s the truth: Even after doing all this, the error may still appear.

🛠️ Trick That Actually Works

If you’re stuck and everything seems configured correctly, try this workaround that’s helped in many real-world deployments:

💡 Scale up your Logic App to WS2 tier temporarily and then scale it back down to WS1.

Why this works:

When switching from public to private storage/VNet, the Logic App runtime may get “stuck” in an inconsistent state, especially regarding storage path mounting or internal config sync.

Scaling up to WS2 forces:

• A runtime refresh
• A full reinitialization of the hosting environment
• Resync of private DNS/storage endpoints

🚀 Step-by-Step: Fix It

1. Go to your Logic App resource.
2. Navigate to Scale Up blade.
3. Change SKU to WS2 (higher tier) and hit Apply.
4. Wait until the deployment is successful (1–2 mins).
5. Now go back and revert the SKU back to WS1.

✅ After this step, your Logic App should restart and mount the secret paths correctly.

🧠 Final Thoughts

This issue is not well-documented, but it’s common when moving to private networking in enterprise deployments. Logic Apps tightly depend on the underlying storage account, and improper sync between the app’s network context and the storage endpoints can lead to the above error.

Scaling the app up and down is a safe way to force the platform to re-establish all bindings.

📌 Quick Checklist

• ✅ VNet Integration configured
• ✅ Private endpoints enabled for Storage Account
• ✅ Private DNS zones linked
• ✅ WEBSITE_CONTENTOVERVNET = 1
• ✅ Allow storage account key access
• ✅ Storage access via system-assigned managed identity
• ✅ Scale-up and scale-down trick applied

💬 Have You Faced This?

Drop your experience or questions in the comments — Azure networking errors can be painful, but you’re not alone!

The following table compares Power Query Join Kinds with their equivalent SQL Join types. Each join kind is explained with a visual icon and SQL analogy.

If you’ve ever tried to connect to Exchange Online using PowerShell and hit a brick wall, you’re not alone. I recently ran into two frustrating errors while using Connect-ExchangeOnline, and after a lot of head-scratching (and Googling), I finally found a clean, working solution.

Let me walk you through what went wrong and how you can fix it — especially if you’re working in a non-interactive or automation-heavy environment.

⚠️ Error #1: “A window handle must be configured”

This was the first error I got when running a simple connection command:

A window handle must be configured. See https://aka.ms/msal-net-wam#parent-window-handles

This usually happens when PowerShell tries to use Windows Web Account Manager (WAM) to launch a browser-based login — but there’s no interactive UI available. If you’re running a script in a headless setup (like Azure Automation, GitHub Actions, or a remote server), this error is a dead end.

🔧 Tried Fix: Using -DisableWAM

Disabling WAM seemed like a logical next step. I ran:

Connect-ExchangeOnline -DisableWAM

But that only led me straight into this new error:

Failed to connect to Exchange Online: An HttpListenerException occurred while listening on http://localhost:49747/ for the system browser to complete the login.

It also suggested running this from an admin shell:

netsh http add iplisten 127.0.0.1

But honestly? That felt like duct-taping the problem instead of solving it.

✅ The Real Fix: Use an Access Token Instead

After some digging, I found a better way — one that doesn’t depend on browser pop-ups, localhost listeners, or WAM. The trick is to generate an access token using your Azure AD app and pass it directly to the Connect-ExchangeOnline command.

📌 Step 1: Register an Azure App

1. Go to Azure Portal → App Registrations.
2. Create a new app registration.
3. Under “API Permissions”, add Exchange.ManageAsApp.
4. Create a client secret or upload a certificate (for secure token access).

🛠 Step 2: Generate Access Token via PowerShell

$tenantId = "<your-tenant-id>"
$clientId = "<your-client-id>"
$clientSecret = "<your-client-secret>"
$scope = "https://outlook.office365.com/.default"

$tokenResponse = Invoke-RestMethod -Method Post -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" `
    -Body @{
        client_id     = $clientId
        scope         = $scope
        client_secret = $clientSecret
        grant_type    = "client_credentials"
    }

$accessToken = $tokenResponse.access_token

🔗 Step 3: Connect Using the Token

Connect-ExchangeOnline -AccessToken $accessToken -Organization "<your-tenant-domain>"

And that’s it — no browser, no WAM, no port listeners. Just a clean, programmatic login.

💡 Pro Tips

• This method is great for automation scripts in environments like Azure Automation, GitHub Actions, or even headless servers.
• Make sure your app has the right permissions and you’ve granted admin consent in Azure AD.
• This method is meant for admin tasks, not user mailbox actions (like reading emails).

🧩 Wrapping Up

If you’re facing authentication issues with Connect-ExchangeOnline, don’t waste hours trying to debug listener ports or browser issues. Switching to access token-based authentication saved me so much time — and now my scripts run flawlessly, even in automated pipelines.

Got questions? Drop them in the comments below — happy to help!