New Custom Reports for QMMAD using different matching attribute (extension4)

I'm surprised that this question hasn't come up many times.

We are using extensionattribute4 as our matching attribute for contacts/groups/users which is totally supported within QMMAD. However we find ourselves when using enterprise reporter unable modify the default report within ER to use this different attribute as it seems that the report is hardcoded to use extensionattribute15. 

What im looking for is either 3xcustom reports using extensionattribute4 for groups/users/contacts

Or

The default reports modified in a way that the matching attribute can be updated.

Parents
  • Hi Graham,

    Yes this issue has come up numerous times. There are two issues related to these reports. First they were created some time ago and use the default attribute that QMMAD was using which is hard coded into the SQL query of the report. The second is that the Active Directory discovery is also hard coded for the single default attribute.

    I have worked with a person from Support last year and came up with a work around for the QMM Matching Users report. This work around was tested in my labs and by the Support person and further in a customers environment. I will put something together and get it to you in about an hour. This work around should also work with the QMM Matching Groups report, I believed, as I remember doing a quick test with it for that report last year.

    Note that it is not a simple change to the report as you will see when you get the info.

    Regards,
    Clarence

  • Clarence, any help would be greatly appreciated. Given my lack of knowledge of sql I initially tried adding the attribute as a discovered attribute in ER config and then tried to alter the report query. Basically wherever I found “15” I replaced with “4” which didn’t work.

    My goal is basically to try and get an understanding of all matched users / groups given a lot of time has elapsed since prestaging users.


    There are various ways I’ve found which aren’t the most elegant. 

    1. You can export data from RUM console against all migration tasks and export to csv.

    2. You can trawl the ADAM dB 

    3. I can check that extension4 exists In target, However given I’m migrating into a large environment there is nothing to say extension4 isn’t used on other objects and don’t feel it a robust query.

    Rgs

Reply
  • Clarence, any help would be greatly appreciated. Given my lack of knowledge of sql I initially tried adding the attribute as a discovered attribute in ER config and then tried to alter the report query. Basically wherever I found “15” I replaced with “4” which didn’t work.

    My goal is basically to try and get an understanding of all matched users / groups given a lot of time has elapsed since prestaging users.


    There are various ways I’ve found which aren’t the most elegant. 

    1. You can export data from RUM console against all migration tasks and export to csv.

    2. You can trawl the ADAM dB 

    3. I can check that extension4 exists In target, However given I’m migrating into a large environment there is nothing to say extension4 isn’t used on other objects and don’t feel it a robust query.

    Rgs

Children