Architecting a Hybrid Cloud Infrastructure with Azure & Windows Server

The Challenge: Enterprise IT Without the Enterprise

Every organization running Windows infrastructure relies on a stack that took years and significant capital to build out: Azure virtual networks, on-premises servers, Active Directory, DNS, IIS, and the automation layer holding it all together. For a consultant or engineer to credibly work inside that stack, they need to have built it — not just read about it.

This project was about building exactly that environment from the ground up: a fully functional hybrid IT infrastructure that mirrors what real enterprises run, designed and deployed end-to-end without relying on pre-built templates or step-by-step tutorials.

Azure: Designing the Cloud Layer

The Azure side of the infrastructure started with a clean virtual network design. Rather than defaulting to a single flat subnet, the network was segmented with purpose: a management subnet for administrative VMs, a services subnet for workloads like IIS and DNS, and network security groups (NSGs) with explicit inbound and outbound rules to control traffic between zones.

Resource groups were organized by function rather than project, which is how real enterprise environments handle cost attribution and access control. Role-based access control (RBAC) was applied at the resource group level so that administrative access was scoped rather than blanket.

Key design decisions:

Address space planned with room for growth — avoiding the common mistake of cramming everything into a /24
NSG rules written explicitly (no "allow all" shortcuts) to enforce least-privilege networking
VNet peering architecture documented so the environment could be extended to a hub-and-spoke topology

On-Premises Layer: Windows Server 2019 with Hyper-V

The on-premises side was built on Windows Server 2019 VMs running nested inside Azure — a configuration that requires specific hardware acceleration settings and careful memory allocation but enables a realistic two-tier hybrid model without physical hardware.

Hyper-V was configured with virtual switches mapped to the Azure VNet, giving guest VMs routable addresses within the domain. Multiple VMs were provisioned: a domain controller, a member server for file and print services, and a dedicated IIS host. Snapshots were used to checkpoint the environment before major configuration changes — a discipline that translates directly to production change management practices.

Identity & Services: Active Directory, DNS, Group Policy, IIS

Active Directory was promoted on a fresh domain controller, with the domain designed to reflect realistic organizational structure: separate OUs for users, computers, and service accounts. Group Policy Objects were created and linked at the OU level to enforce security baselines — password policies, desktop lockdown settings, and software restriction policies.

DNS was configured both within AD (for internal name resolution and domain join) and with forwarders set to handle external resolution. A secondary DNS server was configured on the member server for redundancy — a detail that's easy to skip in a lab but critical in production.

IIS was deployed on the services VM and configured to host a test intranet site, with bindings set to the server's internal domain name rather than IP — again, mirroring how real web services are managed inside enterprise environments.

Automation: PowerShell for Provisioning and Administration

Manual point-and-click configuration doesn't scale and doesn't prove repeatable competency. The infrastructure was provisioned and administered using PowerShell throughout:

AD users, groups, and OUs created via New-ADUser, New-ADGroup, and New-ADOrganizationalUnit
GPO creation and linking scripted with the GroupPolicy module
IIS site configuration managed through the WebAdministration module
A provisioning script that could rebuild the full server configuration from scratch — the infrastructure-as-code mindset applied to Windows Server

What This Demonstrates

This project exists to answer a question clients ask: Can you actually operate inside our environment? Building this infrastructure demonstrates:

Cloud architecture thinking — designing Azure networking with security and scalability in mind, not just "getting it working"
Infrastructure-as-code mindset — automating what can be automated, documenting what can't
Cross-stack integration — connecting Azure cloud services with on-premises Windows workloads the way real enterprises do
Operational discipline — change management, least-privilege access, and documentation built in from the start

If your organization runs Windows infrastructure — on-premises, in Azure, or hybrid — this is the foundation for understanding how to extend, secure, and automate it.