Reallocating After Disposal
When a machine is decommissioned, the licenses it was using become available for other consumptions. This page covers what the engine does automatically and what you may need to do manually.
What Happens When You Dispose an Asset
When you mark an asset as disposed in xAssets:
- The asset's status changes to Disposed (StatusID = 6) and
DateDisposedOfis set. - On the next calculation, the engine sees the disposal date on the asset.
- Consumptions for that asset are end-dated (a reversal is posted with apply date = the disposal date).
- Grants for those consumptions are also reversed.
- The license capacity that was used by the disposed asset is freed.
- The freed capacity is available for affinity-based allocation to other consumptions.
This happens automatically — you do not need to manually unassign licenses from disposed assets for the capacity to be freed.
DateOutOfService vs DateDisposedOf
These two date fields look similar but behave very differently in the SAM calculation:
| Field | Asset Status | Engine Behavior |
|---|---|---|
DateDisposedOf (set via Bulk Disposal or Dispose menu) |
StatusID changes to 6 (Disposed) | Consumption ends on the disposal date; capacity is freed |
DateOutOfService (set on the asset record directly) |
StatusID stays 2 (In Service) | No effect on consumption. The install is still counted as licensable for as long as the AssetDetailSoftware row exists |
The reasoning behind the asymmetry:
- DateDisposedOf marks an asset as permanently retired. The software install goes with it — the box is gone, so the entitlement requirement ends. This is the standard disposal path and the correct choice for a sold, scrapped, or decommissioned machine.
- DateOutOfService typically means "this asset is in storage / temporarily switched off / put aside". Software vendors don't care that a licensed machine is sitting in a cupboard — the install is still on the hardware and the entitlement is still required until the install is uninstalled or the asset is actually disposed of. So SAM does not end consumption when
DateOutOfServiceis set.
If you actually want SAM to stop counting an install — for example because the software has been uninstalled, or because the asset is genuinely retired — use one of these instead:
- Dispose the asset (sets
DateDisposedOfand StatusID = 6). - Remove the software from the asset's
AssetDetailSoftware(uninstall recorded by discovery, or removed manually).
DateOutOfService remains useful as an asset-management flag (it appears on reports and is honoured by other parts of the system, including for licence assets — see the licence side under Software Licenses: License Status Codes). It just doesn't drive SAM consumption end-dating.
Direct-Assigned Licenses on Disposed Assets
The exception: licenses that were directly assigned to the disposed asset still have the assignment record. The grant is reversed (because the consumption ended) but the assignment relationship remains. This is technically an inactive direct assignment.
Best practice: when you dispose an asset, also remove its direct license assignments. The cleanup steps:
- Find direct assignments for the disposed asset.
- Open each license; remove the asset from Related Assets.
- Recalculate.
For bulk cleanup, the Manage Duplicates menu category and asset-deletion workflows can help — see the IT Asset Management Guide for asset disposal procedures.
Stale Direct Assignments
A common reason license capacity feels "stuck" is stale direct assignments to long-disposed assets.
To find them, build an xAssets query that joins Software License records to their related-asset dependencies, filtered to where the related asset has a Date Disposed Of value. Sort by disposal date so the longest-stale assignments come first. See Daily Tasks: License Reclaim for the recommended save-as name and quarterly cadence.
Each row is a direct assignment to a disposed asset. Remove the assignment from the license's Related Assets tab to free the capacity.
Replacement Workflow
When an asset is replaced (not just retired), the typical pattern:
- Discover and onboard the replacement asset.
- Confirm consumptions are posted for the replacement.
- Dispose the old asset.
- Recalculate.
The engine reallocates from the old asset's licenses to the replacement automatically (because the same custodian/department/location combination still has consumption). For directly-assigned licenses, also move the direct assignment from old to new.
When the Engine Won't Reallocate
A few cases where you might expect reallocation and not see it:
- The replacement asset has different attributes — different department, location, custodian. Affinity may now favor a different license. This is the expected behaviour.
- The license has an end date that has passed — the license is no longer In Service for the new period. Update or replace it.
- The replacement asset has no consumption — discovery has not yet found the product on it. Wait for the next discovery, or check that recognition is working.
Verifying Reclaim
After disposal and recalculation:
- Open the licenses that previously covered the disposed asset.
- Confirm the Allocated count has decreased by the disposed asset's seat count.
- Confirm the Outstanding Requirement on the relevant products has decreased (if there were deficit consumptions waiting for capacity).
If the Allocated count has not changed, the reversal did not happen — most likely the asset is not actually marked Disposed, or the calculation has not yet been run.
Related Reading
- Direct Assignment — what to clean up manually
- Daily Tasks: License Reclaim — proactive reclaim workflow
- Concepts: Consumption, Grant, and Reversal — how reversals work