Enrol
Enrol on one, available on all.
When a card or token is enrolled on one computer, CodeB also writes it to the share, so you never have to re-enrol the same card on every machine by hand.
Multi-computer deployments
Share NFC cards and tokens across every computer.
CodeB keeps each computer’s enrolled credentials — NFC card tokens, TOTP/2FA tokens, Bluetooth tokens and certificate logon data — as small files on that machine. Point every computer at one shared folder on a file server and the whole fleet uses the same cards and tokens: enrol once, sign in anywhere, revoke everywhere.
One registry value turns it on, it rolls out by Group Policy, and it is built so a file-server outage never locks anyone out — computers keep working with the cards they already hold.
What it does
One shared folder, the same cards on every computer.
In a network with several computers, an administrator points every machine at a single file share. From then on all of them read and write the same credential files, so an operator’s card works the same way at any workstation in scope.
Sign in
Each computer pulls the latest at the logon screen.
At the logon screen every computer copies new or updated cards and tokens from the share, once per logon screen — so a card enrolled a minute ago on another machine already works here.
Revoke
Delete once, gone fleet-wide.
When a card or token is deleted — in the CodeB card admin tool or the command-line admin tool — every other computer removes its copy too, at the latest on its next card logon attempt. Previously a deleted card kept working on any computer that had already copied it.
Setup
Three steps, then enrol as usual.
The feature is driven by a single registry value, so it deploys the same way as the rest of your Windows configuration — Group Policy, MDT, Intune or a one-line script.
-
Create a file share. Make a share that every computer can reach, for example
\\fileserver\CodeBData. -
Set the
RemoteDataFoldervalue on every computer. Create the REG_SZ valueHKLM\SOFTWARE\WOW6432Node\CodeB\RemoteDataFolderand set it to the share path, e.g.\\fileserver\CodeBData. This rolls out well by Group Policy (registry preference). An empty value ornonemeans the feature is off — CodeB writesnoneitself when the value is missing. -
Enrol cards and tokens as usual. CodeB creates the subfolders on the share by
itself:
CodeBSerialCredentials,CodeBX509Credentials,2FA,totp,CodeBBluetooth,temp, and adeletedfolder inside each.
How it behaves
Built so an outage can never lock you out.
The share makes the fleet consistent, but the local copy is always what signs the user in. The share is never mirrored blindly, so losing it costs you nothing but new enrolments until it is back.
01 / When it syncs
Reads at the logon screen; checks deletions on every card logon.
Cards and tokens are taken from the share when the logon screen needs them, once per logon screen. Deletions are checked at every card logon attempt. The newer file always wins, so a card enrolled again after a deletion works again everywhere.
02 / Deletions are safe
A marker removes copies — an outage never wipes cards.
A deleted card leaves a small marker file in the deleted folder on the share, and
other computers remove their copy when they see it. If the share cannot be reached, or is
empty, nothing is deleted locally — a network outage cannot wipe your cards.
03 / Share unreachable
Laptop away, server down? Logon still works.
A computer that cannot reach the share simply keeps working with the cards it already has: an unreachable share is checked for at most about three seconds and then left alone for five minutes, so the logon never stalls. When the share returns, the computer picks up changes at the next logon screen.
04 / Moving a card to Active Directory
Hand a card over to AD and the share copies clear.
When a card’s logon data is moved into Active Directory with the CodeB card tool, its file is removed from the share and from every other computer. From then on that card logs on through Active Directory, so the computer needs a connection to the domain (or its cached logon) for it.
Security & trust
Only the right people can revoke a card — and a revoked card stays revoked.
The share is a convenience, not a trust hole. A deletion only travels to the other computers when it comes from someone allowed to make it, and each user’s own data on the share is fenced off from everyone else.
Who can revoke
Administrators, the computer itself, or the card’s owner.
A card deletion propagates across the fleet only when it is made by an administrator (the NFCAdmin or command-line admin tool), by a computer running as SYSTEM, or by the user the card belongs to — deleting their own card, or moving it to Active Directory. A deletion an ordinary user tries to plant for someone else’s card is ignored. (An administrator’s deletion counts everywhere only if they are also an administrator on the file server; otherwise it removes only the cards they enrolled themselves.)
A revoked card stays revoked
No quiet comeback from the share.
A card enrolled again after a deletion is kept on every computer, even if the old deletion record is still on the share. A revoked card can no longer be copied back from the share — the earlier gap, where a computer could restore it once if the share copy could not be removed, is closed — and a deletion made within two minutes of enrolment now applies too. Even a newer copy of a revoked token is accepted only when an administrator, a computer, or the user who deleted the card put it there, so a revoked user cannot bring their own card back by dropping an old token file onto the share.
Each Web SSO folder is fenced off
Owner-checked on the share.
A user’s Web SSO folder on the share is used only if it belongs to that user (or to SYSTEM or an administrator), so another user cannot create it first and then read or replace the logins inside. Edits are no longer lost when several programs load the store at once, when a save lands just after a sync, or when one computer’s clock is wrong; logins saved while the share was away are uploaded at the next start.
No wait at the logon screen
Offline laptops sign in without delay.
The logon screen never waits for the domain controller — domain information is read locally, so a laptop away from the network signs in without a pause. A computer that lost the share retries after about five minutes rather than waiting for a restart, and a share configured later is picked up the same way.
New · Web SSO roaming
Web SSO logins follow the user to every computer.
The web and application logins CodeB fills in for a user — the websites and apps such as
T2med
— are stored per user. With RemoteDataFolder set they now travel with the user
across every computer on the share, so a clinician or operator finds their logins waiting at
whichever workstation they sit down at.
Saved in the background
When the user saves in the Web SSO manager, their logins are copied to the share in the background — no extra step.
Picked up automatically
On another computer the logins are read from the share at least every 30 seconds while the user is signed in, so a new computer gets them automatically.
Private per user
Every user has their own folder on the share (WebSSO\<user ID>), openable only by that user, administrators and the domain’s computers. Other users cannot read it.
Newest save wins, outage-tolerant
If the same user changes logins on two computers at once, the later save counts — changes are not merged. If the share is unreachable the local logins keep working; CodeB retries after five minutes and never makes the user wait more than about three seconds.
For administrators
Who can read and change the credential files.
Users enrol their own cards and tokens, so CodeB applies the usual Windows rules for shared data
folders — both locally under C:\ProgramData\CodeB and on the share. It sets these
itself when it runs with administrator rights.
| Token files | CodeB protects every token file it writes. Full control is given only to SYSTEM (the computer itself), the Administrators groups, Domain Admins and Enterprise Admins, Domain Computers (so every computer can read the shared copy), and the user the card or token belongs to. |
|---|---|
| Token folders | Signed-in users may create their own card and token files and have full control over the files they created. Only administrators and SYSTEM may delete or replace other people’s files; Domain Computers have full control. (Previously everybody had full control on these folders.) |
| Data-folder root | Users may still write into the root, but cannot delete, rename or replace the token folders below it. |
| The share | Set up by the administrator: give Domain Computers full access and users the right to create files (users enrol their own cards). CodeB adds the folder rules above by itself when it runs with administrator rights. Recommended: create the WebSSO folder on the share yourself, so each user can create their own folder inside it but cannot delete another user’s. |
| Revoking cards | An administrator who revokes or re-enrols cards needs administrator rights on the file server that holds the share — otherwise the change reaches only the cards they enrolled themselves. NFCAdmin and the command-line admin tool now warn when a deletion or re-enrolment could not be recorded on the share. |
| Deletion-record folders | The deleted folders on the share are created by the computers themselves at the logon screen, so no user can own or tamper with them. On a NAS where the computer accounts cannot write, create CodeBSerialCredentials\deleted and 2FA\deleted once as an administrator. |
FAQ
Common questions.
I deleted a card. Does it stop working everywhere?
Yes. Deleting a card leaves a marker on the share, and every computer that can reach the share removes its copy at the next card logon attempt. This replaces the old behaviour, where a deleted card kept working on computers that had already copied it. Revocation is not instant everywhere — it takes effect at each computer’s next card logon, and only while that computer can reach the share.
What if the file server is down?
The computers keep using the cards and tokens they already have, and nothing is deleted because of an outage — the share is never mirrored blindly. Sign-in never waits more than a few seconds for an unreachable share.
Do my Web SSO logins work on other computers too?
Yes, when your administrator has set up the CodeB data share (RemoteDataFolder). Logins you save on one computer are copied to your own folder on the share and are available on every other computer you sign in to; a new computer picks them up automatically.
Can a colleague delete my card on all computers?
No. A card deletion only travels to the other computers when it is made by an administrator, by a computer itself, or by you — the card’s owner. A deletion another ordinary user tries to plant for your card is ignored.
I revoked a card but it still works on another computer. Why?
Two things to check. First, each computer removes its copy at its next card logon attempt, and only while it can reach the share — so a machine that has not tried a card logon since, or is offline, has not caught up yet. Second, the revocation has to be recorded on the share: an administrator who revokes or re-enrols cards needs administrator rights on the file server that holds the share, otherwise the change reaches only the cards they enrolled themselves. NFCAdmin and the command-line admin tool now warn when a deletion or re-enrolment could not be written to the share.