Not built yet. This record covers plans and documents only. No Windows Server, Active Directory or Azure resources have been deployed.

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 public host 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 public-host 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.

Planned 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 public host as the Windows VM host.

The public host has no /dev/kvm, no exposed hardware virtualization flags and limited CPU/RAM. It is also already responsible for public services.

Alternatives considered

  • Try software-emulated Windows VMs on the public host.
  • 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.

Alternatives considered

  • 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.

Alternatives considered

  • Couple Tickly directly to the lab from the beginning.
  • Use the lab as a required production dependency.

What exists so far

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.

All projects