# CS-SERVER Entra Connect Readiness — Verdict

**Executed:** 2026-04-22 17:26 MST (via GuruRMM agent `6766e973-e703-47c1-be56-76950290f87c`)
**Exit code:** 0
**Full output:** `reports/2026-04-22-cs-server-entra-readiness.md`
**Script source:** `docs/migration/scripts/entra-connect-readiness.ps1`

## Overall verdict

**READY to install Entra Connect, after addressing three small pre-install items.** No hard blockers. Hardware / OS / AD / network environment all meet requirements.

## PASS (13 checks)

| Check | Result |
|---|---|
| Operating system | Windows Server 2019 Standard, build 17763 (≥2016 required) |
| .NET Framework | 4.8 (release 528049, ≥4.7.2 required) |
| PowerShell | 5.1.17763.8510 (≥5.0 required) |
| Disk space | C: 149 GB free / D: 548 GB free |
| AD domain / forest mode | Windows2016Forest / Windows2016Domain |
| AD Schema version | 88 (Windows Server 2019) |
| FSMO roles | All 5 on CS-SERVER (expected for single DC) |
| AD size | 44 users, 55 groups, 18 OUs — small enough for fast sync |
| Internet to Microsoft | All 7 sync endpoints reach on HTTPS 443 |
| WinHTTP proxy | Direct access, no proxy config needed |
| Existing AAD/Entra Sync | None — clean install target |
| DC health (dcdiag) | Connectivity / Advertising / Services / FsmoCheck all pass |
| CPU / RAM headroom | 1% CPU, 27% of 48 GB RAM used |

## Pre-install items to fix (in order)

### 1. Time sync — HIGHEST priority

Currently free-running on the local system clock. `w32tm /query /status` reports:

- `Source: Free-running System Clock`
- `ReferenceId: 0x4C4F434C ("LOCL")`
- `Last Successful Sync Time: 4/21/2026 8:31:32 PM` (~21 hours ago at time of check)
- Peer state: `Pending`

Cloud sync has a ±5-minute drift tolerance. A PDC emulator with no external NTP source will drift over days and Entra Connect will start failing intermittently. As the PDC, it's also supposed to be the authoritative time source for the domain — so every other machine is inheriting this drift.

**Fix (no reboot needed):**

```powershell
w32tm /config /manualpeerlist:"time.windows.com,0x8 pool.ntp.org,0x8 time.nist.gov,0x8" /syncfromflags:manual /reliable:yes /update
Restart-Service w32time
w32tm /resync /force
w32tm /query /status   # verify Source is no longer "Free-running"
```

### 2. Backup before install — safety net

Per the earlier audit, **Windows Server Backup feature is Available but not Installed** and there's no documented Synology ABB of CS-SERVER. Entra Connect install touches the AD schema (extends it with a couple of attributes) and creates a service account. If anything goes sideways, we need a rollback path.

**Fix:**

```powershell
Install-WindowsFeature Windows-Server-Backup
# One-shot full backup + system state to Synology SMB share
wbadmin start backup -backupTarget:\\CASCADESDS\Backups\CS-SERVER -include:C:,D: -allCritical -vssFull -quiet
```

(Or use existing Synology ABB if configured — confirm it covers CS-SERVER before install.)

### 3. TLS 1.2 explicit enforcement — HIPAA + defense in depth

Server 2019 defaults to TLS 1.2 enabled, so Entra Connect will work today. But the Schannel registry entries are "unset (OS default)" and `.NET SchUseStrongCrypto` is set on 64-bit but missing on 32-bit. Best practice (and cleaner audit story) is to explicitly enable TLS 1.2 and disable 1.0/1.1.

**Fix (REQUIRES REBOOT for Schannel):**

```powershell
# .NET side (takes effect immediately for new processes)
$paths = @(
  'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319',
  'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319'
)
foreach ($p in $paths) {
  New-Item -Path $p -Force | Out-Null
  Set-ItemProperty -Path $p -Name SchUseStrongCrypto -Type DWord -Value 1
  Set-ItemProperty -Path $p -Name SystemDefaultTlsVersions -Type DWord -Value 1
}

# Schannel side (requires reboot)
$base = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'
foreach ($proto in 'TLS 1.0','TLS 1.1') {
  foreach ($role in 'Client','Server') {
    $k = "$base\$proto\$role"
    New-Item -Path $k -Force | Out-Null
    Set-ItemProperty -Path $k -Name Enabled -Type DWord -Value 0
    Set-ItemProperty -Path $k -Name DisabledByDefault -Type DWord -Value 1
  }
}
foreach ($role in 'Client','Server') {
  $k = "$base\TLS 1.2\$role"
  New-Item -Path $k -Force | Out-Null
  Set-ItemProperty -Path $k -Name Enabled -Type DWord -Value 1
  Set-ItemProperty -Path $k -Name DisabledByDefault -Type DWord -Value 0
}
# Then: Restart-Computer
```

Schedule this for a maintenance window since it requires a reboot of the only DC.

## Observations (not blockers)

- **Windows Internal Database (`MSSQL$MICROSOFT##WID`) running** — likely AD Certificate Services or a legacy role. No conflict with Entra Connect's SQL Server LocalDB. Check if still needed.
- **QBVSS (QuickBooks VSS) running** — QuickBooks on a DC is already known issue #17 per `hipaa.md`. Not blocking. Keep on long-term cleanup list.
- **Event log: 3 System errors + 4 Application errors last 24h** — Firefox browser agent, TPM-WMI (benign on non-TPM hardware), DistributedCOM, .NET Runtime, Security-SPP (licensing). None critical. Not blocking.
- **Expired self-signed cert `CN=CS-SERVER.cascades.local`** — known issue #19 (hipaa.md), unrelated to Entra Connect (which uses its own cert for the sync service account).

## Recommended pre-install sequence

1. Run the time-sync fix immediately — no downtime, fixes drift right away
2. Install Windows Server Backup, run a full backup to Synology share (~30 min depending on D: size)
3. Schedule TLS reboot window (tell Meredith — brief disruption)
4. After reboot, re-verify with the readiness script (same command, same agent)
5. Proceed with Wave 0.5 Entra Connect install

## Hardware note (not changed by this check)

CS-SERVER is still the 2009-era Dell R610 with consumer SATA drives carrying C: (the OS drive Entra Connect installs on). This check confirms it's *ready* for Entra Connect — it does not change the underlying "extreme failure risk" status noted in the issue tracker. Entra Connect adds one more critical dependency on aging hardware. A second DC on modern hardware is still the right long-term fix, independent of this rollout.
