locked
Opalis Folder Monitor Stops Working RRS feed

  • Question

  • We have a Folder Monitor object in a policy that works fine for a while when you starts it and notices changes made to files under the monitored folder, and does what it is supposed to do. However, after an undetermined amount of time (sometimes hours, sometimes days) it just stops seeing any changes. If we stop and re-start the monitor policy then it will work again for a while, and then the same thing happens.

    Has anyone seen this behavior? Any ideas?

    Tuesday, August 28, 2012 9:10 PM

Answers

  • Hello,

    yes, I've seen that before. This issue may happen if you monitor a Network-Path and after the connection from Action Server to this Folder was temporary broken. You should see Events in the Events Tab for the time it was broken.

    Regards,

    Stefan


    German Orchestrator Portal , My blog in English

    • Marked as answer by Jerry Rice Wednesday, August 29, 2012 4:42 PM
    Tuesday, August 28, 2012 9:36 PM
  • Jerry,

    It is not fixed in Orchestrator, I believe it is on the list of items Microsoft are looking to improve but when or if it get resolved I couldn't say.

    If the time delay in detecting updates to that folder are not super critical I would suggest you use a Monitor Date/Time Object and then a Get File Status object, and then process your policy results from the Get File object, rather than a monitor folder.

    The reason being that the Get File will make a fresh connection to the folder each time it checks so will handle the Network blips.

    P.S. You will need to check the File Management objects as I might have got the Get File Status Object name wrong.  Been a while since I last looked at the Opalis objects, I know the functionality is there as I used it for a number of Opalis customers.  It is no good me looking at Orchestrator as the names have changed between Opalis and Orchestrator.

    • Marked as answer by Jerry Rice Wednesday, August 29, 2012 4:42 PM
    Wednesday, August 29, 2012 8:03 AM

All replies

  • Hello,

    yes, I've seen that before. This issue may happen if you monitor a Network-Path and after the connection from Action Server to this Folder was temporary broken. You should see Events in the Events Tab for the time it was broken.

    Regards,

    Stefan


    German Orchestrator Portal , My blog in English

    • Marked as answer by Jerry Rice Wednesday, August 29, 2012 4:42 PM
    Tuesday, August 28, 2012 9:36 PM
  • Any thoughts on how to fix this? Really, the object should be resilient to this sort of thing, as network hiccups are not uncommon. It would be better if the monitor re-connected rather than just keep on running but not actually do anything.

    Does anyone know if this is fixed in Orchestrator?

    Tuesday, August 28, 2012 10:13 PM
  • Jerry,

    It is not fixed in Orchestrator, I believe it is on the list of items Microsoft are looking to improve but when or if it get resolved I couldn't say.

    If the time delay in detecting updates to that folder are not super critical I would suggest you use a Monitor Date/Time Object and then a Get File Status object, and then process your policy results from the Get File object, rather than a monitor folder.

    The reason being that the Get File will make a fresh connection to the folder each time it checks so will handle the Network blips.

    P.S. You will need to check the File Management objects as I might have got the Get File Status Object name wrong.  Been a while since I last looked at the Opalis objects, I know the functionality is there as I used it for a number of Opalis customers.  It is no good me looking at Orchestrator as the names have changed between Opalis and Orchestrator.

    • Marked as answer by Jerry Rice Wednesday, August 29, 2012 4:42 PM
    Wednesday, August 29, 2012 8:03 AM
  • Ok, thanks for the advice... I can look into just using the Monitor Date/Time Object to kick this off. Do you know if there is a bug filed for this that I can +1 somewhere?
    Wednesday, August 29, 2012 4:42 PM
  • Hi, because the next Version is released with System Center 2012 Orchestrator it makes sense to consecrate and report it via Microsoft Connect.

    I think the same as Greg a" "Monitor Date/Time" (with an interval you can specify on your own) -> Get File -> Change File (that it doesn't meet the filter from Get File) -> next steps " is the best. Because so you can be sure you get all status changes you are interested even if the status is occurring while the connection to the object to monitor is broken.

    Regards

    Stefan


    German Orchestrator Portal , My blog in English

    Wednesday, August 29, 2012 6:23 PM
  • Huh, I can't figure out how this would work, since the output from the Get File Status object does not indicate that a file "Changed", it just indicates last access time, etc. On top of that, we have multiple files changing in subfolders, which would need to be treated as separate monitor objects, so things get complex in a hurry.

    We are currently looking to see if we can set up a monitor policy for the File monitor policy, maybe use Monitor Date/Time -> Query Database (to Opalis DB Event Log Table and match on the error event) -> Invoke Web Services (or something to that effect to stop/start the Policy). Maybe something similar to Ryan's work here: http://opalis.wordpress.com/2012/05/02/monitoring-the-monitor-runbooks/.

    Wednesday, August 29, 2012 7:11 PM
  • Ok, what do you want to monitor in this folder? Let's say new files with the pattern *.txt. You can check with "Get File Status" if some exist then rename to *.old and then trigger the following objects.

    If "Monitor File" fails you will miss all the changes that will occur until the Policy is started.


    German Orchestrator Portal , My blog in English

    Wednesday, August 29, 2012 10:17 PM
  • We are monitoring these files to trigger a separate set of installation policies, so we can't rename things, etc. Some of these files end up being very large.

    The end solution for us was to just monitor the policy for the failure and re-start the policy. Assuming this bug gets fixed at some point (in Orchestrator) then we can just delete this extra Monitor policy, so it works out pretty well.

    Thanks for your help, it seems we are sorted for now! I'd like to submit the bug, but Microsoft Connect doesn't have either Opalis or Orchestrator listed as a possible product to submit on...

    Wednesday, August 29, 2012 10:42 PM
  • Greg Charman said in August 2012 that the issue with the Monitor Folder object stopping to work after a network hickup is not fixed in Orchestrator.

    Now in 2014, do we know if this has been fixed by now in Orchestrator 2012 R2?

    Tuesday, August 12, 2014 7:23 AM
  • Just to answer my previous question: We are now in 2015, using SCORCH 2012 R2, and Monitor folder is still not reliable after network hickups.
    Friday, June 12, 2015 9:25 AM
  • in 2016 it's still the same.

    I've used the scheduled time + script to check for files before, but this causes issues as well (workflow takes to long and consecutive workflows pick up the same files).

    I'm looking at a way to pick up the events (with scom) and restart the workflow. Anyone know where these events are located? only in the orchestrator db?


    Rob Korving
    http://jama00.wordpress.com/

    Monday, June 27, 2016 9:54 AM