Overnight maintenance stops the Workspace ONE Access Connector VM. What is the most accurate impact the next morning?
Select an answer to reveal the explanation.
Short Explanation
Kill the Access runner and the identity roster stops updating—catalog names go stale. The UEM runner (Cloud Connector) can still walk phones in. Access Connector is not MDM check-in, not the Horizon broker, and not the edge.
Full Explanation
If overnight maintenance stops the Workspace ONE Access Connector VM, the most accurate morning impact is that directory sync into Access pauses so Hub catalog users and groups can go stale, while UEM enrollment can still proceed through AirWatch Cloud Connector. Kill the Access runner and the identity roster stops updating—catalog names and group memberships drift until sync resumes. Claiming every UEM-enrolled inspector phone fails check-in because Access Connector is the MDM path fails by concept: MDM check-in and enrollment services are UEM-plane concerns, typically aided on-premises by AirWatch Cloud Connector, not Access Connector. Claiming Horizon Agent on VDI hosts cannot register because Access Connector is the broker fails because Horizon Agent registers with Horizon Connection Server (and related Horizon infrastructure), not Access Connector. Claiming Unified Access Gateway drops all Tunnel sessions because Access Connector owns the edge fails because UAG—not Access Connector—is the edge for Tunnel and external Horizon paths. Exam caveat: already-synced users may still authenticate for a time depending on tokens and cached state, but new hires, group changes, and directory updates will not flow until Access Connector returns; do not equate “connector down” with “all civic phones bricked.” Operational check: stop or isolate Access Connector in a lab, confirm Access directory sync status shows failure or staleness, enroll or check in a test device via UEM/Cloud Connector successfully, and verify Horizon Agent registration and UAG Tunnel are not inherently dependent on Access Connector.