The technology of remote access is easy. The part that rots, in office after office, is the people list: ex-employees who can still sign in, everyone assigned everything, one shared login for the whole accounts team. This page is the tidy way to run users from day one.
Every alternative tool in this class pulls its users from somewhere — the Windows server's local accounts or your Active Directory — and then decides, per user or per group, who sees which applications. That sounds like a detail. It is actually the whole security model: a user's login is the key to your office data from anywhere in the world. Treat the user list with the same seriousness as the office's physical keys.
Make groups that mirror how the office actually works — Accounts, Sales, Warehouse, Managers. Publish each application to the groups that need it. Then people simply join groups. The day someone changes departments, you move their group membership and their app list fixes itself. Offices that assign apps person by person end up, within a year, unable to answer the simple question: who can open what?
On a domain, the tool reads Active Directory users and groups — create and disable people in AD as you already do, and the portal follows. On a small workgroup server, users are local Windows accounts on that server, created in Computer Management. Both work. The trap is mixing casually: some users local, some domain, nobody sure which list is real. Pick one source of truth and write it down.
The moment the portal is reachable from outside, your users' passwords are being tested by strangers' scripts — that is not drama, it is the normal background noise of the internet. Enforce passwords that are long and unique, turn on account lockout so guessing slows to a crawl, and enable two-factor authentication if your product offers it. A short, shared, never-changed password on a published-apps server is the single most common real-world failure of setups like this.
When someone leaves the company, disabling their account is a same-day task, on the same checklist as collecting their keys. A remote-access account is more powerful than a key: it works from anywhere, at 2 a.m., without being seen. Keep a simple written joiner-and-leaver routine — account created, groups added, on day one; account disabled, sessions ended, on the last day.
Once a quarter, export or print the user list and the app assignments and read them with a manager. You will find the intern from two summers ago, the contractor whose project ended, the test account named 'test' with a password to match. Delete or disable what nobody can justify. Ten minutes of audit is cheaper than one incident — and in a small office, this list is short enough that there is no excuse to skip it.
The full on-screen walkthrough — server setup, app publishing and access from anywhere — is in the video above.
▶️ Watch Full VideoIf your office already runs a domain, use Active Directory — one place to create, disable and group people, and the portal inherits it. For a tiny office with a standalone server, local Windows accounts are acceptable, provided you keep the list short, the passwords strong and the leaver routine strict.
Yes — that is exactly how group assignment is meant to work. A manager in Accounts and Managers groups sees the union of both groups' applications in one portal, with one login. You never need duplicate accounts for one person.
Disable their account the same day and end any active sessions. Then review what that account could reach — published apps, shared folders, email — as part of the normal leaver checklist. Re-enabling later for a genuine handover is easy; an account left live 'just in case' is a standing risk.