Deployment Guide

Preparing your network for the RoomSuite Collaboration Bar is straightforward. Follow this guide to ensure your environment is ready for a smooth deployment.

Note: If you are an IT administrator or network engineer responsible for preparing your network and security infrastructure, start with the first section below.

Note: If you are an installer or AV integrator focused on device onboarding and registration, proceed to Onboard and Register the Device.

The RoomSuite Collaboration Bar is a Q-SYS-integrated collaboration appliance designed for Microsoft Teams Rooms deployments. The device runs Windows 11 IoT Enterprise and communicates with Q-SYS cloud services for certificate provisioning, over-the-air (OTA) software updates, and optional cloud monitoring through Q-SYS Reflect.

After completing this guide, you will have:

  • Validated that your network allows required outbound communication.

  • Configured firewall rules, DNS, and time synchronization.

  • Confirmed that security tools will not interfere with device operation.

  • Successfully onboarded the device to your environment.

To ensure proper communication with Q-SYS cloud services, check with your IT administrator to ensure that these network prerequisites are followed.

Critical URLs

The RoomSuite Collaboration Bar establishes outbound connections over port 443 (HTTPS) to communicate with Q-SYS cloud services. All cloud-facing communication is encrypted using TLS 1.2 or higher. No inbound connections from the internet are required.

Firewalls should be configured to allow access to the following endpoints using DNS-based rules (FQDNs) rather than hard-coded IP addresses.

URL Protocol Purpose
ca.qsys.io HTTPS over TCP 443 Initial device certificate issuance (TLS)
secure-ca.qsys.io HTTPS with mTLS over TCP 443 Device certificate renewal
secure-ota.qsys.io HTTPS with mTLS over TCP 443 Over-the-air software update delivery
Q-SYS Reflect endpoints (if applicable) HTTPS over TCP 443 Cloud monitoring, remote management, and registration
Microsoft Teams Rooms services HTTPS and media traffic per Microsoft requirements Meetings, signaling, calling, and media workflows

A wildcard allowlist for *.qsys.io on TCP 443 is the simplest way to cover Q-SYS cloud communication where permitted by your security policy.

If Q-SYS Reflect is part of your deployment, also allow the Reflect endpoints described in the Getting Started with Q-SYS Reflect topic.

Local Management Access

Port Protocol Direction Purpose
443 TCP Inbound from local network RoomSuite Collaboration Bar Manager web interface (HTTPS)
80 TCP Inbound from local network HTTP redirect to HTTPS

Administrators access the device's local management interface by navigating to https://<device-ip> from a client on the same network.

 

TLS Inspection

The device uses mutual TLS (mTLS) for certificate renewal and OTA update transactions. The device presents its own certificate to the cloud service for authentication during these operations.

Do not perform SSL or TLS interception for secure-ca.qsys.io or secure-ota.qsys.io. Man-in-the-middle inspection breaks mutual TLS and will prevent certificate renewal or software updates.

DNS, NTP, and Proxy

DNS — Q-SYS cloud services use DNS-based endpoints behind load balancers and CDNs. IPs may change without notice. Do not hardcode IP addresses. Allow outbound TCP 443 to the critical URLs listed above and rely on corporate egress policies. Use enterprise DNS with split-horizon if applicable. The device must resolve ca.qsys.io, secure-ca.qsys.io, and secure-ota.qsys.io from the deployment network.

NTP — Enable time synchronization to avoid token and TLS clock-drift issues. Configure an enterprise NTP source or use public NTP servers (for example, time1.google.com and time2.google.com). Accurate time is required for certificate validation and reliable event timestamps.

Proxy — If a proxy is required, allow HTTPS tunneling and WebSocket over TLS. Transparent proxies that do not alter TLS sessions are generally acceptable. Explicit proxy behavior should follow Windows system proxy settings. Any proxy performing certificate substitution must exempt the mTLS-protected services listed above.

Wildcard Rules

Adding these wildcard rules provides flexibility for Q-SYS URL variations while maintaining restricted access:

  • *.qsys.io

Because the RoomSuite Collaboration Bar runs Windows 11 IoT Enterprise, enterprise security controls (EDR, endpoint protection, application control) may interact with local applications and outbound service communication.

Validate Before Broad Rollout

Area What May Happen Recommended Action
Application control Management or OEM processes may be blocked or quarantined Allowlist RoomSuite Collaboration Bar Manager and OEM service executables in your EDR policy
Network control Outbound connections to Q-SYS cloud services may be blocked Allowlist required Q-SYS domains on TCP 443
TLS inspection mTLS sessions may fail Exclude secure-ca.qsys.io and secure-ota.qsys.io from TLS interception

Known Local Services and Processes

The following services run on the device. If your endpoint security tool flags or quarantines processes, consider adding these to your allowlist:

  • RoomSuite Collaboration Bar Manager Backend — HTTPS server on port 443 (API and management UI)

  • RoomSuite Collaboration Bar Manager UI — Frontend web application on port 3000 (behind reverse proxy)

  • Edge Control Plane — HTTP service on port 3005

  • gRPC inter-service communication — Ports 4040 and 4041 (local only)

  • OEM device services — UdiServer (port 49673), UdiBroker (port 9820)

  • Audio/video interface service — Ports 42201 (TCP), 61201 (UDP), 9090 (TCP)

Confirm exact executable filenames against your specific software version before publishing final security exceptions.

Disable LLMNR on AIO Bar Windows Image

What it is: Link-Local Multicast Name Resolution (LLMNR) is active on the AIO Bar. No disable recommendation exists in the deployment guidance.

Risk: Windows machines fall back to LLMNR when DNS does not respond. An attacker on the same LAN can respond to LLMNR requests and impersonate a legitimate service, causing the device to attempt authentication against the attacker. This enables credential capture and NTLM relay attacks.

Impact: Credential theft, hash relay, potential pivot into the customer's environment via an AIO Bar.

Why remediate: LLMNR disablement is a standard Windows hardening baseline. Leaving it enabled conflicts with common enterprise security policies and Acuity PSB expectations.

Recommendation: Disable LLMNR in the shipping Windows image; include disablement guidance in the deployment guide.

Disable or Restrict SMB File Sharing on AIO Bar

What it is: SMB services are exposed on the device without network isolation guidance.

Risk: SMB is among the most abused protocols in real-world compromises (lateral movement, ransomware propagation, credential theft via NTLM relay). Exposed SMB is routinely probed for null sessions, weak shares, and known vulnerabilities.

Impact: Ransomware propagation, unauthorized access, lateral movement into customer networks.

Why remediate: Customers deploying the AIO Bar inherit unnecessary attack surface unless SMB is disabled or documented as requiring network isolation.

Recommendation: Disable SMB where not required; where required, document explicit isolation requirements in the deployment guide.

Disable NetBIOS over TCP/IP on AIO Bar

NetBIOS sessions are exposed alongside SMB.

Risk: Legacy protocol enabling network reconnaissance, hostname disclosure, and name-spoofing attacks. Frequently paired with LLMNR and SMB to complete credential-theft attack chains.

Impact: Information disclosure and lateral movement precursor.

Why remediate: Provides limited legitimate value on a modern collaboration device and materially expands attack surface.

Recommendation: Disable NetBIOS over TCP/IP; document the change in deployment guidance.

Replace Wildcard .qsys.io DNS Allow-List with Explicit Approved Endpoints

What it is: The deployment guide recommends allowlisting *.qsys.io, granting broad trust to any subdomain under the parent domain.

Risk: An actor able to create a subdomain under Q-SYS - Cloud-manageable Audio, Video and Control (whether an insider, a compromised DNS-management account, or a future subdomain misconfiguration) can stand up a rogue endpoint that devices will trust. This could redirect certificate issuance, OTA update requests, or Reflect cloud communications to attacker-controlled infrastructure.

Impact: Rogue certificate issuance, tampered updates, long-term device compromise at fleet scale.

Why remediate: Wildcard trust breaks least privilege at the DNS/network boundary — the foundation on which mTLS, code signing, and OTA integrity rely.

Recommendation: Replace wildcard allow-list with an explicit FQDN list required for device operation (e.g., ca.qsys.io, ota.qsys.io, and Reflect-specific endpoints). Publish the finalized list to Engineering and Customer-facing documentation.

Dynamic Ports > 50,000 Exposed

What it is: A range of dynamic TCP/UDP ports above 50,000 is exposed for EDP/internal communications.

Risk: Broad dynamic port ranges are effectively impossible to firewall precisely, difficult to monitor, and offer attackers a wide reconnaissance and pivot surface. Any process that binds within the range becomes network-reachable.

Impact: Unintended service exposure to the LAN, pivot opportunities for a compromised process or malware, near-impossible containment during an incident.

Why remediate: Wide-open dynamic port ranges violate least-privilege networking and are inconsistent with a hardened device posture.

Recommendation: Constrain the dynamic port range to the minimum required; document exact ports/protocols; where feasible, replace with fixed, known ports and enforce loopback binding for internal-only services.

What Happens at First Boot

  1. The device comes online and establishes a connection to ca.qsys.io over standard TLS.

  2. An initial device certificate is provisioned automatically.

  3. The device checks the OTA service for available software packages and updates.

  4. Administers can access the local management interface at https://<device-ip>.

  5. If using Q-SYS Reflect, the device is ready for registration.

Configure Network Settings on the Device

From the RoomSuite Collaboration Bar Manager (accessed at the device's IP address in a browser):

  1. Sign in with administrator credentials.

  2. Navigate to Network Settings.

  3. Verify that the device has a valid network connection and can reach the internet.

  4. If using Wi-Fi, enable Wi-Fi and connect to the appropriate network.

  5. Set the device Hostname for easy identification on your network.

Enable Time Synchronization (Recommended)

Time synchronization helps ensure accurate certificate validation and consistent event log timestamps.

  1. From the Manager menu, navigate to Date and Time.

  2. Click Edit.

  3. Select the appropriate Time Zone.

  4. Enable Time Synchronization and specify valid NTP servers. Use servers from your IT administrator or public NTP such as time1.google.com and time2.google.com.

  5. Click Save.

Test Connectivity to Q-SYS Cloud Services

  1. From the Manager menu, navigate to Reflect.

  2. Click Test Connection to verify that the device has a valid communication channel to the Q-SYS cloud servers.

  3. If you see any errors, refer to the Troubleshooting section below.

Register with Q-SYS Reflect (Optional)

Reflect is optional for basic device operation, but it enables cloud-based monitoring and management.

How Updates Are Delivered

Software for the RoomSuite Collaboration Bar Manager is delivered through the Q-SYS OTA service at secure-ota.qsys.io using mutual TLS. The device checks for updates at boot and at a recurring daily interval.

Updates to the Windows platform and Microsoft Teams Rooms application are delivered separately through Microsoft Windows Update channels.

What to Expect During an Update

  • The RoomSuite Collaboration Bar Manager interface may be temporarily unavailable while an update is applied.

  • The system may reboot as part of update completion.

  • Successful OTA updates depend on continued certificate validity and uninterrupted access to secure-ota.qsys.io and secure-ca.qsys.io.

Update Service Dependencies

Service Why It Matters If Unavailable
secure-ota.qsys.io Delivers OTA update packages Software updates cannot be downloaded
secure-ca.qsys.io Renews device certificate used for mTLS services Future secure cloud transactions may fail
Reliable time source Supports certificate validation Certificate-related errors may occur
Symptom Likely Cause Recommended Action
OTA updates do not download

Outbound access to secure-ota.qsys.io is blocked

Verify firewall policy and domain allowlist for TCP 443

Certificate renewal fails

TLS inspection or mTLS interruption on secure-ca.qsys.io

Bypass TLS inspection for mTLS-protected domains

Local management UI is unreachable

 Wrong subnet, blocked inbound 443, or device is updating

Verify IP, local network path; wait briefly if an update is in progress
Reflect registration does not complete

Reflect connectivity or DNS issue

 Validate outbound access to Reflect endpoints and confirm account prerequisites
Processes quarantined by security software

EDR policy blocks device applications

Add required exclusions for validated executables and services

Certificate-related errors appear unexpectedly

Incorrect system time

Confirm NTP reachability and time configuration

Logging and Diagnostics

Event Log — View and export system events from the Manager interface. Events can be filtered by severity and time window, and exported to CSV.

Download System Information — From Utilities, download a system information file containing a snapshot of device state. This file can be shared with Q-SYS Support for troubleshooting.

Use this checklist to confirm readiness before deploying the RoomSuite Collaboration Bar.

  • [ ] Outbound TCP 443 is allowed to ca.qsys.io, secure-ca.qsys.io, and secure-ota.qsys.io.

  • [ ] Microsoft Teams Rooms network requirements have been reviewed and implemented.

  • [ ] DNS correctly resolves required Q-SYS and Microsoft Teams-related services.

  • [ ] NTP or approved time synchronization is reachable from the device network.

  • [ ] TLS inspection exclusions exist for secure-ca.qsys.io and secure-ota.qsys.io.

  • [ ] EDR or endpoint security allowlists are prepared for required device processes.

  • [ ] Local administrator access to the device over HTTPS 443 has been validated.

  • [ ] DHCP or static addressing has been planned for the deployment VLAN.

  • [ ] Reflect organization and domain are ready (if cloud onboarding is planned).

  • [ ] A pilot deployment has been scheduled before broad rollout.

Recommended Rollout Approach

Pilot — Deploy a small number of units in representative rooms. Validate certificate provisioning, OTA behavior, Teams functionality, and security tool compatibility.

Review — Collect findings from event logs, system information exports, and administrator feedback.

Scale — Proceed to broader deployment after confirming network, DNS, security, and management access patterns are stable.

What network ports does the RoomSuite Collaboration Bar require?

The device requires outbound TCP 443 to Q-SYS cloud services (ca.qsys.io, secure-ca.qsys.io, secure-ota.qsys.io) and Microsoft Teams Rooms endpoints. Locally, administrators access the management interface over HTTPS 443. No non-standard outbound ports are required.

How does this product interact with CrowdStrike or other endpoint security tools?

Because the device runs Windows 11 IoT Enterprise, EDR tools may flag or quarantine local management services. Allowlist the RoomSuite Collaboration Bar Manager executables and OEM services in your endpoint security policy. Ensure TLS inspection does not intercept mTLS traffic to Q-SYS domains.

Can we use a proxy? Which configurations are supported?

Transparent, non-intercepting proxies are generally compatible. Explicit proxy settings follow Windows system proxy configuration. Any proxy performing TLS certificate substitution must exempt secure-ca.qsys.io and secure-ota.qsys.io to avoid breaking mutual TLS.

How are software updates managed, and can we control the timing?

Q-SYS OTA updates are checked at boot and daily. Updates are delivered automatically when a newer version is available. The local management interface may be briefly unavailable during an update. Windows and Teams Rooms platform updates are delivered through separate Microsoft Windows Update channels.

What do we need to give our security team before deployment?

Provide this guide along with the list of required domains, the note about mTLS and TLS inspection exclusions, and the list of local services/processes for EDR allowlisting.

Does the device need Q-SYS Reflect to receive software updates?

No. The device receives OTA updates directly from secure-ota.qsys.io as long as it has internet access and a valid device certificate. Reflect registration is optional and enables additional cloud monitoring and management features.