MAP 9.1 - Inventory is scanned but failed during Assessment, Duplicate Primary Key RRS feed

  • Question

  • Hi MAP team, saw the similar thread but didn't want to hijack it if it's a different root cause.

    We have a client using MAP for data collection that is having failures with generating the assessment. In the MAPToolkitLog, we get this:

    “Microsoft.AssessmentPlatform.MapException: Caught SqlException running the stored procedure [WinClient_Assessment].[LicensingAssessmentProc]. ---> System.Data.SqlClient.SqlException: Violation of PRIMARY KEY constraint 'LicensingAssessment_pk'. Cannot insert duplicate key in object 'WinClient_Assessment.LicensingAssessment'. The duplicate key value is (4d74950a-3c31-4b7e-9464-12fd8ae03942).”

    Tracing it down it looks like there are two entries for a DeviceNumber under Win_Inventory.SoftwareLicensingProducts, with these two descriptions: “Windows Operating System - Windows(R) 7, RETAIL channel”, and “Windows Operating System - Windows(R) 7, OEM_SLP channel”. So two lines are trying to get created for an OEM and a RETAIL line in the LicensingAssessmentProc, causing a duplicate PRIMARY KEY and hence the issue with the assessment. Is this an existing bug and if so is there a quick way to resolve it so we can conduct the assessments? The issue is that we cannot run additional scans to improve coverage as it wants us to refresh the assessment before letting us run another scan.

    Thank you,


    Friday, November 7, 2014 9:57 PM

All replies

  • Following up on this, digging into the data it looks like "Windows(R) 7, OCUR add-on for Ultimate,HomePremium,Enterprise,Professional,ServerHomePremium,Embedded" is getting flagged as an OS and being included in the Win_Inventory.SoftwareLicensingProducts, conflicting with the actual OS line. When I deleted those rows the duplicate primary key issue was resolved and we were able to process assessments. Not sure if we can run additional scans on that database, will check soon.

    This is a pretty inconvenient way to get around this bug however, can this be addressed without having to delete SQL rows, or is this an edge case that needs to be caught in the filtering in the next release?

    Tuesday, November 11, 2014 8:33 PM