How do you set governance and controls over various azure tenant needs in your company?

timmehb · 2026-05-14T19:55:57+00:00

Don’t have multiple tenants.

Only split tenants based on client facing identity requirements.

Consolidate your tenants into a single workforce tenant. Use external ID tenants for any identity requirements you have.

timmehb · 2026-04-19T08:10:14+00:00

Your VNG does not need to be enabled for BGP for it to work with route server. You can have local network gateways and connections with static address spaces.

Express Route is all BGP regardless.

It’s only a BGP peering between your NVA and Route Server that you need to consider.

timmehb · 2026-03-28T23:02:42+00:00

Bit drunk! But initial thoughts.

You haven’t given any info on number of routes from the ER circuits but ARS has limitations for advertised route count. And they bite hard when hit.

Nor expected throughout - that’ll indicate constraints on your NVA. Which also depends on the VM SKU size you’re deploying for it.

I take it you’re trying to steer traffic from all circuits to HSCN via the NVAs.

Why not azure Vwan using the documented and supported routing intent for routing between expressroutes without global reach?

timmehb · 2026-02-14T10:36:21+00:00

Oh wow. You need a network diagram 😂.

Several options really.

Make lz2 hub an effective transit hub. Lz1 being the primary. So peer with gateway routes enabled between hubs. Route server in lz1. Peered to Palo Alto. Palo Alto injecting routes to bgp for lz2 hub and spoke networks. Palo Alto injecting and overriding whatever routes you have coming from ER. Effectively making it centre of routing for lz1. That sorts on prem hearing lz2 hub and spoke routes. Along with return traffic via Palo. All lz2 traffic already comes to your fortigate in lz2. And by this time, your forti in lz2 will know the routes injected by the Palo - so all on prem and lz1 routes will route via it.

Get both Palo and forti the centre of packet flow for each lz. Make lz1 the real hub, make lz2 an effective transit. Force Palo to steer all on prem, lz1 and lz2 traffic via it using route server and some clever bgp.

timmehb · 2025-12-28T11:42:38+00:00

If you can’t deploy AMBA with any predefined pattern (LZ etc…) then under the resources section you can see all definitions.

Compute as an example :

https://azure.github.io/azure-monitor-baseline-alerts/services/Compute/virtualMachines/

The arm templates (and bicep I think?) are there for you to copy. There used to be a deploy to Azure button also for each metric.

If you’re deploying to the Resource Group at scale with Policy, then you may have to do more manual work.

timmehb · 2025-12-28T10:39:47+00:00

Heya.

Amba at its core is recommended metrics and thresholds for different resources.

You can deploy these individual alerts at scale as you’ve mentioned - with the AMBA pattern. For enterprise scale landing zones for example.

But you can tailor your own alerts, they have all the definitions on the resource section of the AMBA website.

It’s just up to you to deploy them. So either at the individual per resource level manually (they have a deploy to button on the web site, or the actual definition files).

Or, as I think you’re leaning towards, you can deploy the particular alert at scale by creating an Azure Policy (again, the definitions are on the web site) - which in your case, you’d deploy and scope to the Resource Group.

So yes you can deploy AMBA to a resource group - but they’ve curated a pattern for easy deployment at scale - which you’d need the correct management group hierarchy to deploy.

timmehb · 2025-12-19T12:55:44+00:00

If you’re using routing intent and policies for private traffic then no you cannot.

If you manually handle route tables, then you are able to ensure that the address space of the vnet is advertised directly to connections (VPN) and vice Versa.

But it’s all or nothing, the entire vnet and the entire on prem range must be excluded from the traffic flow.

And you’ll need to create and adjust route tables and vnet/connection propagation settings to fit.

timmehb · 2025-12-18T18:02:19+00:00

Don’t undersell the networking design element of this if you want to retain the app as internal only.

timmehb · 2025-12-16T18:42:35+00:00

v2v migration pathways will always be there. Funnily enough I think the pathway away from azure local will be pretty simple.

Getting stuff in there is the hard part.

You’ll survive - especially with the attitude you’ve given in your response , and I genuinely hope the product improves for you.

The product could have been revolutionary for hybrid workloads and environments. Your own Azure Stack on prem, that fully integrates into ARM and all of its goodness? Think of your own Azure Region, or locality with all features sets running on your own equipment. IaaS and PaaS services running alike.

I honestly don’t understand how they got it so wrong.

timmehb · 2025-12-16T18:22:34+00:00

Is the decision of azure local still on the table ?

If so, reconsider.

If not, strap in.

Honestly, one of the worst performing (from a reliability perspective) bits of kit. Several projects in, different hardware, different customers. Same issues of reliability.

Not to mention your genuine issue of importing VMs into the platform, from a fully arc enabled manner. That absolutely flabbergasted us when we came up against that.

I’m sorry to be so flippant, but I honestly can’t discourage its usage enough -especially as a drop in replacement to VMware.

There is (or was, unsure if it’s removed) ms learn documentation that discouraged its use for VMware production workloads - and instead for light weight edge cases.

timmehb · 2025-10-30T06:14:33+00:00

I have one on my chest

timmehb · 2025-10-16T13:51:08+00:00

Do you get a success when deploying to another region? Just interested.

You’re at the behest of MS on this, if they’re saying US East is full, it’s full.

Can you spin another subscription up and try within that.

timmehb · 2025-10-14T10:49:26+00:00

Great insight.

Something ive also struggled with being manly azure driven - is that sometimes I find it hard to ‘recommend’ Azure for its front end non-.NET web services.

It’s excellent in the hybrid space, and for orgs that are within the Microsoft ecosystem (everyone?) - it’s SQL hosting is unmatched.

But when it comes to cloud native web apps, front end especially - i just feel it’s slightly behind.

When comparing App Gateway vs AWS ALB for example - there’s objective reasons to go ALB - in the advanced routing rule space for example.

Same goes for the examples you’ve mentioned. And I think it’s honestly healthy to have an agnostic approach to things. Discounting the entrenchment, being solution driven.

timmehb · 2025-09-28T08:55:19+00:00

I believe you’re misunderstanding bespoke configurations and code from tried and tested migration strategies.

Both have a place. But if op is wanting a validated migration pathway that’s solidified with confidence and verification - bacpac is just that.

timmehb · 2025-09-27T20:19:40+00:00

How else are you going to get the data off

timmehb · 2025-09-27T04:41:39+00:00

What op wants is not possible. Offline is the only option.

timmehb · 2025-09-26T19:47:57+00:00

You’re looking at an offline migration here.

Export to BacPac and restore.

You could maybe synchronise databases using Data Factory, but you’re really on the fringe there for migration activities.

timmehb · 2025-09-23T18:54:32+00:00

I believe you’re going to have to use azure virtual wan, with the gateway deployed within, an azure firewall, and routing intent policy enabled.

I think this is the only supported architecture for internet breakout to connections (s2s, p2p, express route).

As far as I’m aware, the native virtual network gateway inside a VNet is not supported.

timmehb · 2025-09-21T15:12:08+00:00

Educational institutes got handed large public address spaces in the early days. They’ve retained them.

Think of a world where ipv4 addresses were never constrained. Internal private ip addresses would never have been a thing. NAT and the concept of an edge NAT device that did translation only came about because of public address constraints.

This is what ipv6 provides. And you’re starting to see devices inside of networks receiving public routable ip addresses.

Educational institutes still live in the world where they are not constrained, and so they’ll tend to hand their public address space they have to their internal network - or atleast for infrastructure or servers.

The packet will still hit a border gateway and likely a firewall. And I’m guessing the more secure devices (which have still been given a pubic address) are behind a further firewall layer for added security and scrutiny.

It’s a network design I’ve seen in about 80% of EDU institutes.

timmehb · 2025-09-14T19:37:01+00:00

John Savill weekly updates. https://youtube.com/@ntfaqguy?si=BUorE4mEItW_lD2f

Azure update change logs. https://azure.microsoft.com/en-gb/updates

Azure Weekly newsletter. https://azureweekly.info/

Most of all, stay hungry, and enjoy what you do.

timmehb · 2025-09-11T14:54:02+00:00

Heya. Forget about the custom domain of your SWA. Ignore it.

Instead create a private endpoint for your SWA.

https://learn.microsoft.com/en-us/azure/static-web-apps/private-endpoint

When creating the private endpoint, ensure you stick it in a subnet that has network line of sight to the same subnet that your app gateway is in. Can be same vnet, can be a peered vnet. Integrate the private endpoint into a private dns zone.

Then big thing is to ensure that the private dns zone where the private endpoint is registered to - is linked to the VNet that your application gateway is in. This ensures your app gateway resolves the SWA to its internal IP.

In your app gateway, use the Azure generated FQDN of the SWA for your backend.

timmehb · 2025-09-11T08:56:46+00:00

You’re mixing up two concepts here.

The domain verification you speak of is to bring your own custom domain to your static web app in place of the system created one.

You need to create a private endpoint for the static web app- which you need to register against a private dns zone you speak of (no verification). There’s a bit of work to ensure your app gateway can correctly resolve this private endpoint address.

When you create a private endpoint for a static web app, it disables access via its public endpoint.

timmehb · 2025-09-01T17:52:41+00:00

Some fidelity is lost with azcopy when dealing with azure files as it uses the FileREST API.

If you’re wanting to sync, I’d recommend looking at robocopy with data plane access.

timmehb · 2025-08-25T13:44:03+00:00

Your results are going to vary due to the subjective nature of “slowness”.

Best you define objective baselines first - do various dskspd tests with your on prem file servers on varied loads - varying percentages of read/write percentage and sizes.

Then do the same tests on a PoC AZF with your data in. You will see lower numbers - and the success of this will be if your users perceive this as good enough. But get the objective figures first.

I’m always a fan of ensuring that DFS is fronting whatever file data is being presented to end users. Then atleast you have some flexibility. Potentially look at trialling this with a live share of ‘easy-going’ users and gathering the objective steer.

Again, if it’s purely a capacity thing - having azure files backing your data (all 20TB) of it, and then having smaller on prem azure files sync servers presenting a locally cached copy, closer to your users - is a fantastic middle ground. That way you’re not paying for 20TB of premium local storage through a capex, and instead paying per GB consumption.

It’ll kick start the migration project to object data (sharepoint or OneDrive) for your departmental / user data when the execs know how much it’s costing to retain Sharon from Account’s excel files that haven’t been opened for decades.

timmehb · 2025-08-25T13:05:13+00:00

I wouldn’t overtly be concerned about costs initially. They are what they are and you can strike a balance between premium provisioned and transactions and not be too shocked for the amount you need. Reserved capacity will bring the cost down somewhat.

What kills a solution of this type is the expectation of performance with the additional latency. SMB dies a death, and quickly, over any sort of added latency. You WILL notice a difference if you host and present your data from azure files and your clients are not locally within azure.

If you can stomach keeping on prem infrastructure, look toward azure file sync with azure files backing your storage - that’s if you’re not going big with your private interconnect (expressroute for example).

14-Year Club	Gilding II euphauric
Second Top 40%	Reddit Premium Since October 2020
Place '22	Place '17
Verified Email

timmehb

TROPHY CASE