Home› General Discussion

What table stores AD mapping of the Support groups?

Nathan_ErdmanNathan_Erdman Customer IT Monkey ✭
in General Discussion
Some AD changes were made and it appears to have broken the Support group mapping.  The Cachebuilder Log file shows errors where it is still looking at the old Active Directory OU where the security group was stored.



Best Answer

Answers

  • merlenette_jonesmerlenette_jones Member Advanced IT Monkey ✭✭✭
    Nathan_Erdman said:
    Some AD changes were made and it appears to have broken the Support group mapping.  The Cachebuilder Log file shows errors where it is still looking at the old Active Directory OU where the security group was stored.



    Any changes that are made in Active Directory you will want to resync your Active Directory connector in the Service Manager console so that those changes replicate through the CMDB.

    Let me know if you have further questions,

    Merle
  • Nathan_ErdmanNathan_Erdman Customer IT Monkey ✭
    This was done ( Several times ) but the Log file still shows it looking in the old OU in AD.

  • Nathan_ErdmanNathan_Erdman Customer IT Monkey ✭
    I just checked a AD security Group that were having the issue with and it is indeed incorrect.
  • Nathan_ErdmanNathan_Erdman Customer IT Monkey ✭
    What is the benefit of creating a new AD connector over re-syncing tthe current AD connector? Also what do I do with the current AD connector? Delete it after the new one is created?

  • Nathan_ErdmanNathan_Erdman Customer IT Monkey ✭
    I created the NEW AD connector and ran a sync. The Correct mappings then appeared under configuration items>users> extenssion tab. But they reverted back to the old mappings again after some time had passed. Resyncing the NEW connector does not fix it a second time BUT recreating yet another AD connector did fix it a second time. after 6 hours i checked the mappings once more and they again reverted back to the OLD AD mappings. Any ideas on whats going on here? I feel as if every time the Cireson Cache builder runs it then changes the mapping back to the old. 
  • merlenette_jonesmerlenette_jones Member Advanced IT Monkey ✭✭✭
    Nathan_Erdman said:
    I created the NEW AD connector and ran a sync. The Correct mappings then appeared under configuration items>users> extenssion tab. But they reverted back to the old mappings again after some time had passed. Resyncing the NEW connector does not fix it a second time BUT recreating yet another AD connector did fix it a second time. after 6 hours i checked the mappings once more and they again reverted back to the OLD AD mappings. Any ideas on whats going on here? I feel as if every time the Cireson Cache builder runs it then changes the mapping back to the old. 

    Are you disabling the other connectors?
  • merlenette_jonesmerlenette_jones Member Advanced IT Monkey ✭✭✭
    Nathan_Erdman said:
    What is the benefit of creating a new AD connector over re-syncing tthe current AD connector? Also what do I do with the current AD connector? Delete it after the new one is created?


    You will want to create a new connector as the old connector has become corrupted. So you can delete it or disable it
  • Nathan_ErdmanNathan_Erdman Customer IT Monkey ✭
    I did disable the old connectors. I am unable to delete the Old one as it throws a generic error message
  • merlenette_jonesmerlenette_jones Member Advanced IT Monkey ✭✭✭
    I would suggest contacting Microsoft as it seems there is an underlying issue with the Service Manager SDK
  • Mike_StormsMike_Storms Customer Adept IT Monkey ✭✭
    I am having a very similar issue and have opened a case with MS. No real solution has been provided to date. It appears that once a users OU is changed in AD it keeps reverting back to the old OU unexpectedly. We have manually changed it to match AD via the console and that restores it for a few days and then it reverts back... the connector doing the overlay is the default SDK connector. MS had us disable the SCCM connector think it was bring over incorrect data... but that didn't work... finally I noticed we had asset management installed... we don't use this component but it has a couple WF that kick off... I disabled them ... and since then we haven't seen the issue reoccur... we are still working with MS on the issue... however... to get at root cause...   
  • Nathan_ErdmanNathan_Erdman Customer IT Monkey ✭
    Im still actively working with MS on this issue as well as its not been resolved. They believe its the Default SDK causing the issue on our end as well. We do use the Asset component so disabling the SCCM connector inst an option for us. As of to date, we've truncated several Cireson tables, reset the watermarks on the LFX data source table and the issue persists. Im currently left with rebuilding a NEW AD connector every morning and restarting the the Cireson Cache builder. @ Mike_Storms if you find the root cause or a fix would you mind posting it here and Ill do the same? Thank you
  • Mike_StormsMike_Storms Customer Adept IT Monkey ✭✭
    what is your case number with MS? Mine is 117042515648047 Austin Mack
  • Nathan_ErdmanNathan_Erdman Customer IT Monkey ✭
    My MS incident # is 117050215679906 Swati Bhawnani. Thanks Mike I appreciate it.
  • Mike_StormsMike_Storms Customer Adept IT Monkey ✭✭

    @Nathan_Erdman were you ever able to get a resolution to your issue? Mine has re-appeared again after weeks of nothing changing...

  • Nathan_ErdmanNathan_Erdman Customer IT Monkey ✭
    Still no permanent resolution on my end. It has "stuck" for about a 2 weeks now. Even though the console shows the Old AD mapping everything works as it should. Im concerned its only a matter of time until it does revert back. All ive done was to clear the water marks on the LFX data-source table and re-sync the AD connector. I ended up clearing clearing the water marks for all the data-sources. 

    Heres the Query and the script.

    -- Execute the following SQL Query to find the DataSourceID number for the AD Connector that is used to bring the users into SM

    Use ServiceManager

    Select * from LFX.datasource

     

    -- Update the line below replacing # with the corresponding AD connector DataSourceID from above to reset the AD Watermark 

    -- for that connector.  The Next AD Synchornization performed will be a FULL synchronization.   Will take a lot longer to run

     

    exec [LFX].[ResetWatermarkForDataSource] #,'erroroutput' 

  • Mike_StormsMike_Storms Customer Adept IT Monkey ✭✭
    Thanks!  We tried that but it didn't seem to do a full sync... the connector only ran for 5 minutes which is typical...
  • Nathan_ErdmanNathan_Erdman Customer IT Monkey ✭
    When you ran the Query how many AD data-sources were listed? I had 5. The first time I only cleared the most recent AD data-source watermark and it ran pretty quickly. The second time I cleared the watermarks for all 5 of the AD connectors and it ran for about 15 mins. 
  • Nathan_ErdmanNathan_Erdman Customer IT Monkey ✭
    Another suggestion that was given to me from a MS consultant was to create a new OU in AD housing all my SCSM security groups and create a new AD connector only pointing to this OU. And then creating a second AD connector pointing to my OU that houses Employee AD accounts. If I continue to have issues with the mapping and I do not get e perm fix this is the path i will be taking. 
Sign In or Register to comment.