Home General Discussion
Options

AD Connector Limit

2»

Answers

  • Options
    Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭

    Yes and No, depends on system. The query is only returning the failed jobs. Failed Jobs happen, the real question is are they failing all the time.

    Here is a query we have (From MS) to review the internal job history.

    The key is that follow up jobs completed. (You can change the top 4 to say top 10 to see more history)


    -- InternalJobHistory StatusCode = 1 = SUCCESS / Completed, it is not uncommon for result to be 0 as long as it later succeeds

    use ServiceManager

    Select top 4 * from InternalJobHistory where command like '%Exec dbo.p_GroomSubscriptionSpecificRECLRows 55270A70-AC47-C853-C617-236B0CFF9B4C%' order by TimeStarted desc

    Select top 4 * from InternalJobHistory where command like '%Exec dbo.p_GroomSubscriptionSpecificECLRows 55270A70-AC47-C853-C617-236B0CFF9B4C%' order by TimeStarted desc

    Select top 4 * from InternalJobHistory where command like '%Exec dbo.p_GroomStagedChangeLogs 55270A70-AC47-C853-C617-236B0CFF9B4C%' order by TimeStarted desc

    Select top 4 * from InternalJobHistory where command like '%Exec dbo.p_GroomManagedEntity A604B942-4C7B-2FB2-28DC-61DC6F465C68%' order by TimeStarted desc

    Select top 4 * from InternalJobHistory where command like '%Exec dbo.p_GroomManagedEntity E6C9CF6E-D7FE-1B5D-216C-C3F5D2C7670C%' order by TimeStarted desc

    Select top 4 * from InternalJobHistory where command like '%Exec dbo.p_GroomManagedEntity D02DC3B6-D709-46F8-CB72-452FA5E082B8%' order by TimeStarted desc

    Select top 4 * from InternalJobHistory where command like '%Exec dbo.p_GroomManagedEntity 422AFC88-5EFF-F4C5-F8F6-E01038CDE67F%' order by TimeStarted desc

    Select top 4 * from InternalJobHistory where command like '%Exec dbo.p_GroomManagedEntity 04B69835-6343-4DE2-4B19-6BE08C612989%' order by TimeStarted desc

    Select top 4 * from InternalJobHistory where command like '%Exec dbo.p_GroomChangeLogs 55270A70-AC47-C853-C617-236B0CFF9B4C%' order by TimeStarted desc

    Select top 4 * from InternalJobHistory where command like '%Exec dbo.p_GroomPartitionedObjects and dbo.p_Grooming%' order by TimeStarted desc

    Select top 4 * from InternalJobHistory where command like '%Exec dbo.p_GroomTypeSpecificLogTables%' order by TimeStarted desc

    Select top 4 * from InternalJobHistory where command like '%Exec dbo.p_DataPurging%' order by TimeStarted desc

  • Options
    Simon_ZeinhoferSimon_Zeinhofer Customer Ninja IT Monkey ✭✭✭✭

    When we had our retention policy to 2 years (in our old system) it was nearly impossible to reduce the period afterwards, as 2 or 3 days less led to all grooming jobs to fail permanently - so we had to reduce it by one day every day. Still it was not possible to reduce it to, let's say 1 year. Needless to say our database grew and grew, and the system was unstable - we had to literally restart the sql service on the sql server several times a day.

    tl;dr: Set the retention policy as short as possible - Especially with the archiver feature, setting retention policies too high is not necessary imo. We now have it to 30 days for all work items except changes (which is configured to 180 days)

  • Options
    Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭

    You don't have to wait for the nightly grooming job to run. Once it complete, if you edit the retention time, kick it off again in SQL, to you can step down say over a weekend when there is less load on the system.

  • Options
    Simon_ZeinhoferSimon_Zeinhofer Customer Ninja IT Monkey ✭✭✭✭

    Yes I know that.

    We tried to manually run the groomings with the query, which microsoft provided - led to a timeout and nothing has been deleted.

    Also after deleting all notification objects from our db (script was provided by microsoft), because they have not been related to the user anymore, our DB was in pending recovery status - so the system was completely broken.

  • Options
    CaterhamITSupportCaterhamITSupport Member Advanced IT Monkey ✭✭✭
    edited April 2023

    Dear Brian / Simon,

    I think I might have identified the issue to be with an actual AD Connector maybe. Is there a way to detect what issues are with a specific AD connector / troubleshoot it? Also at the moment the retention is set to 90 days for incidents too, if i set it to say 30 days, will this impact anything for example the datawarehouse?

    Thank again.

    Daniel

  • Options
    Simon_ZeinhoferSimon_Zeinhofer Customer Ninja IT Monkey ✭✭✭✭

    One way to investigate issues is the Event Viewer on your Primary Management Server. We currently have the issue, that our AD User Connector brings in AD Users, which do not exist anymore, and the funny part is, the OU in the LFXSTG.AD_User table points to a non existing OU, which got deleted months ago. I haven't had any success by reviewing the log files, as there were no errors - I ended up opening a case on Microsoft side. So detecting issues with connectors is painful imo. But maybe you are lucky.

    The retention period is up to you, but a shorter retention means less data in the DB - but in the current state, people are not able to search for groomed workitems in global search. What do you mean with data warehouse impact? The data should be in the data warehouse, no matter what your retention policy is (if you set it to 0 and the warehouse jobs run after the grooming ofc not ;) ). But as we dropped our data warehouse when the archiver was released, I am no longer able to test something ;) I can just say that 30 days retention period works fine for us, but I am really looking forward to the global search update, where archived work items can be searched for as well :)

  • Options
    CaterhamITSupportCaterhamITSupport Member Advanced IT Monkey ✭✭✭

    Dear Both,

    Do you know if there is a limit on the amount of subscriptions SCSM can handle?

    We have 37 of them.

    Daniel

  • Options
    Simon_ZeinhoferSimon_Zeinhofer Customer Ninja IT Monkey ✭✭✭✭

    @CaterhamITSupport I guess it does not make much sense asking for limits specifically.

    It depends on when a subscription triggers, the polling interval and the batch size - this is a pretty good explanations of how workflows in general work:

    All you can do is to have a look at the workflow performance and if you are falling behind too much. If yes you can still change the polling interval and/or batch size for your custom workflows/subscriptions, but be aware that this might even cause even more trouble - so just do that if you know what to do.

    In short, "hard coded" limits exist very rarely (I guess in case of exchange connectors they say 15), it depends on your environment - so asking for them will mostly get you the answer "It depends on your environment" - There are just too many factors. So all you can do is to try!

  • Options
    Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭

    Depends on what the are connecting to. We have 27 currently. With the goal of not having two connectors attempt to update the same data.

    One thing you should watch out for on the AD connector is the option to

    When this was enabled it really burned out AD jobs.

    If you are syncing the groups you need for the security roles. Do Not have this checked off. It runs every 24 hours on the cycle of the create time of the AD connector.

  • Options
    Simon_ZeinhoferSimon_Zeinhofer Customer Ninja IT Monkey ✭✭✭✭

    @Brian_Wiest maybe this is a misunderstanding from my side but do you mean you need this checked, if you want to use AD groups for security roles? We never checked this one and it had no impact on our security roles. But I guess you mean when there is not its own connector for the users which are members of these groups right?

  • Options
    Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭

    If you are polling specific OU's or LDAP query for just users. And configure the SCSM Security roles via AD groups. Then you must check it.

    If your Ad connector is syncing all the groups as part of the OU or LDAP DO NOT check it.

    On a support ticket with MS, where our entire farm was becoming unresponsive at 3pm every day ended up being the AD connector and this check box. We pull in the entire AD tree and at 3pm it was expanding the groups for all 30K users including their membership to domain users to it just crushed our environment.

  • Options
    Simon_ZeinhoferSimon_Zeinhofer Customer Ninja IT Monkey ✭✭✭✭

    We now have one connector which brings in all users and groups from our domain via LDAP Query (|(objectclass=user)(objectClass=group)) and we don't check it.

    Also when we had multiple AD Connectors with LDAP Queries behind, we never had to check this option in order for security groups to work. But I guess I am just misunderstanding what you mean :D But doesn't matter, it works fine for us so no need to discuss this further (for me) ;)

Sign In or Register to comment.