MultiDeskKore — Troubleshooting

Version 1.0 · 25 October 2026 · Applies to MultiDeskKore Solo — the Single Host edition (MultiDeskKore V1) on Windows 10 Pro 22H2

Editions: these manuals cover MultiDeskKore Solo — the Single Host edition (MultiDeskKore V1/RC1, available now). MultiDeskKore Fleet (Multi-Host, V2) and MultiDeskKore Station (Same Machine, local multiseat) are in development and are not covered here.

Every fix below is something the product actually does. Nothing here is guessed. Where a behaviour has not yet been proven by a live test, the entry says so — report what you observe rather than assuming the manual is wrong.

First step for almost anything: on the host, run

MultiDeskKoreSetup.exe verify

and expect checks 0–35 ALL PASS. A failing check names the fault better than any guess. Report the check number and its detail to TrimKore Support.

1. Cannot connect (Remote Desktop fails)

Check in this order:

Is the host on and reachable? Try the host address from the user's device. If nothing responds, the host is off or the network is down — that is not a MultiDeskKore fault.
Is the user account enabled? In the console, Users → check the account status. A disabled account cannot sign in. Also check Allow remote sign-in is ticked for that user.
Is the password right? Passwords are case-sensitive. The administrator can reset the user's password from the Users page.
Is the licence or trial still active? Console → Licence. If the trial has expired, new users are refused until a licence key is activated. (Live sessions are not signed out at expiry, and a new user cannot be created until a key is activated.)
Is RDP listening? On the host, verify check 5 confirms port 3389 is listening. If it fails, the TermService or the session layer is the fault — report the check to Support.
Is the seat count the problem? Remember the seat rule: one seat is one user account on one licensed host. A seat is held by an enabled account in the console user store — creating an enabled account uses the seat at once, whether or not that user has ever signed in. A user created disabled holds no seat until re-enabled, and re-enabling is refused while the limit is reached. If the enabled-account count has reached the licensed count, creating another user fails and the console shows the service's own error (the licence seat limit is reached). A disconnected session never blocks anything: it stays running and resumable, and signing a session out (Kick) ends the session but does not free a seat. To free a seat, disable or delete an account you no longer need.

⚠ Signing out ends a session — it does not free a seat.

Closing the Remote Desktop window only disconnects — the session keeps running on the host. Only Sign out (Start → your user icon → Sign out, inside the desktop) ends the session. Neither frees a seat: a seat belongs to the account, and only disabling or deleting the account frees it. An administrator can end a disconnected session from the console by signing it out (Kick).

Do not create the account directly in Windows to work around a refused creation. An account created directly in Windows is not managed by MultiDeskKore and will not have seat accounting, limits, or folder isolation — and only accounts created through the console can sign in, so it will be stopped at sign-in.

2. Licence / grace problems

What the Licence page shows	What it means	What to do
Trial active, N day(s) remaining — 1 host + 2 remote	The 3-day trial is running (started from the Licence page with a trial key).	Buy and activate a key before it expires (Licence → Buy seats).
Trial active (backend confirmation pending), N day(s) remaining	The trial key is activated but the backend has not confirmed it yet.	Wait — the trial is running. If it stays pending, check the host's internet connection.
Trial suspended: system clock appears to have been set back…	The host clock was rolled back; the trial is suspended as a tamper precaution.	Correct the host clock and restart the service.
Trial ended — enter a licence key	No key stored and the trial has ended. New users are refused.	Activate a licence key (Licence → Update activation).
No licence key stored. Enter a trial licence key or a paid licence key.	No key stored and no trial has run yet.	Start the trial from the Licence page (Get trial key) or activate a paid key.
Grace — N days remaining	A new key is stored and online activation is pending (14-day grace). The licence is validated locally, so the host keeps working.	Check the host's internet connection; activation is attempted online. If grace runs out without activation, new users are refused.
Hardware mismatch / key invalid	The key belongs to a different host. This is not a grace case.	Use the key issued for this host. If the host was replaced, use Licence → Move this licence to a new host.
Perpetual licence: Active, but "Upgrades and support expired on [date] — licence still active"	The support/maintenance period has lapsed. This is not a fault.	Nothing. The licence stays active and seats keep working. Renew support only if you want upgrades and standard support again (optional annual renewal: 10% of the licence value).

Maintenance expiry never disables anything. If the console ever shows a lapsed maintenance date as an expired licence, that is a bug — report it.

"No expiry date recorded — the licence itself is perpetual" is also not a fault: it means the backend has not returned a maintenance date with activation yet. Absence of a date is "not recorded", never "expired".

3. Wallpaper not applying

The wallpaper applies at the user's next sign-in.

The user must sign fully out and back in (Start → user icon → Sign out). Disconnecting and reconnecting is not enough — that returns the same running session, with the old wallpaper.
The administrator sets the wallpaper on the Host page (upload a JPG, PNG, or BMP up to 5 MB, then activate it). Rotation is Off, Daily, or Weekly.
Users cannot change the wallpaper themselves — if a user reports that they cannot, that is by design.

4. Session not appearing in the console

The Sessions page refreshes automatically every 5 seconds. Press Refresh if you have just changed something.
A session whose RDP window was closed without signing out shows as Disconnected, not missing. It is still listed, with its apps running and its RAM held. Reconnecting brings it back.
A session that was signed out (by the user, or Kicked from the console) is gone from the list — that is correct. Signing out ends the session; it does not hide it.
If a user is definitely connected but no session shows, run verify on the host and report the result.

5. App blocked (an app will not launch for a user)

In the console, Users → edit that user → check Allowed apps and Denied apps. A denied app is blocked for that user only; an allowlist means only the listed apps may run.
App changes apply at the user's next sign-in. The user must sign fully out and back in — disconnecting and reconnecting is not enough.
Denied apps are also hidden from that user's Start Menu. If an app is missing from the Start Menu, check the deny-list before assuming it is not installed.
The administrator account is never locked out by app rules — the allow-all rule for administrators is always first.
If a denied app still runs: AppLocker enforcement on Windows 10 Pro 22H2 has not yet been proven live. Report it to TrimKore Support with the app name, the user, and the output of verify (check 14 covers the app-control service and the admin allow-all rule). The allowlist remains the working control in that case.

6. Ticket not showing (support tickets)

Tickets need a licence key stored. With no key stored, the console says tickets cannot be sent yet. Activate a key first.
Tickets need internet. If the host is offline, the Support page shows the banner "Cannot reach the server — check the host's internet connection." Sending fails with the same message. That is the expected behaviour — nothing is queued or faked, so there is no ticket to find later. Try again once the host is online.
Replies: replies from TrimKore appear in the ticket thread in the console. They are checked every 30 seconds while the Support page is open, and on every view refresh. Open the ticket and press Refresh thread.
Live round-trip not yet proven: sending a ticket, replying in the owner portal, and seeing the reply in the console has never run end to end (the pilot VM has no internet). If a reply sent from the portal does not appear in the console on an internet-connected host, report it with the ticket subject and time.

7. Host-transfer request failing

The request needs a stored licence key. With no key stored, a request cannot be sent.
Offline, it fails with "Cannot reach the server — check the host's internet connection." Nothing is queued. Try again once online.
The request is filed through POST /api/host/transfer-request on the TrimKore server. Check its status in the Licence page; TrimKore approves it in the owner portal, which clears the old hardware binding so the key can activate on the new host. If the request fails, report the backend's plain answer rather than assuming the transfer worked.

8. Console will not open

The console is at http://127.0.0.1:8443/ on the host. Open it from the host itself (Desktop shortcut "MultiDeskKore Console"). It is a local console, not a website.
If the page does not load, check the SeatManager service is running on the host, then run verify and report any failing check.
If you cannot sign in, check the username (admin by default) and the password chosen at install. There is no password-reset link in the console — contact TrimKore Support.

9. USB device or audio not working in a session (device mapping)

A dedicated USB device does not appear in the session: the host-wide switch must allow it — run verify and check 31 (fDisablePNPRedir absent or 0). The client must also enable RemoteFX USB redirection on its side (mstsc "Other supported RemoteFX USB devices") and the vendor driver must be installed on the host by hand (the console records it, it never installs it). Until the VM live test runs, a dedicated device appearing and working in a session is UNPROVEN — report exactly what you observe rather than assuming the switch is broken.
A shared printer does not print from another seat: the printer must be shared from the host's print server by hand and its share name recorded on the client (mode shared). The console does not create the share itself.
No audio in a session, or audio where it should be off: the host-wide switch is the proven control (verify check 32: playback allowed, microphone off). A client's own audio toggle takes effect at the seat user's next sign-in — but whether Windows 10 Pro 22H2 honours the per-user value is UNVERIFIED (live check Q9). If a seat still hears audio after its client was set to audio off, that is the Q9 outcome to report, not a console fault.
A non-printer device marked shared does nothing special: there is no sharing mechanism for non-printer USB devices in this increment — the console says so ("shared (mechanism not defined for this device type)").

10. Something else is wrong

Run MultiDeskKoreSetup.exe verify on the host and note any check that is not PASS.
In the console, check the Audit Log for the operation that failed (search by user or event type).
Raise a ticket from the console Support page (needs a licence key and internet), or contact TrimKore Support with: the check number and detail from verify, what you were doing, and what you expected to happen.

MultiDeskKore V1 · by TrimKore · trimkore.com Tested configuration: Windows 10 Pro 22H2.

MultiDeskKore V1 · by TrimKore · trimkore.com · Tested configuration: Windows 10 Pro 22H2. The Markdown files in Docs/ are the canonical source for these pages.