What does day-2 operation of the RDS estate actually consist of?

Session-broker management of concurrent Tally Virtual User licenses through peak hours via custom timeout policies, the win-acme 60-day certificate renewal binding all four RDS roles, and watching the single Ubuntu connector host — the routine, not the rescue.

How are concurrent Tally licenses managed at peak hours?

Custom session-timeout policies through the RDS connection broker govern concurrent Tally Virtual User licenses; session exhaustion at peak is handled by those timeout policies rather than by adding licenses.

What recurs on a schedule after cutover?

The Let's Encrypt 60-day renewal via win-acme DNS-01 plus the four-role PowerShell binding script — the same pipeline from the binding guide, now as routine instead of incident response.

What day-2 topics does this post not cover?

CAL licensing math, roaming profiles or FSLogix, and branch-printer redirection — none of those facts exist in the repo, so they are named as gaps rather than invented. What is here is what the case and binding guide commit.

Tally Prime on RDS RemoteApp: The Day-2 Shape (Sessions, Licenses, Certificates)

The RDS migration case ends with access restored, the binding guide extracts the certificate fix, and the intake checklist turns the scars into a buying process. None of them says what Tuesday looks like. This is that post: the routine that keeps the estate up after the heroic weekend fades, built only from what the case commits.

Sessions: the license governor

The unified-infra case states it in the architecture table: the session broker “manages concurrent TVU licenses”. Tally Virtual User licenses, the concurrency unit the whole ERP serving model turns on. The mechanism is custom session-timeout policies, with idle sessions reclaimed so peak retail hours never exhaust the pool.

The RDS case’s operations section confirms the steady state: “RDS session exhaustion at peak hours is handled by the connection-broker timeout policies.” Handled by policy rather than by a human, in other words. The policy is the operations runbook for the commonest day-2 event, already written into the broker. Lunch-rush invoice wave hits, sessions pile up, and the timeout policy sheds the idle ones before the license count becomes the outage.

Certificates: the 60-day heartbeat

The second day-2 rhythm is the renewal cycle from the binding guide: win-acme DNS-01 via Cloudflare, forced PrivateKeyExportable, four Set-RDCertificate lines across RDRedirector, RDPublishing, RDWebAccess, and RDGateway. Every 60 days, automatically. The RDS case’s operations section frames the verification discipline: “the final-binding screenshot is the verification — checked after each renewal rather than assumed.”

Cutover night made this pipeline incident response. Day 2 makes it calendar: the renewal fires, the script binds, somebody checks the Gateway cert instead of assuming. The binding guide’s honest limitation travels with it. A failed renewal that leaves the old cert expiring has no documented page path, so the check-after-renewal is load-bearing rather than ceremonial.

The connector: the one box that can end you

The estate’s single Ubuntu 24.04 connector VM on the Hyper-V host carries every branch’s path, and the case’s retrospective says so plainly: “a single point of failure wearing a Zero Trust badge.” Day 2 means that box is the first health check. Its outbound TLS heartbeat is one of two things in the estate allowed to phone home (the other is the renewal). Its death takes every branch offline. The unbuilt second connector on a different Hyper-V host remains the cheapest resilience purchase available. Named in the case, still unbuilt here, and I feel worse about that line every time I re-read it.

The people rhythm

Day 2 is staff as well as systems. The 10-years post Lesson 1 is the people-side record: 47 staff, champions per department, one-branch-at-a-time rollouts, two weeks of parallel running. The RDS estate streams Tally Prime as a RemoteApp window (“branches get an app window, not a server to nurse” per the stack note), and that simplicity keeps the people rhythm sustainable: the app surface staff touch never changed shape, only the path underneath it did.

Grounded vs omitted

Grounded in committed sources: session-broker TVU management and timeout policies (unified-infra case architecture table plus RDS case operations), the 60-day renewal pipeline and four-role binding (binding guide plus RDS case), the single-connector risk (RDS case retrospective), the people rhythm (10-years Lesson 1), the app-window framing (windows-server-rds stack note). Deliberately omitted: CAL licensing math, roaming profiles or FSLogix design, branch-printer redirection specifics. None exist anywhere in the repo (grep across about, uses, and both cases returns nothing), so they are gaps rather than sections. A follow-on engagement would scope those first; this post does not pretend they are solved.

Honest limitations

No new infra claims. Every operational fact here is restated from the case and guide, reframed as routine — the post adds the day-2 lens, not new evidence.
The renewal-alerting gap is still open. No page path on failed renewal exists in the repo; the manual check carries it until somebody builds the alert.
One connector, still. The retrospective’s cheapest fix is still a paragraph, not a VM.

Rescue stories prove you can land the plane. This rhythm proves you can keep flying it, and clients shopping for an operator read day-2 text for exactly that signal. The intake checklist asks for five outputs before a sketch; this post is what the sketch promises to become.