locked
Fileserver role discovered on non fileserver RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    On a server on which i do not have admin rights we get discovery errors for the fileserver role
    The responsible group sais this server does not have the fileserver role, but in scom it is discoverd, there is an instance of the class 'File Services Role (Windows Server 2012 R2)'

    The process started at 14:09:38 was unable to create System.Discovery.Data; no errors were detected in the output. The process closed with 3221225794
    Command executed: "C: \ Windows \ system32 \ cscript.exe" / nologo "DFSN63FileServerRoleDiscovery.vbs" {EF2CD78D-8437-FEC3-3DF4-D1D99F381B17} {F02CC7ED-92D2-B010-3EA5-900F0FD12492 }ACED
    Workbook: C: \ Program Files \ Microsoft Monitoring Agent \ Agent \ Health Service State \ Monitoring Host Temporary Files 3738 \ 15388 \
    Workflow Name: Microsoft.Windows.FileServer.DFSN.6.3.FileServerRelationDiscovery

    So I've looked up the discovery responsible for creating this class and that seems to be
    Microsoft.Windows.FileServices.6.3.Discovery
    And as far as i see this only runs a wmi query:
    SELECT ID, Name FROM Win32_ServerFeature WHERE ID = '6'

    I tried to run this query on the server via powershell and on another server of which i'm sure it never had the role and on both servers this query hangs forever.

    Any idea how i can find out why it's still discoverd as fileserver role?

    Ronald

    Friday, June 12, 2020 8:29 AM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Your first analysis is correct, you found the right discovery for the File Service role and it indeed only runs a simple WMI query.

    Based on that, two things :

    • Something as simple as a basic shared folder will make the server behave as a "File Server"
    • If the WMI query hangs, the discovery is not returning anything, which is not the same thing as the discovery returning an empty property bag : when the discovery doesn't return anything, SCOM consider it never ran so it won't discover or undiscover anything.

    Since you do see a discovered instance of the file service class, we can guess it used to run properly.

    So now you need to figure out why the WMI query hangs, if it hangs only for your account or also for the account under which the SCOM agent runs (is it local system?), and if it is actually normal or not to have a discovered instance of the file service class for that server.

    If it is actually normal, you will have to go one step further and troubleshoot the failing vbs script (you can find it here : https://systemcenter.wiki/?GetElement=Microsoft.Windows.FileServer.DFSR.6.3.ServiceDiscovery&Type=Discovery&ManagementPack=Microsoft.Windows.FileServer.DFSR.2012R2&Version=7.1.10100.2 ), but my guess is that the root cause is identical since the script also queries WMI.



    • Edited by CyrAz Friday, June 12, 2020 10:11 AM
    Friday, June 12, 2020 8:45 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thx, i now see the amount of instances of that server role in scom and thats 50% of the servers.

    I'll then change focus on the failing discovery, and sended the vbs script to the team to run it manually.

    Ronald

    Friday, June 12, 2020 9:40 AM