locked
DFS-N Folder Target monitoring help wanted! RRS feed

  • Question

  • Hi!

    I´ve enabled "Client monitoring" for the "Windows Server 2003/2008 DFS Namespaces Management Pack 6.0.6321.0".

    My first experience was that the monitor "DFS-N: Folder Target State Mapped from Metadata" was not very useful since it presents a Healthy state on targets that in real life are inaccessible (at least if other targets of the same dfs-folder is still accessible). I therefore enabled the "DFS-N: Folder Target Availability"-monitor on critical paths. I also changed the default interval of 5 hours!? to 15 minutes.

    On a few targets the state changes between healthy and critical for no obvious reason and I´m having a hard time figuring out where these statechanges (and alerts) are triggered.

    Question:
    The state from the "DFS-N: Folder Target Availability"-monitor does not seem to roll-up to the DFS-client. How can I identify wich DFS-client triggered a "DFS-N: Folder Target Is Not Accessible"-alert, or from where is it triggered?

    Sincerely
    Peter

    Tuesday, April 27, 2010 8:47 AM

Answers

  • Hi, No activity for 30 days. Will mark as answer. Feel free to re-open. Thanks


    Anders Bengtsson | Microsoft PFE | blog at http://www.contoso.se
    Sunday, December 26, 2010 7:57 PM

All replies

  • If you open the alert and look at its context, or from the alert, right click and show the diagram, you should be able to determine where the alert was triggered from the alert context information.  You can also view the health state change history from there as well.

     


    Microsoft Corporation
    Tuesday, April 27, 2010 3:23 PM
  • Hi!

    No, I cannot find any useful information in any of these places, in the sense of determining from where the test/script was run.
    What I need to know is from where is the target not accessible? Is it from any of the configured DFS-clients, is it from the namespace servers, is it from the SCOM-server or from somewhere else?

    Alert Context:
    Date and Time: 2010-04-27 17:47:41
    Property Name Property Value
    TargetState NotAccessible

    Alert Details:
    DFS-N: Folder Target Is Not Accessible  Alert Description 
    Source:  \\server\share$  The following DFS folder (link) target is not accessible and may not exist: \\server\share$
    Path:  \\DOMAIN\vdata\\\DOMAIN\vdata\share\\\server\share$  
    Alert Monitor:  DFS-N: Folder Target Availability  
    Created:  2010-04-27 17:47:41

    Alert Description:
    The following DFS folder (link) target is not accessible and may not exist: \\server\share$

    Health Explorer shows about the same.

    /Peter

    Tuesday, April 27, 2010 4:02 PM
  • The agent that is running that is on a server named \\DOMAIN\vdata

    You can always find the agent name by looking at the PATH value for any context.  Blank path means RMS.

    So, if the account you run the agent/workflow with on the vdata host is not able to access the \\serve\share$ (hidden share) then you may want to update the run-as account for that workflow or agent.  Since the reference is to a hidden share, only accounts that have local file access and administrative and login permission on that host will be able to successfuly access the share.  The share will also have to grant read on the target file objects to the account used to run the agent/workflow


    Microsoft Corporation
    Wednesday, April 28, 2010 3:31 PM
  • Hello again!

    VDATA is not a server/host, it´s a namespace, so I still don´t know wich agent?

    /Peter

    Thursday, April 29, 2010 12:26 PM
  • Ahh.  I see.  There is another piece of data called "Path" that is provided as part of all alert descriptions.  Look at the class the monitor targets - it should also show a property called "path".

    It seems the DFS team added details on the file share path to their alert.  The full alert detail should include SCOM provided details, including the agent provided value of path (not share path)


    Microsoft Corporation
    • Proposed as answer by Dan Rogers Tuesday, June 15, 2010 3:36 PM
    • Unproposed as answer by LTHPETER Thursday, June 24, 2010 3:09 PM
    Friday, June 11, 2010 3:31 PM

  • I´m not sure what you mean, I´ve stated the complete alert description above and it doesn´t contain any client hostnames. However, I´m in the middle of upgrading/replacing the DFS MP:s with those included in the Fileservices MP, so I will evaluate if they behave the same when I´m finished, might take a while.

    Update:

    Hello again!

    I´ve now "migrated" to 6.0.6600.0, however I´ve only installed the following since we only have DFS-servers with 2003 R2:

    File Services Management Pack Library    6.0.6600.0
    File Services Management Pack for Windows Server 2008R2  6.0.6600.0
    DFS Namespaces Management Pack Library    6.0.6600.0
    DFS Namespaces Management Pack for Windows Server 2003  6.0.6600.0
    DFS Replication Management Pack Library    6.0.6600.0
    DFS Replication Management Pack for Windows Server 2003 R2 6.0.6600.0

    After two days of tearing my hair I´ve not managed to get the monitoring for our quadrillion of namespaces even close to satisfactory.

    Before I even start to put down the problems on paper I must ask you for comments on the following assumption:

    The "Default Action Account"-run-as-profile is configured for "Local System Action Account" for all servers, therefore I should not need to configure any of the supplied run-as-profiles, since the documentation states that the account should...

    ..."have permission to export the DFS Namespaces configuration"
    ..."required privileges to connect to the WMI provider on the monitored computers and retrieve replication backlogs."
    ..."require that the Action Accounts have local Administrator rights on the monitored computer"

    I guess all of these are true if you´re local system, at least if the tasks are run locally (wich is not discussed in the docs.)?

    If this assumption is incorrect, it is remarkable that most of the views gets populated now since I have enabled both client-, folder-, target- and backlog-monitoring without using anything else than "Default Action Account". But as said, there are many problems, wich I will not investigate further until I´ve cleared this account issue out.

    Sincerley
    Peter

    Thursday, June 24, 2010 6:01 AM
  • I think that you should re-read the guide describing why there are run-as profiles you can use.  To do remote file share monitoring, localsystem account just cannot work.  The reason is this is a sandboxed account and is not allowed to make calls over the network.

    So if you are monitoring secured file shares or monitoring file shares that are exposed on the network, then you need to use run-as account mappings to satisfy the permissions ...

     

     


    Microsoft Corporation
    Friday, June 25, 2010 3:45 PM
  • Hi Dan!

    I have a reason for not following the docs, let me explain.

    I was faced with the problem with the "Health Service Credentials Not Found Alert Message", discussed here:

    http://social.technet.microsoft.com/Forums/en-US/operationsmanagermgmtpacks/thread/8813afc0-0e63-4cce-8442-01d5bb9a59a7

    At the time I didn´t know what was the cause. So I rolled back the configuration of Run-As-Profiles and completed other optional configuration steps except populating any Run-As-Profiles.

    When finished, I noticed that all namespace servers, namespaces and folders were nicely listed and healthy in the views, wich lead me to belive that these discoveries only take place locally on each agent and that "Local system" therefore would be enough. Also, no alerts indicating a problem with the discoveries had come up.

    It is still my current opinion that the Run-As-Profile "DFS Namespace Discovery Account" does not need to be populated if your "Default Action Account" is Local System, and that a domain account only is necessary in "DFS Paths Access Account" and possibly "DFS Replication Monitoring Account".

    Anyway, besides if I´m wrong or right, would the following alternative workaround be useful:

    1. Distribute a domain account only to namespace servers, replication members and selected DFS Clients. (More Secure-option)
    2. Instead of adding the account to "All targeted objects" in each Run-As-Profile, only add it for use on the "Windows Computer"-object of each of the selected computer in step 1. (Select -> Object -> Look for: -> Windows Computer)

    Or is it some other class that should be chosen, such as "Health Service", or "Agent" or is this not an option at all?

    Regards,
    Peter

    Monday, June 28, 2010 9:22 AM
  • I think you are saying "Hey, I got it working by deleting the run-as profiles I had previously defined".  First off, congrats - that is good.

    DFS needs run as profiles only for cases (and on specific agents) where you are doing remote monitoring of DFS nodes.  This is important scenario wise because while the local computer may be able to access a share, a remote connected network user may not.


    Microsoft Corporation
    Monday, June 28, 2010 11:43 PM
  • Sorry for being difficult, let´s get back to the initial issue.

    I now think I´ve configured the run-as-profiles by the book, but to avoid the seed discovery problem I´ve defined each computer in question in each run-as-profile as stated yesterday.

    I now have a state where one of the "DFS-N: Folder Target Availability"-monitors looks like this:

    Date and Time: 2010-06-29 12:57:37
    Property Name Property Value
    TargetState NotAccessible

    What is different this time is that no alert is generated, this is probably a new issue in this version.
    Anyway, if I manually activate the alert on the monitor, I get the following:

    Microsoft.Windows.FileServer.DFSN.LinkTarget.AccessStateUnitMonitor
    Source:  \\server\share  
    Path:  \\DOMAIN\namespace\\\DOMAIN\namespace\folder1\folder2\\\server\share
    Alert Monitor:  DFS-N: Folder Target Availability

    If I check with dfsutil I get State="OK" on the link and State="Online" on the target.

    How can I determine wich agent that is responsible for turning this monitor into critical?

    You earlier stated that I should "Look at the class the monitor targets", it targets "DFS Folder Targets" but how exactly do I "look at the class" to get the property?

    /Peter

    Tuesday, June 29, 2010 12:15 PM
  • I really am having trouble figuring out whether or not you are saying that it works or that it doesn't work.

     

    Take a look at any alert (not the DFS ones) - and you will see a path entry is always a part of the details.  Path is something that Ops manager provides you so you can find the computer name associated with the agent that created the alert or runs the workflow.

    I don't follow what you are trying to do with run-as profiles.  The guide is pretty extensive on how to configure run-as profiles for the MP.  you shouldn't have to do this on a per server basis.

     

    Are there errors in your operations manager event log on the agents that are monitoring your DFS shares?

     


    Microsoft Corporation
    Wednesday, June 30, 2010 4:31 PM
  • Hi again!

    >I really am having trouble figuring out whether or not you are saying that it works or that it doesn't work.
    Well, if you configure everything perfect there are no problems, I´ve learned. What I´m trying to say is that it would be very helpful to know wich agent that flipped a monitor from green to red. At least in order to troubleshoot issues one could get when distibuting Run-As-Accounts and determining their lowest possible permission level on monitored objects.

    >Take a look at any alert (not the DFS ones) - and you will see a path entry is always a part of the details. Path is something that Ops manager provides you so you can find the computer name associated with the agent that created the alert or runs the workflow.
    Certainly, and this is also true on all other alerts, but not the DFS ones. The alert details looks like this:

    Path: \\DOMAIN\namespace\\\DOMAIN\namespace\folder\\\server\target

    DOMAIN = The domain I´m in.
    namespace = The namespace in question
    folder = The DFS-folder (or link)
    server = The server who shares the target
    target = The physical share 

    No clue about wich agent !?

    It is easy to replicate this problem, just enable the "DFS-N: Folder Target Availability"-monitor on any target where there are no permissions. Look at the alert.

    >I don't follow what you are trying to do with run-as profiles.  The guide is pretty extensive on how to configure run-as profiles for the MP.  you shouldn't have to do this on a per server basis.
    If I don't, I'll get spammed with "Health Service Credentials Not Found Alert Message" from all agents to wich the credentials have not been distributed, for the reason that they do not take part in the DFS infrastructure.
     
    >Are there errors in your operations manager event log on the agents that are monitoring your DFS shares?
    No.

    Anyway, this question has evolved from a real problem to more of a feature request, so I guess we can end it here.
    I will investigate newly discovered
    problems with this release and create new threads if necessary.

    Thank you
    /Peter

    Thursday, July 1, 2010 10:29 AM
  • Thanks Peter.

    I've asked the product group to look at two potential issues:

    1.  Does DFS have a property that masks the alert property named "path"?

    2.  Are there workflows that run on all agents that are defined in this MP unless the user scopes the context of the MP down?


    Microsoft Corporation
    Thursday, July 1, 2010 9:52 PM
  • Hi, No activity for 30 days. Will mark as answer. Feel free to re-open. Thanks


    Anders Bengtsson | Microsoft PFE | blog at http://www.contoso.se
    Sunday, December 26, 2010 7:57 PM
  • I had similar issues.  The DFS folder targets I was trying to monitor were showing critical but not presenting an alert in the Active Alerts dashboard and the alert was that the path was not accessible.  The DFS namespace guide is pretty good but there were a couple of things that I didn't understand clearly from it

    I discovered that by default the monitor does not alert so that was solved by creating an override and setting the alert parameter to true for each folder target that I had already overridden to enable the monitor.  Should have seen that when I went to enable the monitor.

    For the path accessibility issue, the account you use for the DFS Path Access Account profile needs to be distributed to the management servers because they are the ones who run the workflow to check the path accessibility.  I discovered this after asking my Father in heaven - seriously.  The Lord gave me the idea to set the DFS Paths Access account profile to "All Targeted Objects".  Once I did that, I got the alert in the console that the management servers didn't have the account distributed to them so I distributed the account and bam - all the alerts went away!

    • Proposed as answer by Hollisorama Thursday, June 26, 2014 2:22 PM
    Thursday, June 26, 2014 2:21 PM