# 2026-04-28 — IMC: New laptop provision for Manda (DESKTOP-KRHQ5TS)

## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home (then onsite at IMC Speedway)
- **Role:** tech

## Session Summary

Provisioned `DESKTOP-KRHQ5TS` for Manda, the incoming General Manager at IMC. Joined to `imc.local`, AD account created, Outlook configured against her existing M365 mailbox, Office activated via retail license, AIMsi station number set per Leslie. Ticket #32218 created and invoiced (1.5 hrs against IMC's prepay block).

## Work Performed (onsite at IMC Speedway, 7063 E Speedway Blvd)

- **Domain join** — `DESKTOP-KRHQ5TS` joined to `imc.local`. Original attempt was made remotely from Howard's home over OpenVPN (CG office to IMC) on 2026-04-22; that attempt was abandoned after a stack of DNS/locator issues (see "Issues encountered remotely" below). Onsite join completed without incident.
- **AD account** — Manda created in AD under `imc.local`. Logged in successfully, Windows profile built.
- **Outlook profile** — Configured against Manda's existing M365 mailbox (IMC mixes Google + Microsoft per user; Manda is on the M365 side).
- **Office activation** — Activated using IMC's retail license key.
- **AIMsi station ID** — Set Windows User environment variable `USER#` to `4` per Leslie's instruction. Per Tri-Tech (https://www.tritechretail.com/topic/aim), this is the per-machine workstation identifier AIMsi requires for POS polling and licensing.

## Personnel context (kept out of customer-facing ticket)

Manda is the new General Manager, replacing **Michael Santander**. Michael's domain account and other software access were already deactivated (no offboarding work required this session).

## Issues encountered remotely (not blocking — onsite path worked)

When attempting the domain join remotely over OpenVPN from Howard's home network, Windows would not resolve `imc.local` reliably and `Add-Computer` failed with "domain could not be contacted." Diagnosis surfaced two real environmental problems at IMC, plus one local conflict:

1. **Phantom DC `ServerIMC` (192.168.0.63)** — registered in DNS as a domain controller (A record + SRV records for `_ldap._tcp.dc._msdcs.imc.local` and `_kerberos._tcp.imc.local` both list it alongside `IMC1`), responds to ICMP ping, but **TCP/389 (LDAP) and TCP/88 (Kerberos) refuse connections.** The DC locator round-robins between the two DCs and times out roughly half the time when it picks `ServerIMC`. **This degrades client authentication for every domain user at IMC**, not just remote/VPN clients — intermittent slow logons, GPO failures, etc. Worth a follow-up ticket: investigate whether `ServerIMC` is a real machine that needs repair (AD services down) or a ghost from a demoted DC that needs `ntdsutil` metadata cleanup. Was previously flagged in the 2026-04-13 IMC ticket notes as "role/status unclear, worth verifying" — now confirmed as a real authentication-degrader.
2. **Subnet overlap** — Howard's home Wi-Fi network is `192.168.0.0/24`, the same as IMC's LAN. OpenVPN's pushed routes won (the laptop reached IMC1 via the tunnel correctly) but Windows multi-homed DNS resolution was racing between Wi-Fi's DNS (`192.168.0.1`) and the OpenVPN-set DNS (`192.168.0.2` = IMC1). Wi-Fi's DNS responded with NXDOMAIN faster, and Windows cached the negative answer.
3. Attempted fixes that **did not** resolve it: NRPT rule for `.imc.local`, hosts file entry for `imc1.imc.local`, `Add-Computer -Server <ip>`, `nltest /dsgetdc /force`. The phantom-DC + subnet-overlap combination was beyond what these client-side workarounds could paper over from outside the network.

**Playbook lesson for the future:** when remote-joining a laptop to a client domain over a tunnel, if your local network's subnet overlaps with the client's LAN, go onsite. The route conflicts and DNS race conditions on the laptop add up faster than they're worth fixing.

## Configuration Changes

### IMC AD
- New user `Manda` (full name TBD — verify in AD next session if not already documented)
- New computer object `DESKTOP-KRHQ5TS`

### Laptop `DESKTOP-KRHQ5TS`
- Joined to `imc.local`
- AIMsi `USER#` user environment variable = `4`
- Outlook profile bound to Manda's M365 mailbox
- Microsoft Office activated (retail license)

### Repo
- This session log
- `PROJECT_STATE.md` updated (workstation table + Recent Changes + ServerIMC follow-up)
- `docs/overview.md` to be updated next session with the workstation table entry once the AIM #4 mapping is confirmed at IMC

## Syncro

| Field | Value |
|---|---|
| Ticket # | 32218 (id 109542334) |
| Customer | Instrumental Music Center (id 7088508) |
| Subject | New User / Workstation Deployment - Manda (DESKTOP-KRHQ5TS) |
| Status | Invoiced |
| Contact | Leslie's House — leslie@imc-az.com (id 731730) |
| Billing | 1.5 hrs × `26118` Labor - Onsite Business @ $175/hr → debited from prepay block (14.0 → 12.5 hrs remaining) |
| Invoice # | 67468 (id 1650078027) — total $0 (prepay applied) |

## Pending / Follow-up

### High priority — IMC AD hygiene
- [ ] Open ticket: investigate `ServerIMC` (192.168.0.63) phantom DC. SRV/A records claim it's a DC; LDAP/Kerberos refuse connections; degrades authentication for all domain clients. Either repair (if a real-but-broken DC) or `ntdsutil` metadata cleanup (if a ghost). Was previously flagged 2026-04-13 with status "unclear" — promote to a real ticket.

### Documentation cleanup
- [ ] Update `docs/overview.md` Speedway workstation table with `DESKTOP-KRHQ5TS` / Manda / AIM USER#=4 entry
- [ ] Confirm Manda's full name in AD and add to overview/contacts
- [ ] Add IMC's Syncro customer ID `7088508` to `docs/overview.md` Contract Details (it wasn't documented there; took a Syncro API search to find it this session)

### Earlier IMC pending (carried forward from 2026-04-13)
- Decision on Server 2019 upgrade path for IMC1 (component-store corruption blocks RDS removal + CU apply)
- Verify `IMC` database (9.8 GB) usage, drop if not in use
- Drop `TestConv61223` (8.8 GB leftover migration test) once confirmed unused
- Disable SMB1 on IMC1
- Clean up stale AD computer objects `IMC2`, `IMC-VM` (last-logon 2023 / 2021)

## Reference

- Tri-Tech AIMsi workstation variable docs: https://www.tritechretail.com/topic/aim — variable name `WORKSTATION_ID` (current versions) or `USER#` (older versions). IMC is on the `USER#` convention per Leslie.
- IMC1 (DC + AIMsi SQL host): `192.168.0.2`, Windows Server 2016, domain `imc.local`
- IMC Speedway address: `7063 E Speedway Blvd, Tucson AZ 85710`
- Earlier domain-join troubleshooting (remote, before going onsite): documented in conversation but not committed as a separate session log; key findings preserved above.