Quantcast
Channel: THWACK: Popular Discussions - Orion SDK
Viewing all 3719 articles
Browse latest View live

Discovery auto import results

$
0
0

Hello all,

 

New to the SDK game so I'm here with some functionality questions. I'd like to automate the addition of discovered nodes to the Orion platform. I attempting to get the DiscoveredNodes and DiscoveredInterfaces tables into my script so that I can then run through them with the addNode script.

 

Is there a nice way to get this information into Power Shell so that I can call upon it? The variable I'm populating now is just returning nothing but the test I did for only one row of data will give me the data as long as I know the column name.

 

Also asked this in another post but figured I'd put it here as well since it pertains to what I'm doing. The XML that gets generated and fed to the discovery now routine has a section for IsAutoImported or something like that. If I change this to true and generate the discovery will Orion finally take care of importing the results automatically?

 

Thanks guys! Below is what I've used to get something/nothing into my variable.

 

$imports = Get-SwisData $swis "SELECT NodeID, ProfileID, IPAddress, IPAddressGUID, SnmpVersion, SubType, CredentialID, Hostname, DNS, SysObjectID, Vendor, VendorIcon, MachineType, SysDescription, SysName, Location, Contact, IgnoredNodeID, DisplayName, Description, InstanceType, Uri

FROM Orion.DiscoveredNodes"


anyone who can parse below text with powershell.

$
0
0

Dear, Team.

Find the method to parse below text ,

Anyone who can tell to me the method to parse to below???

 

===PARSE RESULT============

Ethernet1/49

Tx Power   -2.67    

Rx Power  -3.48    

 

 

 

===ORIGINAL=================

Ethernet1/47

    transceiver is not applicable

Ethernet1/48

    transceiver is not applicable

Ethernet1/49

    transceiver is present

    type is 10Gbase-SR

    name is SumitomoElectric

    part number is SPP5100SR-YB   

    revision is A  

    serial number is 42T569100590   

    nominal bitrate is 10300 MBit/sec

    Link length supported for 50/125um OM2 fiber is 82 m

    Link length supported for 50/125um OM3 fiber is 300 m

    cisco id is --

    cisco extended id number is 4

           SFP Detail Diagnostics Information (internal calibration)

  ----------------------------------------------------------------------------

                Current              Alarms                  Warnings

                Measurement     High        Low         High          Low

  ----------------------------------------------------------------------------

  Temperature   38.54 C        75.00 C     -5.00 C     70.00 C        0.00 C

  Voltage        3.28 V         3.63 V      2.97 V      3.46 V        3.13 V

  Current        5.50 mA       15.00 mA     2.00 mA    14.00 mA       2.50 mA

  Tx Power       -2.67 dBm       1.49 dBm  -11.30 dBm   -1.50 dBm     -7.30 dBm

  Rx Power       -3.48 dBm       1.99 dBm  -13.97 dBm   -1.00 dBm     -9.91 dBm

  ----------------------------------------------------------------------------

  Note: ++  high-alarm; +  high-warning; --  low-alarm; -  low-warning

Powershell scripts to automatically unmanage\remanage a node using the Orion SDK

$
0
0

First, I'll share the script. Then, I'll explain why we need it and how it helps us in our environment.

To use the script you must have the Orion SDK installed on the monitored node.

 

Take the text below, paste in Powershell ISE and save it as a PS1.

------------------------------------ Start PS1 -----------------------------------------------------------------

 

# 2014-07-21 Node Unmanage script for SolarWinds SDK Powershell

# by Joe Dissmeyer | Thwack - @JoeDissmeyer | Twitter - @JoeDissmeyer | www.joedissmeyer.com

# This script will unmanage a single node in the Orion database. First, it finds the node number in the Orion database, then it will unmanage it for 99 years.

# This script assumes you are running it LOCALLY from an already managed node AND that the machine has the Orion SDK v1.9 installed on it.

# If the machine is not already managed in SolarWinds this script will fail without warning.

# Replace ORIONSERVERNAME with the appropriate values.

# ORIONSERVERNAME = Your Orion poller instance. (Ex. 'SOLARWINDS01.DOMAIN.LOCAL'). Single quotes are important.

 

# Load the SolarWinds Powershell snapin. Needed in order to execute the script. Requires the Orion SDK 1.9 installed on the machine this script is running from.

Add-PSSnapin SwisSnapin

 

 

# SolarWinds user name and password section. Create an Orion local account that only has node management rights. Enter the user name and password here.

$username = "SWnodemanagement"

$password = "MyP@44w0$d"

 

# This section allows the password to be embedded in this script. Without it the script will not work.

$secstr = New-Object -TypeName System.Security.SecureString

$password .ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username,$secstr

 

# The actual job

$ORIONSERVERNAME = 'SWServer1.domain.local'

$nodename = $env:COMPUTERNAME

 

$swis = Connect-Swis -Credential $cred -host $orionservername

$nodeid = Get-SwisData $swis "SELECT NodeID FROM Orion.Nodes WHERE SysName LIKE '$nodename%'"

$now =[DateTime ]:: Now

$later =$now.AddYears(99)

Invoke-SwisVerb $swis Orion.Nodes Unmanage @("N: $nodeid ", $now ,$later , "false")

 

------------------------------------ End PS1 -----------------------------------------------------------------

 

 

 

And now the Remanage script. Again, save as a .PS1 file.

------------------------------------ Start PS1 -----------------------------------------------------------------

 

# 2014-07-21 Node Remanage script for SolarWinds SDK Powershell

# by Joe Dissmeyer | Thwack - @JoeDissmeyer | Twitter - @JoeDissmeyer | www.joedissmeyer.com

# This script will remanage a single node in the Orion database.

# This script assumes you are running it LOCALLY from an already managed node AND that the machine has the Orion SDK v1.9 installed on it.

# If the machine is not already managed in SolarWinds this script will fail without warning.

# Replace ORIONSERVERNAME with the appropriate values.

# ORIONSERVERNAME = Your Orion poller instance. (Ex. 'SOLARWINDS01.DOMAIN.LOCAL'). Single quotes are important.

 

 

# Load the SolarWinds Powershell snapin. Needed in order to execute the script. Requires the Orion SDK 1.9 installed on the machine this script is running from.

Add-PSSnapin SwisSnapin

 

 

# SolarWinds user name and password section. Create an Orion local account that only has node management rights. Enter the user name and password here.

$username = "SWnodemanagement"

$password = "MyP@44w0%d"

 

 

# This section allows the password to be embedded in this script. Without it the script will not work.

$secstr = New-Object -TypeName System.Security.SecureString

$password .ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username,$secstr

 

 

# The actual job

$ORIONSERVERNAME = 'SWServer1.domain.local'

$nodename = $env:COMPUTERNAME

 

 

$swis = Connect-Swis -Credential $cred -host $orionservername

$nodeid = Get-SwisData $swis "SELECT NodeID FROM Orion.Nodes WHERE SysName LIKE '$nodename%'"

$now =[DateTime ]:: Now

$later =$now.AddYears(99)

Invoke-SwisVerb $swis Orion.Nodes Remanage @("N: $nodeid ", $now ,$later , "false")

 

------------------------------------ End PS1 -----------------------------------------------------------------

 

Explanation:

My company had a very unique need to monitor our enterprise Windows application that runs not only on standard desktop PCs, but also runs on mobile tablets connected to WiFi access points. These tablets run the standard Windows 7 Professional OS so it makes it easy to set up application monitoring in SolarWinds SAM for these machines. However, the problem comes at the end of the day when these tablets are turned off and placed in their charging docks for the night. As you can imagine, this creates an administrative nightmare (not to mention an email alert flood) in SolarWinds when this happens.

 

SolarWinds Orion NPM and SAM is designed to always keep an eye on a node or application that is entered in it's database. It is not designed to monitor an application or node only "part of the time" --- well, at least it isn't designed for this purpose out of the box. So instead, we have to create a workaround that will suit our needs. What we needed to do was figure out how to automatically "unmanage" these Windows tablet PCs in SolarWinds when they are shut down for the night, but also automatically "re-manage" them once they boot up. This is where the script comes into play.

 

The idea is to take the Unmanage script and apply it as a shut down script in Group Policy, then take the Remanage script and apply it as a boot up script in Group Policy.

Here is why this works for us:

The business is supposed to gracefully shut down the tablet by clicking Start > Shut down. If not, then an email alert triggers that informs us that the application is down on the machine.

If the tablet goes offline in the middle of the day for any reason, we will receive an email alert about that node.

When the machine is shut down properly, the node is automatically unmanaged in SolarWinds.

When the machine boots up and someone logs into the machine, the node is automatically remanaged in SolarWinds.

 

But here is an even better use for these scripts --- Scheduled Server Maintenance! How many times have we, server administrators, had to patch Windows Servers during scheduled maintenance hours? Normally you would have to go into SolarWinds and unmanage the node first BEFORE rebooting as not to trigger an email alert. Well with these scripts you wouldn't have to worry about that as much since this would be automatic.

 

Final notes:

Of course, this is just one way to go about auto-managing nodes in SolarWinds. There are some alternatives to doing this using the Orion SDK and Powershell which is to, instead, use the built-in .NET properties in Powershell 2.0 to access the Orion SQL database directly, find the node ID, and unmanage it in that manner. For those that are interested in how do to this without the Orion SDK, let me know and I'd be happy to elaborate.

Exporting Items to CSV via SWIS

$
0
0

Hi Folks,

I want to export Data to a CSV to compare this Data with another import CSV.

 

I already have the "wrapping" around but I can not export the Data. Is there any Powershell-Expert out there to help?

 

#Load SWIS Snapin
if (!(Get-PSSnapin | where {$_.Name -eq "SwisSnapin"})) {    Add-PSSnapin "SwisSnapin"
}
# CSV definition
$ExportFile = 'D:\_NCM_Scripts\Import\ExprtNCM.csv'

#Define Solarwinds System
$hostname = "localhost"
$username = "admin"
$password = "admin"
$cred = New-Object -typename System.Management.Automation.PSCredential -argumentlist @($username,(ConvertTo-SecureString -String $password -AsPlainText -Force))

#Connect to the System
$target = Connect-Swis -v2 -Credential $cred -Hostname $hostname

#Get all URIs of Nodes in the System
$UriBasket = Get-SwisData $target "SELECT Uri FROM Orion.Nodes"

#Loop through all URIs and get Node Properties
foreach($UriEntry in $UriBasket){
    $CustomProps = $UriEntry+'/CustomProperties'    $NodeProps = Get-SwisObject $target $UriEntry  $NodeCustomProps = Get-SwisObject $target $CustomProps

write-host $NodeProps.Caption
}



 

I would like to get $NodeProps.Caption etc into a CSV File, I can already access them by the Variables..I just don't know how to build my CSV File in Powershell.

As you can see I can already access the Data I want in the write-host statement

 

Thanks for any help

Orion SDK does not provoke Auditing Events?

$
0
0

I'm working on a perl library that will, among other things, slurp a family of Custom Properties out of our CRM and into SolarWinds NPM Nodes.  I'm noticing that when I use the web interface to manually edit a Custom Property, an Auditing Event appears in the Node Summary widget we have defined for 'Last 5 Audit Events', which selects from all possible event types related to the node.  When I run my perl script to edit these same Custom Properties, no Audit Events appear.

 

From playing in the Message Center, I find that if I do a search for events generated by my own username (using %jlellis% rather than the *jlelllis* I expected) then I do get my own events for actions performed through the web gui.  If I do the same search for actions taken by the account I created specifically for use by perl scripts, I get zippo.  It appears that nothing done through the perl SDK is being tracked by the Auditing system.

 

My assumption is that SWIS and/or the SDK has not been updated to automatically create the Auditing Events new in 10.4.  For security purposes, I would expect that something beyond the SDK would be responsible for tracking these events.  Are there plans to ensure SWIS/SDK operations are also generating appropriate Auditing Events without us having to generate them in our own code?

 

This seems like an Auditing hole big enough to drive a semi through.  I could write a script to destroy our tables and there would be nothing tracking it.  Tsk.

Changes to SDK-Scripts when using NCM 7.3.x

$
0
0

Hi Folks,

my Customer just upgraded to NCM 7.3.2.

We are still on SDK 1.6

 

We have a script running that parses a CSV File and this script adds/removes/updates Nodes.

With the "old" NCM we were adding/removing/updating Nodes in Both Databases.

e.g.

 

$targetNodeUri = Get-SwisData $target "SELECT Uri FROM Orion.Nodes WHERE IPAddress=@ip" @{ip=$entry.IP_ADRESSE}
$targetNCMUri = Get-SwisData $target "SELECT Uri FROM Cirrus.Nodes WHERE AgentIP=@aip" @{aip=$entry.IP_ADRESSE}
$targetNodeID = Get-SwisData $target "SELECT NodeID FROM Orion.Nodes WHERE IPAddress=@ip" @{ip=$entry.IP_ADRESSE}

 

After the Upgrade it seems only the Removal of Nodes is causing Problems. When we run the Command:

 

                        if($entry ImportedByAPI -eq 1){  $targetNodeUri = Get-SwisData $target "SELECT Uri FROM Orion.Nodes WHERE IPAddress=@ip" @{ip=$entry.IP_ADRESSE}  $targetNCMID = Get-SwisData $target "SELECT NodeID, AgentIP FROM Cirrus.Nodes WHERE AgentIP=@aip" @{aip=$entry.IP_ADRESSE}  Remove-SwisObject $target $targetNodeUri  Invoke-SwisVerb $target Orion.Nodes RemoveNode @($targetNCMID.NodeID)|Out-Null  }

 

Is removing from NCM obsolete?

It is sufficient to just remove the Node from "Orion"

 

 

How about Adding Nodes? We still run the Command  "AddNodeToNCM"

 

Invoke-SwisVerb $target Cirrus.Nodes AddNodeToNCM $newNode.NodeID > $null
$newNCMUri = Get-SwisData $target "SELECT Uri FROM Cirrus.Nodes WHERE AgentIP=@aip" @{aip=$entry.IP_ADRESSE}
Set-SwisObject $target $newNCMUri -Properties $NCMProperties

 

Is this still OK? or do we need to Change this as well.

I was looking for Information on the changes in 7.3.2 but was not able to find any documents. If someone could point me in the right direction this would be great.

The Change to NCM 7.3.2 was a necessary "emergency update" because we were having huge issues with the web-console so now we have to adjust everything that is running in the background as well.

 

Thanks for further Information

Holger

Any good links for queries on the REST API using JavaScript?

$
0
0

Subject line says it all.  I've been trying to figure it out, but I get a 500 error with every format I've tried. 

Where to add Access-Control-Allow-Origin?

$
0
0

Hi all, I'm trying to poll data from the REST API, only I can't get that data because of an access-control-allow-origin header error.  I've tried adding the appropriate xml data to the web config for both the inetpub and solarwinds web.config files, but I still see the error.  Does anyone know where I should add the header info to talk Solarwinds into allowing the ajax request cross-domain? 

 

I'm running IIS 7.5.  I restarted the server after making the change below.

 

The information I added to the web.config file is below. (I would swap the "*" for a specific origin once I got this working.)

 

<customHeaders>

      <add name="Access-Control-Allow-Origin" value="*" />

      <add name="Access-Control-Allow-Methods" value="GET,PUT,POST,DELETE,OPTIONS" />

      <add name="Access-Control-Allow-Headers" value="Content-Type" />

      </customHeaders>

    </httpProtocol>

 

 

Any one have any ideas? 


How to access Orion REST/JSON API using Java?

$
0
0

Hi ,

 

  Please provide Java client code  to access  Orion REST/JSON API.

Powershell scripts to automatically unmanage\remanage a node using the Orion SDK

$
0
0

First, I'll share the script. Then, I'll explain why we need it and how it helps us in our environment.

To use the script you must have the Orion SDK installed on the monitored node.

 

Take the text below, paste in Powershell ISE and save it as a PS1.

------------------------------------ Start PS1 -----------------------------------------------------------------

 

# 2014-07-21 Node Unmanage script for SolarWinds SDK Powershell

# by Joe Dissmeyer | Thwack - @JoeDissmeyer | Twitter - @JoeDissmeyer | www.joedissmeyer.com

# This script will unmanage a single node in the Orion database. First, it finds the node number in the Orion database, then it will unmanage it for 99 years.

# This script assumes you are running it LOCALLY from an already managed node AND that the machine has the Orion SDK v1.9 installed on it.

# If the machine is not already managed in SolarWinds this script will fail without warning.

# Replace ORIONSERVERNAME with the appropriate values.

# ORIONSERVERNAME = Your Orion poller instance. (Ex. 'SOLARWINDS01.DOMAIN.LOCAL'). Single quotes are important.

 

# Load the SolarWinds Powershell snapin. Needed in order to execute the script. Requires the Orion SDK 1.9 installed on the machine this script is running from.

Add-PSSnapin SwisSnapin

 

 

# SolarWinds user name and password section. Create an Orion local account that only has node management rights. Enter the user name and password here.

$username = "SWnodemanagement"

$password = "MyP@44w0$d"

 

# This section allows the password to be embedded in this script. Without it the script will not work.

$secstr = New-Object -TypeName System.Security.SecureString

$password .ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username,$secstr

 

# The actual job

$ORIONSERVERNAME = 'SWServer1.domain.local'

$nodename = $env:COMPUTERNAME

 

$swis = Connect-Swis -Credential $cred -host $orionservername

$nodeid = Get-SwisData $swis "SELECT NodeID FROM Orion.Nodes WHERE SysName LIKE '$nodename%'"

$now =[DateTime ]:: Now

$later =$now.AddYears(99)

Invoke-SwisVerb $swis Orion.Nodes Unmanage @("N: $nodeid ", $now ,$later , "false")

 

------------------------------------ End PS1 -----------------------------------------------------------------

 

 

 

And now the Remanage script. Again, save as a .PS1 file.

------------------------------------ Start PS1 -----------------------------------------------------------------

 

# 2014-07-21 Node Remanage script for SolarWinds SDK Powershell

# by Joe Dissmeyer | Thwack - @JoeDissmeyer | Twitter - @JoeDissmeyer | www.joedissmeyer.com

# This script will remanage a single node in the Orion database.

# This script assumes you are running it LOCALLY from an already managed node AND that the machine has the Orion SDK v1.9 installed on it.

# If the machine is not already managed in SolarWinds this script will fail without warning.

# Replace ORIONSERVERNAME with the appropriate values.

# ORIONSERVERNAME = Your Orion poller instance. (Ex. 'SOLARWINDS01.DOMAIN.LOCAL'). Single quotes are important.

 

 

# Load the SolarWinds Powershell snapin. Needed in order to execute the script. Requires the Orion SDK 1.9 installed on the machine this script is running from.

Add-PSSnapin SwisSnapin

 

 

# SolarWinds user name and password section. Create an Orion local account that only has node management rights. Enter the user name and password here.

$username = "SWnodemanagement"

$password = "MyP@44w0%d"

 

 

# This section allows the password to be embedded in this script. Without it the script will not work.

$secstr = New-Object -TypeName System.Security.SecureString

$password .ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username,$secstr

 

 

# The actual job

$ORIONSERVERNAME = 'SWServer1.domain.local'

$nodename = $env:COMPUTERNAME

 

 

$swis = Connect-Swis -Credential $cred -host $orionservername

$nodeid = Get-SwisData $swis "SELECT NodeID FROM Orion.Nodes WHERE SysName LIKE '$nodename%'"

$now =[DateTime ]:: Now

$later =$now.AddYears(99)

Invoke-SwisVerb $swis Orion.Nodes Remanage @("N: $nodeid ", $now ,$later , "false")

 

------------------------------------ End PS1 -----------------------------------------------------------------

 

Explanation:

My company had a very unique need to monitor our enterprise Windows application that runs not only on standard desktop PCs, but also runs on mobile tablets connected to WiFi access points. These tablets run the standard Windows 7 Professional OS so it makes it easy to set up application monitoring in SolarWinds SAM for these machines. However, the problem comes at the end of the day when these tablets are turned off and placed in their charging docks for the night. As you can imagine, this creates an administrative nightmare (not to mention an email alert flood) in SolarWinds when this happens.

 

SolarWinds Orion NPM and SAM is designed to always keep an eye on a node or application that is entered in it's database. It is not designed to monitor an application or node only "part of the time" --- well, at least it isn't designed for this purpose out of the box. So instead, we have to create a workaround that will suit our needs. What we needed to do was figure out how to automatically "unmanage" these Windows tablet PCs in SolarWinds when they are shut down for the night, but also automatically "re-manage" them once they boot up. This is where the script comes into play.

 

The idea is to take the Unmanage script and apply it as a shut down script in Group Policy, then take the Remanage script and apply it as a boot up script in Group Policy.

Here is why this works for us:

The business is supposed to gracefully shut down the tablet by clicking Start > Shut down. If not, then an email alert triggers that informs us that the application is down on the machine.

If the tablet goes offline in the middle of the day for any reason, we will receive an email alert about that node.

When the machine is shut down properly, the node is automatically unmanaged in SolarWinds.

When the machine boots up and someone logs into the machine, the node is automatically remanaged in SolarWinds.

 

But here is an even better use for these scripts --- Scheduled Server Maintenance! How many times have we, server administrators, had to patch Windows Servers during scheduled maintenance hours? Normally you would have to go into SolarWinds and unmanage the node first BEFORE rebooting as not to trigger an email alert. Well with these scripts you wouldn't have to worry about that as much since this would be automatic.

 

Final notes:

Of course, this is just one way to go about auto-managing nodes in SolarWinds. There are some alternatives to doing this using the Orion SDK and Powershell which is to, instead, use the built-in .NET properties in Powershell 2.0 to access the Orion SQL database directly, find the node ID, and unmanage it in that manner. For those that are interested in how do to this without the Orion SDK, let me know and I'd be happy to elaborate.

Orion SDK does not provoke Auditing Events?

$
0
0

I'm working on a perl library that will, among other things, slurp a family of Custom Properties out of our CRM and into SolarWinds NPM Nodes.  I'm noticing that when I use the web interface to manually edit a Custom Property, an Auditing Event appears in the Node Summary widget we have defined for 'Last 5 Audit Events', which selects from all possible event types related to the node.  When I run my perl script to edit these same Custom Properties, no Audit Events appear.

 

From playing in the Message Center, I find that if I do a search for events generated by my own username (using %jlellis% rather than the *jlelllis* I expected) then I do get my own events for actions performed through the web gui.  If I do the same search for actions taken by the account I created specifically for use by perl scripts, I get zippo.  It appears that nothing done through the perl SDK is being tracked by the Auditing system.

 

My assumption is that SWIS and/or the SDK has not been updated to automatically create the Auditing Events new in 10.4.  For security purposes, I would expect that something beyond the SDK would be responsible for tracking these events.  Are there plans to ensure SWIS/SDK operations are also generating appropriate Auditing Events without us having to generate them in our own code?

 

This seems like an Auditing hole big enough to drive a semi through.  I could write a script to destroy our tables and there would be nothing tracking it.  Tsk.

Trouble getting the Java Client example to work

$
0
0

Hello

I am trying to get the JavaClient example from the SDK to work. Here is the error I keep getting:

 

 

 

 

 

 

Exception in thread "main"

 

 

javax.xml.ws.WebServiceException: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException

: Connection reset

at com.sun.xml.internal.ws.streaming.TidyXMLStreamReader.close(Unknown Source)

at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(Unknown Source)

at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(Unknown Source)

at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(Unknown Source)

at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)

at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)

at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(Unknown Source)

at javax.xml.ws.Service.<init>(Unknown Source)

at org.tempuri.InformationService_Service.<init>(

 

 

InformationService_Service.java:46

)

at SwisClient.getSwisClient(

 

 

SwisClient.java:90

)

at SwisClient.main(

 

 

SwisClient.java:42

)

Caused by:

 

 

javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException

: Connection reset

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkEOF(Unknown Source)

at com.sun.net.ssl.internal.ssl.AppInputStream.available(Unknown Source)

at java.io.BufferedInputStream.available(Unknown Source)

at sun.net.www.MeteredStream.available(Unknown Source)

at sun.net.www.http.KeepAliveStream.close(Unknown Source)

at java.io.FilterInputStream.close(Unknown Source)

at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.close(Unknown Source)

... 11 more

Caused by:

 

 

javax.net.ssl.SSLException: java.net.SocketException

: Connection reset

at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(Unknown Source)

at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source)

at java.io.BufferedInputStream.fill(Unknown Source)

at java.io.BufferedInputStream.read1(Unknown Source)

at java.io.BufferedInputStream.read(Unknown Source)

at sun.net.www.MeteredStream.read(Unknown Source)

at java.io.FilterInputStream.read(Unknown Source)

at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(Unknown Source)

at com.sun.org.apache.xerces.internal.impl.XMLEntityManager$RewindableInputStream.read(Unknown Source)

at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(Unknown Source)

at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(Unknown Source)

at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.scanQName(Unknown Source)

at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)

at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)

at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)

at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(Unknown Source)

at com.sun.xml.internal.ws.util.xml.XMLStreamReaderFilter.next(Unknown Source)

at com.sun.xml.internal.ws.streaming.XMLStreamReaderUtil.next(Unknown Source)

at com.sun.xml.internal.ws.streaming.XMLStreamReaderUtil.nextContent(Unknown Source)

at com.sun.xml.internal.ws.streaming.XMLStreamReaderUtil.nextElementContent(Unknown Source)

at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parseBindingOperation(Unknown Source)

at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(Unknown Source)

... 10 more

Caused by:

 

 

java.net.SocketException

: Connection reset

Any help would be greatly appreciated

Can I have query get NPM(i.e, interface and node) related data by using queyXML()?

$
0
0

Hi ,

 

   I am trying get Network Performance related monitoring data from server using Orion SDK'squeryXML() method.

Here I have Interface, Node and InterfaceTraffic tables in Orion SDK's data base.

What are tables need to join to prepare the query to get data?.

what is the relationship between these three tables above mentioned.

 

Please help on this.  It will be  much appreciated .

 

Thanks .

How do we programmatically discover the non-interface properties [in Orion] and enable them

$
0
0

We are automating the hydration of assets in Orion, and after adding a node, we know how to discover the interfaces, but how do we programmatically discover the non-interface properties and enable them like the sample below?Orion interface discovery ss.png


Thanks,

Scott F.


Full documentation of Orion SDK verbs?

$
0
0

Hello,

 

In the latest version of the SolarWinds Technical Reference for the Orion Software Development Kit there is a section called "Some Useful Verbs".  However, by both it's own name and by how I have seen others used here on Thwack I know that this is not the full list of verbs.

 

Is there any documentation, official or otherwise, of a full list of what verbs are available and for what operations within the Orion SDK?  The Tech Ref document is lacking such a list, and even the "Some Useful Verbs" section lacks some verbs that are used elsewhere in the same document.


Help with Volume Information in SolarWinds

$
0
0

Hello

 

I am try to automate adding nodes into SolarWinds for a project we have going. I am able to add the Node to be managed with ICMP and WMI and polling for CPU and Memory utilization without any issues. I've been using the Powershell snapins to accomplish this. I also want to monitor the volumes and the network adapter(s) on each node that is added. I am able to add a volume but only if I provide the information for it. Because the index's change from server to server this could be a problem. Cause I don't know if index 3 is the C: drive or if it is the A: drive. Index 1 seems to normally be physical memory but from looking at all drives currently in the environment that doesn't even seem consistent.

 

So my question is, is there a way to mimic what is being done when I click "List Resources" on the web interface? Or what exactly does SolarWinds check when it pulls back this information? Since it is connection via WMI I am guessing I should be able to use a get-wmiobject cmdlet to retrieve the same information but for the Life of me I can't seem to find a class that shows "Physical Memory,Virtual Memory, Local Drives, etc". Any ideas on how this could be done? Essentially I want to be able to determine the data shown below and the indexes that SolarWinds will see them as so I can add them via a script rather than manually selecting the drives on hundreds of servers.

 

SolarWindsVolumes.jpg

 

 

Thank it in advance for any help on this matter!

Powershell scripts to automatically unmanage\remanage a node using the Orion SDK

$
0
0

First, I'll share the script. Then, I'll explain why we need it and how it helps us in our environment.

To use the script you must have the Orion SDK installed on the monitored node.

 

Take the text below, paste in Powershell ISE and save it as a PS1.

------------------------------------ Start PS1 -----------------------------------------------------------------

 

# 2014-07-21 Node Unmanage script for SolarWinds SDK Powershell

# by Joe Dissmeyer | Thwack - @JoeDissmeyer | Twitter - @JoeDissmeyer | www.joedissmeyer.com

# This script will unmanage a single node in the Orion database. First, it finds the node number in the Orion database, then it will unmanage it for 99 years.

# This script assumes you are running it LOCALLY from an already managed node AND that the machine has the Orion SDK v1.9 installed on it.

# If the machine is not already managed in SolarWinds this script will fail without warning.

# Replace ORIONSERVERNAME with the appropriate values.

# ORIONSERVERNAME = Your Orion poller instance. (Ex. 'SOLARWINDS01.DOMAIN.LOCAL'). Single quotes are important.

 

# Load the SolarWinds Powershell snapin. Needed in order to execute the script. Requires the Orion SDK 1.9 installed on the machine this script is running from.

Add-PSSnapin SwisSnapin

 

 

# SolarWinds user name and password section. Create an Orion local account that only has node management rights. Enter the user name and password here.

$username = "SWnodemanagement"

$password = "MyP@44w0$d"

 

# This section allows the password to be embedded in this script. Without it the script will not work.

$secstr = New-Object -TypeName System.Security.SecureString

$password .ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username,$secstr

 

# The actual job

$ORIONSERVERNAME = 'SWServer1.domain.local'

$nodename = $env:COMPUTERNAME

 

$swis = Connect-Swis -Credential $cred -host $orionservername

$nodeid = Get-SwisData $swis "SELECT NodeID FROM Orion.Nodes WHERE SysName LIKE '$nodename%'"

$now =[DateTime ]:: Now

$later =$now.AddYears(99)

Invoke-SwisVerb $swis Orion.Nodes Unmanage @("N: $nodeid ", $now ,$later , "false")

 

------------------------------------ End PS1 -----------------------------------------------------------------

 

 

 

And now the Remanage script. Again, save as a .PS1 file.

------------------------------------ Start PS1 -----------------------------------------------------------------

 

# 2014-07-21 Node Remanage script for SolarWinds SDK Powershell

# by Joe Dissmeyer | Thwack - @JoeDissmeyer | Twitter - @JoeDissmeyer | www.joedissmeyer.com

# This script will remanage a single node in the Orion database.

# This script assumes you are running it LOCALLY from an already managed node AND that the machine has the Orion SDK v1.9 installed on it.

# If the machine is not already managed in SolarWinds this script will fail without warning.

# Replace ORIONSERVERNAME with the appropriate values.

# ORIONSERVERNAME = Your Orion poller instance. (Ex. 'SOLARWINDS01.DOMAIN.LOCAL'). Single quotes are important.

 

 

# Load the SolarWinds Powershell snapin. Needed in order to execute the script. Requires the Orion SDK 1.9 installed on the machine this script is running from.

Add-PSSnapin SwisSnapin

 

 

# SolarWinds user name and password section. Create an Orion local account that only has node management rights. Enter the user name and password here.

$username = "SWnodemanagement"

$password = "MyP@44w0%d"

 

 

# This section allows the password to be embedded in this script. Without it the script will not work.

$secstr = New-Object -TypeName System.Security.SecureString

$password .ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username,$secstr

 

 

# The actual job

$ORIONSERVERNAME = 'SWServer1.domain.local'

$nodename = $env:COMPUTERNAME

 

 

$swis = Connect-Swis -Credential $cred -host $orionservername

$nodeid = Get-SwisData $swis "SELECT NodeID FROM Orion.Nodes WHERE SysName LIKE '$nodename%'"

$now =[DateTime ]:: Now

$later =$now.AddYears(99)

Invoke-SwisVerb $swis Orion.Nodes Remanage @("N: $nodeid ", $now ,$later , "false")

 

------------------------------------ End PS1 -----------------------------------------------------------------

 

Explanation:

My company had a very unique need to monitor our enterprise Windows application that runs not only on standard desktop PCs, but also runs on mobile tablets connected to WiFi access points. These tablets run the standard Windows 7 Professional OS so it makes it easy to set up application monitoring in SolarWinds SAM for these machines. However, the problem comes at the end of the day when these tablets are turned off and placed in their charging docks for the night. As you can imagine, this creates an administrative nightmare (not to mention an email alert flood) in SolarWinds when this happens.

 

SolarWinds Orion NPM and SAM is designed to always keep an eye on a node or application that is entered in it's database. It is not designed to monitor an application or node only "part of the time" --- well, at least it isn't designed for this purpose out of the box. So instead, we have to create a workaround that will suit our needs. What we needed to do was figure out how to automatically "unmanage" these Windows tablet PCs in SolarWinds when they are shut down for the night, but also automatically "re-manage" them once they boot up. This is where the script comes into play.

 

The idea is to take the Unmanage script and apply it as a shut down script in Group Policy, then take the Remanage script and apply it as a boot up script in Group Policy.

Here is why this works for us:

The business is supposed to gracefully shut down the tablet by clicking Start > Shut down. If not, then an email alert triggers that informs us that the application is down on the machine.

If the tablet goes offline in the middle of the day for any reason, we will receive an email alert about that node.

When the machine is shut down properly, the node is automatically unmanaged in SolarWinds.

When the machine boots up and someone logs into the machine, the node is automatically remanaged in SolarWinds.

 

But here is an even better use for these scripts --- Scheduled Server Maintenance! How many times have we, server administrators, had to patch Windows Servers during scheduled maintenance hours? Normally you would have to go into SolarWinds and unmanage the node first BEFORE rebooting as not to trigger an email alert. Well with these scripts you wouldn't have to worry about that as much since this would be automatic.

 

Final notes:

Of course, this is just one way to go about auto-managing nodes in SolarWinds. There are some alternatives to doing this using the Orion SDK and Powershell which is to, instead, use the built-in .NET properties in Powershell 2.0 to access the Orion SQL database directly, find the node ID, and unmanage it in that manner. For those that are interested in how do to this without the Orion SDK, let me know and I'd be happy to elaborate.

Orion API via PHP

$
0
0

One of the things I have been tasked with doing is understanding the API to see if we can use it for some of our reporting. I reviewed the Orion API documentation and there aren’t any PHP examples. I also can not find any such examples in thwack. Can anyone help me with an example? I have spent some time trying to figure this out and I can’t tell if I am doing something wrong or if SWIS is even available.

Using Powershell to add nodes with Custom Properties for Device Type

$
0
0

Hello,
Running Orion NPM 10.6.0 and SDK 1.7 on Win2k8R2

 

Can anyone help with adding devices into Orion using Powershell?

 

To complete via NPM Web console, select Management, Edit Node.
Select groups, break down the group to a specific node.
Choose node properties, then edit node.
Custom properties show Device_Type:

12-4-2013 3-35-46 PM.png

 

Sample script adding a server fails for the custom properties:
---------------

Add-PSSnapin SwisSnapin

# initialize SWIS connection
$swis = Connect-Swis -Certificate

# add a node
$newNodeProps = @
{
EntityType="Orion.NodesCustomProperties";
DisplayName="servername_here";
Device_Type="Server_Windows";
}

$newNodeUri = New-SwisObject $swis –EntityType "Orion.NodesCustomProperties" –Properties $newNodeProps

$nodeProps = Get-SwisObject $swis -Uri $newNodeUri Orion.Nodes

Output:
PS C:\> $newNodeUri = New-SwisObject $swis -EntityType "Orion.NodesCustomProperties" -Properties $newNodeProps
New-SwisObject : Cannot bind argument to parameter 'Properties' because it is null.
At line:1 char:89
+ $newNodeUri = New-SwisObject $swis -EntityType "Orion.NodesCustomProperties" -Properties <<<<  $newNodeProps
    + CategoryInfo          : InvalidData: (:) [New-SwisObject], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,SwisPowerShell.NewSwisObject

PS C:\>


Similar blog = http://thwack.solarwinds.com/message/163190#163190

PowerShell Module based on the SDK

$
0
0

Hi All,

 

I started working on a PowerShell module, converting existing code examples in the SDK to “Cmdlets” Functions.  The ultimate goal is to just make it easier to re-use code. My own use case in particular arose from just wanting to simplify automating primarily working with SAM & NPM nodes, but I thought this may be of interest to others, so I’m going to share it on Codeplex as well. By posting it there not only can you can get a copy of the current code, but it also allows you to submit any changes you may make back in to the main code, which will ultimately lead to more functionality, and faster ( this is just a personal project, and not a SolarWinds one, so the code is offered as-is. Plus as I'm just doing this in free-time, so it may not get updated as frequently or as often as I would ).


Why A Module?

Converting this code into a module has several benefits:

  • By creating Cmdlets, actions can be performed much faster. For example, to add nodes, rather than editing a script and calling that, you can now just call something like

$swis=Connect-Swis-UserNameadmin-Password""-Hostname10.160.5.75

New-OrionNode-SwisConnection$swis-IPAddress10.160.5.10             

What this boils down to is when writing your own scripts, these can now be much smaller in size, and faster to develop, as a lot of the “plumbing” is already done (instead of having to copy and paste a 75 line script, you can now achieve the same in a couple of lines).    

  • It’s more intuitive, and fits conventional PowerShell Verb-Noun naming conventions. Plus, the  documentation is built-in, so calling the Get-Help command can return help and examples, the same as standard Cmdlets.

PowerOrionGet-Help Example.jpg

  • By building in error handling, and through the use of defaults and parameter sets, there is less chance for user error. For example, when building statements in either the console or the IDE it can prompt on possible options for parameters.

PowerOrion Parameters Populated.jpg


What functionality is available at present? 
At the moment it’s very much version 0.0.1, and contains a few helper Cmdlets, plus the ability to Add ICMP Nodes, Remove Nodes, and retrieve properties. Next on the to-do list is (and this is just a wishlist, so depending on time, these may or may not be completed)

  1. Adding in SNMP nodes
  2. Adding in volumes and interfaces
  3. Adding in WMI nodes
  4. Managing applications
  5. Setting custom properties

 

EDIT: Technically these are "advanced functions" and not "Cmdlets". From a users perspective they are essentially the same, the only difference being in how the code is written: Cmdlets are written in C#, advanced functions are written in PowerShell

Viewing all 3719 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>