Microsoft Enterprise Lab Foundation
The lab has documented architecture, network, security, dataset and automation scaffolds without deploying Windows VMs or paid cloud resources.
Overview
ABD Labs is preparing a reproducible Windows, Active Directory, Microsoft 365 and automation lab. The foundation stage captures architecture and guardrails before any heavy infrastructure is installed.
Problem
A realistic Microsoft lab needs enough fidelity to demonstrate administration and troubleshooting, but the current VPS is too small and does not expose nested KVM. Building directly on it would risk existing services and produce a weak lab.
Constraints
- No Proxmox, KVM/libvirt, Windows VMs or Azure paid resources without explicit approval.
- Keep Tickly and existing VPS services operationally independent from the lab.
- Use only synthetic data and sanitized outputs.
- Do not expose Windows management services to the public internet.
- Document manual steps before encoding them into automation.
Approach
Create a repository foundation first: architecture notes, security boundaries, Lab V1 specification, network plan, synthetic employee data and PowerShell scaffolds. Leave compute selection and private access as explicit next decisions.
Key Decisions
Reject the current VPS as the Windows VM host.
The VPS has no /dev/kvm, no exposed hardware virtualization flags and limited CPU/RAM. It is also already responsible for public services.
- Try software-emulated Windows VMs on the VPS.
- Install Proxmox or libvirt directly on the current host.
- Move the lab to a separate compute target.
Start with documentation and synthetic data.
The lab can be designed, reviewed and partially automated before paid infrastructure or risky host changes are introduced.
- Provision infrastructure first and document later.
- Use real tenant exports for faster demo data.
Make Tickly integration read-only and later.
Tickly should consume stable synthetic signals only after the lab can produce them. The commercial product must not depend on lab runtime health.
- Couple Tickly directly to the lab from the beginning.
- Use the lab as a required production dependency.
Tech Stack
- Markdown architecture docs
- Mermaid diagrams
- Synthetic CSV data
- PowerShell scaffolds
- Git
Result & Impact
- 14Synthetic users
- 0Windows VMs deployed
- 0Paid cloud resources
- 0Public management ports
The project now has a clear foundation that can be reviewed before choosing compute, private access and storage policy.
Learnings
- A lab meant to prove operations work needs operational boundaries first, not after the first incident.
- Synthetic datasets are enough to design lifecycle workflows before connecting to any real tenant.
- Portfolio work and lab infrastructure should progress together but remain operationally separate.
Current State
The repository contains the foundation materials for the Microsoft Enterprise Lab. The actual lab infrastructure is not deployed yet.
The next operational decision is the Lab V1 compute path: external dedicated host, local lab host, Azure-first slice or a mixed approach.
Acceptance Gate
The foundation becomes implementation-ready only after compute, private access, storage quota and snapshot policy are selected.