why is assigned_to field on cmdb_sam_sw_install is empty?

[pavan Punna]

I have over 5 million software installs where assigned_to field is empty most of them are serves like ESX, Linux, AIX and some are computer systems, Ip routers , IBM Frame. Whereas, some computer systems, linux servers, network gear, windows servers have assigned to. Can we expect all the serves to have assigned_to and i know this data is not coming from CMDB. How this can be handled in sam for license calculations without assigned_to?

[Naveen20]

Should all servers have assigned_to?

Not necessarily. It's common for servers — especially ESX hosts, AIX LPARs, Linux VMs, IBM Frames, IP routers, and network gear — to lack an assigned_to value. The reason is that assigned_to on a CI typically represents an individual user or owner, which makes sense for endpoints (laptops, desktops) but not for shared infrastructure. Servers are usually "owned" by a team or business unit, not a single person. So the absence of assigned_to on server CIs is expected behavior, not a data quality gap per se.

That said, CIs that represent user-facing machines (Windows desktops, some Windows servers used as terminal servers) would ideally have assigned_to populated.

Where does this data come from?

The assigned_to on cmdb_ci is typically populated by Discovery, SCCM/Intune imports, or LDAP-based reconciliation. For servers, Discovery often doesn't set assigned_to because there's no single "logged-in user" concept the way there is for endpoints. So it's not a bug — it's by design.

How SAM handles license calculations without assigned_to

This depends on the license metric (entitlement type) you're reconciling against:

1. Device-based metrics (per server, per install, per instance) — assigned_to is irrelevant. SAM counts the number of installs or CIs, not users. Most server software (Oracle DB, SQL Server, VMware, IBM middleware) is licensed this way. The reconciliation engine on sam_sw_license_calculation matches installs to entitlements by device count, so empty assigned_to has zero impact.

2. Processor/core-based metrics (per core, per processor, PVU) — Again, assigned_to doesn't matter. SAM looks at the CI's core/processor attributes from cmdb_ci_server or cmdb_ci_computer to calculate consumption. This is the typical metric for enterprise server software.

3. User-based metrics (per named user, per concurrent user) — This is where assigned_to matters. If the license metric is "named user" and there's no assigned_to, SAM can't attribute the install to a user, and the install may show up as unallocated or create a compliance gap. However, for servers, user-based licensing is uncommon (except for things like CALs or specific database named-user licenses).

Practical approaches to handle this:

• For server software — make sure your entitlements in sam_sw_entitlement use the correct metric type (device, core, processor). If they do, empty assigned_to won't affect compliance position at all.

• For user-based licenses on servers — consider using the managed_by or support_group fields on the CI as a proxy, or use SAM's allocation features to manually or programmatically assign licenses. You can also populate assigned_to on the software install record (cmdb_sam_sw_install) itself rather than relying on the CI's assigned_to.

• For reporting/filtering — if you need to exclude unmanaged or orphaned installs from calculations, you can use install filters or exclusion rules in SAM to scope out CIs that are decommissioned, out of scope, or infrastructure-only.

• Reconciliation rules — in SAM Pro's license calculation engine, you can customize how installs are counted. The sam_sw_reclamation and normalization rules let you handle edge cases where installs exist on CIs without user attribution.

The bottom line: for the vast majority of server software, assigned_to is not a factor in license math. Focus on ensuring your entitlement metric types are correct and that your CI attributes (cores, processors, OS) are accurate — that's what drives server license compliance in SAM.