Hey,
yeah, if public network access is disabled, it can totally mess with webhooks ‘cause they need to talk to the Automation account over the internet. So, if the account is locked down, those webhook calls are just gonna bounce off like a bad ping pong shot. But don’t sweat it, there’s a way to make it work without opening up public access. U can use private endpoints instead. Private endpoints let u connect securely to your Automation account over a private network, so u don’t gotta expose it to the whole internet. It’s like giving your webhooks a VIP pass instead of making them wait in the public line.
Set up a private endpoint for your Automation account. This’ll let it communicate securely over Azure’s private network. Make sure your webhook and the resources it’s hitting are in the same virtual network or connected through something like VNet peering or VPN. Update your webhook config to use the private endpoint URL instead of the public one. This way, u keep everything locked down and secure, but still get those pre and post events firing like they should. No need to enable public network access and risk exposing your stuff to the wild west of the internet. Just in case check urr webhook setup in the runbook. Sometimes it’s just a small typo or misconfig that’s causing the issue. Azure can be picky like that. Private endpoints are your friend here. They’ll keep things secure while still letting u do your thing with Azure Update Manager.
Hope that helps,
rgds,
Alex