Recovering an RD Licensing Server to Different Hardware (Without Calling Microsoft)

I recently had to move an RDS License Server role off a box that was stuck in a recovery environment, onto an existing server with a completely different name. Here's what I learned, including the dead ends, because the "official" way Microsoft documents this is not actually a migration.

The Problem

Server had RD Licensing installed with several CAL key packs (2012, 2016, 2019, 2022 — a mix of Volume License and Built-in OverUse packs). The source box was only reachable in a backup/recovery environment — not production, and not coming back online long-term. I needed those CALs working on a different, already-existing server.

Dead End #1: "Migrate licenses from another server to this one"

RD Licensing Manager has a wizard for this. It sounds like it should just move the database over. It doesn't.

You point it at the old server name, then it asks for the license/keypack numbers, which kicks you into the same "Manage Licenses Wizard" used for installing brand new CALs. That wizard wants:

• The License Program the CALs were originally purchased under (Open License, Select License, Enterprise Agreement, Select Plus, etc.)
• An Authorization number and License number (for Open License) or the equivalent agreement number for whatever program applies

In other words: "migrate" here means revoke the old activation and re-activate from scratch through the Microsoft Clearinghouse, using the exact same purchase info the original admin used years ago. If you don't have that paperwork sitting around (we didn't), you're stuck either digging through old invoices or calling Microsoft's Licensing Activation Center and giving them your old server's License Server ID (visible under server Properties in RD Licensing Manager) so they can look up the agreement on their end.

This is a legitimate path if you have no other option, but it's not fast and it's not really a "migration."

Dead End #2 (Partial): Registry Certificate Copy

I went looking for a registry-based trick to fix a server-name mismatch, based on the assumption that the license server's identity lives partly in the registry (like the RDSH role's Terminal Server\RCM\Licensing Core key does). That key doesn't exist for the licensing service — I was thinking of the wrong role. Lesson: RD Licensing's state appears to live entirely in its own database, not scattered registry keys shared with RDSH.

What Actually Worked

The RD Licensing database is an ESE (Extensible Storage Engine) database that lives at:

%systemroot%\System32\lserver

Since I had the old server's files available (via the backup environment), the fix was:

1. Stop the "Remote Desktop Licensing" (TermServLicensing) service on the destination server.
2. Copy the entire lserver folder from the old server over the destination server's lserver folder.
3. Start the service back up.

That's it. No Clearinghouse call, no re-entering License Program or Authorization numbers, despite the destination server having a completely different name than the original. RD Licensing Manager came up showing every key pack from the old server — same Keypack IDs, same issued counts — now sitting under the new server name.

The Gotcha: Permissions

After the copy, the service failed to start. No useful error in the GUI — it just looked like it silently kept trying and failing, which reads exactly like a permissions problem. It was: the copied folder kept the old server's ACLs, and the NETWORK SERVICE account the licensing service runs as couldn't touch the files on the new box.

Fix:

icacls "C:\Windows\System32\lserver" /reset /T
icacls "C:\Windows\System32\lserver" /grant "NT AUTHORITY\NETWORK SERVICE:(OI)(CI)F" /T
icacls "C:\Windows\System32\lserver" /grant "SYSTEM:(OI)(CI)F" /T
icacls "C:\Windows\System32\lserver" /grant "Administrators:(OI)(CI)F" /T

Then net start TermServLicensing again. It came up clean.

One more note if the service ever gets stuck in a "stopping" state instead of failing outright: TermServLicensing runs inside a shared svchost.exe process, so don't kill svchost.exe blind — you'll take out whatever else shares that process. Check what's riding along first:

tasklist /svc | findstr /i termserv

If it's alone (or only sharing with stuff you don't care about) in that PID, taskkill /PID <pid> /F is safe. Otherwise, a reboot is the cleaner fix.

Takeaways

• The "Migrate licenses" wizard in RD Licensing Manager is not a database migration. It's a guided reactivation that still needs your original purchase info.
• The real migration path is a file copy: back up %windir%\System32\lserver as part of your normal server backups. If you'd had that, this whole exercise is a five-minute copy instead of an afternoon of registry archaeology and Microsoft phone calls.
• Server name mismatch didn't block the restore in my case, but treat that as a bonus, not a guarantee. Where possible, keep the destination server name matching if you're doing this on purpose.
• If the service won't start after a restore, check permissions before you assume the database is corrupt. ACLs don't survive a file copy across servers.
• Decommission the old license server for real once the new one is confirmed working — two live license servers claiming the same key packs is asking for trouble.