claudetools/clients/instrumental-music-center/session-logs/2026-04-28-howard-manda-laptop-provision.md

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.