Work through this before the install date is booked. What decides whether a first deployment goes smoothly happens well in advance: the address people will type, the paths their audio and video will take, and the person whose job this becomes once the platform is in use.
Prerequisites
- A server your organization operates, with capacity for the concurrent sessions you expect.
- A domain name for the deployment and a valid certificate for it. People connect to an address your organization publishes.
- Network paths that let live audio and video through, including for a participant behind a restrictive office or home network.
- A named person or team responsible for provisioning access. RoomHex accounts are reviewed before they are created, and that job needs an owner.
- A backup and update routine that fits the operations your team already runs.
- A decision on where data and media are kept.
How the deployment sits
One environment serves one organization. It answers on your domain, and no other customer shares it. Staff at head office, staff working from home, and invited outside guests all reach that same environment through the single address.
On-premises data centres and restricted networks both work. If your users sit behind a network that filters heavily, agree the paths for live media with whoever runs that network before the install.
Capacity assumptions
Size the first deployment against concurrent sessions and participants. Headcount is a weak guide: a large staff who rarely meet at the same time ask less of a server than a smaller group who all join the same all-hands. Write the assumptions down, because they are what a later capacity conversation will start from.
You are not sizing this alone. Capacity is sized with our team at the design review, the second of the seven steps a RoomHex deployment runs through, and these are the answers worth having ready for it.
Rollout stages
Each stage ends when the people in it stop reporting anything new, not on a date somebody picked in advance.
A second site is a separate exercise and belongs after the last of those, when you hold load figures from your own use.
Backup routine
- Write down before launch what a backup covers and how often it runs.
- Keep one copy on storage the deployment itself cannot reach.
- Test a restore on a schedule, and note the date of the last one that worked.
- Put updates on the same calendar, and agree the upgrade and support scope with our team in writing before launch.
Post-install validation
- Sign in as a provisioned user and place a one-to-one call, checking ringing, answer, decline, and end.
- Create a meeting room, join from a second account, and approve the waiting participant before they appear in the grid.
- Share a screen, send in-session chat, raise a hand, and switch camera and microphone while the session is running.
- Join once from outside the office network and once from a phone on mobile data, to confirm live media gets through on paths you do not control.
- Join twice with the same account and confirm the duplicate-session warning appears.
- Restart the server and confirm it comes back. It refuses to start while security settings are incomplete, and a clean restart confirms they are complete.
- Take a backup and restore it into a spare environment before the first real meeting is booked.
Hold a short review partway through the pilot and again once the wider rollout is done, with capacity figures from your own deployment in hand.
When you are ready to fix the specifics for your environment, a deployment review with our team is the next step. Five points are agreed there: the infrastructure you will run on, the domain the environment answers from, how large it has to be sized, which tasks belong to which team, and when you want it live.
- deployment
- self-hosted
- operations