Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
Unordered list
Bold text
Emphasis
Superscript
Subscript
If a meeting room audiovisual (AV) system has to be restarted regularly just to keep it working, that is rarely a coincidence. A restart only buys time. Recurring faults usually have a system-level problem behind them: a degrading cable or connector, a firmware incompatibility, an overheating device or an undocumented configuration. GHT-SYS is a vendor-independent AV systems integrator based in Hungary. We build meeting room systems and keep them running with SLA-based maintenance. Below are the five signs that a problem needs proper diagnostics, not another service visit.
In short: Five signs suggest that a meeting room AV system has a deeper problem than a simple fault: (1) the same fault keeps coming back, (2) the symptom looks different every time, (3) the system has to be restarted several times a day, (4) the fault only appears during live meetings, (5) there is no documentation and the original installer is no longer available. If you recognise more than one, the system needs an independent inspection, not another restart.
A restart is not a fix because it clears the current symptom, not the cause. Most meeting room faults do not develop overnight: the system gives small warning signs before it fails outright, and a restart hides those signs for a while.
What is left afterwards? The underlying cause: the worn cable, the unstable power supply or the faulty firmware.
It is like the engine warning light coming on in your car and the mechanic simply clearing the fault code. The next day the light is off. The fault is still there, and within a week the light is back on.
Maintenance engineers have a name for a fault that hides like this: “no fault found” (NFF). The reported fault cannot be reproduced during inspection and nothing abnormal turns up, even though the fault was real.
Years ago, with one projector and one microphone, a restart really did solve most problems. Today a meeting room is a layered system in which a codec, a DSP, a controller, a camera, a display and a software platform all work together, often from several manufacturers. In that environment, a restart rarely gets anywhere near the cause.
A fault is system-level when it keeps coming back, changes form, forces daily restarts, appears only in live meetings or sits on an undocumented system. Each of these signs is suspicious on its own. When two or more appear together, they point strongly to a system-level problem rather than user error or a one-off software fault.
Repetition is the most telling sign. If one room produces the same fault again and again while the other meeting rooms do not, the problem is in that room, not with the user.
Microsoft’s troubleshooting documentation for Teams Rooms follows the same logic. The first step is a restart, to rule out a temporary fault. If the issue repeats several times and affects only one specific device, though, there may be inconsistencies or corruption in the core Windows components or the Teams Rooms app, and at that point reimaging the compute module is worth considering.
The trap here is the closed ticket. If nobody records how many times the same thing has happened, the pattern stays invisible.
A changing symptom is worse news than a constant fault. If the audio drops out the first time, the picture the second time and the connection hangs the third time, that is rarely three separate problems. It is far more likely that one shared physical cause, such as a degrading cable, a loose connector or an unstable power supply, is showing up in a different place each time.
The manufacturer documentation points the same way. According to Microsoft’s guidance, if the Teams Rooms touchscreen console does not respond after waking, restarting the console or the device is the first step to restore it. If the issue keeps returning on the same console, the next step is physical: reseating the USB connectors on the compute module and the console, or replacing the cable. Put simply, when a fault comes back, the physical layer is the next thing to check after the restart.
If a device freezes regularly or the controller stops responding, and this happens every week or even several times a day, it is no longer a one-off software fault. Frequent freezes often come down to heat, poor ventilation or power problems. Manufacturers account for this too: Crestron’s warranty terms explicitly exclude failures caused by insufficient ventilation, incorrect temperatures and improper wiring. If a system has to be restarted several times a day, treat it as if it were on the verge of a more serious failure, because heat, ventilation and power problems do not get better on their own.
One of the most frustrating situations is when the fault “disappears” the moment the technician arrives. The system behaves while someone is watching and lets you down when you actually need it. That is not the user’s fault. Why then, of all times? Because many intermittent faults depend on load: they surface when there are lots of participants, screen sharing is running and a remote call is live, but not during a quiet test.
When you report an issue, support for Microsoft Teams Rooms Pro Management asks for the exact time of the most recent occurrence and, if the issue keeps coming back, how often it happens. A single snapshot is not enough to pin down a fault like this. It takes diagnostics under load, in a real meeting.
The fifth sign is not a symptom of a fault. It is a system risk in its own right. If nobody knows what was installed, which firmware is running, what is in the rack or who last changed the configuration, diagnostics have to start from the ground up every time. A 2026 article published by AVIXA recommends documenting a multi-vendor stack at handover “like an asset register, not an installation report”. Without documentation, every fault turns into a fresh investigation.
In that situation, the next step is for someone to inherit the system and take responsibility for it. Here is how taking on an orphaned AV system works.
The table below shows what each sign may point to and the first sensible step to take. When a meeting room fault keeps recurring, at GHT-SYS we start by pulling up the previous tickets and looking at the pattern they form.
| Sign | What it may mean | First sensible step |
|---|---|---|
| The same fault keeps coming back | A room-specific configuration or hardware problem | Compare the room’s settings with those of the other rooms, and keep the ticket open |
| The symptom is different every time | A shared physical cause: cable, connector, power supply, heat | Ask for physical and system-level diagnostics |
| Several restarts a day | An unstable system state, a device close to failure | Log how often the restarts happen |
| Only appears in live meetings | An intermittent, load-dependent fault | Ask for diagnostics under load, in a real meeting |
| No documentation | Every fault has to be diagnosed from scratch | A survey and documentation come first |
The wrong decision is rarely made at the moment of the fault; it is made in the reflex that follows. The ticket is closed after a restart without anyone noting how many times the same thing has happened, or the fault is put down to user error because the technician could not reproduce it.
So what should you ask? Not “is it working again?” but: how many times has this happened? When did it first happen? Does it happen in every meeting or only in some, in one room or in several? That is what decides whether you end up with a closed ticket or a cause you have actually found.
Before you restart the system, decide whether the restart will hide the cause of the fault or help you find it. Three questions help:
On GHT-SYS projects, the same room appearing in the tickets three times within 30 days is a diagnostic signal. When a client has “solved” a problem with restarts for a long time, the real cause is typically a degrading component or an undocumented change. The longer it stays hidden, the more expensive the repair. We have itemised the hidden costs of reactive maintenance in a separate article.
Our overview article on meeting room failures also describes a specific case: a boardroom whose control processor was routinely restarted before every important meeting, until the first inspection showed that the fault came from the original control program. The program had to be rewritten, and since then the room has worked without restarts.
If you recognise even one sign from the list above, start documenting it: which room, what symptom, when, how many times. If you recognise several, have the system inspected independently, because another quick call-out will only lead back to the same place. That is what preventive maintenance is for. A scheduled check finds the degrading component and the firmware version that has drifted out of line, rather than an interrupted meeting finding them for you.
For this to work in practice, the maintenance contract has to include it. We set out what a good meeting room SLA includes in a separate article, and typical failures after updates in our article on meeting rooms freezing after a Teams update.
A restart is enough when the fault was a one-off and does not come back. If the same fault repeats, or the same room causes problems again and again, a restart only postpones the problem. In our experience at GHT-SYS, a recurring fault typically has a system-level cause behind it, and that cause has to be found through diagnostics.
The deciding factor is whether the fault is tied to one room: if the same meeting room produces the same fault again and again while the other rooms do not, the problem is in the room. In that case, compare the room’s settings, firmware versions and devices with those of the rooms that work well. According to Microsoft, if the same issue repeats on a Teams Rooms device and affects only that device, reimaging the compute module is worth considering.
A technician often cannot find the fault because many meeting room faults are intermittent: they appear under load and cannot be reproduced during a quiet on-site test, even though the fault is real. Finding them takes diagnostics under load, in a real meeting, together with an accurate log of previous occurrences, not a one-off inspection.
An undocumented system is one where nobody knows what was installed, which firmware is running, what is in the rack or who last changed it. That is a risk because the system has to be investigated from scratch every time a fault occurs, which costs time and money. At GHT-SYS, the first step with any system we take on is to map and document it.
The IT team gets back the time that recurring AV faults would otherwise take up. The AV layer (the codec, DSP, control system and cabling) is a separate discipline and is rarely part of IT’s day-to-day work. IT can take the first steps itself: record how many times the fault has occurred, and compare the room’s settings with those of the rooms that work well. If a pattern emerges, or suspicion shifts to the physical layer (cable, connector, heat) or to the control program, that is the time to call in an AV specialist. An AV specialist finds the cause of the recurring fault, documents the system and reduces the number of escalations during meetings, so IT can concentrate on its own work.
Ádám Horváth is the managing director, founding owner and a systems engineer at GHT-SYS.
About GHT-SYS: GHT-SYS is a Hungary-based audiovisual (AV) systems integrator. The company designs, installs and commissions integrated AV systems in Hungary and across Europe, and provides SLA-based maintenance for corporate clients in Hungary. If you have a room that generates more tickets than any other, book a consultation and we will look at what is really behind the recurring fault.
Related articles:
