×

Prerequisites

On Gateway

• OpsRamp Classic Gateway(Linux) 14.0.0 and above.
• OpsRamp Nextgen Gateway 14.0.0 and above.

Pre-requisites to be fulfilled on target cluster nodes / standalone nodes:

Starting from Windows Fail-over Cluster version 10.1.0, the option to select the connectionMode is available. The supported options are:

• PowerShell (existing)
• OpenSSH (new)

Pre-requisites to be implemented if “PowerShell” is selected:

• PS Remoting and WMI remoting to be enabled on each cluster node. If the configured user is non-administrator, then the below user should have privileges on WMI remoting and on Windows Services.

• Add OpsrampGatewayIp to the TrustedHosts list on the target machine to allow the powershell connection from gateway to the target machine.

  • To add TrustedHosts use the following command:
    • To allow any host:

      *Set-Item WSMan:\localhost\Client\TrustedHosts -Force -Value**
      

    • To allow a specific host:

      Set-Item WSMan:\localhost\Client\TrustedHosts -Force -Concatenate -Value <IPAddress>
      

• Setup and restart the WinRM service for the changes to reflect

  • To set up: Set-Service WinRM -StartMode Automatic
  • Restart using: Restart-Service -Force WinRM

• Windows domain user should be added to “Remote Management users” group

  net localgroup "Remote Management Users" /add <user>
  

• Windows domain user should be added to “Performance monitor users” group

  net localgroup "Performance monitor users" /add <user>
  

Following are the specific prerequisites for non-administrator/operator level users:

Enable WMI Remoting

To enable WMI remoting:

1. Click Start and select Run.
2. Enter wmimgmt.msc and click OK.
3. Right click WMI control (Local) and select Properties.
4. Click Security tab.
5. Expand Root.
6. Select WMI and Click Security.
7. Add user and select the following permissions:
   • Execute methods
   • Enable account
   • Enable remoting
   • Read security

Enable WMI Remoting – CPU, Disk, Network

1. Click Start and select Run.
2. Enter lusrmgr.msc and click OK.
3. In the Groups folder, right click Performance Monitor Users and select Properties.
4. Click Members of tab, and click Add.
5. Add users.

Enable Windows Service Monitoring

1. Retrieve the user SID of the User Account from the monitored device.
2. Open Command Prompt in Administrator mode.
3. Run the following command to retrieve the user SID.
   Note: Replace UserName with the user name for the User account.

   wmic useraccount where name="UserName" get name,sid
   

   Example:

   wmic useraccount where name="apiuser" get name,sid
   

4. Note down the SID.
   (Ex. S-1-0-10-200000-30000000000-4000000000-500)
5. Retrieve the current SDDL for the SC Manager.
6. Run the following command which will save the current SDDL for the SC Manager to CurrentSDDL.txt.

   sc sdshow clussvc > CurrentSDDL.txt
   

7. Edit the CurrentSDDL.txt and copy the entire content. The SDDL will look like below:

   D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)(A;;CC;;;AC)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
   

8. Update the SDDL:
   Frame new SDDL snippet for above SID

   (A;;CCLCRPWPRC;;; <SID of User> )
   

   Example:

   (A;;CCLCRPWPRC;;;S-1-0-10-200000-30000000000-4000000000-500)
   

9. Place this snippet before “S:” of original SDDL.
   Updated SDDL will be like this:

   D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)(A;;CC;;;AC)(A;;CCLCRPWPRC;;;S-1-0-10-200000-30000000000-4000000000-500)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
   

10. Execute the following command with the updated SDDL:

    sc sdset clussvc D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)(A;;CC;;;AC)(A;;CCLCRPWPRC;;;S-1-0-10-200000-30000000000-4000000000-500)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
    

Open ports and add user in all nodes and cluster

• OpsRamp gateway should be able to access cluster and nodes.
• Ports to be opened are 5985 and 5986.
  Note: By default, WS-Man and PowerShell remoting use port 5985 and 5986 for connections over HTTP and HTTPS, users should be present in nodes and cluster.

Pre-requisites to be implemented if “OpenSSH” is selected:

• OpenSSH must be installed and configured on the target Windows machine.
• Password authentication must be enabled in SSH config: PasswordAuthentication yes
  • Edit sshd_config (run PowerShell as Administrator)
  • Open: notepad C:\ProgramData\ssh\sshd_config (Note: If not this location, locate the correct path for sshd_config and perform below steps)
  • Find the line #PasswordAuthentication yes (or PasswordAuthentication no), uncomment it and set it to yes, then save.
  • Find the line AllowUsers (or add it if missing) and set it to: AllowUsers <ssh-username>
  • Restart-Service sshd
• Ensures the sshd service startup type is Automatic.
  • Set-Service -Name sshd -StartupType Automatic
• Use the following command to set the OpenSSH default shell to powershell.exe on all the nodes.
  • Set-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "$PSHOME\powershell.exe"; Restart-Service sshd
• Open default ssh port 22 on all the nodes & cluster.
• The user should be added in all the target nodes & cluster.

Ensure that the provided IP address/host name, and credentials are valid and accessible for successful integration. Verify connectivity from gateway using below steps:

• Launch power shell using the {pwsh} command.
• Run the following commands to establish connection, using the details of your end device.
  • {$pw = convertto-securestring -AsPlainText -Force -String "<password>"}
  • {$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist "<username>", $pw}
  • {$session = new-pssession -computername "<ipAddress>" -credential $cred -Authentication Negotiate -ErrorAction Stop}
  • {session.state}
    Note: The session state should be open.
• If the session is not establishing, cross check that all of the pre-requisites are met on all servers and clusters.
• If a resource is initially discovered as a Cluster and later changed to Standalone, the previously created cluster and node entities will remain, as they are not associated with the node. To reduce unnecessary noise and avoid confusion, we recommend not changing the Type from cluster to standalone.
• Make sure the cluster and subordinate node credentials are the same, and then add them to the configuration.

Configure Windows failover cluster monitoring

Modify Windows failover cluster

Discover Resources in Windows failover cluster