{ "projects/windows-admin-center-lab": { "title": "Windows Admin Center Lab Management", "description": "Centralized Windows administration backed by connectivity, authentication, and remote-management validation.", "body": "

Project 04 / Infrastructure

Windows Admin Center Lab Management

Centralized Windows administration backed by connectivity, authentication, and remote-management validation.

COMPLETEValidated lab work
GitHub documentation ↗Original portfolio ↗Evidence library

Overview

Centralized Windows administration backed by connectivity, authentication, and remote-management validation.

Classification: Validated lab work.

Operational scenario & objectives

Establish centralized administration and isolate management-tool slowness from connectivity, authentication, and server-health issues.

Environment & technologies

Administrative laptop running Windows Admin Center, connecting to Windows servers and endpoints through controlled management paths.

Windows Admin CenterWinRMPowerShell

Architecture

Administrative laptop running Windows Admin Center, connecting to Windows servers and endpoints through controlled management paths.

Explore infrastructure architecture →

Implementation & administration

Project 04 · COMPLETE

Windows Admin Center Lab Management

Centralized Windows administration with connectivity testing, PowerShell remoting, and evidence-based troubleshooting.

Back to projectsReview proof index
WACManagement
WinRMRemote path
PowerShellValidation
ScopedFirewall rules

Scope

Centralized Windows management

Windows Admin Center is used from the administrative laptop to manage Windows Server and endpoint systems in the lab over controlled remote-management paths.

Validation

Connectivity before configuration

WinRM reachability, PowerShell remoting, host resource state, and management-path behavior were validated before changing server configuration.

Troubleshooting

Slow management isolated from server health

When WAC felt slow, direct tests separated network reachability, authentication overhead, and actual server resource state instead of assuming a server-performance problem.

Evidence

Sanitized validation

Current Validated State / README.md
Original source ↗Open document page

Current Validated State

\n

This public evidence folder summarizes reviewer-safe records from the private home-lab operations repository without exposing private repository links. Public claims use stable classifications instead of date-based proof labels. The direct-evidence/ folder contains sanitized direct artifacts for the current infrastructure claims.

\n

Document

\n
    \n
  • Title: Jeremy Fontenot’s On-Premises Home Lab Documentation
    • \n
  • Filename: Jeremy-Fontenot-On-Premises-Home-Lab-Documentation.docx
    • \n
  • Download description: Download the Professional Home Lab Documentation (.docx)
    • \n
  • SHA-256: D7E81A06DCFBD2E91EB8F52A02BDC795AC5B7084A70F343233F1104CCD297BDB
    • \n
\n

Source Commits

\n
    \n
  • Website source commit at generation: effdbeb0ed8d632a0b0c93328cd593cf85c3eb46
    • \n
  • Home-lab source commit for direct evidence: fb6c286873285778d88d6d5cfde0b9bd00b96f36
    • \n
\n

Supported Public Claims

\n
    \n
  • Personal nonproduction lab hosted on Dell PowerEdge R710 with Proxmox VE 9.2.3.
    • \n
  • pfSense, DC01, WS01, and Linux01 are the primary lab VMs described by current records.
    • \n
  • Linux01 current supported placement is VLAN 30 at 10.10.30.20/24; older 10.10.20.x Linux01 evidence is historical.
    • \n
  • DC01 direct evidence supports Windows Server 2022, AD DS, DNS, DHCP, Group Policy Management, Global Catalog status, FSMO ownership, and DC01 IP.
    • \n
  • WS01 direct evidence supports Windows 10 Pro, domain membership, secure channel, and current network state.
    • \n
  • Linux01 direct evidence supports Ubuntu 26.04 LTS, kernel, VLAN 30, current IP/gateway/DNS, current-versus-historical address boundary, and directly proven domain integration indicators.
    • \n
  • Linux01 SSSD remediation is documented as remediated and validated for Linux01 only.
    • \n
  • Backup job configuration and retained backup counts are supported; all-recent-backups-succeeded, recurring disaster-recovery assurance, RTO, and RPO are not claimed.
    • \n
  • One isolated Linux01 restore drill is supported; it does not prove recurring restore assurance.
    • \n
\n

Direct Evidence Links

\n\n

Limitations

\n

Personal lab evidence does not represent employer production administration, client infrastructure ownership, enterprise scale, guaranteed uptime, full firewall assurance, or full security assurance. Timeout observations remain timeout observations. The restore evidence is one isolated Linux01 restore drill only and does not establish recurring restore assurance, RTO, RPO, SLA, or disaster-recovery readiness.

DC01 System and Role Validation / dc01-system-and-role-validation.md
Original source ↗Open document page

DC01 System and Role Validation

\n

Claim supported

\n

Direct DC01 inventory supports Windows Server, installed role, domain, Global Catalog, FSMO, and DC01 IP claims for the personal nonproduction lab.

\n

Directly observed values

\n
    \n
  • Operating system: Microsoft Windows Server 2022 Standard Evaluation.
    • \n
  • Version: 10.0.20348.
    • \n
  • Build number: 20348.
    • \n
  • Active Directory Domain Services installed: AD-Domain-Services, InstallState 1.
    • \n
  • DNS Server installed: DNS, InstallState 1.
    • \n
  • DHCP Server installed: DHCP, InstallState 1.
    • \n
  • Group Policy Management installed: GPMC, InstallState 1.
    • \n
  • Domain DNS root: ad.jeremyfontenot.online.
    • \n
  • NetBIOS domain: JFAD.
    • \n
  • Domain controller host: DC01.ad.jeremyfontenot.online.
    • \n
  • DC01 IPv4 address: 10.10.20.10.
    • \n
  • Global Catalog: true.
    • \n
  • FSMO roles on DC01: PDC Emulator, RID Master, Infrastructure Master, Schema Master, and Domain Naming Master.
    • \n
\n

Source command or source object

\n

Authenticated DC01 target-local inventory result objects: OperatingSystem, InstalledRolesFeatures, Domain, Forest, and DomainControllers.

\n

Source repository

\n

fontenotjeremy71-hub/jeremy-homelab-ops

\n

Source commit

\n

fb6c286873285778d88d6d5cfde0b9bd00b96f36

\n

Source path

\n

inventories/dc01-inventory-20260626-022543.json

\n

Source file SHA-256

\n

inventories/dc01-inventory-20260626-022543.json: F60A6DD8C9EE42E90B02B210B1B1A775F89E5C3DED26618B593DEE1362C6DE42

\n

Public artifact SHA-256

\n

Recorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.

\n

Sanitization performed

\n

Removed executing account, privileged group details, SIDs, object GUIDs, GPO GUIDs, unrelated installed features, event details, raw time values not needed for the claim, and unrelated command output. Retained DC01 IP because it is already part of the current public home-lab evidence boundary.

\n

Limitations

\n
    \n
  • Personal nonproduction home lab only.
    • \n
  • Captured-state evidence only.
    • \n
  • This artifact validates collected DC01 inventory values only.
    • \n
  • It does not prove ongoing Active Directory health, production readiness, security assurance, employer-system administration, or service availability beyond the captured inventory.
    • \n
\n

Validation date

\n

2026-06-30

\n

Classification

\n

Validated

Linux01 SSSD Remediation Validation / linux01-sssd-remediation-validation.md
Original source ↗Open document page

Linux01 SSSD Remediation Validation

\n

Claim supported

\n

Direct Linux01 remediation evidence supports a narrow Linux01-only SSSD responder/socket conflict remediation and post-remediation validation.

\n

Directly observed values

\n
    \n
  • Initial condition: SSSD NSS, PAM, and PAC sockets were enabled and failed.
    • \n
  • Initial condition: SSSD was configured for direct responder activation through services = nss, pam.
    • \n
  • Initial condition: config_file_version = 2 was rejected by SSSD 2.12 config validation.
    • \n
  • Remediation action: removed only the rejected config_file_version = 2 directive.
    • \n
  • Remediation action: disabled conflicting NSS, PAM, and PAC sockets.
    • \n
  • Remediation action: restarted sssd.service.
    • \n
  • Remediation action: cleared failed-unit state.
    • \n
  • Post-remediation service state: sssd.service enabled and active/running.
    • \n
  • Post-remediation failed-unit state: zero failed units.
    • \n
  • SSSD configuration validation: passed.
    • \n
  • AD identity lookup: passed.
    • \n
  • New AD-authenticated SSH session: passed.
    • \n
  • Initial diagnostic SHA-256: 3CAD0FB73202D777D41DEE40D6F4D19D4019B9AD30552B37970B55A5CA5AB3BB.
    • \n
  • Original/backup configuration SHA-256: 23ACE1BECA5FF6F7D58200EFE054EA8E5A938E02F37FCE25B1CA1B5D2F05BD14.
    • \n
  • Post-remediation diagnostic SHA-256: FD55604BFB94487B86FBF631703FA995B9726471689385CCB2D277492AA7CBEE.
    • \n
\n

Source command or source object

\n

Linux01 SSSD remediation evidence record.

\n

Source repository

\n

fontenotjeremy71-hub/jeremy-homelab-ops

\n

Source commit

\n

fb6c286873285778d88d6d5cfde0b9bd00b96f36

\n

Source path

\n

evidence/linux01-sssd-remediation-20260626-110159.md

\n

Source file SHA-256

\n

evidence/linux01-sssd-remediation-20260626-110159.md: 04773570FBE305353F5EB370B8F9629AC335E35A7BEF7151A2CBB98D7371CC49

\n

Public artifact SHA-256

\n

Recorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.

\n

Sanitization performed

\n

Removed diagnostic artifact paths, backup filesystem path, account context, raw command history, and implementation details not needed to support the remediation claim. Retained hashes because they are part of the validation evidence.

\n

Limitations

\n
    \n
  • Personal nonproduction home lab only.
    • \n
  • Captured-state evidence only.
    • \n
  • Linux01 only.
    • \n
  • This does not claim that all Linux domain-authentication paths were tested.
    • \n
  • This does not prove production readiness, employer-system administration, or recurring assurance.
    • \n
\n

Validation date

\n

2026-06-30

\n

Classification

\n

Validated

Linux01 System, Network, and Domain Validation / linux01-system-network-domain-validation.md
Original source ↗Open document page

Linux01 System, Network, and Domain Validation

\n

Claim supported

\n

Direct Linux01 inventory, Proxmox inventory, and source reconciliation evidence support Linux01 VM association, Ubuntu version, kernel, VLAN, IP addressing, DNS, gateway, current-versus-historical address boundary, and directly proven domain integration state.

\n

Directly observed values

\n
    \n
  • Proxmox VM association: VM 400 name linux01, running.
    • \n
  • Operating system: Ubuntu 26.04 LTS.
    • \n
  • Kernel: Linux 7.0.0-22-generic.
    • \n
  • Architecture: x86_64.
    • \n
  • VLAN: 30, from current source reconciliation.
    • \n
  • Interface state: ens18 UP.
    • \n
  • Current IPv4 address: 10.10.30.20/24.
    • \n
  • Default gateway: 10.10.30.1.
    • \n
  • DNS server: 10.10.20.10.
    • \n
  • DNS domain: ad.jeremyfontenot.online.
    • \n
  • Current-versus-historical boundary: current Linux01 address is 10.10.30.20/24; older Linux01 10.10.20.x evidence is historical.
    • \n
  • Domain integration state: realmd reports ad.jeremyfontenot.online configured as a Kerberos member, server software active-directory, client software SSSD, and domain identity resolution returned resolved.
    • \n
  • Kerberos configuration: present.
    • \n
\n

Source command or source object

\n
    \n
  • Authenticated Linux01 target-local inventory result objects: Distribution, Kernel, IP addresses, Routes, DNS, realmd, Domain identity resolution, and Kerberos config.
    • \n
  • Proxmox read-only inventory object: virtualMachines[] entry for VM 400.
    • \n
  • Source reconciliation table for Linux01 VLAN and current-versus-historical address boundary.
    • \n
\n

Source repository

\n

fontenotjeremy71-hub/jeremy-homelab-ops

\n

Source commit

\n

fb6c286873285778d88d6d5cfde0b9bd00b96f36

\n

Source path

\n
    \n
  • inventories/linux01-inventory-20260626-084312.json
    • \n
  • inventories/proxmox-inventory-20260626-010601.json
    • \n
  • evidence/home-lab-source-reconciliation-20260626-012606.md
    • \n
\n

Source file SHA-256

\n
    \n
  • inventories/linux01-inventory-20260626-084312.json: 75F82AF4882FA9C869C78C1AC127C5D4F37C5CB62F4E8894361A352695EFC40D
    • \n
  • inventories/proxmox-inventory-20260626-010601.json: D652D1EF753E14242C07F84F19FBF09F642F07C3B09CFE2E98AA7F2B176ADE3D
    • \n
  • evidence/home-lab-source-reconciliation-20260626-012606.md: 2D377A7A6703F8C3C5FBB77AA093569806DDB7939CFA88FD6A0ECF801484C3EE
    • \n
\n

Public artifact SHA-256

\n

Recorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.

\n

Sanitization performed

\n

Removed executing account, machine identifiers, link-local IPv6 address, raw boot/session identifiers, unrelated package/service details, unnecessary filesystem paths, and distro metadata not needed for the public claim.

\n

Limitations

\n
    \n
  • Personal nonproduction home lab only.
    • \n
  • Captured-state evidence only.
    • \n
  • Domain integration is limited to the directly observed realmd, SSSD client, Kerberos config, and identity-resolution indicators.
    • \n
  • This artifact does not claim that all Linux domain-authentication paths were tested.
    • \n
  • Timeout or listener observations are not complete firewall validation.
    • \n
\n

Validation date

\n

2026-06-30

\n

Classification

\n

Validated

Proxmox Backup Configuration / proxmox-backup-configuration.md
Original source ↗Open document page

Proxmox Backup Configuration

\n

Claim supported

\n

Direct Proxmox backup configuration evidence supports the configured weekly snapshot job for primary lab VMs.

\n

Directly observed values

\n
    \n
  • Backup job ID: backup-critical-lab-vms.
    • \n
  • Enabled state: enabled.
    • \n
  • Schedule: Sunday 02:00 (sun 02:00).
    • \n
  • Mode: snapshot.
    • \n
  • Compression: zstd.
    • \n
  • Retention: keep-last=4.
    • \n
  • Storage target: backup-hdd.
    • \n
  • Target VMs: 100, 200, 300, and 400.
    • \n
\n

Source command or source object

\n
    \n
  • Proxmox read-only inventory object: backupJobs[].
    • \n
  • Backup and restore validation text: backup job block with prune/retention details.
    • \n
\n

Source repository

\n

fontenotjeremy71-hub/jeremy-homelab-ops

\n

Source commit

\n

fb6c286873285778d88d6d5cfde0b9bd00b96f36

\n

Source path

\n
    \n
  • inventories/proxmox-inventory-20260626-010601.json
    • \n
  • evidence/home-lab-backup-restore-validation-20260629.txt
    • \n
\n

Source file SHA-256

\n
    \n
  • inventories/proxmox-inventory-20260626-010601.json: D652D1EF753E14242C07F84F19FBF09F642F07C3B09CFE2E98AA7F2B176ADE3D
    • \n
  • evidence/home-lab-backup-restore-validation-20260629.txt: 4637E848C9B318B8C74BB9C6E4569B3CC03E6686CE64FA367CF6DEC05FA52E13
    • \n
\n

Public artifact SHA-256

\n

Recorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.

\n

Sanitization performed

\n

Removed scheduling metadata not needed for the claim, command context, host details, and any unrelated storage, VM, or task information.

\n

Limitations

\n
    \n
  • Personal nonproduction home lab only.
    • \n
  • Configuration presence does not prove that every recent backup task succeeded.
    • \n
  • This artifact does not claim successful recent backups for VMs 200 or 300 because no direct recent OK task output is published here.
    • \n
  • This artifact does not prove restore integrity, RTO, RPO, recurring restore assurance, or disaster-recovery readiness.
    • \n
\n

Validation date

\n

2026-06-30

\n

Classification

\n

Configured

Proxmox Backup Inventory / proxmox-backup-inventory.md
Original source ↗Open document page

Proxmox Backup Inventory

\n

Claim supported

\n

Direct backup inventory evidence supports active backup-hdd storage, retained archive presence by VM count, and the boundary that archive presence is not the same as recurring restore assurance.

\n

Directly observed values

\n
    \n
  • Storage: backup-hdd.
    • \n
  • Storage path retained as claim-relevant evidence: /mnt/pve/backup-hdd.
    • \n
  • Storage status from current inventory: type dir, content backup, total 982,809,350,144 bytes, used 172,812,951,552 bytes, available 759,996,993,536 bytes.
    • \n
  • Backup validation storage view: 916 GB size, 127 GB used, 743 GB available, 15 percent used.
    • \n
  • Retained backup counts: VM 100 count 4, VM 200 count 4, VM 300 count 4, VM 400 count 4.
    • \n
  • No successful recent per-VM vzdump task status is claimed from this artifact.
    • \n
  • Operational limitation retained: Proxmox thin-pool risk is visible. The retained storage source directly shows a 428 GB thin pool and provisioned VM/snapshot thin volumes that exceed that physical thin-pool size. The requested auto-extension warning is retained as a limitation boundary; the retained source set inspected for this publication does not include a separate thin-pool auto-extension configuration dump.
    • \n
\n

Source command or source object

\n
    \n
  • Proxmox read-only inventory object: storage[].
    • \n
  • Backup and restore validation text: backup counts and storage block.
    • \n
  • Retained public storage evidence: Proxmox storage status, logical volume, and thin-pool usage sections.
    • \n
\n

Source repository

\n
    \n
  • fontenotjeremy71-hub/jeremy-homelab-ops
    • \n
  • fontenotjeremy71-hub/jeremyfontenot, for the retained older public storage limitation artifact
    • \n
\n

Source commit

\n
    \n
  • Operations source: fb6c286873285778d88d6d5cfde0b9bd00b96f36
    • \n
  • Website retained public evidence source: 5813445f3cc828e2146773299c47967292da7fd5
    • \n
\n

Source path

\n
    \n
  • inventories/proxmox-inventory-20260626-010601.json
    • \n
  • evidence/home-lab-backup-restore-validation-20260629.txt
    • \n
  • evidence-library/projects/on-prem-home-lab/validated-2026-06-21/text/proxmox-storage-validation.txt
    • \n
\n

Source file SHA-256

\n
    \n
  • inventories/proxmox-inventory-20260626-010601.json: D652D1EF753E14242C07F84F19FBF09F642F07C3B09CFE2E98AA7F2B176ADE3D
    • \n
  • evidence/home-lab-backup-restore-validation-20260629.txt: 4637E848C9B318B8C74BB9C6E4569B3CC03E6686CE64FA367CF6DEC05FA52E13
    • \n
  • evidence-library/projects/on-prem-home-lab/validated-2026-06-21/text/proxmox-storage-validation.txt: 7F069AA31390D90D99F0000D6F6236A2B60F5D28F061668C0BBD5054FA93741F
    • \n
\n

Public artifact SHA-256

\n

Recorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.

\n

Sanitization performed

\n

Removed PIDs, unrelated filesystems, device identifiers not needed for the claim, snapshot parent names, raw command history, and backup archive filenames. Retained the backup storage path because it is the public claim being validated.

\n

Limitations

\n
    \n
  • Personal nonproduction home lab only.
    • \n
  • Captured-state evidence only.
    • \n
  • Backup archive count does not prove backup integrity.
    • \n
  • No claim is made that all recent backup tasks succeeded.
    • \n
  • The thin-pool warning is an operational limitation and is not framed as a failed backup or failed restore.
    • \n
  • No RTO, RPO, production disaster-recovery readiness, or recurring restore assurance is claimed.
    • \n
\n

Validation date

\n

2026-06-30

\n

Classification

\n

Documented / Limitation

Proxmox Platform Inventory / proxmox-platform-inventory.md
Original source ↗Open document page

Proxmox Platform Inventory

\n

Claim supported

\n

Direct Proxmox inventory supports the personal nonproduction lab platform claim for Proxmox VE, primary VM IDs, VM names, running state, allocated vCPU, memory, disk, bridge placement, guest-agent state, and Linux01 VLAN tag where captured.

\n

Directly observed values

\n
    \n
  • Proxmox VE version: 9.2.3.
    • \n
  • Proxmox kernel: Linux 7.0.12-1-pve.
    • \n
  • VM 100: pfsense-fw, running, 2 vCPU, 4 GB memory, 32 GB disk, bridges vmbr0 and vmbr1, guest agent not configured and not responding.
    • \n
  • VM 200: dc01, running, 2 vCPU, 4 GB memory, 80 GB disk, bridge vmbr1, guest agent not configured and not responding.
    • \n
  • VM 300: ws01, running, 2 vCPU, 4 GB memory, 80 GB disk, bridge vmbr1, guest agent not configured and not responding.
    • \n
  • VM 400: linux01, running, 2 vCPU, 2 GB memory, 40 GB disk, bridge vmbr1, guest agent configured and responding.
    • \n
  • Linux01 VLAN tag: 30, from the retained source reconciliation record.
    • \n
\n

Source command or source object

\n
    \n
  • Proxmox read-only inventory object: version, node.kernel, virtualMachines[], and storage[].
    • \n
  • Source reconciliation object: current command/API evidence row for Linux01 Proxmox VM tag.
    • \n
\n

Source repository

\n

fontenotjeremy71-hub/jeremy-homelab-ops

\n

Source commit

\n

fb6c286873285778d88d6d5cfde0b9bd00b96f36

\n

Source path

\n
    \n
  • inventories/proxmox-inventory-20260626-010601.json
    • \n
  • evidence/home-lab-source-reconciliation-20260626-012606.md
    • \n
\n

Source file SHA-256

\n
    \n
  • inventories/proxmox-inventory-20260626-010601.json: D652D1EF753E14242C07F84F19FBF09F642F07C3B09CFE2E98AA7F2B176ADE3D
    • \n
  • evidence/home-lab-source-reconciliation-20260626-012606.md: 2D377A7A6703F8C3C5FBB77AA093569806DDB7939CFA88FD6A0ECF801484C3EE
    • \n
\n

Public artifact SHA-256

\n

Recorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.

\n

Sanitization performed

\n

Removed node uptime, repository ID, host resource details not needed for the public claim, snapshot parent names, raw paths unrelated to the platform claim, and any fields not required to prove the listed inventory values.

\n

Limitations

\n
    \n
  • Personal nonproduction home lab only.
    • \n
  • Captured-state evidence only; this does not prove ongoing availability.
    • \n
  • Proxmox inventory does not prove guest operating-system health, pfSense firewall policy, Active Directory health, backup restore integrity, or Windows service state.
    • \n
  • Linux01 VLAN tag is supported by the reconciliation source, not by the VM list object alone.
    • \n
\n

Validation date

\n

2026-06-30

\n

Classification

\n

Validated

Proxmox Restore Validation / proxmox-restore-validation.md
Original source ↗Open document page

Proxmox Restore Validation

\n

Claim supported

\n

Direct restore validation evidence supports one isolated Linux01 restore drill from source VM 400 to temporary VM 401.

\n

Directly observed values

\n
    \n
  • Source VM: 400.
    • \n
  • Temporary restore VM: 401.
    • \n
  • Restored disk size boundary: VM 400 boot disk shown as 40 GB in the retained restore validation source.
    • \n
  • Temporary VM network isolation: temporary VM network isolated before boot.
    • \n
  • Guest validation: Ubuntu 26.04 LTS boot and QEMU Guest Agent response were validated in the retained restore evidence.
    • \n
  • Cleanup: temporary VM 401 was shut down and purged successfully.
    • \n
  • The source set inspected for this publication does not include a retained per-command restore transcript with archive filename, progress percentage, or literal final TASK OK line; those details are therefore not claimed here.
    • \n
  • Operational limitation retained: Proxmox thin-pool risk remains visible and is not framed as a failed restore.
    • \n
\n

Source command or source object

\n

Backup and restore validation text: VM state and restore drill sections.

\n

Source repository

\n

fontenotjeremy71-hub/jeremy-homelab-ops

\n

Source commit

\n

fb6c286873285778d88d6d5cfde0b9bd00b96f36

\n

Source path

\n

evidence/home-lab-backup-restore-validation-20260629.txt

\n

Source file SHA-256

\n

evidence/home-lab-backup-restore-validation-20260629.txt: 4637E848C9B318B8C74BB9C6E4569B3CC03E6686CE64FA367CF6DEC05FA52E13

\n

Public artifact SHA-256

\n

Recorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.

\n

Sanitization performed

\n

Removed PIDs and retained only the VM IDs, restore scope, network isolation, guest identity, guest-agent response, and cleanup outcome needed to support the public claim.

\n

Limitations

\n
    \n
  • Personal nonproduction home lab only.
    • \n
  • Captured-state evidence only.
    • \n
  • One isolated Linux01 restore drill only.
    • \n
  • No recurring restore assurance.
    • \n
  • No RTO or RPO claim.
    • \n
  • No disaster-recovery readiness, SLA, production, or employer-system claim.
    • \n
  • Thin-pool warnings are operational limitations and are not evidence of a failed restore.
    • \n
\n

Validation date

\n

2026-06-30

\n

Classification

\n

Tested

WS01 System and Domain Validation / ws01-system-and-domain-validation.md
Original source ↗Open document page

WS01 System and Domain Validation

\n

Claim supported

\n

Direct WS01 inventory and Proxmox inventory support the WS01 system, VM association, domain membership, and network-state claims for the personal nonproduction lab.

\n

Directly observed values

\n
    \n
  • Proxmox VM association: VM 300 name ws01, running.
    • \n
  • Windows edition: Microsoft Windows 10 Pro.
    • \n
  • Windows version: 10.0.19045.
    • \n
  • Windows build: 19045.
    • \n
  • Domain membership: WS01 is part of domain ad.jeremyfontenot.online.
    • \n
  • Secure channel result: true.
    • \n
  • Network interface: Ethernet.
    • \n
  • IPv4 address: 10.10.20.100.
    • \n
  • Default gateway: 10.10.20.1.
    • \n
  • DNS server: 10.10.20.10.
    • \n
  • DHCP enabled: true.
    • \n
  • DHCP server: 10.10.20.10.
    • \n
  • Current supported OS reconciliation: Windows 10 Pro 10.0.19045 is the supported current value in the retained WS01 inventory.
    • \n
\n

Source command or source object

\n
    \n
  • Authenticated WS01 target-local inventory result objects: OperatingSystem, NetworkConfiguration, DomainMembership, and SecureChannel.
    • \n
  • Proxmox read-only inventory object: virtualMachines[] entry for VM 300.
    • \n
\n

Source repository

\n

fontenotjeremy71-hub/jeremy-homelab-ops

\n

Source commit

\n

fb6c286873285778d88d6d5cfde0b9bd00b96f36

\n

Source path

\n
    \n
  • inventories/ws01-inventory-20260626-012952.json
    • \n
  • inventories/proxmox-inventory-20260626-010601.json
    • \n
\n

Source file SHA-256

\n
    \n
  • inventories/ws01-inventory-20260626-012952.json: 1438FA0F72F241E2613C5D35B797492FFC754B0E818A74154DE38DD74082A6B1
    • \n
  • inventories/proxmox-inventory-20260626-010601.json: D652D1EF753E14242C07F84F19FBF09F642F07C3B09CFE2E98AA7F2B176ADE3D
    • \n
\n

Public artifact SHA-256

\n

Recorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.

\n

Sanitization performed

\n

Removed executing account, local administrator membership, SIDs, GUIDs, group policy raw details, software inventory, unrelated services, event data, and local profile or path information.

\n

Limitations

\n
    \n
  • Personal nonproduction home lab only.
    • \n
  • Captured-state evidence only.
    • \n
  • This artifact validates WS01 inventory values and domain membership state only.
    • \n
  • It does not claim production support, employer-system administration, complete endpoint hardening, or complete application/service validation.
    • \n
\n

Validation date

\n

2026-06-30

\n

Classification

\n

Validated

Redaction Log / redaction-log.md
Original source ↗Open document page

Redaction Log

\n

No credentials, private keys, tokens, cookies, or secrets were copied. Public summaries avoid private repository links and retain only reviewer-safe claim context.

\n

For the direct evidence artifacts, usernames, executing accounts, MAC addresses, UUIDs, VM generation IDs, UPIDs, PIDs, SIDs, internal object GUIDs, absolute local Windows user paths, unnecessary root paths, unrelated installed features, unrelated command history, unnecessary timestamps, and snapshot parent names were removed or omitted where they were not required to support the stated public claim.

\n

The Proxmox thin-pool warning is retained as an operational limitation. It is not framed as a failed restore or infrastructure failure.

Backup and Restore Validation / backup-and-restore-validation.md
Original source ↗Open document page

Backup and Restore Validation

\n

Status

\n

Partially validated by retained June 24 documentation. No restore test was repeated during the 2026-06-26 read-only operations run.

\n

Current Evidence

\n

Read-only Proxmox inventory observed an enabled scheduled backup job:

\n
    \n
  • Job ID: backup-critical-lab-vms
    • \n
  • VMs: 100,200,300,400
    • \n
  • Storage: backup-hdd
    • \n
  • Schedule: sun 02:00
    • \n
  • Mode: snapshot
    • \n
  • Compression: zstd
    • \n
\n

Storage inventory observed backup storage named backup-hdd at /mnt/pve/backup-hdd.

\n

The June 24 IP-address-documented portfolio documentation records isolated startup restore checks for:

\n
    \n
  • WS01 restored temporarily as VM 500, with the NIC link down before startup.
    • \n
  • Linux01 restored temporarily as VM 600, with the NIC link down before startup.
    • \n
\n

The current Proxmox inventory no longer shows VM 500 or VM 600, which is consistent with the documentation stating both temporary restore VMs were removed after validation.

\n

Required Future Validation

\n

Before claiming recurring restore assurance, perform an approved fresh restore validation that documents:

\n
    \n
  • Exact VM or test restore target
    • \n
  • Backup file selected
    • \n
  • Restore command or UI action
    • \n
  • Network isolation approach
    • \n
  • Validation checks
    • \n
  • Cleanup steps
    • \n
  • Rollback procedure
    • \n
  • Evidence proving successful boot or file-level recovery
    • \n
\n

Claim Boundary

\n

The current operations repository validates backup job configuration visibility and retains documentation of June 24 isolated startup restore checks. It does not validate current backup archive integrity, recurring restore success, RTO, RPO, or disaster-recovery readiness.

Centralized Logging Expansion Change Plan / centralized-logging-expansion.md
Original source ↗Open document page

Centralized Logging Expansion Change Plan

\n

Status

\n

Planned. Approval required before implementation.

\n

Current State

\n

June 24 documentation records pfSense forwarding selected system, firewall, authentication, VPN, and gateway events to Linux01 at 10.10.30.20:514, with Linux01 rsyslog listeners and alert-match logging. Current Proxmox metadata validates Linux01 is running on VLAN 30 and QEMU guest agent is responding.

\n

The June 26 authenticated Linux01 target-local inventory validates rsyslog runtime state from inside the guest. Linux01 reports rsyslog active, TCP and UDP 514 listening on 10.10.30.20, remote collector configuration under /etc/rsyslog.d/10-remote-collector.conf, pfSense alert file configuration under /etc/rsyslog.d/05-pfsense-alerts.conf, and rsyslog logrotate configuration under /etc/logrotate.d/rsyslog.

\n

Evidence

\n
    \n
  • Proxmox current API: Linux01 VM 400 running, tag=30, guest agent responding.
    • \n
  • DNS current command: linux01.ad.jeremyfontenot.online resolves to 10.10.30.20.
    • \n
  • June 24 IP-address-documented documentation: pfSense-to-Linux01 rsyslog forwarding and alert logging documented.
    • \n
  • Current reachability check: TCP 514 from the current client path timed out and is not treated as rsyslog service failure.
    • \n
  • inventories/linux01-inventory-20260626-020257.json: SSH from the management execution path timed out; guest-side rsyslog state was NOT TESTED.
    • \n
  • inventories/linux01-inventory-20260626-084312.json: authenticated target-local Linux01 inventory validates rsyslog service/listener state, route/DNS state, AD integration indicators, disk capacity, and logrotate summary.
    • \n
  • evidence/linux01-local-inventory-validation-20260626-035220.md: sanitized evidence for Linux01 target-local inventory import and validation.
    • \n
\n

Target State

\n

Expand centralized logging beyond pfSense by adding documented, least-privilege log forwarding or collection for Windows and Proxmox sources without weakening existing firewall policy.

\n

Candidate target design, pending implementation approval:

\n
    \n
  • Keep Linux01 as the primary syslog receiver because target-local evidence now confirms available root filesystem capacity, active rsyslog listeners on 10.10.30.20:514 for TCP and UDP, and rsyslog log rotation. UFW source restrictions still require a clearer privileged summary before any new source is added.
    • \n
  • Evaluate Windows Event Forwarding for DC01 and WS01 with DC01 as the likely Windows Event Collector only if existing domain policy and firewall posture support it safely. Do not make DC01 a collector until a separate change plan covers subscription type, source computers, event channels, retention, and rollback.
    • \n
  • Evaluate Proxmox remote syslog forwarding to Linux01 or another approved receiver only after documenting source IP, destination IP, protocol, port, and retention.
    • \n
  • Keep Linux local logs on Linux01 in local journald/rsyslog paths unless an approved monitoring platform is introduced.
    • \n
\n

Exact Systems

\n
    \n
  • Linux01 VM 400
    • \n
  • DC01 VM 200
    • \n
  • WS01 VM 300
    • \n
  • Proxmox host 192.168.0.242
    • \n
  • pfSense VM 100
    • \n
\n

Exact Commands

\n

Discovery and planning only until approved:

\n
pwsh -NoProfile -File .\\scripts\\linux\\Get-LinuxReadOnlyInventory.ps1\npwsh -NoProfile -File .\\scripts\\active-directory\\Invoke-DC01LocalReadOnlyCollection.ps1\npwsh -NoProfile -File .\\scripts\\windows-server\\Invoke-WS01LocalReadOnlyCollection.ps1\n
\n

Implementation commands are intentionally not authorized in this change plan. Linux01 rsyslog state has been validated, but Windows Event Forwarding, Proxmox logging state, pfSense sender configuration, and any firewall or GPO requirements still need a dedicated approved implementation plan.

\n

Target-local validation commands prepared for the next inventory pass:

\n
run_id=\"$(date -u +%Y%m%d-%H%M%S)\"\nbash ./Invoke-Linux01LocalReadOnlyCollection.sh \"/tmp/linux01-inventory-${run_id}.json\"\n
\n

Required Privileges

\n
    \n
  • Read-only collection: existing approved sessions.
    • \n
  • Any logging configuration change: administrative privileges on the target system and explicit approval.
    • \n
\n

Network Requirements

\n

No firewall openings are approved by this plan. Any proposed log path must identify source, destination, protocol, port, and existing firewall state before implementation.

\n

Expected network review before implementation:

\n
    \n
  • pfSense to Linux01 syslog path: verify existing source restriction, protocol, and port from configuration evidence before changing anything.
    • \n
  • DC01 and WS01 to collector: identify whether Windows Event Forwarding uses existing domain/Kerberos paths or requires new firewall scope. Any firewall or GPO change requires a dedicated approved plan.
    • \n
  • Proxmox to Linux01 syslog: document management-network source, Linux VLAN destination, routing path, and firewall requirements before implementation.
    • \n
\n

Security Impact

\n

Positive if implemented carefully: stronger audit trail and troubleshooting visibility. Risk if overbroad: excessive log exposure, sensitive log retention, or unnecessary inter-network access.

\n

Security controls required in the implementation plan:

\n
    \n
  • Exclude credentials, private keys, Kerberos tickets, certificate private material, and sensitive raw log excerpts from repository evidence.
    • \n
  • Prefer source-restricted firewall rules over broad subnet acceptance if any new rules are approved.
    • \n
  • Document whether logs are unauthenticated syslog, authenticated Windows Event Forwarding, or locally collected files.
    • \n
  • Define integrity expectations honestly; plain syslog improves visibility but does not provide strong transport integrity by itself.
    • \n
\n

Service-Impact Risk

\n

Low for discovery. Medium for configuration changes because logging service reloads or firewall changes could disrupt visibility or access if done incorrectly.

\n

Implementation must avoid service restarts unless the approved plan explicitly requires them. Prefer configuration validation and reload-only workflows where technically appropriate.

\n

Retention, Rotation, and Capacity

\n

Linux01 authenticated inventory currently supports:

\n
    \n
  • Root filesystem capacity: 19 GiB total, 13 GiB available, 29 percent used.
    • \n
  • Current rsyslog listener state: TCP and UDP 514 listening on 10.10.30.20.
    • \n
  • Current rsyslog destination templates/configuration: /var/log/remote/%FROMHOST-IP%/messages.log and /var/log/remote/pfsense-alerts.log are configured.
    • \n
  • Current logrotate policy for rsyslog-managed files: weekly rotation, four rotations, compression, missing files tolerated, empty files skipped.
    • \n
  • Disk-use alert threshold. Initial planning threshold: warning at 80 percent used, critical at 90 percent used, pending Jeremy approval.
    • \n
  • Failure behavior if Linux01 is unavailable: sources should continue local logging and must not block authentication, DNS, DHCP, routing, or VM operation.
    • \n
\n

Alerting

\n

Alerting remains planned. Candidate non-invasive alerts after receiver validation:

\n
    \n
  • Linux01 log filesystem above threshold.
    • \n
  • rsyslog service inactive.
    • \n
  • No pfSense log receipt within an expected interval.
    • \n
  • Proxmox backup job failure or missing latest backup.
    • \n
  • Windows Event Forwarding subscription source inactive, if WEF is later approved.
    • \n
\n

Validation

\n
    \n
  • Confirm log sender service state.
    • \n
  • Confirm listener state on Linux01.
    • \n
  • Send one controlled non-sensitive test event.
    • \n
  • Confirm event arrives in the expected file or index.
    • \n
  • Confirm no credentials or private data are written to repository evidence.
    • \n
\n

Rollback

\n
    \n
  • Revert only the logging configuration added by the approved implementation.
    • \n
  • Restore any exported pre-change configuration where applicable.
    • \n
  • Restart/reload only affected logging services if required and approved.
    • \n
\n

Evidence Capture

\n
    \n
  • Timestamped pre-change inventory.
    • \n
  • Sanitized configuration diff or export.
    • \n
  • Exact command transcript with secrets omitted.
    • \n
  • Controlled test-event result.
    • \n
  • Rollback verification.
    • \n
\n

Approval Requirement

\n

Explicit Jeremy approval is required before any logging configuration, firewall, service, package, or scheduled-task change.

\n

Claim Boundary

\n

This plan is implementation-ready documentation only. It does not implement centralized logging expansion, change firewall policy, install software, restart services, or modify any infrastructure system. Linux01 rsyslog receiver state is now validated by target-local inventory; additional sources and alerting remain planned until separately approved and implemented.

Home Lab Inventory and Validation Evidence / home-lab-inventory-validation.md
Original source ↗Open document page

Home Lab Inventory and Validation Evidence

\n
    \n
  • Timestamp: 2026-06-26T01:06:01.2273166-05:00
    • \n
  • Source workstation: DESKTOP-MR3F9A1
    • \n
  • Repository: C:\\Users\\jeremy\\Documents\\projects\\jeremy-homelab-ops
    • \n
  • Execution mode: read-only discovery, inventory, and validation
    • \n
  • Infrastructure configuration changes: 0
    • \n
\n

Commands and Access Paths

\n
    \n
  • Proxmox inventory: mcp__home_lab read-only Proxmox tools.
    • \n
  • Repository validation: pwsh -NoProfile -File .\\tests\\Test-RepositoryStructure.ps1 -WriteEvidence
    • \n
  • Connectivity validation: pwsh -NoProfile -File .\\scripts\\monitoring\\Test-HomeLabConnectivity.ps1 -TimeoutMilliseconds 1000
    • \n
  • DNS validation: Resolve-DnsName ad.jeremyfontenot.online -Server 10.10.20.10
    • \n
  • Route validation: route.exe print -4
    • \n
  • Domain discovery: nltest /dsgetdc:ad.jeremyfontenot.online, nltest /dclist:ad.jeremyfontenot.online, nltest /sc_query:JFAD
    • \n
  • Module availability: Get-Command Get-ADDomain, Get-Command Get-GPO, Get-Command Get-DhcpServerv4Scope, Get-Command Get-DnsServerZone
    • \n
\n

Validated Results

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
CheckStatusObserved result
Proxmox API inventoryPASSVersion 9.2.3, node proxmox online, VMs 100, 200, 300, and 400 running.
Proxmox storage inventoryPASSlocal-lvm, backup-hdd, and local reported capacity and usage.
Proxmox backup job inventoryPASSJob backup-critical-lab-vms enabled for VMs 100,200,300,400, storage backup-hdd, schedule sun 02:00.
Proxmox management TCPPASS192.168.0.242:8006 connected in 67 ms.
DC01 DNS TCPPASS10.10.20.10:53 connected in 6 ms.
Domain DNS resolutionPASSad.jeremyfontenot.online resolved to 10.10.20.10 using server 10.10.20.10.
VPN routePASSRoute table includes 10.10.20.0/24 via 10.10.40.1 from 10.10.40.2.
Repository validationPASSRepository validation completed with no failing checks.
\n

Warnings and Inconclusive Results

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
CheckStatusObserved result
pfSense LAN HTTPS TCPWARNING10.10.20.1:443 timed out after 1000 ms.
DC01 Kerberos TCPWARNING10.10.20.10:88 timed out after 1000 ms.
DC01 LDAP TCPWARNING10.10.20.10:389 timed out after 1000 ms.
DC01 SMB TCPWARNING10.10.20.10:445 timed out after 1000 ms.
DC01 WinRM TCPWARNING10.10.20.10:5985 timed out after 1000 ms.
Domain controller discoveryINCONCLUSIVEnltest /dsgetdc:ad.jeremyfontenot.online returned ERROR_NO_SUCH_DOMAIN from the current workstation context.
Secure channel queryINCONCLUSIVEnltest /sc_query:JFAD returned RPC_S_SERVER_UNAVAILABLE from the current workstation context.
DNS Server module inventoryNOT TESTEDGet-DnsServerZone is not installed on the management workstation.
DHCP Server module inventoryNOT TESTEDGet-DhcpServerv4Scope is not installed on the management workstation.
Group Policy inventoryNOT TESTEDGet-GPO is not installed on the management workstation.
WS01 guest inventoryNOT TESTEDNo verified WS01 management IP or guest-agent response was available in this run.
\n

Claim Boundary

\n

This evidence records read-only repository validation, Proxmox connector inventory, local route inspection, DNS resolution, and bounded TCP reachability checks. It does not validate pfSense configuration, firewall policy, NAT policy, VPN configuration correctness, Active Directory health, DNS zone health, DHCP scope health, Group Policy processing, WS01 domain relationship, backup restore integrity, or administrative access to Windows guests.

\n

Timeouts, module absence, and nltest failures are recorded observations only. They are not proof that the corresponding infrastructure components are offline, misconfigured, or unavailable.

Home Lab Source of Truth / home-lab-source-of-truth.md
Original source ↗Open document page

Home Lab Source of Truth

\n

Status

\n

Current as of the 2026-06-26 read-only reconciliation run.

\n

Source Precedence

\n
    \n
  1. Current command output, API output, guest-agent output, or authenticated system query.
    2. \n
  2. New timestamped evidence collected during this run.
    3. \n
  3. Current jeremy-homelab-ops inventories and evidence.
    4. \n
  4. Current main branch of fontenotjeremy71-hub/jeremyfontenot.
    5. \n
  5. June 24, 2026 IP-address-documented portfolio documentation.
    6. \n
  6. June 21, 2026 curated historical evidence.
    7. \n
  7. Currently deployed website content.
    8. \n
  8. Old prompts, summaries, assumptions, or undocumented memory.
    9. \n
\n

Current Supported Architecture

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ComponentCurrent supported valueClassificationEvidence
Physical hostDell PowerEdge R710Current documentationPortfolio and operations docs
HypervisorProxmox VE 9.2.3CurrentProxmox API
Proxmox management192.168.0.242/24, gateway 192.168.0.1CurrentProxmox API and TCP validation
pfSenseVM 100 pfsense-fwCurrentProxmox API
pfSense WAN192.168.0.205/24Current documentation, not re-queried from pfSenseJune 24 DOCX
pfSense LAN10.10.20.1/24Current documentationJune 24 DOCX and topology
Linux VLAN gateway10.10.30.1/24Current documentationJune 24 DOCX
OpenVPN network10.10.40.0/24Current documentation plus route evidenceJune 24 DOCX and local route
DC01VM 200, 10.10.20.10/24, Windows Server 2022 domain controllerCurrent authenticated guest inventoryProxmox API, DNS/RDP validation, inventories/dc01-inventory-20260626-022543.json
WS01VM 300, 10.10.20.100/24, Windows domain workstationCurrent authenticated guest inventoryProxmox API, inventories/ws01-inventory-20260626-012952.json
Linux01VM 400, 10.10.30.20/24, VLAN 30, Ubuntu 26.04 LTS domain memberCurrent authenticated guest inventoryProxmox API, DNS validation, inventories/linux01-inventory-20260626-084312.json
AD domainad.jeremyfontenot.onlineCurrent authenticated guest inventoryDC01 target-local inventory, 2026-06-26
NetBIOS domainJFADCurrent authenticated guest inventoryDC01 target-local inventory, 2026-06-26
Backup storagebackup-hdd at /mnt/pve/backup-hddCurrentProxmox API
Backup jobbackup-critical-lab-vms, Sunday 02:00, snapshot, zstd, VMs 100/200/300/400CurrentProxmox API
\n

Historical or Stale Values

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ValueClassificationCurrent handling
Linux01 10.10.20.20/24HistoricalRetained as pre-VLAN 30 address only
Linux01 DHCP 10.10.20.101HistoricalRetained as initial setup address only
backup-nvme or /mnt/pve/backup-nvmeStale or inconclusiveNot current unless future evidence proves rename/replacement
Direct WAN-side RDP forwardingHistoricalCurrent design uses OpenVPN-only RDP path
June 21 restore outstanding limitationHistoricalSuperseded by June 24 isolated restore documentation, not re-run during this ops pass
\n

Claim Boundary

\n

This file corrects explanatory documentation using current evidence. It does not modify historical evidence and does not claim live guest OS internals unless current command output or explicitly cited retained evidence supports the claim.

\n

The June 26 target-local workflow imported authenticated DC01 evidence in inventories/dc01-inventory-20260626-022543.json and evidence/dc01-local-inventory-validation-20260626-022811.md. It imported authenticated WS01 evidence in inventories/ws01-inventory-20260626-012952.json and evidence/ws01-local-inventory-validation-20260626-033405.md. It also imported authenticated Linux01 evidence in inventories/linux01-inventory-20260626-084312.json and evidence/linux01-local-inventory-validation-20260626-035220.md.

Home Lab Source Reconciliation Evidence / home-lab-source-reconciliation.md
Original source ↗Open document page

Home Lab Source Reconciliation Evidence

\n
    \n
  • Timestamp: 2026-06-26T01:26:06.6980689-05:00
    • \n
  • Source workstation: DESKTOP-MR3F9A1
    • \n
  • Operations repository: C:\\Users\\jeremy\\Documents\\projects\\jeremy-homelab-ops
    • \n
  • Portfolio repository: C:\\Users\\jeremy\\Documents\\projects\\jeremyfontenot
    • \n
  • Deployed page inspected: https://jeremyfontenot.online/on-prem-home-lab.html
    • \n
  • Infrastructure changes made: 0
    • \n
\n

Current Command/API Evidence

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ComponentResult
Proxmox version9.2.3
VM 100pfsense-fw, running, vmbr0 and vmbr1
VM 200dc01, running, vmbr1
VM 300ws01, running, vmbr1, guest agent disabled
VM 400linux01, running, vmbr1, tag=30, QEMU guest agent responding
Backup storagebackup-hdd, path /mnt/pve/backup-hdd, active
Backup jobbackup-critical-lab-vms, enabled, sun 02:00, snapshot, zstd, VMs 100,200,300,400
Linux01 DNSlinux01.ad.jeremyfontenot.online resolves to 10.10.30.20
Linux01 PTR10.10.30.20 resolves to linux01.ad.jeremyfontenot.online
VPN pathDC01 DNS TCP 53 and RDP TCP 3389 reachable
Expected blockDC01 SMB TCP 445 and pfSense WAN direct RDP TCP 3389 timed out
\n

Conflicts

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ComponentHigher-precedence current valueLower-precedence conflicting valueClassificationAction
Linux01 IP10.10.30.20/24Deployed website and June 21 evidence show 10.10.20.20/24Stale deployed/historical valueOperations docs now treat 10.10.20.20 as historical
Linux01 VLANProxmox config has tag=30Deployed website omits VLAN 30 current stateStale deployed valueOperations docs use current Proxmox metadata
Restore statusJune 24 DOCX records isolated restore checks for VM 500 and 600June 21 redaction log says restore outstandingHistorical differenceRecovery docs distinguish June 21 historical limitation from June 24 documentation
Backup storageProxmox API shows backup-hdd at /mnt/pve/backup-hddOlder prompt/doc values mention backup-nvmeStale or inconclusive historical valueOperations docs use backup-hdd and flag backup-nvme as stale unless rename evidence is found
\n

Claim Boundary

\n

Current Proxmox API output and current DNS/RDP checks are treated as current observed state. Portfolio and DOCX records are retained as documentation evidence where live command output cannot validate guest internals from this client path. Historical evidence is not rewritten.

Linux01 SSSD Remediation / linux01-sssd-remediation.md
Original source ↗Open document page

Linux01 SSSD Remediation

\n

Summary

\n
    \n
  • Target: Linux01
    • \n
  • Date: June 26, 2026
    • \n
  • Domain: ad.jeremyfontenot.online
    • \n
  • Classification: SSSD responder activation conflict
    • \n
  • Result: Remediated and validated
    • \n
\n

Initial Condition

\n
    \n
  • sssd-nss.socket, sssd-pam.socket, and sssd-pac.socket were enabled and failed.
    • \n
  • /etc/sssd/sssd.conf used direct responder activation with services = nss, pam.
    • \n
  • config_file_version = 2 was rejected by SSSD 2.12 configuration validation.
    • \n
  • Initial diagnostic: artifacts/target-local-collection/Linux01/linux01-sssd-diagnostic-20260626-094322.json
    • \n
  • Initial SHA-256: 3CAD0FB73202D777D41DEE40D6F4D19D4019B9AD30552B37970B55A5CA5AB3BB
    • \n
\n

Backup

\n
    \n
  • Backup: /root/sssd.conf.pre-remediation-20260626-095429.bak
    • \n
  • Original and backup SHA-256: 23ace1beca5ff6f7d58200efe054ea8e5a938e02f37fce25b1ca1b5d2f05bd14
    • \n
\n

Remediation

\n
    \n
  1. Removed the rejected config_file_version directive.
    2. \n
  2. Confirmed sssctl config-check completed with zero issues.
    3. \n
  3. Disabled the NSS, PAM, and PAC SSSD socket units.
    4. \n
  4. Restarted sssd.service.
    5. \n
  5. Cleared the historical failed-unit state.
    6. \n
\n

Validation

\n
    \n
  • sssd.service is enabled, active, and running.
    • \n
  • No failed systemd units remain.
    • \n
  • All three responder sockets report disabled.
    • \n
  • AD identity lookup succeeded.
    • \n
  • A new AD-authenticated SSH session succeeded.
    • \n
  • Post-remediation diagnostic: artifacts/target-local-collection/Linux01/linux01-sssd-diagnostic-20260626-110159.json
    • \n
  • Post-remediation SHA-256: FD55604BFB94487B86FBF631703FA995B9726471689385CCB2D277492AA7CBEE
    • \n
\n

Final Status

\n

Linux01 is operating normally using direct SSSD responder activation.

Troubleshooting

Direct tests separated WinRM reachability, authentication overhead, and actual host resources when the WAC experience felt slow. The source does not establish a broader server-performance root cause.

Validation & results

Windows management and connectivity/remoting validation are documented. The registry does not identify a fully separate WAC evidence directory.

DC01 System and Role Validationevidence-library/projects/on-prem-home-lab/current-validated-state/direct-evidence/dc01-system-and-role-validation.mdLinux01 SSSD Remediation Validationevidence-library/projects/on-prem-home-lab/current-validated-state/direct-evidence/linux01-sssd-remediation-validation.mdLinux01 System, Network, and Domain Validationevidence-library/projects/on-prem-home-lab/current-validated-state/direct-evidence/linux01-system-network-domain-validation.mdProxmox Restore Validationevidence-library/projects/on-prem-home-lab/current-validated-state/direct-evidence/proxmox-restore-validation.mdWS01 System and Domain Validationevidence-library/projects/on-prem-home-lab/current-validated-state/direct-evidence/ws01-system-and-domain-validation.mdBackup and Restore Validationevidence-library/projects/on-prem-home-lab/current-validated-state/source-summaries/backup-and-restore-validation.mdHome Lab Inventory and Validation Evidenceevidence-library/projects/on-prem-home-lab/current-validated-state/source-summaries/home-lab-inventory-validation.md

Evidence

STRONG for documented centralized Windows management and connectivity/remoting validation; exact dedicated evidence directory NEEDS VERIFICATION.

proxmox-backup-configuration.mdReviewed backup coverage, archive state, network isolation, temporary restore VMs, validation checkpoints, cleanup, and result boundaries. ↗proxmox-platform-inventory.mdReviewed node, VM, storage, bridge, VLAN, guest-agent, snapshot, backup, and lifecycle state. ↗home-lab-source-reconciliation.mdMaintained a documented nonproduction environment spanning virtualization, firewalling, Windows, Linux, networking, and backup services. ↗home-lab-source-of-truth.mdMaintained a documented nonproduction environment spanning virtualization, firewalling, Windows, Linux, networking, and backup services. ↗linux01-sssd-remediation.mdReviewed Ubuntu networking, SSH, time synchronization, logging, updates, security controls, guest integration, Kerberos, realmd, and SSSD. ↗provenance.jsonMaintained a documented nonproduction environment spanning virtualization, firewalling, Windows, Linux, networking, and backup services. ↗backup-and-restore-validation.mdReviewed backup coverage, archive state, network isolation, temporary restore VMs, validation checkpoints, cleanup, and result boundaries. ↗provenance.csvMaintained a documented nonproduction environment spanning virtualization, firewalling, Windows, Linux, networking, and backup services. ↗manifest.jsonMaintained a documented nonproduction environment spanning virtualization, firewalling, Windows, Linux, networking, and backup services. ↗claim-map.csvMaintained a documented nonproduction environment spanning virtualization, firewalling, Windows, Linux, networking, and backup services. ↗
Browse and filter the complete evidence libraryGitHub project source ↗

Skills demonstrated

Windows Admin CenterWinRMPowerShell
View the complete capability map →

Limitations & claim boundaries

Personal lab management. Does not imply production WAC administration or enterprise-scale fleet management.

Next milestones

Revalidate only if the managed server inventory, gateway, authentication path, or remote-management topology materially changes.

Continue exploring

Related projects

", "active": "Projects" }, "projects/scvmm-2022": { "title": "SCVMM 2022 Hyper-V Management", "description": "A managed nested Hyper-V host, VMM logical networking, and validated APP01 lifecycle operations.", "body": "

Project 05 / Virtualization

SCVMM 2022 Hyper-V Management

A managed nested Hyper-V host, VMM logical networking, and validated APP01 lifecycle operations.

COMPLETEValidated lab work
GitHub documentation ↗Original portfolio ↗Evidence library

Overview

A managed nested Hyper-V host, VMM logical networking, and validated APP01 lifecycle operations.

Classification: Validated lab work.

Operational scenario & objectives

Centralize Hyper-V management without replacing Proxmox; model the lab network, manage existing switches, and validate VM operations.

Environment & technologies

VMM01 runs SCVMM 2022, managing HVHOST01 as one nested Hyper-V host and APP01 as an observed guest.

SCVMM 2022Hyper-VLogical networking

Architecture

VMM01 runs SCVMM 2022, managing HVHOST01 as one nested Hyper-V host and APP01 as an observed guest.

Explore infrastructure architecture →

Implementation & administration

\n

Windows Server · Virtualization management · Logical networking · Remote administration

SCVMM 2022 management from server build to VMM-managed networking and VM operations.

Built a System Center Virtual Machine Manager environment on VMM01, added HVHOST01 as a managed Hyper-V host, repaired host-agent management credentials, modeled the 10.10.20.0/24 lab in VMM, converted the existing Hyper-V switch to a VMM logical switch, classified APP01 network traffic, and validated lifecycle operations without breaking the isolated lab path.

Review the networking updateInspect screenshotsReturn to the Home Lab
\n
Project 05 · COMPLETE · Validated in personal labVMM

Centralize a nested Hyper-V environment without replacing Proxmox.

The lab keeps Proxmox as the underlying platform while using VMM01 and SCVMM to manage the nested Hyper-V layer on HVHOST01. The work now covers installation, prerequisite remediation, service identity, host onboarding, Run As credentials, logical network and IP-pool modeling, logical-switch conversion, port classification, VM discovery, lifecycle control, checkpoint handling, interactive console use, and a deliberately scoped remote-management path.

Windows Server 2022SCVMM 2022SQL Server 2022 DeveloperHyper-VLogical NetworksLogical SwitchesIP PoolsRun As AccountsOpenVPNPowerShell
Management server
VMM01 running the SCVMM management server and console.
Managed host
HVHOST01, a Windows Server 2022 nested Hyper-V host.
Managed workload
APP01, discovered from the existing Hyper-V inventory and managed through VMM.
Logical network
ad mapped to 10.10.20.0/24 with VMM IP pool 10.10.20.201–10.10.20.220.
Boundary
Personal nonproduction lab; no clustering, high availability, live migration, or enterprise-scale claim.
\n

Validated management path

The tested control chain stayed narrow and reviewable.

Non-domain laptopOpenVPN · 10.10.40.0/24VMM01 · 10.10.20.100HVHOST01 · 10.10.20.102APP01 · 10.10.20.103
\n

Implementation and troubleshooting

Build, remediate, onboard, and verify.

\n
01

Server and database foundation

Prepared VMM01 on Windows Server 2022 and installed SQL Server 2022 Developer as the local database platform for the VMM management server.

\n
02

ADK and WinPE prerequisites

Installed Windows ADK Deployment Tools and the Windows PE add-on. When VMM could not locate the Component Studio libraries, verified that the DLLs existed under WSIM\\amd64 and copied the WSIM architecture files into the root path expected by Setup.

\n
03

Dedicated service identity

Created JFAD\\svc_scvmm, configured the account for the lab service role, added it to VMM01's local Administrators group, and used it for the Virtual Machine Manager service.

\n
04

SCVMM installation

Installed both the SCVMM 2022 management server and VMM console, configured the local VMM database and library, retained standard service ports, and verified a successful console connection to VMM01.

\n
05

Hyper-V host onboarding

Added HVHOST01 as a trusted-domain Hyper-V host. The first agent deployment exposed an unreachable ADMIN$ path; TCP 445 testing isolated the firewall block, File and Printer Sharing was enabled, and the retry completed with host status OK.

\n
06

VM discovery and control

SCVMM discovered APP01 on HVHOST01. Remote power-on completed successfully, guest information populated, and VM Viewer confirmed an interactive APP01 console session.

\n
07

Laptop console over OpenVPN

Installed only the VMM console MSI on the non-domain-joined laptop, connected to VMM01 with domain credentials through OpenVPN, and validated TCP 8100 access plus APP01 control and console viewing.

\n
08

Temporary access cleanup

Removed the temporary SCVMM installer SMB share, deleted the laptop's cached SMB connection, and removed the temporary OpenVPN TCP 445 rule. TCP 8100 remains as the scoped VMM console path.

\n
\n

August 15, 2026 operational update

Extended the lab from host management into VMM logical networking and repeatable operations.

This working session focused on correcting host-management health, bringing the existing Hyper-V network under VMM control, and exercising APP01 through the VMM abstraction layer while preserving the isolated 10.10.20.0/24 lab behind pfSense.

\n
09

Recovered VMM host-agent health

HVHOST01 initially reported Needs Attention with VMM error 12704 even though vmms and SCVMMAgent were running and both server and agent were version 10.22.1287.0. WinRM tests passed. A VMM Run As account named HVHOST01 Management was created with the validated domain-management credential and assigned under Host Access. After refresh, host status, network, WinRM, agent service, and agent version all reported OK.

\n
10

Modeled the isolated AD network

Validated the VMM logical network ad and network site AD-10.10.20.0-24 for subnet 10.10.20.0/24. The static VMM IP pool spans 10.10.20.201 through 10.10.20.220 and VMM reports the logical network as Fully compliant.

\n
11

Resolved logical-switch conversion blockers

The existing External-LAN standard switch could not convert while the VMM logical switch used a different minimum-bandwidth mode and uplink teaming mode. The Host management port profile weight was cleared, HomeLab-Logical-Switch was changed to Absolute bandwidth mode, and its uplink mode was changed to No Uplink Team to match the single-adapter standard switch.

\n
12

Converted to a VMM logical switch

Converted External-LAN into HomeLab-Logical-Switch using the HomeLab-Uplink uplink profile. VMM completed the host-change job successfully, Hyper-V reported the new external switch name, and the host management vNIC retained 10.10.20.102/24, gateway 10.10.20.1, and DNS 10.10.20.10.

\n
13

Applied a VM traffic classification

Adjusted the built-in Medium Bandwidth Adapter profile so it was compatible with the logical switch's Absolute bandwidth mode, mapped the Medium bandwidth classification into HomeLab-Logical-Switch, and assigned that classification to APP01's virtual network adapter.

\n
14

Validated guest network and domain services

APP01 remained connected to HomeLab-Logical-Switch with status Ok. Inside the guest, 10.10.20.103/24, gateway 10.10.20.1, and DNS 10.10.20.10 remained intact. Gateway ping succeeded, DC01 resolved to 10.10.20.10, and TCP 389 to the domain controller succeeded.

\n
15

Exercised checkpoint lifecycle

Created the VMM checkpoint Pre-VMM-Lab-Changes while APP01 remained running, verified the checkpoint in APP01 properties, then deleted it and confirmed the checkpoint list returned to empty.

\n
16

Protected resource headroom

Measured HVHOST01 at four logical processors and about 8 GB RAM. APP01 Dynamic Memory was already configured with 2048 MB minimum, 4096 MB startup, and 6144 MB maximum; its active assignment had settled to 2 GB with memory status OK. No additional Windows VM was deployed so the nested host retained practical headroom.

\n
\n

Observed results

The management behaviors were exercised, not inferred.

\n
Host health

HVHOST01 status OK

Network, WinRM, Host Agent Service, Host Agent Version, and overall host health were returned to OK after assigning the Run As account.

\n
Logical network

10.10.20.0/24 fully compliant

The ad logical network, network site, and 20-address VMM pool were recognized as fully compliant.

\n
Logical switch

External-LAN converted successfully

HVHOST01 now exposes HomeLab-Logical-Switch as the external Hyper-V switch while preserving the existing host management IP path.

\n
VM networking

APP01 classification and connectivity

APP01 uses HomeLab-Logical-Switch with the Medium bandwidth classification and retained working gateway, DNS, and LDAP connectivity.

\n
Lifecycle

Checkpoint create and delete

The VMM checkpoint workflow completed without stopping APP01, and cleanup returned the VM to a checkpoint-free state.

\n
Scoped remote access

OpenVPN management retained

Remote administration continued through the lab VPN path rather than exposing the isolated 10.10.20.0/24 network directly to the home subnet.

\n
\n

Screenshot evidence

Preserved VMM screenshots anchor the management story.

The gallery contains the previously imported SCVMM working-session screenshots. The August 15 update extends the same case study with the validated logical-network, logical-switch, host-health, APP01 classification, connectivity, and checkpoint work recorded during the VMM project session.

Inspect screenshot hashes and provenanceTrace the public claim
\n

Scope and limitations

A working management lab, not an enterprise VMM deployment.

The evidence supports a single SCVMM 2022 management server, one managed nested Hyper-V host, one observed guest, a VMM logical network and IP pool, conversion of an existing external switch into a VMM logical switch, VM port classification, remote lifecycle control, checkpoint handling, VM Viewer access, and a scoped OpenVPN management path. It does not prove clustering, high availability, live migration, Storage Spaces Direct, enterprise scale, production availability, security assurance, or management of Proxmox guests through VMM.

Review related capabilityReturn to ProjectsDiscuss role fit
\n

The original case-study narrative and linked evidence provide the detailed record for this project.

Troubleshooting

The published case study records prerequisite remediation and repaired host-agent management credentials before validating host onboarding and VMM-managed networking.

Validation & results

One host and an observed guest were managed; logical networking, checkpoint lifecycle, remote power, and VM Viewer behavior are documented.

Evidence

VERY STRONG — build, prerequisite remediation, host onboarding, logical networking, logical-switch conversion, VM operations, checkpoint lifecycle, remote console, and screenshots are documented.

scvmm-hvhost01-managed.pngReviewed server roles, services, storage, event summaries, directory indicators, DNS, DHCP, and Group Policy. ↗scvmm-setup-complete.pngReviewed server roles, services, storage, event summaries, directory indicators, DNS, DHCP, and Group Policy. ↗scvmm-app01-discovered.pngReviewed server roles, services, storage, event summaries, directory indicators, DNS, DHCP, and Group Policy. ↗scvmm-app01-remote-power.pngReviewed server roles, services, storage, event summaries, directory indicators, DNS, DHCP, and Group Policy. ↗index.htmlReviewed server roles, services, storage, event summaries, directory indicators, DNS, DHCP, and Group Policy. ↗evidence-manifest.jsonReviewed server roles, services, storage, event summaries, directory indicators, DNS, DHCP, and Group Policy. ↗scvmm-app01-vm-viewer.pngReviewed server roles, services, storage, event summaries, directory indicators, DNS, DHCP, and Group Policy. ↗
Browse and filter the complete evidence libraryGitHub project source ↗

Skills demonstrated

SCVMM 2022Hyper-VLogical networking
View the complete capability map →

Limitations & claim boundaries

One SCVMM management server, one nested Hyper-V host, and observed APP01 operations in a personal lab. No clustering, HA, live migration, S2D, or enterprise-scale claim.

Next milestones

Maintenance-only unless VMM topology changes; optional future work must not be described as already implemented.

Continue exploring

Related projects

", "active": "Projects" }, "projects/azure-arc-hybrid-management": { "title": "Azure Arc Hybrid Windows Management", "description": "Two Arc-connected Windows Server lab machines, agent validation, and one SQL Server Developer instance.", "body": "

Project 06 / Cloud administration

Azure Arc Hybrid Windows Management

Two Arc-connected Windows Server lab machines, agent validation, and one SQL Server Developer instance.

COMPLETEValidated lab work
GitHub documentation ↗Original portfolio ↗Evidence library

Overview

Two Arc-connected Windows Server lab machines, agent validation, and one SQL Server Developer instance.

Classification: Validated lab work.

Operational scenario & objectives

Connect non-Azure lab servers to Azure Arc and verify the agent, service state, resource placement, and bounded SQL inventory.

Environment & technologies

HVHOST01 and VMM01 in a personal hybrid Windows lab; the published evidence also covers one SQL Server 2022 Developer instance.

Azure ArcWindows ServerSQL Server

Architecture

HVHOST01 and VMM01 in a personal hybrid Windows lab; the published evidence also covers one SQL Server 2022 Developer instance.

Explore infrastructure architecture →

Implementation & administration

\n

Hybrid management · Windows Server · SQL Server · Evidence-driven validation

On-premises Windows and SQL Server resources connected to Azure Arc.

Onboarded HVHOST01 and VMM01 from a personal Proxmox/QEMU lab into a bounded Azure resource group, validated the Connected Machine agent, completed SQL Server discovery on VMM01, and verified the SQL extension, licensing choice, telemetry state, and current limitations with fresh evidence.

Review the verified stateInspect screenshotsReturn to the Home Lab
\n
Project 06 · COMPLETE · Validated in personal labARC

Executive summary

The project extends an existing on-premises Windows management path into Azure without moving the workloads out of the lab. Proxmox remains the hypervisor, Windows Admin Center remains the local browser-based management point, and Azure Arc adds Azure resource representation, agent health, extension management, and SQL inventory for systems that continue to run on premises.

Azure ArcAzure portalWindows Server 2022SQL Server 2022 DeveloperWindows Admin CenterProxmox VEPowerShell remotingConnected Machine agent
Arc machines
HVHOST01 and VMM01.
SQL resource
VMM01, SQL Server 2022 Developer, connected mode.
Azure scope
rg-hybrid-lab-centralus-01 in Central US under the Azure for Students subscription.
Observed state
Freshly collected on 2026-08-31; see the manifest for integrity records.
Boundary
Personal nonproduction lab; no production, enterprise-scale, availability, or business-impact claim.
\n

Problem, objective, and architecture

Add cloud-based inventory and extension management while keeping the lab on premises.

The objective was to represent two Windows Server systems and the VMM01 SQL instance in Azure, preserve the existing local management design, and make every public claim traceable to current evidence.

Proxmox/QEMUHVHOST01 + VMM01Windows Admin Center + PowerShellAzure Connected Machine agentAzure Arc resource groupArc-enabled SQL Server
\n

Role of Proxmox

Proxmox supplies the QEMU virtualization layer. Both Arc-enabled Windows servers remain running as personal-lab virtual machines; Azure Arc does not replace or directly manage the hypervisor.

\n

Role of Windows Admin Center

Windows Admin Center provides the local connection inventory and Azure integration surface. Its connection list shows both HVHOST01 and VMM01 with Azure Arc status Connected.

\n

Identity separation

The Windows Admin Center gateway uses an on-premises Windows identity, while Azure integration uses a separate Azure identity. Public screenshots redact both account names and the email address while preserving the visible signed-in states.

\n

Resource-group and RBAC boundary

The collected resources are grouped under rg-hybrid-lab-centralus-01. The current evidence does not enumerate role assignments, so it supports resource-group scope but makes no claim about a specific Owner, Contributor, or custom Azure RBAC role.

\n
\n

Onboarding and troubleshooting

Validate the missing agent, use the generated script, and verify the resulting Azure resource.

\n

1. Connectivity before installation

The Windows Admin Center workflow initially appeared to stall while installing the Arc agent. Direct validation found that the Connected Machine agent executable was absent, while outbound TCP 443 connectivity to gbl.his.arc.azure.com succeeded.

\n

2. Manual onboarding script

The Azure-generated onboarding script was transferred to VMM01 and executed through the authorized PowerShell remoting path. The agent installed, authenticated, created the Azure resource, and reported Connected.

\n

3. Agent and service validation

Fresh direct validation on HVHOST01 confirmed agent version 1.67.03504.3207, Connected status, enabled agent auto-upgrade, successful TCP 443 reachability, and the himds, ExtensionService, and GCArcService services running with Automatic startup.

\n

4. Current access limitation

VMM01 answered WinRM but rejected the current Windows credential for a fresh remote session. Its local Arc and SQL services were not re-read directly during this collection; Azure portal and Windows Admin Center supplied the current connected, extension, SQL inventory, licensing, and telemetry evidence.

\n
\n

SQL Server discovery and extension

Move from a pending extension to a connected SQL inventory record.

\n

Initial extension state

The SQL extension initially remained in Creating/ENABLING while the SqlServerExtension service was StartPending. Onboarding logs showed least-privilege configuration and local-group membership work still in progress.

\n

Observed resolution

The service later reached Running, the WindowsAgent.SqlServer extension reached Succeeded, SQL inventory appeared, and DPS upload status reached OK. The current portal evidence shows extension version 1.1.3518.465 with automatic upgrade enabled.

\n

Licensing decision

The Arc-enabled SQL resource reports SQL Server 2022 Developer edition. License only is selected instead of pay-as-you-go; Developer edition is not presented as production licensed.

\n

Services not inferred

Azure Monitor, Azure Backup, Update Manager, Defender, Site Recovery, automated SQL updates, and automatic SQL backups are not described as enabled. The SQL overview explicitly showed automated updates and automatic backups Disabled.

\n
\n

Verified final state

Current results are separated from historical troubleshooting.

\n
Connected

HVHOST01 Arc machine

Azure portal and direct agent output both report Connected in Central US; the three Arc services were running and TCP 443 validation succeeded.

\n
Connected

VMM01 Arc machine

Azure portal and Windows Admin Center report Connected. The portal shows Windows Server 2022 Standard Evaluation and agent version 1.67.03504.3207.

\n
Succeeded

WindowsAgent.SqlServer

Version 1.1.3518.465 reports Succeeded, no update available, and automatic upgrade Enabled.

\n
Connected · telemetry OK

VMM01 SQL Server instance

SQL Server 2022 Developer is inventoried in connected mode with License only, DPS OK, metrics OK, and Connected Machine agent status Connected.

\n
Open the sanitized validation outputReview the public-safe PowerShell commandsInspect hashes and provenance
\n

Security and privacy controls

Publish the evidence, not the identities or control-plane identifiers.

Private originals

Fresh raw captures were retained outside the public repository. Published PNG files are cropped derivatives with tenant IDs, subscription IDs, account names, email addresses, private IP addresses, and unnecessary interface data removed or redacted.

No authentication material

No passwords, MFA codes, device-login codes, tokens, cookies, private keys, connection strings, or raw authentication logs are published.

Integrity records

The evidence manifest records SHA-256 hashes, byte sizes, dimensions, source context, transformation notes, and the specific claim supported by every public screenshot.

Least-claim posture

Connected and Succeeded states are reported only where current evidence shows them. Unavailable direct VMM01 service validation remains a named limitation.

\n

Screenshot evidence

Fresh views from PowerShell, Proxmox, Windows Admin Center, and Azure.

Each image is a cropped and redacted derivative of a newly captured authenticated view. Captions state exactly what the visible fields support.

\n

Skills demonstrated

Hybrid onboarding with operational boundaries and evidence integrity.

Azure Arc onboardingAzure resource groupsConnected Machine agent validationWindows service validationPowerShell remotingOutbound connectivity testingWindows Admin Center integrationSQL Server discoveryAzure extension troubleshootingLog interpretationLicense-scope documentationScreenshot sanitizationEvidence manifests
\n

Limitations and next steps

A verified hybrid-management lab, not a production Azure operations claim.

The evidence supports two Arc-connected Windows Server lab machines, one Arc-enabled SQL Server 2022 Developer instance, current extension and telemetry states, and direct HVHOST01 agent/service validation. It does not prove production administration, enterprise scale, broad Azure RBAC ownership, high availability, disaster recovery, SLA performance, security assurance, or enabled Azure services beyond the fields shown. VMM01 local service state was not freshly read because the current Windows credential was rejected.

Practical next steps are to restore an approved VMM01 remoting path, repeat the local service and SQL checks, document the exact Azure RBAC assignment through a public-safe export, and evaluate optional Azure services separately before making any enablement claim.

Review related capabilityTrace the public claimOpen the evidence mapDiscuss role fit
\n

The original case-study narrative and linked evidence provide the detailed record for this project.

Troubleshooting

The evidence preserves a direct-remoting limitation for VMM01. Portal and agent observations are reported within their actual scope; local service state is not inferred where it was not read.

Validation & results

Two connected Windows lab servers and one SQL Developer instance are supported by sanitized retained records, with remoting and administrative boundaries intact.

Evidence

VERY STRONG — portal state, Connected Machine agent validation, Windows services, SQL extension/inventory, sanitized screenshots, manifest/integrity records, and explicit limitations are documented.

vmm01-arc-overview-public.pngMaintained a documented nonproduction environment spanning virtualization, firewalling, Windows, Linux, networking, and backup services. ↗azure-arc-validation.ps1Reviewed server roles, services, storage, event summaries, directory indicators, DNS, DHCP, and Group Policy. ↗powershell-hvhost01-arc-services-public.pngReviewed server roles, services, storage, event summaries, directory indicators, DNS, DHCP, and Group Policy. ↗evidence-manifest.jsonMaintained a documented nonproduction environment spanning virtualization, firewalling, Windows, Linux, networking, and backup services. ↗azure-arc-validation-public.txtReviewed server roles, services, storage, event summaries, directory indicators, DNS, DHCP, and Group Policy. ↗hvhost01-arc-overview-public.pngMaintained a documented nonproduction environment spanning virtualization, firewalling, Windows, Linux, networking, and backup services. ↗vmm01-sql-extension-public.pngMaintained a documented nonproduction environment spanning virtualization, firewalling, Windows, Linux, networking, and backup services. ↗vmm01-sql-dps-status-public.pngReviewed server roles, services, storage, event summaries, directory indicators, DNS, DHCP, and Group Policy. ↗proxmox-vmm01-summary-public.pngReviewed node, VM, storage, bridge, VLAN, guest-agent, snapshot, backup, and lifecycle state. ↗azure-resource-group-public.pngMaintained a documented nonproduction environment spanning virtualization, firewalling, Windows, Linux, networking, and backup services. ↗
Browse and filter the complete evidence libraryGitHub project source ↗

Skills demonstrated

Azure ArcWindows ServerSQL Server
View the complete capability map →

Limitations & claim boundaries

Supports two Arc-connected Windows Server lab machines and one SQL Server 2022 Developer instance. Does not prove production Azure administration, broad RBAC ownership, HA/DR, SLA performance, or enablement of Azure services not explicitly shown.

Next milestones

Restore an approved VMM01 remoting path and optionally re-read local Arc/SQL services and document exact Azure RBAC if those claims are later desired.

Continue exploring

Related projects

", "active": "Projects" } }