This article summarizes community insights originally aggregated by MSDynamicsWorld.com, covering topics from KEDA and Azure AD to VPN Gateway configuration and Azure’s ten-year evolution.
Deploying KEDA for Kubernetes-Based Event-Driven Autoscaling
KEDA — the Kubernetes-based Event Driven Autoscaler — extends Kubernetes with the ability to scale workloads based on external event sources, such as message queue depth, rather than relying solely on CPU or memory metrics. Richard Hooper covered the installation and configuration process in a post on his Pixel Robots blog.
How KEDA Works
KEDA introduces two key custom resources:
- ScaledObject — defines the scaling target and the event source trigger, linking an external metric source to a Kubernetes Deployment or StatefulSet.
- TriggerAuthentication — manages credentials used to authenticate against event sources, keeping secrets separate from scaling configuration.
Together, these resources generate configuration that informs the Kubernetes Horizontal Pod Autoscaler (HPA), allowing it to scale pods down to zero when idle and scale out rapidly when events arrive.
Installation Options
KEDA can be installed using either of two methods:
- YAML manifests — apply official KEDA manifests directly from the KEDA GitHub repository using
kubectl apply. - Helm charts — install via Helm, with slightly different commands depending on the Helm version (Helm 2 vs. Helm 3). Hooper walked through both paths in his post.
After installation, users connect to their target Kubernetes cluster and deploy ScaledObject definitions pointing at their chosen event source. Hooper noted he uses KEDA in production with RabbitMQ as the message broker, scaling consumers horizontally based on queue depth — a common and well-supported KEDA use case.
Controlling Microsoft Teams Creation with Azure Active Directory
By default, every user in a Microsoft 365 tenant can create a new Microsoft Teams team. While this enables rapid collaboration, it can lead to sprawl and governance challenges in larger organizations. Cor den Boer documented a straightforward method to restrict this on the 2 Azure blog.
The Restriction Approach
Because Microsoft Teams teams are backed by Microsoft 365 Groups, the restriction is applied at the Azure Active Directory group creation level, not within the Teams admin center directly. The process involves:
- Installing the Azure Active Directory PowerShell module for Graph.
- Running a PowerShell script that reads the current directory settings, sets
EnableGroupCreationtofalse, and applies the updated settings object back to the directory. - Creating a dedicated security group in the Azure portal whose members are explicitly permitted to create groups (and therefore Teams).
Once the script runs successfully, the output should display the updated configuration with EnableGroupCreation set to the intended value on the final line. Only members of the designated security group will then be able to create new Teams.
This is a practical governance control for organizations that want to standardize team naming conventions, apply provisioning workflows, or limit licensing impact.
Configuring Azure VPN Gateway with Always On VPN
Thomas Thornton published a detailed walkthrough on configuring Always On VPN using Azure VPN Gateway, positioning it as a modern replacement for Microsoft DirectAccess.
Key Characteristics of Always On VPN
- Always On connectivity — the VPN tunnel is established automatically when the device connects to the internet, without user intervention.
- Routing-based configuration — requires a route-based Azure VPN Gateway (as opposed to policy-based).
- Certificate-based authentication — used for device tunnel authentication; Thornton used self-signed certificates in his example but explicitly recommends certificates from a trusted Certificate Authority for production environments.
Configuration Steps
Thornton used PowerShell throughout his configuration, covering:
- Setting up a point-to-site (P2S) VPN configuration on the Azure VPN Gateway.
- Creating and exporting a VPN profile for client devices.
- Defining specific routes so that only designated traffic traverses the VPN tunnel (split tunneling).
- Storing certificates in the personal-TrustRoot device certificate store on Windows clients.
Always On VPN is particularly relevant for enterprises moving away from DirectAccess or those managing hybrid workforces where reliable, automatic connectivity to on-premises or Azure-hosted resources is required.
Ten Years of Azure: MVP Reflections on the Platform’s Evolution
To mark Azure’s tenth anniversary, Dan Sheridan — writing for the Nigel Frank blog — interviewed three prominent Microsoft MVPs: Mark Scholman (Azure Stack consultant), Charbel Nemnom (ICT security expert), and Thomas Maurer (Microsoft Senior Cloud Advocate).
Early Days: Limited but Promising
When Scholman began working with Azure around 2011, the platform offered a narrow set of capabilities — primarily stateless virtual machines and Azure SQL Database for storage. The early portal experience drew criticism: Nemnom recalled the original management portal as far from user-friendly, noting it was not replaced until 2015 with the modern Azure portal.
Security skepticism was also common in the early years. Nemnom acknowledged his own initial hesitations about trusting workloads to a public cloud, a sentiment shared widely across the industry at the time.
PaaS First, Then IaaS Unlocked Migration at Scale
All three MVPs agreed that Azure’s Platform-as-a-Service (PaaS) offering made it easy to build cloud-native applications from the start. However, the introduction of mature Infrastructure-as-a-Service (IaaS) capabilities was a significant turning point — it allowed organizations to lift and shift existing workloads into Azure rather than requiring ground-up rewrites, dramatically expanding the platform’s addressable audience.
Thomas Maurer on Azure’s Scale Today
For me, it has exceeded my wildest expectations. I would never have imagined the global scale, security and services that are available in Azure today. Today, Azure offers over 600 services from IaaS and PaaS, including container and serverless technologies. Microsoft didn’t just focus on new cloud native technologies, but also improved the way we think about classic workloads on Azure IaaS.
Thomas Maurer, Microsoft Senior Cloud Advocate
Key Turning Points Identified by the MVPs
Each MVP highlighted different milestones as defining moments in Azure’s maturation:
- Azure Stack — extending Azure services to on-premises data centers, enabling true hybrid scenarios.
- Azure Arc — bringing Azure management and governance to resources running outside of Azure, including other clouds and on-premises environments.
- Hybrid Cloud Management — the broader shift toward unified control planes that span cloud and on-premises infrastructure.
Looking forward, the three MVPs shared optimism about Azure’s continued trajectory, with hybrid, multi-cloud management, and AI-integrated services featuring prominently in their outlook.
Original source: MSDynamicsWorld.com. Individual blog posts referenced include work by Richard Hooper (Pixel Robots), Cor den Boer (2 Azure), Thomas Thornton, and Dan Sheridan (Nigel Frank blog).