• State Suggested Answer
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 62 subscribers
  • Views 3370 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Preventing Duplicate Alerts onPostModify

lee.andrews_82510
over 7 years ago

Preventing Duplicate Alerts onPostModify and I guess duplicate processing. 

I have some ARS script policies which have to use DirSync to capture the change.  The script works fine BUT it runs on every ARS administration service in our environment.  This is not normally a problem, although I have tried suppressing the duplicate processing by setting virtual attributes in the $request object and this has had limited success. 

In this instance I get ARS to email an alert out.  All of the ARS servers, and sometimes one will send out two emails, presumably the change replicating in from two DCs. 

I could in theory force all ARS services to use the same DirSync server but I doubt that's good practice and probably would not stop the email alerts being generated. 

One option I have used before was to suppress multiple updates based on changes happening in a short space of time but looking at log files generated I have a 10 second window before the change replicates into anther DC so that would be a very small time window.  

I looked at using the OperationID as I figured this would be unique to the change but this is only on the Request object if the change is made using ARS and I'm using DirSync to capture the change so that's a dead end.

Has anyone come up with a successful strategy to do this.  A drop file seems best but there is a small chance that a email won't be generated if two changes were made at the same time, although thinking about this as I write I guess I could reduce / eliminate that if the file has a relationship to the object so the chance of two changes being made to the same object are small.  How successful this might be is  debatable too as the file will take longer that 10 seconds to produce and all of the ARS server will have seen the change by then :-(.

  • 0 over 5 years ago

    Hi Andrew,

    Have you ever found a solution to this? I'm facing the exact same issue that I have the policy script to send an email notification when DirSync captures the change, and I'm receiving emails from every ARS administration services in our environment. So, I used Execute-On server specified in the script triggers only from one specified server and sends a notification, but sometimes 2 times, presumably what you mentioned "the change replicating in from two DCs". I'm concerning that if I promoted this to where we have many more DCs, possibly I will get more notifications than 2 per event.

  • 0 over 5 years ago

    This is an interesting issue. I can absolutely see where replication would trigger a DirSync event which would trigger additional notifications.

    Setting a Virtual Attribute or a a drop file would not be ideal, since they would also be subject to replication or access delays.

    I suggest instead that you have a job server for notifications.

    # Connect to the root of the current Active Roles service

    $AR = [ADSI]"EDMS://rootDSE" 

    # Get the name of the current Active Roles service
    $ARServer = $AR.psbase.InvokeGet("edsvaServiceFullDns")

    $ARServer will contain the FQDN of the Active Roles instance which is executing the script. You can compare this value to the hard-coded FQDN of your job server. If it matches, send the notification. Otherwise, do not.

    In this way, the same script and Workflow can be executed on multiple Active Roles instances with only one actioning the notification.