An upgrade built on a messy user list just makes the mess official. Spend one hour finding every config file, every shared login and every forgotten account first - the MFA rollout then takes an afternoon instead of a month of surprises.
Every OpenVPN problem in a small office starts the same way: nobody knows who can connect. Configs were emailed in 2022, a laptop was replaced, two people left, and the files kept working because files do not resign. Before you touch the authentication settings from the video, build one honest list of who and what can reach your network today. It is boring work, and it is the work that decides whether the upgrade is real.
Start from the server side, not from memory. Open the OpenVPN area of your firewall and note every client configuration that exists. Then search the office for copies: old laptops, the "IT" folder on the file server, email attachments, pen drives in the drawer. Every copy of a config is a working key until the authentication changes, so the count that matters is copies, not people. Write each one down with its owner - or write "owner unknown", which is itself a finding.
Shared accounts hide in plain sight: one config on three machines, a username like "office" or "admin2" that a whole team uses. Shared access is worse than no list, because when something goes wrong the log shows the shared name and proves nothing about the person. Mark every shared arrangement for replacement - the upgrade in the video creates one local directory account per person, and this audit is where you decide exactly who those persons are, including owners and the external accountant.
Now compare the list against people who have left. In most small offices this is where the audit earns its hour: a config issued to someone who resigned last year still connects, because nobody's joining and leaving process mentioned the VPN. Do not panic-delete yet - note them. The moment username and password authentication plus MFA goes live, these files stop being master keys, and disabling their accounts (there is a full page on revocation in this series) finishes the job properly and provably.
End the audit with the list you will actually build: name, full name, which device they connect from, and whether they need VPN at all. "Needs VPN" deserves one honest question per person - the home printer troubleshooter of 2021 may not need permanent network access in 2026. Fewer accounts means fewer codes to enrol, fewer configs to chase and a smaller door to guard. Everyone not on the final list loses access when the upgrade lands, and that is a feature, not an accident.
From today until the rollout is done, stop handing out the old style config "just for this week". Every temporary exception becomes permanent - that is how the current list got this way. If someone genuinely cannot work, create their proper named account early and enrol them in MFA first; they become your pilot user instead of your next audit finding. Keep the audit sheet afterwards: it becomes the register you review every few months, and the starting point the day someone leaves.
With the audit done, the video's steps - authentication, named users, MFA - land cleanly on a list you trust.
▶️ Watch Full VideoAbout an hour for up to twenty users: list the configs on the server, search the obvious hiding places for copies, compare against current staff, and write the final user list. The searching is what takes the time, not the writing.
Note it first, then act as part of the upgrade: once username and password authentication is on and their account is disabled, the file alone connects nothing. Deleting in a panic without the list risks locking out someone still working under a misleading file name.
Yes - if they connect, they belong on the list with their own named account and their own MFA enrolment, like everyone else. Rank does not change the physics of a copied config file.