Discovery Issues with OnCommand Plug-in 4.1 for SCOM 2012 R2

[SteveB05]

I have a customer who has a NetApp cluster with FAS8040s running 8.2.1 in cluster-mode. The have SCOM 2012 R2 UR6 and the OnCommand 4.1 SCOM plug-ins. I can do an initial discovery of the cluster and it pulls back the SVM, but no other objects are discovered...no LIFs, no Nodes, no Volumes etc.

I've been over the install doc many times and have not found where I might be doing something wrong. I've also searched on the interwebs and found a few suggestions, but none have changed the outcome.

I've ensured the overrides are appropriate and to be sure its not a rights thing, I'm using "the" admin account. I see no indication of issues in:

- The OnCommand Event Log

- The OC.SCOM.logs (even in debug mode)

- The SCOM task status

Any help would be greatly appriciated.

[ChanceBingen]

This may sound like a silly question, but have you made sure to add a cluster management LIF with a cluster scoped account  (meaning, not using vserver credentials) ?

[ChanceBingen]

You might also want to check the SQL database and make sure it hasn't hit the size limit and we just can't add more data to it.

[SteveB05]

The SQL side is fine and the account is cluster scoped, but you do make me wonder if the problem lies in the fact that they set the account up locally, rather than as a domain account and thats causing issues with SCOM getting the information.  I'm working with my customer to reveiw the account used. I'll report back when I know if that is the answer or not.

[SteveB05]

We are now using a Domain account and I still can't get any further. Below are the only indications of issues I can find.

********************************************************************************

Log Name:      Operations Manager
Source:        Health Service Modules
Date:          8/3/2015 6:27:00 PM
Event ID:      22406
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      SCOM_SERVER
Description:
The PowerShell script failed with below exception

System.Management.Automation.MethodInvocationException: Exception calling "CreateDomain" with "3" argument(s): "The specified user does not have a valid profile.  Unable to load 'Microsoft.EnterpriseManagement.HealthService.Internal, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=121212121212121212'."At line:40 char:12
+     return [AppDomain]::CreateDomain("OC.Cluster.OM.Powershell.NonDefaultAppDoma ...
+            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   at System.Management.Automation.ExceptionHandlingOps.ConvertToMethodInvocationException(Exception exception, Type typeToThrow, String methodName, Int32 numArgs, MemberInfo memberInfo)
   at CallSite.Target(Closure , CallSite , RuntimeType , String , Object , Object )
   at System.Dynamic.UpdateDelegates.UpdateAndExecute4[T0,T1,T2,T3,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3)
   at System.Management.Automation.Interpreter.DynamicInstruction`5.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)

 

Script Name:    Monitoring.ps1

One or more workflows were affected by this.  

Workflow name: DataONTAP.Cluster.Monitoring.GetDataProtectionLagTimePerformanceData.Rule
Instance name: Storage virtual machine SVM_NAME.
Instance ID: {UUID_STRING}
Management group: MG

********************************************************************************

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          8/3/2015 6:28:00 PM
Event ID:      4666
Task Category: Application Generated
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      SCOM_SERVER
Description:
An application attempted an operation:

Subject:
    Client Name:        OC_ACTION_ACCOUNT
    Client Domain:        DOMAIN
    Client Context ID:    111122222333

Object:
    Object Name:        IsUserAdministrator
    Scope Names:        50585907-7858-4488-ab9c-13e0eaac08be

Application Information:
    Application Name:    Microsoft System Center
    Application Instance ID:    22350934216

Access Request Information:
    Role:            Role
    Groups:            Group
    Operation Name:    User_IsAdministrator__Check (142)

********************************************************************************

Log Name:      Security
Source:        MOMSDK Service Security
Date:          8/3/2015 6:28:00 PM
Event ID:      26401
Task Category: (3)
Level:         Information
Keywords:      Classic,Audit Failure
User:          DOMAIN\OC_ACTION_ACCOUNT
Computer:      SCOM_SERVER
Description:
Data access operation: User_IsAdministrator__Check
Data access method: IsUserAdministrator
User name: DOMAIN\OC_ACTION_ACCOUNT
sessionId: uuid:UUID_STRING;id=NUM

********************************************************************************

[ChanceBingen]

Ok, that's a pretty common error.

See if this helps: https://kb.netapp.com/support/index?page=content&id=2020050

[SteveB05]

Sorry for the delay, I was out of town with another customer.

Thanks for the reply and the link. I'd seen that earlier in my search to find an answer and I'm fairly certain the ID is set up properly. As I indicated in an earlier reply, I moved to using a domain account specifically to allow me to log into the SCOM server with that ID and build the local profile.

Is there some mechanism I can use to verfy that the ID I've put in as the default action account, the configured account for the storage system, or some other account is being used by the discovery rules?

[ChanceBingen]

No worries.

Try this, https://technet.microsoft.com/en-us/library/Hh456432.aspx

We're looking for the "this is the user account under which all rules...".

We need to make sure that every SCOM management server where OCPM is installed has a user profile generated by this account in order to prevent that error.