Written by Terry Doner. November 13 2020. Updated on November 19 2020.
Many people find themselves responsible for running computer systems that are part of Audio, Video and Lighting (AVL) installations but don’t really know the best practices they should be using.
This document is meant for them, with a particular focus on the church setting.
These practices apply to all systems: Windows, Mac or Linux.
As a general rule, everyday system operation should be done using a ‘user’ account and not an ‘administrator’ account. The principle is to grant the user account the least privilege needed to get the job done.
For example you have a computer that is running ProPresenter, you should create a user account that your volunteers use to run it. You would create a separate account (with a different password!) that is used to install software and to change settings.
It is a good idea to have two administrative accounts that are managed by two different people. That way they can back each other up. If one forgets their password, or leaves the organization, the other account can be used to manage the system(s). (And reset the password or create a new administrator account).
If an administrator leaves the organization, the passwords should be changed.
All systems should be password protected.
You may choose, especially if there is only one administrator, to have all important passwords (with IDs) written down in a booklet That is left in the custody of a trusted party. Perhaps locked in a safe, or a safety deposit box. This can be useful in a variety of situations. Some real examples include:
The system administrator leaves the organization or is fired.
The system administrator takes a sudden sickness or dies
The system administrator is on vacation or out-of-town on business and somebody else needs to step in to solve a problem.
The system administrator forgot them.
Of course, you would need to ensure that these are kept up to date whenever there is a change made.
The same type of practice should also be applied to appleID or Microsoft Store accounts. Also would be applicable to Planning Centre Online, Vimeo, youtube, etc.
Keep copies of license keys for licensed software that use them. You can write them in the same book as the passwords.
Maintaining current backups of your computer is an important process. In the advent of a catastrophic failure, the ability to restore a system from a backup can save a lot of time and hassle.
Failures that this process can protect you from include:
Hard drive failure
System theft
Hardware or Software update that has gone very wrong
It is best practice to maintain three backups, let's label them A, B and C. This is what a schedule might look like:
Week 1
A is brought onsite,
Backup made to A daily.
B and C are offsite
Week 2
B is brought onsite
Backup made to B daily.
A and C are offsite
Week 3
C is brought onsite
Backup made to C daily.
A and B are offsite.
Repeat the cycle.
Alternatively you could use a service like Backblaze for backups to cloud.
Or you could keep all important files on dropbox or iCloud, or onedrive. And you could keep fewer system backups separately; those would only need to be updated when system updates are applied.
A good artcile that goes deeper into the topic and provides more options: here.
Your systems should be protected by antivirus software.
These systems are meant to get a job done. If you want to play around with the latest release of any software, do that on a different system that isn’t important. If something goes wrong, it won't impact your ability to deliver services.
Turn off auto updates. You want to be in control of when updates are applied. If you have services on Sunday’s, then apply your updates on Monday (after that days’ backup). And then test it thoroughly to make sure everything works as expected.
This is worth repeating. Do not apply updates Sunday morning before service for no good reason. Wait until the days events are done. There are very few extreme circumstances where applying a software update before an event makes sense. For example, your streaming service changed something in the past week, and now your streaming software needs an update. The only way to go live when you need to is to update the software.
Keep copies of the latest versions of software that you have downloaded. For example, you are running OBS 26.0.1 and there is a reason to update to 26.0.2. You download and install 26.0.2 but it fails your testing. You want to reinstall 26.0.1, but it is not easy to find online. It would be a much easier process if you had kept the 26.0.1 installer.
Before you apply any updates, ensure that the new version is compatible and supported. For example, you run ProPresenter on MacOS and there is a new version of MacOS available. Before you apply the OS update, make sure that ProPresenter is actually supported on that OS version. This is particularly important in configurations that have hardware drivers.
Before you update, make a backup. In the event of a catastrophic failure, you can restore to your backup.
Don’t be in a hurry to apply updates. If you aren't suffering from a persistent fault that the update will address, then wait a bit. A month or two won't hurt, in fact it might hurt to be in a hurry. Let others try it first, see if they are happy before you try. And if you have a less critical system, apply the update there first. (Don’t worry, not everybody will read this!)
Don’t hold off on updates forever either. Try to apply security updates relatively quickly, within a week or a month. Faster if the security update is for a critical vulnerability. Other updates should be applied within a few months of release. Being reasonably up-to-date will help avoid some potential problems.
If you have multiple systems that are due for an update, don’t do them all on the same day. Do them a week apart. (This recommendation may not be applicable in cases where there are server installations that require your clients to all be on the same version.)
A common question is “Can I run Software X on the same Computer as Y”, For example, Can I run vMix and ProPresenter on the same system? There are several considerations to answering this. I will call things like ProPresenter, vMix, OBS, Lightkey, Reaper, etc ‘Roles’.
Does the system have enough resources to handle the load? (Chances are not enough details were provided to answer an already difficult question).
If you have two roles on one computer, are you also going to have two people trying to do their job on one keyboard? Even if it is only one person, you can still create errors because the one person gets confused about which program is in focus.
Operational Resiliency - If you have multiple roles on one system, if there is a system hiccup that causes a freeze or a crash, both roles are impacted.
Update management. You can run into conflicting version requirements. FOr example the software for role A requires OS version x, but the software for role B is not yet supported on version x. You won’t encounter this problem if they run on separate systems.
By having more than one computer you can have an emergency capacity if a system goes down. For example, suppose you have two roles, and two computers similarly configured and large enough to handle both roles at the same time. If you have a system die on you on short notice, you can run both roles on one system. All other concerns listed about still apply and you may also have some licensing challenges that you would need to plan for.
If the role is super critical to your events, then you might purchase and configure a dedicated secondary system for that role only. This would mean that you have a computer that does nothing most of the time.
More computers does increase your cost. So you need to strike the right balance between the cost and resiliency.
Your systems should be protected by firewalls installed on the system AND your entire building network should be protected by a firewall just after you Internet Service Provider’s modem
Your production systems should not be accessible on the network to the general public. You neither want just anybody poking around on your systems, and you want to protect your network capacity for jobs it was intended to provide.
The common way of doing this is via VLANs. How to set this up varies on the network gear you have installed.
If a system does not actually need to be network connected, then it is also okay to leave the network cable unplugged. (I like the ability to remotely administer systems so would want them plugged in.)
Many people like the ability to remotely access the church computer systems, either for administrative purposes, remote assistance if somebody has a problem, or for remote preparation of materials for the next event.
There are several solutions for this, but whatever you choose, you want something that is reasonably secure against hacking.
May not include this section.
May not include this section.
To be added