0

MA Connector Errors Drill-down reporting capability

Bob Bradley 4 weeks ago in MIM Health Check • updated 3 weeks ago 3
Topic collaborators

As part of a recent engagement at a customer, where consolidated reports of all export and import (sync) errors per MIM connector were required to support a MIM sync config deployment, a new script MIMErrors.ps1 has been developed to run selected SQL reports from a library AllSQL.xml.  A separate HTML application (MIMErrors.hta) has always allowed these reports to be run interactively, displaying the results in an HTML table.  However the script version was required for the customer due to problems running an HTA on their host.  I have checked the above files into a new subfolder in the UNIFY Solutions.Tools repository.

As a result of this development, the script could now be adapted for inclusion in the Run-HealthCheck.ps1 scheduled task ... either as a custom extension or as a standard option with the -FIMSync switch, and generate JSON data instead of HTML files, for consumption in OMS/PowerBI.  These could then be used to drive new reports, including 2 specific ones (ExportErrors and ImportErrors) to support drill-down capability for the existing MA Connector Errors report.

Some things to consider:

  • Frequency - at least two customers run the healthcheck report hourly, and this may be overkill ... a separate suggestion is being made to support the running of this script at different frequencies for different switches
  • Security - a check would need to be made before implementing a report that identified individual CS/MV objects to make sure that this isn't in violation of any security constraints that need to be observed for each specific customer
  • Approach - SQL may not be the best way of retrieving the data, e.g use of the https://github.com/lithnet/miis-powershell PS module may be preferable in an architectural sense because the FIMSynchronizationService database is not strictly designed as a reporting source and is prone to locking if queries are not constructed explicitly to avoid this possibility.
  • Target audience - this would generally only be for SD resources who need to be able troubleshoot specific issues without needing to VPN to the customer site to investigate
+1

Not answering the actual question, but ideally all telemetry should be sent as close to real time as possible. I think for the MIM Health Check product, development efforts should be around getting the telemetry as close to real time as possible. That way you use the operational intelligence platform for filtering, which it is good at, instead of product logs, which are not so good at it.

I agree @Shane - which is why I am looking into getting this working now: https://voice.unifysolutions.net/communities/5/topics/3549-powershell-logging