The licence is the cheap part of a 200-seat rollout

from Stardock Forums

We are evaluating Start11 and Fences for about 200 seats, and the per-seat price has been the least interesting number in the whole exercise.

The cost is everything around it. Who owns a key when the person leaves. Whether a reimaged machine counts twice. Whether it goes out through the deployment tooling we already run, or somebody touches 200 desks. That last one decides whether this is a Tuesday or a project with a name on it.

So my position is one finance does not love. I would rather pay more per seat for something that installs quietly and reports its own licence state than take the cheaper line item and absorb the admin. We have taken the cheaper line item before. It did not stay cheaper.

The fair objection is that these are quality-of-life tools and nobody should be spending project hours on them at all. I agree in principle. In practice someone hands you 200 seats of it and the hours happen whether or not anyone budgeted them.

business Answered
396 views 3 replies
Reply #2 from Stardock Forums Top
Answer

Pricing goes through sales. The operational half you are worried about is already settled, which should make that conversation a lot shorter.

On key ownership, a rollout your size would be a single key with multiple activations, and the key belongs to the account it is activated under rather than to a person. The thing to get right on day one is the email address, because the first activation ties the key to that address permanently. Use a generic one, [email protected] or similar, not a named admin.

Activating a company key under someone's work address is exactly the failure you are anticipating, and it is unpleasant to unwind after they have gone.

On reimaging, the image has to be unactivated and activation happens on the destination machine. Pre-activating into a golden image does not survive, the license.sig it writes under ProgramData gets overwritten by the deployment.

A reimage only counts twice if the old activation is never released. Deactivating before you wipe frees the seat, and when a machine is gone before anyone thought about it you can release that activation from the account page instead.

On deployment, it goes out through what you already run. The installer takes /s, plus /noreboot if you are controlling restarts, and activation is a separate command line step after it.

Three things that catch people on the first wave. The activation window and the app UI still open after a silent install, so the script needs a taskkill between the install and the activation step. The installer returns 9 for a successful upgrade, so set your tool to treat 0 and 9 both as success or every upgrade will report as failed. And the activation command wants -company="Stardock" literally, not your company name, which is the single most common reason a scripted activation fails.

On the part you said you would pay extra for, the licence state is a file. A successful activation writes license.sig into ProgramData\Stardock under the product name, and that is what Intune detection rules key on, so your tooling can report activation status across the estate without anyone touching a desk.

Jump to answer in thread
Reply #1 from Stardock Forums Top

Hello,

Appreciate your interest in Start11 and Fences. You’ve raised some very valid points about the hidden costs of large-scale rollouts, licensing logistics, deployment tooling, and the admin overhead that often outweighs the per-seat price. Those considerations definitely matter when evaluating tools like these.

It is best to refer to the Stardock Corporate Sales here:  https://stardock.atlassian.net/servicedesk/customer/portal/79. Use those link to get more information.

Thank you,

Basj,

Stardock Community Assistant

Reply #2 from Stardock Forums Top
Answer

Pricing goes through sales. The operational half you are worried about is already settled, which should make that conversation a lot shorter.

On key ownership, a rollout your size would be a single key with multiple activations, and the key belongs to the account it is activated under rather than to a person. The thing to get right on day one is the email address, because the first activation ties the key to that address permanently. Use a generic one, [email protected] or similar, not a named admin.

Activating a company key under someone's work address is exactly the failure you are anticipating, and it is unpleasant to unwind after they have gone.

On reimaging, the image has to be unactivated and activation happens on the destination machine. Pre-activating into a golden image does not survive, the license.sig it writes under ProgramData gets overwritten by the deployment.

A reimage only counts twice if the old activation is never released. Deactivating before you wipe frees the seat, and when a machine is gone before anyone thought about it you can release that activation from the account page instead.

On deployment, it goes out through what you already run. The installer takes /s, plus /noreboot if you are controlling restarts, and activation is a separate command line step after it.

Three things that catch people on the first wave. The activation window and the app UI still open after a silent install, so the script needs a taskkill between the install and the activation step. The installer returns 9 for a successful upgrade, so set your tool to treat 0 and 9 both as success or every upgrade will report as failed. And the activation command wants -company="Stardock" literally, not your company name, which is the single most common reason a scripted activation fails.

On the part you said you would pay extra for, the licence state is a file. A successful activation writes license.sig into ProgramData\Stardock under the product name, and that is what Intune detection rules key on, so your tooling can report activation status across the estate without anyone touching a desk.

Sins of a Solar Empire II
Reply #3 from Stardock Forums Top

That settles the operational half, and one item in it changes my plan today.

The first activation binding the key to an email address permanently is the thing I would have got wrong. My instinct was to activate under my own account, because I'd be the one running it, which hands my successor a problem on the way out. A licensing mailbox costs nothing to stand up before we've bought anything, so it goes in as a prerequisite.

The detection file is the part I said I'd pay extra for, and it turns out I don't have to. I'll confirm the switches against our own build before I script anything. Worth saying though: none of that was pricing-sensitive, and I got it because I happened to ask where someone knowledgeable was reading. Basj routed me correctly, but an evaluator shouldn't need a sales ticket open to learn how the licensing behaves.