A hotel could not view its cameras from off site. That was the whole problem.

It took about two months to fix. Four separate companies were involved. The eventual cause was a single setting on one recorder that somebody already knew about and had not got round to changing.

Nothing about that is unusual. It is close to the standard shape of a support failure on any system with more than one party attached to it, and it is worth walking through because the lesson is not technical.

What actually happened

A hospitality venue had a CCTV system and wanted remote viewing. Management needed it — an incoming consultant was to monitor areas of the property and could not be on site permanently.

Involved were: the client, an IT and service provider under contract, a third contractor, and us. We had not installed the CCTV. That is stated plainly in the thread at the time, because by then it needed stating.

Roughly two months in, the client wrote that they were no further along, and that if it was not resolved within days they would move the CCTV work to another company and reconsider the service contract entirely.

Within two days of that message it was working.

The cause was known before the deadline was issued

This is the part worth sitting with.

Remote access had been partly configured. A note existed, in writing, from ten days earlier: the dynamic DNS was set up, but a port on the second recorder still needed changing, and the person who knew this had received instructions on how to do it and had not yet done it.

So the diagnosis was correct, recorded and circulated — and the system still did not work, because the step sat between people rather than with one of them.

Then, once the change was made, it still did not work for one party, who reported specific application errors and had already eliminated his own network by testing against the software vendor’s public demo. That is a well-run diagnosis, done by someone who was not the installer, on a Monday night.

The problem was never that nobody could solve it. Everybody involved was capable. The problem was that no single person was accountable for the outcome, so each person solved their own part and stopped.

Why multi-party CCTV goes wrong

CCTV sits in an unusual position. It touches the building, the network, the internet connection, and often a security company as well. That means several trades have a legitimate claim on part of it and no natural claim on all of it.

The failure mode is predictable:

  • The camera installer says the cameras and recorder are working, which is true.
  • The IT provider says the network is fine and the ports are open, which is also true.
  • The internet provider says the line is up, which is true as well.
  • Nobody says “I will make remote viewing work by Thursday.”

Everyone is being honest. Everyone is technically correct about their own scope. And the client, who does not care about scope, experiences two months of not being able to see their cameras.

A client measures elapsed time, not fault. That is the only metric they have, and it is a fair one.

Supporting a system you did not install

This is common and worth being straight about.

Being asked to help with somebody else’s installation is normal — a client has a problem, you are the one they can reach, and refusing to look is rarely the right answer. But it carries a specific risk: you can end up owning the appearance of the problem without owning the system, the documentation or the original design decisions.

What makes that workable:

  • Say what you are doing and what you are not. “I have made this change on your system. It is still not working, and I did not install this equipment” is a fair and useful message. It sets expectations without walking away.
  • Do the thing you were asked to do, promptly. The single biggest contributor to that two-month delay was a known action sitting undone.
  • Push for one owner. Not necessarily you — but somebody, named, with a date.

Fixing the structure, not the port

If you are the client in this situation, the useful intervention is not technical.

  1. Name one person who owns the outcome. Not a company — a person. Their job is to get it working, including coordinating other parties. They may need to be paid for that, and it is worth it.
  2. Ask for the next action and a date, in writing, after every exchange. Vagueness is what lets a known fix sit for ten days.
  3. Put everyone on one thread. Parallel private conversations are how three parties each believe another is handling it.
  4. Set the escalation point before you are angry. The deadline in this case worked, but it arrived after two months and a threatened contract loss. It would have worked in week one too.

And a word about how the credentials moved

One detail from that thread deserves calling out, because it has not improved in the years since.

Early on, the client sent system access details — the machine addresses, a workstation login, and the administrator username and password for the viewing software — by email, in plain text, to several people across multiple companies, in order to get help.

That is completely understandable. Somebody needs access to fix your problem, and email is what you have. It is also how administrator credentials for a camera system end up sitting permanently in the mailboxes of four organisations, several of whom will not be working with you next year.

Better habits, none of them difficult:

  • Send credentials separately from the request, by a different channel, and never to a group.
  • Create a distinct account for the contractor rather than handing over the administrator login.
  • Change the password when the work is finished — the single most skipped step in the entire industry.
  • Keep a list of who has access, so that when a relationship ends there is something to revoke.

An old email is a permanent one. Assume anything sent that way is still readable somewhere.

The short version

The technical fault was one setting. The delay was structural: four capable parties, no single owner, and a known action waiting for someone to claim it.

If your cameras have not worked properly for weeks and everyone involved is telling you their part is fine, they are probably all telling the truth. Ask a different question — who owns this working, and by when?

Based on a multi-party support thread from 2012, fully anonymised. Remote-access methods described are those of the period and are not current guidance; modern systems generally use manufacturer cloud services rather than manual port configuration.