if you have the application which writes it log file (same file name) every day new i don't have the posibilities to monitor the log file. I have read the blog http://contoso.se/blog/?p=281 from Anders Bengtsson but there is no chance to configure the application to write multiple log files. From a log file monitor i do expect that it recognizes that the creation day of the log file is new and has to read the file from the beginning. It there any workarrounds ? Lehugo

Hi there. Not so much a bug, but "as designed" I'm afraid. SCOM remembers the last line it reads in a log file. Anders also has a post about using a script to read a log file from the beginning every time. Hope this helps. Layne

Hi there. Not so much a bug, but "as designed" I'm afraid. SCOM remembers the last line it reads in a log file. Anders also has a post about using a script to read a log file from the beginning every time. Hope this helps. Layne

Hi, Regarding Log file monitoring, please also refer to: How to Create a Log File Simple Event Detection Unit Monitor in Operations Manager 2007 http://technet.microsoft.com/en-us/library/bb381375.aspx Using a Generic Text Log rule to monitor an ASCII text file – even when the file is a UNC path http://blogs.technet.com/b/kevinholman/archive/2009/06/20/using-a-generic-text-log-rule-to-monitor-an-ascii-text-file-even-when-the-file-is-a-unc-path.aspx Hope these are helpful. Thanks. Nicholas Li - MSFT Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi, Regarding Log file monitoring, please also refer to: How to Create a Log File Simple Event Detection Unit Monitor in Operations Manager 2007 http://technet.microsoft.com/en-us/library/bb381375.aspx Using a Generic Text Log rule to monitor an ASCII text file – even when the file is a UNC path http://blogs.technet.com/b/kevinholman/archive/2009/06/20/using-a-generic-text-log-rule-to-monitor-an-ascii-text-file-even-when-the-file-is-a-unc-path.aspx Hope these are helpful. Thanks. Nicholas Li - MSFT Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi, from a log file monitor i expect 2 key important functionalities. 1. if the log file only changes (modified time has changed but not the creation time) the monitor has to remember the last reading line. 2. if the log file is new, that means the creation time has changed, the monitor has to read the log file from the beginning. The log file monitors from BMC and IBM Tivoli has these 2 functionalities. I miss the second key functionality from the SCOM log file monitor because of this it is useless for us. Try to explain your customer, when they ask you, why they don't reveive the alert from the log file monitor. Unfortunaly the log file was recycled because its size had reached the limit. Ok, you always can make script monitor to monitor everything. It's funny, when a product like SCOM offers a log file monitor and you have the write a script to monitor the log file Lehugo

Hi, from a log file monitor i expect 2 key important functionalities. 1. if the log file only changes (modified time has changed but not the creation time) the monitor has to remember the last reading line. 2. if the log file is new, that means the creation time has changed, the monitor has to read the log file from the beginning. The log file monitors from BMC and IBM Tivoli has these 2 functionalities. I miss the second key functionality from the SCOM log file monitor because of this it is useless for us. Try to explain your customer, when they ask you, why they don't reveive the alert from the log file monitor. Unfortunaly the log file was recycled because its size had reached the limit. Ok, you always can make script monitor to monitor everything. It's funny, when a product like SCOM offers a log file monitor and you have the write a script to monitor the log file Lehugo

We had the same problem here. We opened a case with PSS and they could not help us. We ended up writing our own script.

Without the functionionality to monitor the recycled log file the SCOM Log file is not worth to be called as Log file monitor. Which log file should be grown unlimited ? All the application log files always have to be recycled manually or automatically some time. Lehugo

Without the functionionality to monitor the recycled log file the SCOM Log file is not worth to be called as Log file monitor. Which log file should be grown unlimited ? All the application log files always have to be recycled manually or automatically some time. Lehugo

Hi, I just noticed this article and would like to share with you: SCOM: How to monitor new line entries in a log or text file using OpsMgr 2007 http://blogs.technet.com/b/schadinio/archive/2010/07/20/scom-how-to-monitor-new-line-entries-in-a-log-or-text-file-using-opsmgr-2007.aspx Hope this helps. Thanks. Nicholas Li - MSFT Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi, I just noticed this article and would like to share with you: SCOM: How to monitor new line entries in a log or text file using OpsMgr 2007 http://blogs.technet.com/b/schadinio/archive/2010/07/20/scom-how-to-monitor-new-line-entries-in-a-log-or-text-file-using-opsmgr-2007.aspx Hope this helps. Thanks. Nicholas Li - MSFT Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

This does not help. A poor design is no different from a bug. There was a serious lack of thought given to this. IMO this feature is unusable as is. Seriously there are no excuses here.

Layne is correct. This is the implementation and design. If you set up a script that deletes the file at the start of a new day, and your logging then recreates it, you will start to possibly see results you prefer. Looking at and remembering create time is an interesting suggestion.Microsoft Corporation

i agree with swyck !! a logfile monitor has to have at least these 2 functionalities : 1. if the log file only changes (modified time has changed but not the creation time) the monitor has to remember the last reading line. 2. if the log file is new, that means the creation time has changed, the monitor has to read the log file from the beginning. There are really no excuces for the missing functionality !!

I did some additional testing with this. What I found was if the log file is renamed and a new one is created using the old name, the monitor works as desired. If you just clear out the log file and start from the top the monitor will wait until it reaches the old max line. I believe most applications will rename and recreate but I guess this may be application specific. Still I agree it's silly to call this "by design" as it's obviously "no thought given".

I did some additional testing with this. What I found was if the log file is renamed and a new one is created using the old name, the monitor works as desired. If you just clear out the log file and start from the top the monitor will wait until it reaches the old max line. I believe most applications will rename and recreate but I guess this may be application specific. Still I agree it's silly to call this "by design" as it's obviously "no thought given".

We also have a need for this type of log file monitoring. We too are unable to change the way the application is rotating the log files. What are our options? AlanZZZZ - would you elaborate on the script written to solve your issue? Thank you, Kate

We also have a need for this type of log file monitoring. We too are unable to change the way the application is rotating the log files. What are our options? AlanZZZZ - would you elaborate on the script written to solve your issue? Thank you, Kate

Hi Kate, The script we built is not a replacement for the log file monitor. Our workaround script monitors the root cause of our problem which is a file not being present where it should be.

Hi Kate, The script we built is not a replacement for the log file monitor. Our workaround script monitors the root cause of our problem which is a file not being present where it should be.

Some test show the following - the creation time of a file does not change even when a file is deleted and recreated. check the creation time of the log file which has been around a while delete the file and recreate it check the creation time: Altough the file has been deleted and recreated, the "creation date" still shows the one before the file was deleted.

Some test show the following - the creation time of a file does not change even when a file is deleted and recreated. check the creation time of the log file which has been around a while delete the file and recreate it check the creation time: Altough the file has been deleted and recreated, the "creation date" still shows the one before the file was deleted.