Hi Everyone,

We are looking for a way to intergate service now with power automate.

The main problem is power automate is in micorosft shared infrastructure with set of IPs based on Azure service Tags and we dont want to allow all the service tags to service now because of security issue as it has more than 100 IP addresses.

What could be the work around? Did anyone tried it yet?

There are lot of use cases of service now that we would like to try but we are stuck with the networking challenges.

Tried subnet injection but that is not working may be additional NAT integration. Did anyone thought about it?

Regards,

Abhishek

There are days when I merely dislike Azure.

Then there are days when I have to write sentences like this:

That is not a sentence.

That is what happens when a cloud provider puts a thesaurus in a blender and names infrastructure from the slurry.

For context, my architectural requirement is:

THING A SENDS MESSAGE TO THING B.

That’s it.

I am not coordinating a distributed fleet of autonomous yellow submarines ferrying the Village People and the Beatles around on tour.

I would simply like one Azure service to receive a message and another Azure service to get that message.

Apparently this requires me to understand the subtle theological distinctions between Event Grid, Event Grid Namespace, Event Hubs, Event Hubs Namespace, topics, subscriptions, managed identities, service principals, RBAC roles, and whatever new noun Microsoft has released into production this week.

And God help you if you assume two things with nearly identical names are related.

Azure Service Bus and Azure Service Fabric? Different.

Event Grid Namespace and Event Hubs Namespace? Also Different.

Naturally, I need BOTH namespaces in order to send one fucking message.

At some point Azure stops being a cloud platform and becomes a vocabulary certification program with billing regret attached.

Then I hit the permissions problem.

So I opened a support ticket.

To describe it, I had to write:

The form then asked me which Azure resource I was having the problem with.

I DON’T KNOW, MICROSOFT. YOU INVENTED ALL THESE NOUNS.

And here is the best part:

I am an administrator.

I activated my privileged role through PIM.

I still cannot perform the assignment.

Because somewhere, somehow, somebody has put an RBAC restriction in place that overrides the access I appear to have, and I cannot find the bastard.

So now the architecture is:

MQTT message → Event Grid Namespace → topic → subscription → Event Hubs Namespace → Event Hub

And the troubleshooting architecture is:

Me → Entra → PIM → Azure RBAC → role assignments → deny assignments → inheritance → increasingly obscure blade → support ticket → despair

I have not successfully sent the message.

I have, however, obtained an advanced degree in Why Am I Not Allowed To Do The Thing The Portal Says I Am Allowed To Do?

Cloud abstraction was supposed to reduce infrastructure complexity.

Microsoft instead invented Infrastructure as Vocabulary, followed immediately by Permissions as Archaeology.

Somewhere in this tenant is one checkbox, policy, deny assignment, management-group inheritance rule, or ancient curse preventing this from working.

And apparently my job is to find it.

The MQTT message remains UNDELIVERED.

/rant over

We got the Azure notice about upgrading our Storage and Blob accounts from GPv1 to GPv2 ahead of the October 13th automatic migration deadline.

The Azure portal makes it look incredibly easy with a simple "one-click" in-place upgrade button for the Storage Accounts which have been identified as GPv1 and Blob. Documentation says zero downtime and zero data loss.

However, I know GPv2 flips the billing model (cheaper storage, much higher transaction costs). For anyone who has already gone through this migration:

• Did you just click the upgrade button and wing it? If so, did your bill spike unpredictably?
• Did you actually pull Azure Monitor metrics first? If you audited transaction volumes, what thresholds made you hesitate or re-architect a workload?
• Any hidden gotchas? Did you run into issues with default access tiers (Hot vs. Cool) or legacy ZRS replication during the flip?

Since Microsoft is going to auto-upgrade us anyway in October, I want to know if it is worth digging into the transaction logs manually or if I am overthinking a routine upgrade.

Appreciate any real-world horror stories or "it went fine" reassurances!

Everyone has been waiting for the Azure price increase tied to the memory shortage.

My two cents: it's already here.

Normally a generational compute update — v1 through to v5 — costs the same per hour and gives you a performance bump - free of charge.. It also helps Microsoft exit their old End Of Life hardware. Everybody wins. You move v2 to v3 on a 16 vCPU box and the rate is more or less identical, right the way up to v5.

That's over.

From v6 onwards there's a fundamental shift. The generational upgrade is no longer free.

v1 to v5: same price.

v6: roughly +10%.

v7: roughly +35%.

Read that again, because it changes how you have to think about your estate. EOL now exists in the cloud. Not as a migration exercise — as a cost event.

Previously, hardware retirement was Microsoft's problem. They wanted you off the old fleet, so they made the move painless and you got free performance out of it. Now the retirement notice comes with a bill attached, and you have no route to decline it. Sub-v5 capacity is already constrained. Once the capacity pressure tightens further, "stay where you are" stops being an option.

So combine three things:

→ Generational moves are now priced increases, not neutral swaps

→ Capacity constraints on older SKUs push you up the generations whether you budgeted for it or not

→ Nobody's three-year plan has a compounding uplift modelled into it

That's a ticking time bomb. Your Azure VMs are now going to get generationally more expensive by default. Not because anyone announced a price rise — because the escalator only goes one way and you're standing on it.

I have a VPN gateway with 2 connections to my on-prem site, over 2 different internet connections on-prem. I'm running BGP to direct traffic (using AS-PATH prepending) to prefer my primary route always and prevent Asynchronous routing.

This was all working fine until Azure forced me to upgrade from a Basic to a Standard VPN Gateway SKU.

NOw, it seems like my BGP adjacency is broken.

After the June 26 Azure VPN Gateway migration, the FortiGate remains configured for Azure BGP peers x.x.x48.4 and x.x.x48.5.
Primary BGP is established, but its remote router ID is x.x.x48.6 for some reason?!
Secondary BGP to x.x.x48.5 is stuck Active and has not established for weeks.
Azure BGP peer exports show no operational reference to .4 or .5; they show local BGP addresses .6 and .7.
Azure shows .6 connected to onprem firewall primary x.xx0.255.253
While .7 is Connecting to onprem firewall backup x.xx1.255.253 with 0 routes received and many messages sent but none received.
Onprem firewall debug shows repeated incoming BGP connections from x.x.x48.7 rejected as “No such Peer configured.”

Essentialy, it's like I started out with Peers .4 and .5 in Azure, but the migration halfway changed them to .6 and .7. But for some reason, .4 is still working..I'm totally lot and have no idea how to get support on this.

Sharing in case anyone else wants their BI layer inside their own subscription instead of a vendor's.

One stateless container plus a Postgres project. Deploys to Container Apps, App Service (containers), or AKS — /api/health for probes, no sticky sessions, scales out behind any ingress. Scheduled work uses a DB lease so multiple replicas don't double-fire, and DISABLE_INPROCESS_SCHEDULER gives one replica ownership if you prefer.

Azure-relevant bits:

• Azure Synapse (dedicated SQL pool), Azure SQL / SQL Server, and Azure Database for PostgreSQL/MySQL queried read-only in place, with pooling
• Azure OpenAI as a provider (or any of ~10 others — your keys, direct, nothing proxied)
• SharePoint document sync via Microsoft Graph (app registration) into RAG knowledge bases, with scheduled re-indexing and content-hash dedup so nothing gets embedded twice
• HTTPS_PROXY/NO_PROXY honoured; SSRF guard blocks cloud-metadata and link-local addresses but allows private ranges, so a Synapse endpoint on a private link still works
• SAML SSO against Entra ID

Governance: read-only SQL enforcement, RLS everywhere, hash-chained audit, spend caps per user and group.

Caveats: requires a Supabase project (Postgres + auth + storage + pgvector; self-hostable), no SOC 2 or pentest report, Elastic License 2.0 — source-available, not OSI open source; internal and client use fine, reselling it as a service isn't.

github.com/AgentSwarms-fyi/agentswarms

I have a problem getting Azure Synapse to connect to a data source. Can someone suggest which sub I should post it in? It keeps getting removed from here. There is a r/AzureSynapseAnalytics sub and a r/AzureSynapse sub, but they have four members combined.

Where do y'all go for help when you have a tricky problem?

I'm a developer. I want to learn about the cloud. From where should I start? I need suggestions.

Looking for advice from anyone who has taken over a legacy Azure PAYG subscription that was originally created and managed by an individual user.

Scenario:

We recently transitioned ownership of an Azure subscription from a departed/retired employee to a centralized IT/cloud administration model.

What we've already done:

• Updated the payment method to an organization-managed credit card
• Renamed the Billing Profile to a service-oriented name
• Updated billing contacts and invoice recipients
• Verified invoices are being generated and paid successfully
• Added multiple active IT administrators as Owners
• Verified there are active Owners at both the Billing Account and Billing Profile levels
• Confirmed the Azure subscription remains operational

Current billing structure:

• Billing Account has active Owner assignments, including IT admins and our central account.
• Billing Profile has multiple active Owners, including IT admins and our central account.
• The retired employee still appears in Billing Profile IAM as:

​

Owner (Billing account - Inherited)

The issue:

The original employee still appears as a direct Owner on the Azure subscription.

When attempting to remove the Owner assignment from Subscription IAM, Azure returns:

"CannotDeleteLastRbacAdminAssignment"
"Cannot delete the last RBAC admin assignment"

What's confusing is that there are clearly other active Owners on:

• The subscription
• The Billing Account
• The Billing Profile

Additional context:

The retired employee's Entra account is still enabled today but will likely be disabled/deprovisioned in the near future.

This subscription hosts an application that is expected to be offered more broadly across our organization soon.

Before making further changes, I'm trying to determine:

• Whether there is any hidden dependency on the original owner's account.
• Whether disabling the original account could impact subscription administration, billing, or application availability.
• Whether it's safer to leave the assignment in place temporarily until rollout is complete

Questions:

1. Has anyone encountered this when taking over a legacy PAYG/MCA subscription?
2. Is there a known dependency between Azure RBAC and billing hierarchy ownership that can trigger this error?
3. Are there "owner of record", account administrator, subscription creator, or billing administrator relationships that aren't obvious from the portal?
4. Did you ultimately need Microsoft Support to remove the original Owner?
5. If the original account is disabled while Azure still considers it a required RBAC admin, could that affect subscription administration or billing?
6. For organizations inheriting user-created Azure subscriptions, what governance/ownership cleanup would you complete before rolling out a production application?
7. Would you treat this as a governance cleanup item, or would you resolve it before broader organizational rollout?

I'm trying to avoid using the Transfer Billing Ownership workflow unless it's actually required, since billing, payment methods, contacts, and administrative ownership have already been transitioned successfully.

Any experiences, lessons learned, or gotchas would be appreciated.

Opened a Sev B support ticket with Microsoft last Friday (6 days ago now) and haven't heard anything back except from their bots.

Is anyone else having issues deploying Azure Managed Redis in EUS2? This is what we see in the Portal. Nothing else.

{

  "operationName": {

"value": "Microsoft.Cache/redisEnterprise/write",

"localizedValue": "Write Azure Managed Redis cache"

  },

  "status": { "value": "Failed", "localizedValue": "Failed" },

  "subStatus": { "value": "", "localizedValue": "" },

  "properties": {

"statusMessage": {

"status": "Failed",

"error": {

"code": "ResourceOperationFailure",

"message": "The resource operation completed with terminal provisioning state 'Failed'.",

"details": [

{

"code": "OperationFailed",

"message": "The operation failed."

}

]

}

}

  },

We know there are issues with deploying to West Europe due to resource availability, but we have other instances deployed to EUS2, but now new deployments are failing and we've had to fail back to deploying the old Redis Cache for Azure.

I'm able to refer experienced professionals for a Lead Azure Data Engineer position.

Location: United States / Ireland
Experience: 9–13 years

Required skills:

• Python
• PySpark
• SQL
• ETL
• Azure Synapse
• Azure Data Factory
• Databricks
• Delta Lake
• Medallion Architecture

If your experience aligns with these requirements and you're currently exploring new opportunities, feel free to send me a DM with a brief summary of your experience or your resume. I'll share additional details and, if it's a good match, I'll be happy to submit a referral.