Documentation

MultiDeskKore — Quick Start Guide

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

This guide takes a new administrator from a bare host to working user desktops in under an hour. It is the short path. The full detail lives in the Installation & Setup Manual, the Administrator Guide, and the other manuals in this set.

What MultiDeskKore is, in one sentence: one Windows host runs several independent desktops at the same time, and each user connects to their own desktop with Remote Desktop — no extra server hardware, no domain, no monthly subscription.

One seat is one user account on one licensed host.

Before you start

You need:

• A host PC running Windows 10 Pro, version 22H2, with a proper Windows licence. (This is the configuration MultiDeskKore was tested on. Windows 11 has not been tested — do not assume it works.)
• Administrator rights on that host.
• A reliable network connection between the host and each user's device.
• One device with a display, keyboard, and mouse per user, each with a Remote Desktop client (Windows Remote Desktop Connection, or any compatible RDP client).
• A licence key from TrimKore — or a free 3-day trial (see step 5). The trial is started from the console's Licence page after install; nothing runs as a trial before that. The installer itself is not publicly downloadable — it arrives only by email (see step 1).

Step 1 — Install (about 10 minutes)

1. Register on the MultiDeskKore website and verify your email. The installer is not publicly downloadable. The download link is emailed to the registered, verified email address only. That email contains a signed download link (valid 7 days) — no licence key. The key is never emailed as the delivery mechanism.
2. Download MultiDeskKoreSetup.exe from that link and copy the single file to the host. There is only one file — the service, the session layer, and the console are all inside it.
3. Right-click it and choose Run as administrator.
4. Run: MultiDeskKoreSetup.exe install
5. If you already have a licence key, you can pass it now: MultiDeskKoreSetup.exe install MDK2-<your-key> The key is case-sensitive — paste it exactly as issued, never retype it from memory.
6. If you have no key, install without one. No trial runs yet — the trial is started from the console afterwards (step 5).
7. The installer asks for the console admin password (minimum 8 characters, typed twice, never shown on screen). Choose it now and keep it safe — it is the only way into the console. It is stored only as a salted hash, never in plain text.
8. The installer finishes by running its own verification. Expect checks 0–35 ALL PASS. If any check fails, do not work around it — report the check number and its detail to TrimKore Support.

Step 2 — Open the console and sign in

1. On the host, double-click the MultiDeskKore Console shortcut on the Desktop (there is also one in the Start Menu). It opens http://127.0.0.1:8443/ in your browser.
2. Sign in with username admin and the password you chose during install. On the first sign-in with no licence key stored, the console opens the Licence page and shows Start your free 3-day trial — that is the first-run flow (step 5).

The console runs entirely on the host. It works with no internet connection. Buying seats, support tickets, host-transfer requests, and getting a trial key need the website.

Step 3 — Create your first users (about 5 minutes per user)

1. In the console, go to Users → + Add user.
2. Enter a username (for example Seat1) and a password (minimum 8 characters). The password is the one the user types when they connect — give it to them securely, not in a shared chat.
3. Leave the defaults on for a first user: RAM limit 2048 MB and disk quota 10240 MB are pre-filled, and Transfer folder, clipboard, and drive redirection are on. You can change all of these later from the same form.
4. Click Create user. The account is created on the host by the console — never create seat accounts directly in Windows. Only accounts created through the console can sign in: an account created directly in Windows is stopped at sign-in. The console admin account and BUILTIN\Administrators are exempt. (Accounts created directly in Windows during the early pilot — for example the Stage-A Seat1/Seat2 accounts — are stopped under this rule; create console-managed users instead.)

Seats, plainly: 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. A disconnected session stays running and resumable, and signing a session out (Kick) ends the session but does not free a seat. Disabling or deleting an account frees its seat for a new account. The console admin account is separate and does not count as a seat. Creating a user past the limit fails: the console shows the service's own error — the licence seat limit is reached (during the trial, at most 2 remote seat accounts can be created, plus the host admin).

Step 4 — Connect the first client (about 5 minutes)

1. On the user's device, open Remote Desktop Connection (mstsc on Windows).
2. Computer: the host's address (its hostname or IP address — the console Host page shows the address, and has a Copy address button).
3. Sign in with the username and password you created in step 3.
4. The user gets their own Windows desktop on the host. Their files live in their own workspace folder; they cannot open the host's full C: or D: drives, only their own folders plus any shared or Transfer folders you assigned.

Close the Remote Desktop window without signing out and the session stays running with its apps open — reconnecting brings back the same session. To fully end a session, the user signs out from inside their desktop (Start → user icon → Sign out), or you sign them out from the console Sessions page.

Step 5 — The 3-day trial

If you installed without a licence key, nothing runs as a trial yet. Start the trial from the console's Licence page:

1. Sign in to the console (step 2). With no key stored, the Licence page shows Start your free 3-day trial with a Get trial key form.
2. Enter your name and the email address you registered and verified with on the MultiDeskKore website. The console sends them with this host's hardware ID to the TrimKore backend, which returns a trial key to the console. The trial key is generated from the console's Licence page and activated there.
3. The console activates the key at once. The Licence page then shows "Trial active, N day(s) remaining — 1 host + 2 remote". The trial runs for exactly 3 days from activation.
4. A copy of the trial key is emailed to you once, after activation, for safekeeping — "Your trial key is already active in your console. Keep this copy in a safe place for your records — you do not need to enter it anywhere." It is a record only: it is not the delivery mechanism and not the activation step.

During the trial the product is fully functional within the host's resources — there are no feature limits. During the trial at most 2 remote seat accounts can be created, plus the host admin (3 users in total: 1 host + 2 remote).

• The console Licence page shows the trial status and days remaining.
• When the trial expires, a licence key is required and new users are refused — but live sessions are not signed out or disabled.
• The trial is bound to this host: it cannot be moved to another PC, and it cannot be refreshed by reinstalling or re-registering. Reinstalling does not restart the trial — the trial activation record survives uninstall.
• Already issued? If a trial key was already issued for your email, or a trial was already activated on this PC, the backend refuses with "already issued" and no second trial is ever issued. Use the key already in your console, or the safekeeping copy emailed after activation.
• No internet? A trial key needs the backend — it cannot be issued offline. The console says so plainly; no trial is faked.
• Clock set back? If the host clock is rolled back, the trial is suspended: the Licence page shows a tamper warning ("Trial suspended: system clock appears to have been set back… Correct the host clock and restart the service"). Correct the clock and restart the service.

Step 6 — Buy and activate

Pricing — buy once, no subscription:

Buy once. Renew support and upgrades only if you need them. The first 12 months of upgrades and standard support are included with every licence. Optional annual renewal after that is 10% of the licence value, rounded once to cents.

1. In the console, go to Licence → Buy seats. It opens the public buy page (multideskkore.trimkore.com/buy) with a short-lived secure token that identifies your host — and your licence too, if you already have one, so extra seats are offered at the upgrade price. No hardware ID, host name or licence ID appears in the page address.
2. The buyer gives only an email address. There is no customer login and no customer account — the buy page is public, and the owner portal is TrimKore-only. Payment is manual: the button only opens the page.
3. TrimKore issues a licence key. Activate it in the console at Licence → Update activation (paste the key exactly), or at install time as in step 1.
4. A new key starts in a 14-day activation grace state while the service activates it online. The licence itself is validated locally by its signature, so the host keeps working. If activation cannot complete, the Licence page shows the grace state and days remaining. A key for a different host is invalid immediately — it is not a grace case.

Licence vs support, kept separate: the Licence page shows two lines — "Perpetual licence: Active" and "Upgrades and support: Included until [date]" (or, when lapsed, "Upgrades and support expired on [date] — licence still active"). A lapsed support period never disables anything and never makes the licence look expired.

Step 7 — Need more seats later?

On the Licence page, Get more seats works the same way as Buy seats: get a new licence key from TrimKore and activate it in the console. Your existing users, sessions, and settings are kept.

If something goes wrong

• Cannot connect: check the host is on, the user account is enabled in the console, and the licence or trial is still active. On the host, run MultiDeskKoreSetup.exe verify — checks 0–35 pinpoint the fault.
• Wallpaper not applying: it applies at the next sign-in. The user must sign fully out and back in.
• An app will not launch for a user: check that user's Allowed / Denied apps in the console. App changes apply at the user's next sign-in.
• A ticket or reply is missing: support tickets need a licence key stored and an internet connection. Without internet the console says so plainly — nothing is queued or faked.

Full detail: see the Troubleshooting manual. To raise a ticket, use Support in the console.

MultiDeskKore V1 · by TrimKore · trimkore.com Tested configuration: Windows 10 Pro 22H2. No customer login exists; the customer uses only the local console.

MultiDeskKore — Installation & Setup Manual

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

1. What you are installing

MultiDeskKore V1 turns one Windows host into several independent desktops. Each user connects with Remote Desktop and gets their own Windows session on the host. The install contains three parts in a single file:

• The session layer — lets Windows run more than one interactive session at a time on the host.
• The SeatManager service — creates and manages user accounts, sessions, limits, folders, and the licence.
• The web console — the local administration pages at http://127.0.0.1:8443/, where the administrator manages users, sessions, the licence, and support.

One seat is one user account on one licensed host.

2. Host requirements

Required

• Windows 10 Pro, version 22H2, properly licensed. This is the configuration MultiDeskKore was tested on: the pilot host was a Windows 10 Pro 22H2 virtual machine. Windows 11 has not been tested — do not assume it works.
• A properly licensed Windows host. MultiDeskKore is not a substitute for a Windows licence, and it does not change how Windows itself is licensed.
• Administrator rights on the host. The installer must be run as administrator; it changes system services, registry settings, and file permissions.
• A reliable network between the host and every user's device.
• Enough host resources for the sessions you plan to run. Capacity depends on workload and host resources — the console Host page shows live CPU and memory use. The tested setup ran 4 concurrent user sessions plus the console administrator on a 12 GB virtual machine; that is a record of one test, not a promise about any other host.

Not required

• No extra server hardware.
• No domain or Active Directory.
• No proprietary thin-client hardware.
• No separate virtual machines.
• No monthly subscription.

Optional

• Thin clients (any device with a compatible Remote Desktop client works as a seat).
• A wired network (recommended where the host and seats are fixed in one place).
• A backup routine for the host (see section 9).

3. The installer

3.1 One file

Distribution is a single file: MultiDeskKoreSetup.exe. It is produced by build-all.bat and contains the service, the session layer, and the whole web console embedded inside it. There are no loose files to copy alongside it.

3.2 Commands

Run from an elevated Command Prompt on the host (right-click → Run as administrator):

3.3 What the installer asks for

Licence key — a command-line argument, or prompted interactively. Empty means "install unlicenced": the install proceeds with no licence stored — the trial is started from the console afterwards (section 6). A malformed key, a bad signature, or an old MDK1 key is refused and the install aborts with no changes. Keys are case-sensitive (MDK2 base64url) — paste exactly as issued, never retype from memory.

Admin password — a command-line argument, or prompted twice (must match, minimum 8 characters, input never shown on screen). Passing it on the command line leaves it in shell history; the prompt is preferred. The password is never stored in plain text and never logged — only a salted hash is kept.

3.4 What the installer does, in order

1. Baseline — records the on-disk termsrv.dll hash and size before any change, so uninstall can prove the stock file is restored.
2. Backup — backs up the current session-service setting under the product's own keys (never over a stock backup).
3. Session layer — stops the SeatManager service (if any), stops dependent services, stops TermService, installs the session proxy, restarts the services, and runs the session-layer verification. Any failure rolls back automatically.
4. SeatManager service — copies the service into the install folder, registers it (Automatic, LocalSystem), and starts it. Failure rolls back fully.
5. Console files — copies the web console into the install folder. If the console files are absent the install continues with a clear warning.
6. Config + licence + admin — creates the seats and shared folders and writes the product settings, licence record, and admin password hash.
7. Session policy, firewall, app service, shortcuts — sets the screen-assistance (shadow) policy to "with user permission" (only when no value is set already), enables the Remote Desktop Shadow firewall rule, sets the AppIDSvc service to Automatic and starts it, and creates the MultiDeskKore Console shortcuts (Desktop and Start Menu, with the TrimKore logo icon). These four are warnings-only on failure — they never fail the install.
8. Final verification — runs the full check set (0–35).

3.5 Shortcuts

After install there are two shortcuts, both named MultiDeskKore Console:

• Desktop — an Internet Shortcut to http://127.0.0.1:8443/ with the TrimKore logo icon.
• Start Menu — the same target.

Both are removed on uninstall.

4. First sign-in

1. Double-click the Desktop shortcut (or open http://127.0.0.1:8443/ in a browser on the host).
2. Sign in with username admin and the password chosen during install.
3. The console opens on the Sessions page.

The console is served from the host itself and works with no internet connection. Only buying seats, support tickets, and host-transfer requests need the website.

Changing the admin password later: Admin accounts → My credentials. You need the current password. This is the console admin account, not the Windows Administrator account.

If you forget the admin password: there is no password-reset link in the console. Contact TrimKore Support — do not edit the admin store files by hand.

5. Verification — checks 0–35

After install (and any time something is wrong), run:

MultiDeskKoreSetup.exe verify

Expect checks 0–35 ALL PASS. Each check prints PASS or FAIL with a short detail. The checks cover, among others: the session layer version and hash, the service running, the RDP port (3389) listening, reconnect behaviour, the shutdown lockdown, the shadow policy, the app-control service, the trial activation record, the embedded payload, the console Support section, the maintenance display, the host-transfer section, and the Help section. Checks 15 and 23–28 cover the trial key: the trial activation record (activation + 3-day expiry), hardware binding, clock-tamper detection, no retired no-key trial anchor, the record surviving uninstall, the console trial fields, and expired-trial handling. Checks 29–35 cover Increment 2 device mapping: the client registry and role store, USB redirection allowed host-wide, audio policy state (with the Q9 note), the console Client machines view, the device-redirection ops, and sessions linking to client records.

If a check fails, report its number and detail to TrimKore Support rather than working around it. A failed check after an upgrade is how a bad install is caught before users are affected.

6. Licence and trial activation

6.1 The 3-day trial

There is no no-key trial. Installing without a licence key stores no trial and starts no clock. The trial is started from the console's Licence page, after install:

1. Get the installer first. Register on the MultiDeskKore website and verify your email. The installer is not publicly downloadable. The download link is emailed to the registered, verified email address only. That email contains a signed download link (valid 7 days) — no licence key.
2. Install (section 3) and sign in to the console with the admin account created at install. On the first sign-in with no licence key stored, the console opens the Licence page and shows Start your free 3-day trial.
3. Get trial key. On the Licence page, enter your name and the email address you registered and verified with. The console sends them with this host's hardware ID to the TrimKore backend (POST /api/licences/trial-key), which returns a trial key to the console. The trial key is generated from the console's Licence page and activated there. The console activates the key at once; the Licence page then shows "Trial active, N day(s) remaining — 1 host + 2 remote".
4. Safekeeping copy. A copy of the trial key is emailed to you once, after activation, for safekeeping — "Your trial key is already active in your console. Keep this copy in a safe place for your records — you do not need to enter it anywhere." It is a record only: it is not the delivery mechanism and not the activation step.

The trial runs for exactly 3 days from activation. During the trial the product is fully functional within the host's resources — no feature limits. During the trial at most 2 remote seat accounts can be created, plus the host admin (3 users in total: 1 host + 2 remote).

At expiry, precisely:

• A licence key is required (licence status becomes none) and new users are refused through the console.
• Live sessions are NOT signed out and are NOT retroactively disabled.

The trial is bound to this host (hardware ID): it cannot be moved to another PC, and it cannot be refreshed by reinstalling or re-registering. The trial activation record lives outside the install folder and is not removed on uninstall — reinstalling does not restart the trial. If the host clock is set back, the trial is suspended (the Licence page shows "Trial suspended: system clock appears to have been set back… Correct the host clock and restart the service"); correct the clock and restart the service.

If a trial key was already issued for your email, or a trial was already activated on this PC, the backend refuses with "already issued" and no second trial is ever issued. Use the key already in your console, or the safekeeping copy emailed after activation. A trial key needs the backend — it cannot be issued offline. If the host is offline, the console says so plainly and no trial is faked.

The console Licence page shows the trial status and days remaining.

6.2 Activating a licence key

Two ways:

• At install time: MultiDeskKoreSetup.exe install MDK2-<key>.
• In the console: Licence → Update activation → paste the key → Activate licence.

A stored key always wins over the trial. A newly stored key starts in a 14-day activation grace state while the service attempts online activation once, best-effort. The licence itself is validated locally by its MDK2 signature, so the host keeps working during grace. The Licence page shows the grace state and days remaining. After the grace period expires without activation, new users are refused. A key for a different host (hardware mismatch) is invalid immediately — that is not a grace case.

6.3 Pricing

Buy once. Renew support and upgrades only if you need them.

The first 12 months of upgrades and standard support are included with every licence. Optional annual renewal after that is 10% of the licence value, rounded once to cents — the console Licence page computes and shows the renewal price for the current seat count. For the 5-seat bundle, for example, the renewal is $10.00 (10% of $99.99).

6.4 Licence vs maintenance — two separate things

The Licence page shows them on separate lines:

• Perpetual licence: Active
• Upgrades and support: Included until [date] — or, when lapsed, "Upgrades and support expired on [date] — licence still active".

Maintenance expiry never disables entitled functionality and never makes the licence look expired. Licence validation and the seat-account limit check only the perpetual licence, never the maintenance date.

Note: until the TrimKore backend returns a maintenance date with activation, the console shows "No expiry date recorded — the licence itself is perpetual." Absence of a date is "not recorded", never "expired".

6.5 Buying and adding seats

Licence → Buy seats opens the public buy page (multideskkore.trimkore.com/buy) with a short-lived secure token that identifies the host — plus the licence when one exists, so extra seats are offered at the upgrade price. No hardware ID, host name or licence ID appears in the page address. The buyer gives only an email address. There is no customer login and no customer account: the buy page is public and the owner portal is TrimKore-only. Payment is manual — the button only opens the page.

To add seats later, get a new licence key from TrimKore and activate it in the console. Existing users, sessions, and settings are kept.

7. Creating the first users

1. Console → Users → + Add user.
2. Username (for example Seat1), display name (optional), password (minimum 8 characters).
3. Role is fixed: seat users are always Standard user. The console admin account is separate.
4. Allow remote sign-in — on by default.
5. Capabilities (tick to set; unticked means off):
6. RAM limit — pre-filled 2048 MB.
7. Disk quota — pre-filled 10240 MB.
8. Allowed apps — an allowlist: only these apps may run.
9. Denied apps — specific apps this user may not run (AppLocker deny-list), even though everyone else may.
10. Shared folders — comma-separated paths assigned to this user.
11. Transfer folder — on by default; the user's drop-box for sharing files with the host.
12. Clipboard redirection — on by default.
13. Drive redirection — on by default.
14. Click Create user.

Users are created only here — never directly in Windows. A user created directly in Windows is not managed by MultiDeskKore: it has no seat accounting, no limits, and no folder isolation — and only accounts created through the console can sign in, so an account created directly in Windows is stopped at sign-in. The console admin account and BUILTIN\Administrators are exempt. (Accounts created directly in Windows during the early pilot — for example the Stage-A Seat1/Seat2 accounts — are stopped under this rule; create console-managed users instead.)

Seat accounting: 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. A disconnected session stays running and resumable, and signing a session out (Kick) ends the session but does not free a seat. Disabling or deleting an account frees its seat for a new account. The console admin account is separate and does not count as a seat. See the Administrator Guide for the full rule.

8. Connecting the first client

1. On the user's device, open a Remote Desktop client (mstsc on Windows, or any compatible RDP client).
2. Computer: the host's address. The console Host page shows it and has a Copy address button.
3. Sign in with the username and password created in section 7.
4. The user gets their own desktop. First sign-in takes a little longer while Windows prepares the profile.

Reconnect: if the user closes the Remote Desktop window without signing out, the session stays running with its apps open. Reconnecting brings back the same session. To fully end a session, sign out from inside the desktop or from the console Sessions page.

9. Backup and uninstall

Backup: back up the host the way you would back up any Windows workstation. MultiDeskKore keeps its data under %ProgramData%\MultiDeskKore\ (user records, licence record, audit log, wallpapers) and its settings under HKLM\SOFTWARE\MultiDeskKore. The trial activation record also lives in that registry key and survives uninstall by design.

Uninstall:

MultiDeskKoreSetup.exe uninstall --keep-data or MultiDeskKoreSetup.exe uninstall --delete-data

Uninstall removes the service, the session proxy, the console files, and both shortcuts, and restores the stock Windows session behaviour (the recorded termsrv.dll hash is checked on the way out). --keep-data keeps user data and settings; --delete-data removes them. The trial activation record is kept either way — reinstalling does not restart the trial.

10. Moving the licence to a new host

If the host is being replaced, use Licence → Move this licence to a new host in the console (Administrator only to submit). Give a reason; TrimKore approves the transfer, which clears the old hardware binding so the key can activate on the new host. The request needs a stored licence key and an internet connection: with no key stored, a request cannot be sent; offline, it fails with a plain message and nothing is queued.

MultiDeskKore V1 · by TrimKore · trimkore.com Tested configuration: Windows 10 Pro 22H2. No customer login exists; the customer uses only the local console.

MultiDeskKore — Requirements Matrix

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

This matrix states exactly what MultiDeskKore V1 needs, what it does not need, and what is optional. Nothing is listed here that was not part of the tested product. Where a capability is implemented but its live behaviour has not yet been proven in a test, the matrix says so.

Required

Not required

Optional

What is proven, and what is not yet proven

The product was verified in the pilot VM on 25 October 2026 (verification checks 0–12 all passing, including 4 concurrent RDP sessions plus the console administrator active at the same time, and the same session reinstated on re-login). The following are implemented in V1 but their live behaviour has not yet been proven by a recorded test. They are listed here so nobody mistakes a console setting for a proven guarantee:

• RAM-limit enforcement — per-session limits are set from the console and applied by the service, but no recorded test has yet shown a session actually being held to its cap.
• Disk quotas — quotas are set from the console with read-back verification, but no recorded test has yet shown a write beyond a quota being refused.
• Application restrictions — denied/allowed apps are set from the console (AppLocker deny-list plus Start Menu hiding), but enforcement on Windows 10 Pro 22H2 has not yet been proven live.
• Clipboard / drive redirection controls — the toggles are set from the console, but no recorded test has yet shown redirection actually blocked in a session.
• Administrator roles (Operator / Viewer) — roles are enforced by the service, but no recorded test has yet shown a role denial (for example, a Viewer being refused a user-creation attempt).
• Audit coverage — the console Audit Log records user, session, licence, admin, wallpaper, ticket, and transfer operations, but no recorded test has yet confirmed an entry for each operation.
• Consent-based screen assistance (shadowing) — the console gives the exact shadow commands and the policy requires user permission, but shadowing against the installed session layer has not yet been proven live.
• USB redirection (Increment 2) — the host-wide switch is set (fDisablePNPRedir absent or 0, verify check 31) and the console records each client's peripherals, but no recorded test has yet shown a dedicated USB device actually appearing and working in a session on Windows 10 Pro 22H2, or a shared printer printing from a different seat's session.
• Per-user audio (Increment 2, live check Q9) — the host-wide audio switch is set and the per-client toggle is written into the seat user's hive, but whether Windows 10 Pro 22H2 honours the per-user hive value has not yet been proven live. Until the live test runs, the host-wide switch is the proven control.
• Support-ticket round-trip — tickets are created in the console and sent to TrimKore, but the live round-trip (send, reply in the portal, reply appearing in the console) has never run; the pilot VM has no internet.
• Folder-permission negative test — seat and shared-folder permissions are in place and the service log shows no permission failures, but no recorded test has yet shown one seat user being refused another seat user's folder. That negative test is still to run.

Compatibility — what is NOT claimed

• Windows 11 — not tested; no compatibility is claimed.
• Any specific number of seats per gigabyte of RAM — no such figure is promised. Seat capacity is governed by the licence (one seat is one user account on one licensed host); how many sessions the host can run at once is governed by the host's resources and the workload in each session.
• Unlimited capacity during the trial — the trial is fully functional within the host's resources; it does not imply unlimited practical capacity. During the trial at most 2 remote seat accounts can be created, plus the host admin.

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

MultiDeskKore — Administrator Guide

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

This guide walks through the local console section by section. The console lives at http://127.0.0.1:8443/ on the host and is opened from the MultiDeskKore Console Desktop or Start Menu shortcut. Sign in with username admin and the password chosen at install. The console works with no internet connection.

0. Seats — the rule, exactly as implemented

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 user uses a 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 (same seat-limit error).
• A disconnected session stays running and resumable (reconnecting brings back the same session). It does not hold or free a seat: the seat belongs to the account, not the session.
• Signing out (Kick) ends the session. It does not free a seat.
• Disabling or deleting an account ends its session and frees the seat for a new account.
• The console admin account is separate and does not count as a seat: 5 seats are 5 remote user accounts, plus the admin.

⚠ Sign out to end a session — but it does not free a seat.

Closing the Remote Desktop window only disconnects — the session keeps running on the host, with its apps open, until you sign out or the administrator signs it out (Kick). Only Sign out ends the session. Neither disconnecting nor signing out frees a seat: a seat is freed only by disabling or deleting the account. If you need a seat for a new user, disable or delete an account you no longer need — do not ask users to sign out for that.

Purchased seats (what the licence key grants), seat accounts used (enabled accounts in the user store — the Licence page shows them as "N of M seat accounts used"), active sessions (live RDP sessions), and disconnected sessions (RDP window closed without signing out) are four different counts. Do not confuse them: a host can show fewer live sessions than seat accounts used, and that is normal — an enabled account holds its seat even with no session.

Creating a user past the limit fails: the service refuses the creation with LICENCE_SEAT_LIMIT and the console shows the service's own error text. During the trial at most 2 remote seat accounts can be created, plus the host admin.

Note: the seat model was decided by the owner on 2026-10-26. This guide states the decided rule: one seat is one user account.

1. Sessions

Sessions is the console's home page. It lists every live session on the host, with user, state, client device, client address, logon time (UTC), and RAM used. It refreshes automatically every 5 seconds.

States

Sessions 0 (Windows services) and 65536 (the RDP listener) are not real user sessions and are hidden from the list.

Actions — select a row for details

• Disconnect — ends the connection but leaves the user signed in. Apps keep running; the user reconnects to the same session.
• Sign out (Kick) — ends the session and closes running applications. Unsaved work may be lost. The console asks for confirmation and advises disconnecting instead if the aim is only to free the screen. Signing out frees the session and its RAM. It does not free a seat — only disabling or deleting the account does (see section 0).

When the account limit is reached

There is no disconnected-seat alert and no session is ever blocked by a disconnected session: a disconnected session keeps running and resumable, and the seat belongs to the account, not the session. When the enabled-account count reaches the licensed count, the console refuses a new user with the service's own error — the licence seat limit is reached. To make room for a new user, disable or delete an account you no longer need (either frees its seat at once), or activate a licence key with more seats. Creating a user past the limit is the only place the seat limit bites: existing accounts and sessions are never touched by it.

Reconnect behaviour

Reconnecting always brings back the same session. This was verified in the pilot VM: the same session was reinstated on re-login.

Shadowing — consent-based screen assistance

On a session's details page, Shadow this session gives the exact commands to watch or control that user's screen using native RDP shadowing:

• View only — mstsc /shadow:<id> /v:<host> (watch, cannot control).
• Take control — mstsc /shadow:<id> /v:<host> /control.
• A Download .rdp file button provides the same shadow session as a file you can double-click.

A browser cannot launch Remote Desktop directly, so run the command in a Command Prompt on the host (or on any Windows PC that can reach it), or double-click the downloaded .rdp file.

Consent: the installed policy is full control with user permission — the user is asked for permission before you take over. View-only first, then with control. A no-permission mode exists but is not the default and is an owner decision; the installer never sets it on its own.

Honest limit: shadowing against the installed session layer has not yet been proven by a live test. The commands and the policy are in place and verified by check 13; a live shadow with the permission prompt is still to be run.

1A. Client machines

Client machines lists the physical stations that connect to this host — PCs, thin clients and laptops, any RDP client. A client is recorded automatically the first time it connects, as unregistered (no seat, no role). Open it to claim it: bind it to a seat user, assign it a role, and record its peripherals.

• Identity is a management record, not a security control. The client name is what the RDP client reports (it can be renamed) and the IP can change with DHCP. The registry tells you which physical station is which; it does not gate logons. Only accounts created through the console can sign in (see section 0).
• Roles are labels you define (for example Cashier, Ticketing, Booth), each with a peripheral checklist (for example a cashier expects a printer, a cash drawer and a barcode scanner). A client is flagged Needs attention when its role expects a peripheral it does not have, or when a peripheral's driver is marked missing — fix that before the seat goes live. A role cannot be deleted while a client uses it.
• Peripherals are any USB hardware attached to the client, in one of two modes. Dedicated — used by the seat where the device is attached (RemoteFX USB redirection; the vendor driver must be installed on the host). Shared — shared with all seats: for a printer, share it from the host's print server and record the share name; for non-printer devices the sharing mechanism is not defined yet and the console says so. A normal printer uses Easy Print (the Windows default) and usually needs no host-side driver.
• Drivers are installed on the host by hand, then marked installed here with the driver name and version. The console never installs a driver itself.
• Audio: the Device redirection panel on this page shows the host-wide switches (USB allowed, audio playback allowed, microphone off). A client's own audio toggle lives on its detail page and takes effect at the seat user's next sign-in. Honest limit: the per-user audio value is unverified on Windows 10 Pro 22H2 (live check Q9) — until the live test runs, the host-wide switch is the proven control.
• Sessions link back: a session row's client name opens its client record, and a session's details page has an Open client record link. Deleting a client record removes only the record — a later connection from that client records it again as unregistered.

2. Users

Users lists every seat account: username, role, account status, session state, last sign-in (UTC), and restrictions. The header shows total users, enabled users, and administrators.

Creating a user

Users → + Add user. Enter a username (for example Seat1), an optional display name, and a password (minimum 8 characters — the password the user types when connecting). Role is fixed: seat users are always Standard user. The console admin account is separate.

Create users only here — never directly in Windows. An account created directly in Windows is not managed by MultiDeskKore: no seat accounting, no limits, no folder isolation — and only accounts created through the console can sign in, so an account created directly in Windows is stopped at sign-in. The console admin account and BUILTIN\Administrators are exempt. (Accounts created directly in Windows during the early pilot — for example the Stage-A Seat1/Seat2 accounts — are stopped under this rule; create console-managed users instead.) Honest note: the session is ended after the logon/connect event, so an unmanaged user may briefly see the desktop before being logged off; the refusal is recorded in the audit log (action UnmanagedAccountLogoff).

Capabilities — per user

Tick a capability to set it; leave it unticked to leave it off. Values apply at the user's next sign-in.

What is proven and what is not: the settings are stored and applied by the service, but live enforcement of the RAM limit, the disk quota, AppLocker app blocking, and the clipboard/drive toggles has not yet been proven by a recorded test on Windows 10 Pro 22H2. Treat a limit as configured, not as proven, until the live test for it has run. (See the Requirements Matrix.)

Editing, disabling, deleting

• Edit — change display name, password, or any capability. Changes apply at the user's next sign-in.
• Allow remote sign-in — unticking it prevents new connections for that user. The account stays, but any session it has ends and its seat is freed.
• Disable — the account cannot sign in. Disabling frees the seat. Re-enabling an account while the limit is reached is refused with the seat-limit error.
• Delete — removes the account and frees the seat. You are offered the option to also delete the user's workspace files; that cannot be undone.

The Transfer folder

Each user with Transfer enabled gets a personal drop-box under the shared root (<SharedRoot>\Transfer\<username>\). It is the only way users share files: a user drops a file in their Transfer folder and the administrator (or another assigned user) collects it from there. Transfer folders are protected so each user sees only their own. Turning a user's Transfer access off removes their drop-box.

What users can and cannot reach

A seat user can reach only their own workspace folder, plus shared folders assigned to them and their Transfer folder. They cannot open the host's full C: or D: drives. Seat and shared-folder permissions are in place and the service log shows no permission failures after install; the negative test (one seat user attempting another's folder and being refused) is still to run.

3. Host

Host overview shows the engine behind every workspace:

• Live CPU usage, physical memory, and active sessions.
• System information (host details) and Connection & service (the host address, with a Copy address button for giving to users).
• Resource usage charts for the last 30 minutes (CPU and memory).
• A note that appears throughout the console: session capacity depends on workload and host resources.

Desktop background (wallpaper)

The wallpaper set here is shown on every seat user's desktop, and users cannot change it.

• Upload a JPG, PNG, or BMP (up to 5 MB). Uploaded wallpapers are listed and can be activated.
• Rotation: Off, Daily, or Weekly.
• It applies at the user's next sign-in. A user who is already signed in must sign fully out and back in — disconnecting and reconnecting is not enough. (This is the most common wallpaper support call; see Troubleshooting.)

4. Licence

Licence manages activation on this host. It shows:

• Licensed to, Licence ID, Host, Activation date.
• Perpetual licence: Active — the licence itself never expires.
• Upgrades and support: Included until [date] — or, when lapsed, "Upgrades and support expired on [date] — licence still active". These are two separate lines on purpose. A lapsed support period never disables anything and never makes the licence look expired. Until the backend returns a maintenance date with activation, the console shows "No expiry date recorded — the licence itself is perpetual." Absence of a date is "not recorded", never "expired".
• Seat entitlement — how many seats the licence grants.
• Licence key (masked, with a Copy button).

Trial

There is no no-key trial. With no key stored, the Licence page shows "No licence key stored. Enter a trial licence key or a paid licence key." and a Start your free 3-day trial panel with a Get trial key form. Enter your name and the email address you registered and verified with on the MultiDeskKore website; the console asks the TrimKore backend for a trial key for this host and activates it there. The trial key is generated from the console's Licence page and activated there. The installer is not publicly downloadable. The download link is emailed to the registered, verified email address only.

Once activated, the Licence page shows "Trial active, N day(s) remaining — 1 host + 2 remote". The trial lasts exactly 3 days from activation and is fully functional within the host's resources. During the trial at most 2 remote seat accounts can be created, plus the host admin. At expiry a key is required and new users are refused; live sessions are not signed out or disabled. Reinstalling does not restart the trial — the trial activation record survives uninstall. The trial is bound to this host and cannot be refreshed by reinstalling or re-registering. If the host clock is set back, the trial is suspended ("Trial suspended: system clock appears to have been set back… Correct the host clock and restart the service"). A copy of the trial key is emailed once, after activation, for safekeeping only — it is not the delivery mechanism. If a trial key was already issued for your email, or a trial was already activated on this PC, the backend refuses with "already issued" and no second trial is ever issued. A trial key needs the backend — it cannot be issued offline.

Activation and grace

Update activation — paste a licence key (exactly as issued) and activate it. A new key starts in a 14-day activation grace state while the service activates it online; the licence is validated locally by its signature, so the host keeps working. The page shows the grace state and days remaining. After grace expires without activation, new users are refused. A key for a different host (hardware mismatch) is invalid immediately — not a grace case.

Pricing

One seat is one user account on one licensed host.

• 1 seat — $29.99 one-time.
• 5-seat bundle — $99.99 one-time.
• Each additional seat beyond five — $10 one-time.

Buy once. Renew support and upgrades only if you need them.

First 12 months of upgrades and standard support are included with every licence. Optional annual renewal: 10% of the licence value, rounded once to cents — the console computes and shows the renewal price for the current seat count.

Buy seats / Get more seats

Buy seats opens the public buy page (multideskkore.trimkore.com/buy) with a short-lived secure token that identifies this host, plus the licence when one exists, so extra seats are offered at the upgrade price. No hardware ID, host name or licence ID appears in the page address. The buyer gives only an email address — no account, no login. Payment is manual: the button only opens the page. If the hardware ID is unavailable the button is disabled with an explanation instead of guessing.

To add seats, get a new licence key from TrimKore and activate it here — existing users, sessions, and settings are kept.

Move this licence to a new host

If the host is being replaced, Request host transfer files a transfer request with TrimKore (Administrator only to submit). Approving a transfer clears the old hardware binding so the key can activate on the new host. The request needs a stored licence key and an internet connection; offline, it fails with a plain message and nothing is queued. The request is filed through POST /api/host/transfer-request on the TrimKore server (licence key + hardware ID headers); you can check its status in the Licence page, and TrimKore approves it in the owner portal — approval clears the old hardware binding so the key can activate on the new host.

Product licence note

This screen manages the MultiDeskKore licence. Windows and remote-access licensing are managed separately.

5. App controls

App control lives on the Users page, per user (see section 2):

• Allowed apps — an allowlist: only the listed apps may run for that user.
• Denied apps — a deny-list: the listed apps may not run for that user, even though everyone else may. Denied apps are also hidden from that user's Start Menu.

Apps are installed on the host once; "deploying" an app to a user means controlling who can see and run it. The administrator account is never locked out: the allow-all rule for administrators is always first. App changes apply at the user's next sign-in.

Honest limit: AppLocker enforcement on Windows 10 Pro 22H2 has not yet been proven live. If a denied app still runs for a user, report it — the allowlist remains the working control in that case.

6. Admin accounts (roles)

Admin accounts manages console administrators and your own credentials. Roles:

Roles are enforced by the service on every operation; the console only hides actions your role cannot use. The last Administrator cannot be deleted or disabled, and you cannot delete your own account.

My credentials — change your own console username and password (current password required). This is the console admin account, not the Windows Administrator account.

Honest limit: role enforcement is implemented server-side, but no recorded test has yet shown a role denial (for example, a Viewer being refused a user-creation attempt).

7. Support tickets

Support is where you raise tickets with TrimKore from the console. Tickets are answered by TrimKore in the owner portal, and replies appear in the thread in the console.

• New ticket — subject and message. Tickets are authenticated with this host's licence key and hardware ID. With no licence key stored, tickets cannot be sent yet.
• My tickets — list with status and last-updated time. Open one to see the thread and replies. Replies are checked every 30 seconds while the Support page is open.
• Offline: if the host has no internet, the page shows the banner "Cannot reach the server — check the host's internet connection." Sending fails with the same clear message — not a silent failure and not a fake success. Nothing is queued.

Honest limit: the live round-trip (send a ticket, reply in the portal, reply appears in the console) has never run — the pilot VM has no internet. The offline path is the behaviour you will see in the VM.

8. Audit Log

Audit Log records activity on the host: user, session, licence, admin, wallpaper, ticket, and transfer operations, with time (UTC), event, actor, target, result, and details. It has search, an event type filter, and Export CSV.

Honest limit: the log is implemented and the console shows it, but no recorded test has yet confirmed an entry appears for each operation, or that the CSV export matches the on-screen log.

9. Help

Help in the console navigation opens this documentation — the six manuals — served from the console itself, so it works offline. The same pages are downloadable as PDFs from the Help section:

• Quick Start Guide (PDF) — the short path, on its own.
• Full Manuals (PDF) — all six manuals in one document.

The Markdown files in Docs/ are the canonical source. The website Documentation page renders the same files — nothing in the console Help contradicts them.

MultiDeskKore V1 · by TrimKore · trimkore.com Tested configuration: Windows 10 Pro 22H2. No customer login exists; the customer uses only the local console.

MultiDeskKore — End-User Guide

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

This guide is for the person using a MultiDeskKore seat — the user connecting to a desktop on the shared host. If you administer the host, see the Administrator Guide instead.

1. What you get

Your administrator has created an account for you on a shared host computer. One seat is one user account on one licensed host: your seat is your account. When you connect, you get your own Windows desktop running on that host — your own apps, your own files, your own settings — while other users have their own separate desktops on the same host at the same time.

You need:

• A device with a display, keyboard, and mouse.
• A Remote Desktop client (Windows Remote Desktop Connection, or any compatible RDP client).
• The host address, your username, and your password — all from your administrator.

2. Connecting

From a Windows PC

1. Open Remote Desktop Connection (mstsc).
2. Computer: the host address your administrator gave you.
3. Click Connect, then sign in with the username and password your administrator created for you.
4. Your desktop opens. The first sign-in takes a little longer while Windows prepares your profile.

From a thin client

Use the thin client's Remote Desktop client the same way: host address, then your username and password. Your administrator will show you where those go on your device.

If the sign-in fails

• Check the username and password carefully — passwords are case-sensitive. If you are unsure, ask your administrator; they can reset your password from the console.
• If the host address does not respond at all, the host may be off or the network may be down — tell your administrator.
• If your account was created directly in Windows instead of in the console, sign-in is stopped — only accounts created through the console can sign in. Ask your administrator to create your account in the console.

3. What you see

• A normal Windows desktop, with the wallpaper your administrator chose. You cannot change the wallpaper.
• Your own files in your own workspace folder.
• The apps your administrator has made available to you. Some apps may be hidden from your Start Menu if your administrator has not allowed them for you — that is by design, not a fault.
• A Transfer folder: the place to put files you want to share with the administrator or another user. It is the only way to share files — see section 5.

4. Signing out vs disconnecting

This is the most important difference to understand.

⚠ Disconnecting does not free your seat — and neither does signing out.

Closing the Remote Desktop window only disconnects — your session keeps running on the host, with your apps open, until you sign out. Only Sign out (Start → your user icon → Sign out, inside your desktop) ends your session. Neither frees your seat: your seat belongs to your account, and only your administrator disabling or deleting your account frees it for someone else. If you cannot sign out yourself, ask your administrator: they can sign your disconnected session out (Kick) from the console, which ends the session at once.

Rule of thumb: disconnect when you are coming back later today and want your work waiting for you. Sign out when you are finished for the day, or when your administrator asks you to (for example, after they change your apps or wallpaper — those changes apply at your next sign-in, and signing out is what starts a fresh sign-in).

5. What you can and cannot do

You can:

• Use the apps your administrator has allowed for you.
• Save files in your own workspace folder.
• Share a file by putting it in your Transfer folder.
• Copy and paste between your session and your own device, if your administrator has left clipboard redirection on.
• Use your own device's drives inside the session, if your administrator has left drive redirection on.

You cannot:

• Open the host's full C: or D: drives. You can reach only your own folders, shared folders assigned to you, and your Transfer folder.
• Open another user's folders.
• Change the desktop wallpaper.
• Install software for everyone, or change settings that affect other users. (What you can install for yourself depends on how your administrator set up your account — ask them.)
• Create new user accounts. Accounts are created only by the administrator, in the console.

6. Sharing files — the Transfer folder

To share a file with the administrator or another user:

1. Put the file in your Transfer folder.
2. Tell the person it is there.

That is the only way to share files between users. Do not try to reach another user's folders directly — you cannot, and that is intentional.

7. Getting help

If something is not working — you cannot connect, an app will not open, a file is missing — tell your administrator. They can see your session in the console, and if they need to look at your screen to help you, they will ask your permission first: screen assistance always asks you before anyone can watch or control your desktop.

MultiDeskKore V1 · by TrimKore · trimkore.com

MultiDeskKore — Troubleshooting

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

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:

1. 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.
2. 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.
3. Is the password right? Passwords are case-sensitive. The administrator can reset the user's password from the Users page.
4. 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.)
5. 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.
6. 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

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)

1. 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.
2. 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.
3. 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.
4. The administrator account is never locked out by app rules — the allow-all rule for administrators is always first.
5. 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)

1. Tickets need a licence key stored. With no key stored, the console says tickets cannot be sent yet. Activate a key first.
2. 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.
3. 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.
4. 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

1. Run MultiDeskKoreSetup.exe verify on the host and note any check that is not PASS.
2. In the console, check the Audit Log for the operation that failed (search by user or event type).
3. 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.