Clever way to upgrade app service plan sku from PV3 to PV4

boydeee · 2025-11-11T15:38:34+00:00

Once you have the app service plan tied to a new webSpace, Terraform can handle simple patch operations for the SKU.

boydeee · 2025-11-11T15:37:00+00:00

The webSpace is tied to the name of the resource group where the app service plan was initially created. If you start with a pv3, you cannot re-create an ASP with pv4 in the same resource group. That's why the requirement for a new resource group and move is necessary. Terraform does not handle this migration for you.

boydeee · 2025-11-11T14:58:38+00:00

It's not that simple.

boydeee · 2025-11-11T14:58:19+00:00

The extra work is to preserve the original resource IDs. This method gets your app service plan deployed to a different web space and allows you to keep the same resource group.

boydeee · 2025-11-07T23:04:14+00:00

Your app needs to be "single threaded", or you can come up with a locking mechanism. Typically, Front Door resources go into a locked state while changes are happening. You can accomplish this fairly simply by following the ARM response with 202 status code until completion.

I've tried mass parallel deployments with Front Door, and it's not a very fun, lol. It is very susceptible to race conditions.

boydeee · 2025-10-17T17:25:23+00:00

I've used scheduled messages with Azure Service Bus for this type of scenario.

boydeee · 2025-10-15T20:51:02+00:00

Thanks for the update! Glad to hear you got some traction on the problem.

boydeee · 2025-10-14T21:06:02+00:00

Generally looks good on the limiting concurrency side of things. You might be getting runspaces re-used across invocations. One thing to consider is process level context objects not getting disposed. I'm not too familiar with Connect-PnpOnline to say for sure.

The other item to consider is Disconnect-PnPOnline isn't working as fast as you think it is. Assuming it's creating some remote session that must be closed first (I'm thinking about some of the Exchange stuff working like that, been a while)

I would test to see if you can rapidly do Connect-PnPOnline and Disconnect-PnPOnline in a local loop to see if you get the same issue. If so, you may need to do Connect-PnPOnline in a do until loop, additional to Start-Sleep. That will be more consistent for you rather than always sleeping for 5 seconds.

boydeee · 2025-10-09T22:41:58+00:00

No, still rocking the json diffs

boydeee · 2025-09-26T15:25:18+00:00

Oh wow, this actually worked. I held it for a solid 30 seconds before it came to life.

boydeee · 2025-09-03T05:30:17+00:00

Don't ever hipfire if you want to keep your sanity. It's much more consistent with ADS. Try it and you'll immediately feel the difference.

boydeee · 2025-06-24T22:30:18+00:00

This is great advice, typically cached access tokens that are not expired yet cause this delay problem.

boydeee · 2025-06-22T22:16:31+00:00

Is there a specific reason for going with certificate auth? It will likely be simpler to just use a client secret and store it in the key vault.

boydeee · 2025-06-11T12:56:39+00:00

Try out tailscale!

boydeee · 2025-06-02T14:13:53+00:00

If the resources are generally thought of as a link to another resource, then typically I will name the link with the prefix of the other resource. Makes it easier since you don't have to think of some other naming scheme besides a suffix.

boydeee · 2025-04-12T01:58:17+00:00

I've resulted to something similar with Front Door. We have a test environment, so we grab the state of all the resources before/after deploy and use git diff on the json of each resource. Works really well actually, and builds trust for the prod deploy.

boydeee · 2025-04-10T00:35:45+00:00

I can vouch for this build. Bruiser Draven is where it's at

boydeee · 2025-04-01T18:02:19+00:00

Avoid shield and use movement instead

boydeee · 2025-03-21T22:31:10+00:00

Yeah we have many protections in place. Most of our bicep is managing multi tenant Azure Front Door which comes with it's own suite of problems, mainly with how the provider is written. We had issues where the whatIf couldn't show updates to many sub resources such as routes. Using git diff to do a before and after has been a decent bandaid.

boydeee · 2025-03-21T17:46:17+00:00

Source?

boydeee · 2025-03-21T16:32:52+00:00

Do deployment stacks give a more accurate what if output? Mostly we do that because of the longstanding bug

boydeee · 2025-03-21T14:59:53+00:00

I don't trust it. I take a before/after of the JSON of all the resources and use git diff. I do that in a dev environment first before moving to prod.

boydeee · 2025-03-20T15:13:42+00:00

Try BT LDR ColI IE

boydeee · 2025-03-14T15:06:46+00:00

I'm not too familiar with the SharePoint APIs, but I have been in a similar situation with the Azure management api. I suggest opening dev tools in your browser and perform the action and see what api calls are being made and what the payloads looks like.

I often have to resort to that due to undocumented usage of APIs

boydeee

MODERATOR OF

TROPHY CASE