Installing JCS in an RDS environment

Overview

JCS can be used in a Microsoft Remote Desktop Services (RDS) environment, previously known as Terminal Server. JCS opens its front-end database exclusively, so every user must have their own copy of it — if two users share one, the second will see the error "JCS16.accde is already in use".

On a standard RDS server the installer handles this automatically. It installs JCS to a local folder on the server (usually C:\JCS    ), then runs a PowerShell script, rdsinstall.ps1    , which copies the per-user files into each user's %LOCALAPPDATA%\JCS     folder.

What is copied to each user

Only three files are copied into each user's %LOCALAPPDATA%\JCS     folder:

• StartAccess5_2016.exe    
• JCS16.accde    
• GEHv*.lib     — a support library whose version varies by JCS release

Everything else stays shared in C:\JCS    , including the databases, themes, report definitions, standard documents and the workgroup file system.mdw    .

Standard installation

On a server with the Microsoft Remote Desktop Session Host role installed, no special steps are needed:

1. Run the JCS installer on the server, installing to local storage (usually C:\JCS    ).
2. The installer detects the RDS environment, installs rdsinstall.ps1    into C:\JCS   , runs it, and records the location of the shared themes folder.
3. Shortcuts are created in the all-users Start Menu and Desktop, pointing at each user's own copy.

Running the script manually

You will need to run rdsinstall.ps1     yourself when adding new users, with User Profile Disks, FSLogix or roaming profiles, and in environments the installer does not detect automatically. On a standard RDS installation the installer runs it for you, including when you apply an update.

Before you start:

• You must be signed in as an administrator, as the script writes into other users' profiles.
• All users must be out of JCS. The script replaces each user's front end and will wait until everyone has closed the application.
• The script must run in 32-bit PowerShell, which the command below takes care of.

Open a command prompt as administrator and run:

C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File C:\JCS\rdsinstall.ps1

The -ExecutionPolicy Bypass     option applies to this command only and does not change your system's settings. It is needed on Windows 10 and 11, which block PowerShell scripts by default, and whenever the script has arrived by email or download.

Parameters

Shortcuts

rdsinstall.ps1     copies files only — it does not create or update shortcuts. On a standard RDS installation the installer creates these for you. If you are setting JCS up manually, create a shortcut with this target:

%LOCALAPPDATA%\JCS\StartAccess5_2016.exe -min /excl /runtime /profile "JCS16" /wrkgrp "C:\JCS\system.mdw" "%LOCALAPPDATA%\JCS\JCS16.accde"

Note that /wrkgrp     points at the shared system.mdw     in C:\JCS    , not at a per-user copy.

You only need one shortcut for everyone. Place it in the all-users Desktop folder (C:\Users\Public\Desktop    ) or the all-users Start Menu — %LOCALAPPDATA%     is expanded for whoever launches it, so the same shortcut takes each user to their own copy.

Themes

JCS's themes — its icons and styling — stay shared in C:\JCS\Themes   . Because each user runs their own copy of the front end from %LOCALAPPDATA%\JCS   , JCS needs a registry setting, ThemesPath   , to tell it where the shared folder is. On a standard RDS installation the installer sets this for you.

If you are setting JCS up manually, open a command prompt as administrator and run:

reg add "HKLM\SOFTWARE\JCS\IFA Professional\JCS Database Paths" /v ThemesPath /t REG_SZ /d "C:\JCS\Themes" /reg:32 /f

This is a single setting for the whole server, not one per user. Adjust the path if JCS is installed somewhere other than C:\JCS  .

If you prefer to use Registry Editor, add a String value named ThemesPath   , set to C:\JCS\Themes   , under HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\JCS\IFA Professional\JCS Database Paths   . Note the WOW6432Node    — JCS is a 32-bit program and will not see the setting anywhere else.

Users need to close and reopen JCS for the change to take effect.

After a JCS update

On a standard RDS installation, no action is needed. The JCS Update Manager is not set up on an RDS server, so updates are applied by running the JCS installer — and the installer runs rdsinstall.ps1     again each time, bringing every user's copy up to date as part of the process.

Make sure all users are out of JCS before applying the update.

It is worth checking C:\JCS\rds_install_log.txt     afterwards to confirm the script ran and covered every user — see Checking the log below. If your PowerShell execution policy prevents the script from starting, the installer will warn you and you will need to run it manually.

In environments the installer does not detect — such as TSPlus — none of this happens automatically, and you must run the script yourself after every update. See TSPlus and other non-Microsoft multi-session products below.

If your users' profiles are only on the server while they are signed in — with User Profile Disks, FSLogix or roaming profiles — the installer can only update users who are signed in at the time. Set up Running the script at logon so everyone else is updated when they next sign in.

Adding users after installation

The script can only set up users who already have a profile on the server — in other words, users who have signed in at least once. A new user therefore needs to sign in once before the script is run for them.

Once they have, run rdsinstall.ps1     again as described in Running the script manually. Existing users are simply refreshed, so it is safe to re-run at any time, provided everyone is out of JCS.

If you add users regularly, you can instead run the script at logon for the current user only, so each user is set up automatically when they sign in — see Running the script at logon.

Running the script at logon

Use this approach if your users' profiles are only on the server while they are signed in — for example with User Profile Disks, FSLogix or roaming profiles. In these setups a user's %LOCALAPPDATA%  folder is attached when they sign in and removed when they sign out, so neither the installer nor a manual run of the script can update users who are signed out at the time.

Instead, run the script at each logon for the user signing in. Each user's copy of JCS is then brought up to date whenever they sign in, so nobody can be missed — including after an update.

C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File C:\JCS\rdsinstall.ps1 -LogPath "%localappdata%\JCS\rdsinstall_log.txt" -Silent -CurrentUserOnly

-Silent  suppresses all prompts, which is essential for a logon script, and -LogPath  keeps each user's log within their own profile. Run this way, the script only writes to the signed-in user's own profile, so it does not need administrator rights.

What it changes

The script only replaces the three JCS program files in the user's own %LOCALAPPDATA%\JCS  folder. It does not touch your data, documents, shortcuts or JCS settings, which are held in the shared databases and the registry. A few minor remembered choices, such as the last label size used when printing labels, are reset each time — the same as happens at every JCS update.

Setting it up with Group Policy

Add the script as a logon script under User Configuration > Policies > Windows Settings > Scripts (Logon/Logoff) > Logon. On a standalone server, use the Local Group Policy Editor (gpedit.msc ) instead. Use the Scripts tab rather than the PowerShell Scripts tab, as the script must run in 32-bit PowerShell:

• Script name: C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
• Script parameters: -ExecutionPolicy Bypass -File C:\JCS\rdsinstall.ps1 -LogPath "%localappdata%\JCS\rdsinstall_log.txt" -Silent -CurrentUserOnly

So that the script finishes before anyone can open JCS, also set:

• Configure Logon Script Delay (Computer Configuration > Administrative Templates > System > Group Policy) to Enabled, 0 minutes. By default Windows waits five minutes before running logon scripts.
• Run logon scripts synchronously (Administrative Templates > System > Scripts) to Enabled.

Updating JCS

Apply updates with the JCS installer as normal. It updates the shared copy in C:\JCS , and each user picks up the new version the next time they sign in. After a major update, sign in yourself and open JCS once before other users return — the first time JCS starts after a major update, it updates the database.

TSPlus and other non-Microsoft multi-session products

The JCS installer identifies an RDS environment by checking for the Microsoft Remote Desktop Session Host role. TSPlus is designed to provide multi-user sessions without that role — its own documentation requires the RDS role to be absent — so the installer treats the machine as an ordinary single-user PC and the automatic setup does not run.

The same applies to other third-party multi-session products.

JCS works perfectly well in these environments, but the per-user setup must be done by hand:

1. Install JCS on the server as normal.
2. Contact JCS Technical Support for a copy of rdsinstall.ps1     matching your JCS version, and place it in C:\JCS    .
3. Run it as described in Running the script manually above.
4. Create the shortcut described in Shortcuts above.
5. Set the themes location as described in Themes above. This only needs doing once.
6. Repeat step 3 after every JCS update — including any applied through the JCS Update Manager — and whenever you add a user. The installer will not do this for you in this environment, and each user's copy will otherwise stay on the previous version.

Troubleshooting

Checking the log

rdsinstall.ps1     writes a log every time it runs. By default this is C:\JCS\rds_install_log.txt     — it is based on your JCS install folder, so the log appears there even if you run the script from somewhere else. If the script was run with -LogPath    , for example as a logon script, the log will be wherever that points.

The log is appended to, never overwritten, so it holds the history of every run. Each run starts with Starting new RDS (Remote Desktop Services) install process...     and, if it finishes successfully, includes Completed the RDS install process     near the end.

If a run has no completion line, it did not finish. Look for a line beginning Aborting install as    , which gives the reason. If there isn't one, the run was cancelled or stopped at an on-screen message — run the script again and note what it says.

A healthy run looks like this (abridged):

2026-09-29 10:14:01	Starting new RDS (Remote Desktop Services) install process...
2026-09-29 10:14:02	Checking for distribution files...
2026-09-29 10:14:02	  StartAccess5_2016.exe...Found
2026-09-29 10:14:02	  JCS16.accde...Found
2026-09-29 10:14:02	  GEHv1.013.lib...Found
2026-09-29 10:14:02	Retrieving list of users...
2026-09-29 10:14:02	  Found User Profile Folder: jsmith
2026-09-29 10:14:02	  Skipping User Profile Folder: Public
2026-09-29 10:14:03	Copying new distribution files...
2026-09-29 10:14:03	  Copying distribution files to: C:\Users\jsmith\AppData\Local\JCS
2026-09-29 10:14:03	    Copying file C:\JCS\JCS16.accde to C:\Users\jsmith\AppData\Local\JCS\JCS16.accde
2026-09-29 10:14:05	Completed the RDS install process

Things worth checking in particular:

• Every user appears as Found User Profile Folder:    . A user with no line at all has no profile on the server yet — usually because they have never signed in — so the script could not set them up. Folders such as Public     always show as Skipping User Profile Folder:    , which is expected; when run with -CurrentUserOnly    , every other user is skipped too.
• All three files show ...Found    . A ...Missing     line means the script and your installed version of JCS don't match — see below.
• Each file copies successfully. Failures are logged as Failed to delete file     or Failed to copy file    .

If you run the script with -Silent    , any message that would have appeared on screen is written to the log instead, prefixed MessageBox:    , so unattended and logon-script runs can still be diagnosed.

"JCS16.accde is already in use"

The user is launching the shared copy in C:\JCS     rather than their own. JCS opens its front end exclusively, so only the first user in will succeed.

Check that their shortcut points at %LOCALAPPDATA%\JCS\StartAccess5_2016.exe     and not at C:\JCS    , and that the three files are present in C:\Users\<username>\AppData\Local\JCS    . If they are missing, run the script.

This error also appears if the same Windows user is signed in to two sessions at once and opens JCS in both, since each Windows user has a single copy. Each person needs their own Windows login.

The script reports success but nothing changes for users

The files have been copied, but the shortcuts still point at the old location. The script only copies files — it does not create or update shortcuts. Check each shortcut's target against the example in Shortcuts above.

JCS looks plain, with no icons

JCS cannot find its themes, so it falls back to a basic look. Each user's own copy in %LOCALAPPDATA%\JCS    has no Themes    folder of its own, and the ThemesPath    setting that points it at the shared one is missing or wrong. This is why the copy in C:\JCS    looks normal while users' own copies do not. See Themes above.

"...cannot be loaded because running scripts is disabled on this system"

PowerShell's execution policy is blocking the script. This is the default on Windows 10 and 11, and also happens when a script has arrived by email or download. Start it using the command in Running the script manually, which includes -ExecutionPolicy Bypass    .

An error mentioning Join-Path or a null path

The script could not read the JCS install location from the registry, almost always because it was started in 64-bit PowerShell. Start it using the 32-bit command shown in Running the script manually.

"This tool is not designed to run within a 64 bit sub system"

The script must run in 32-bit PowerShell. Click Retry to restart it in 32-bit PowerShell. If that does not work, cancel and start it using the command in Running the script manually.

"The update cannot continue as the following source files cannot be found"

Usually names a file such as C:\JCS\GEHv1.013.lib    . The script is from a different JCS release than the one installed.

Look in C:\JCS     for the file beginning GEHv     and note its version. Then open rdsinstall.ps1     in Notepad and change the GEHv...     file name in the first list near the top of the script ($script:FilesDist    ) to match. Nothing was copied or deleted, so it is safe to correct and re-run.

"ALL users must first exit JCS or Microsoft Access"

The script will not replace files while JCS is open. Ask all users to close JCS, including anyone signed in at the server console, then click Retry. If the message persists, check the Details tab in Task Manager for any remaining msaccess.exe     processes, from any user.

"Error: could not delete the file..." or "Error: could not copy the file..."

The named user's copy is locked or protected — usually because they still have JCS open, or an antivirus scan has the file in use. Make sure that user has closed JCS, then run the script again. If it persists, check the permissions on their AppData\Local\JCS     folder.

"Setup could not determine a valid JCS install folder"

The InstallPath     registry value is missing or points to a folder that no longer exists. The message shows the folder and the registry key it looked in — note that on 64-bit Windows, Registry Editor shows this key under HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\JCS    . Confirm the folder exists and contains JCS16.accde    .

A newly added user has no JCS

The script can only set up users who have a profile on the server — that is, who have signed in at least once. Users who were created, or who first signed in, after the script last ran will have no files. Ask the user to sign in once, then run the script again — or set it to run at logon.

Only some users were updated (User Profile Disks, FSLogix or roaming profiles)

The script updates every user profile folder it finds in C:\Users   at the moment it runs. With User Profile Disks, FSLogix, or roaming profiles that are removed at sign-out, a user's profile is only on the server while they are signed in. Only the users signed in at the time are updated, and everyone else is missed without any error. This applies equally when the installer runs the script as part of an update.

Missed users do not appear in the log at all — check the Found User Profile Folder:   lines in rds_install_log.txt   against your list of users.

To bring missed users up to date, ask them to sign in to the server, without opening JCS, and run the script again. To stop it happening in future, run the script at each logon for the current user only, as described in Running the script at logon — each user's copy is then refreshed every time they sign in, so nobody can be missed.

The logon script did not update a user's copy

Check that user's log at %localappdata%\JCS\rdsinstall_log.txt . If there is no entry for the time they signed in, the script did not run — check the Group Policy settings in Running the script at logon. A Failed to delete file  line usually means JCS was already open when the script ran, typically because Windows delayed the logon script — set Configure Logon Script Delay to 0 minutes as described above.

Users are on an old version after a JCS update

In environments the installer does not detect automatically, such as TSPlus, this is expected: the update only refreshes C:\JCS    . Run the script after every update, and make sure nobody starts JCS in between.

On a standard RDS installation this should not happen — check rds_install_log.txt     to see whether the script ran during the update, and whether every user was listed.

"The update could not complete as the local user list could not be determined"

The script could not find any user profile folders on the server, including your own. This is rare — please contact JCS Technical Support.