Looks like content was released to the Vulnerability Reporting site, The Analysis there will not activate and has this error 
Yes @jojo that looks like a problem with our publishâŚmy console now has two copies of the âVulnerability Reportingâ site again.
I think weâre going to need to make a change on our end, and then youâll likely need to delete one of the duplicated âvulnerability reportingâ sites in your console as well. Itâll be difficult to tell which copy you should remove though until we publish the next version. We have that in-work now.
@jojo do you see two copies of the âVulnerability Reportingâ site in your Console?
If so, please delete whichever one has the older site version. The latest site we just published is version 26, and should only update on the âgoodâ copy of your Vulnerability Reporting site.
Thanks Jason, I was able to do this last night. Thanks again
1 Like
I am seeing the same thing today. I had 2 sites originally, one had the fixlets but wouldnât allow me to assign any computer subscriptions to it and the other didnât have any fixlets but had all computers subscribed. I ended up deleting both of them and then resubscribing to the site. Now I have version 26 but still getting the error described earlier.
I think you should open a Support Incident so we can look at whatâs going on in your console. Iâm not seeing that behavior in mine, I was able to activate the analysis on each of my demo systems once I got rid of the duplicate site.
I donât see why restarting the Console would be necessary, but maybe worth a try?
We have several instances of BigFix Compliance installed and our nightly imports started failing last night in each one. We also have two instances of the Vulnerability Reporting site in each BigFix instance, and both are version 26. On one we could subscribe computers and one we could not, so we deleted the one where we could not subscribe computers.
The imports still fail so we deleted both of the sites to verify the imports in Compliance then worked. We have re-added the Vul Reporting site and had two again, deleted one, but our imports are failing.
It seems that adding the Vulnerability Reporting site caused our Compliance imports to fail. Has anyone else seen an error with their Compliance imports failing?
We also have another BigFix instance where the Vul Reporting site is still version 5 and trying to gather it did not update it for some reason. In that one our nightly Compliance import is still working.
I wanted to add that this is where our import errors start in Compliance and reference a duplicate key in Vulnerability Reporting:
2022-11-03 05:06:37 (+0:00:00.656) ERROR: File excluded_sites.json was not found on BES Server
2022-11-03 05:08:59 (+0:02:22.108) ERROR: SQL: {call [dbo].etl_raw_datasource_analyses}
2022-11-03 05:08:59 (+0:00:00.000) ERROR: Batch execution error:
2022-11-03 05:08:59 (+0:00:00.000) INFO: ETL Datasource task: from Lab Compliance - RawDatasourceAnalysis (0x00000000614AA173 - 0x000000006164B8FB): Failed
2022-11-03 05:09:00 (+0:00:00.219) ERROR: Sequel::UniqueConstraintViolation: Java::JavaSql::BatchUpdateException: Cannot insert duplicate key row in object âdbo.raw_datasource_analyses_etl_changesâ with unique index âraw_datasource_analyses_etl_changes_datasource_id_sitename_id_indexâ. The duplicate key value is (1, Vulnerability Reporting__26, 1001).
com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeBatch(com/microsoft/sqlserver/jdbc/SQLServerPreparedStatement.java:1870)
java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:508)
org.jruby.javasupport.JavaMethod.invokeDirectWithExceptionHandling(org/jruby/javasupport/JavaMethod.java:441)
org.jruby.javasupport.JavaMethod.invokeDirect(org/jruby/javasupport/JavaMethod.java:305)
Do you have a support ticket open? I think you should open one so we can look at your system more closely
We do not have a support ticket open yet but will work on that next. Thanks.
For an update for anyone else with the same issue, we were able to fix our problem with the Vulnerability Reporting site by going into SQL. We used the steps at the end of this thread to delete the SiteID=15727 that we had in addition to the 15733 for the Vulnerability Reporting site.