1. That works a treat - thanks for that.
2. Yup - I've seen how to add an interface in the SDK.pdf. So this leads to another question - what does Orion regard as the primary address for a device (say a server)? Is it the details containted in the Orion.nodes -> IPAddress value? Or is it the interface object related to the server with an index of 0? (or do i need to always add at least one interface to a node when adding in this way?)
4. The queries I've been trying look like this:
$mynode = 'SELECT NodeID, caption From Orion.Nodes where Caption="Testnode"'
Get-SwisData $swis $mynode
Error comes back as: Get-SwisData : Cannot resolve property Testnode.
Seems to work ok if i query on where NodeID=1 or variations on that.
2. Yes, you are right. The primary address for communication with a device is a value available in the IPAddress property of the Orion.Nodes entity.
4. The quotes in your query are not recognized by SWQL. String literals needs to enclosed in a pair of apostrophes. Try to use:
SELECT NodeID, caption From Orion.Nodes where Caption='Testnode'
I'm trying to find a way to automate adding new nodes. These nodes will be SNMP nodes with Custom Properties set and whatever other parameters necessary to make it work. One problem I see is if I add a node using a script, then want to add Custom Properties, I have to know the NodeID to do that.I've been trying without success to write a query to get that info so I can go on and add Custom Properties to the node. I can run a query successfully if I already know the NodeID;
Get-SwisData $swis 'SELECT NodeID, Caption FROM Orion.Nodes WHERE NodeID=18'
NodeID Caption
------ -------
18 106 (Z23) Sacramento, CA
But how would I find the NodeID of that node with a query? I've tried using LIKE in the query, but can't seem to find a way to specify '106%' to match the node Caption above in order to get that node information. I've tried these queries without success;
Get-SwisData $swis 'SELECT NodeID, Caption FROM Orion.Nodes WHERE Caption like "106%"'
Get-SwisData $swis 'SELECT NodeID, Caption FROM Orion.Nodes WHERE Caption like '106%''
Get-SwisData $swis 'SELECT NodeID, Caption FROM Orion.Nodes WHERE Caption like "%Sacramento%"'
Is there a guide to using queries under PS for Orion? The examples in the SDK book don't give a novice like me enough information to help me get this done. Enclosing the SELECT statement in apostrophes changes the way the query works.
OR, is there a better way to do this?
SWIS recognizes single-quotes as string delimiters, so you may use double-quotes to delimit the query and single-quotes to delimit a string literal inside. E.g.:
Get-SwisData $swis "SELECT NodeID, Caption FROM Orion.Nodes WHERE Caption like '106%' "
Other than that, when you add a node to Orion, you receive a SWIS URI for the new Orion.Nodes entity you can use in other CRUD operations. E.g. if you use the Read operation to get the properties of the node, you can easily get NodeID directly: (fragment taken from the SDK PS sample):
# $newNodeUri is what you receive from the Create operation
$nodeProps = Get-SwisObject $swis -Uri $newNodeUri
$nodeId = $nodeProps["NodeID"];
# $nodeId contains the NodeID of the node
Following the example in the book for setting the Custom Properties of the node, everything seems to be set correctly. But when I issue the Set-SwisObject command it errors out;
PS H:\> $nodeId
2373
PS H:\> $customProps = @{
>> Comments="Franchise Router";
>> NodeID=$nodeId;
>> Building="Franchise";
>> Country="USA";
>> Franchise="True";
>> FranData="True";
>> FranServers="False";
>> HQ_Critical="False";
>> HQData="True";
>> HQServers="False";
>> HQWksta="False";
>> iSeries="False";
>> PhoneSys="False";
>> Remote="True";
>> Service_Provider="Sprint";
>> Service_Type="";
>> SpecialCase="False";
>> State=$nnST;
>> Virtual="False";
>> DisplayName="";
>> Description="";
>> }
>> # build the node URI
>> $uri = "swis://localhost/Orion/Orion.Nodes/NodeID=$nodeId/CustomProperties";
>> # set the custom property
>> Set-SwisObject $swis -Uri $uri -Properties $customProps
>>
Set-SwisObject : Object reference not set to an instance of an object.
At line:27 char:15
+ Set-SwisObject <<<< $swis -Uri $uri -Properties $customProps
+ CategoryInfo : NotSpecified: (:) [Set-SwisObject], NullReferenceException
+ FullyQualifiedErrorId : System.NullReferenceException,SwisPowerShell.SetSwisObject
It seems to be saying the value for $swis is set incorrectly. This is what it looks like;
OperationTimeout Channel ClientChannel
---------------- ------- -------------
01:00:00 SolarWinds.InformationService.Contra... SolarWinds.InformationService.Contra...
What's wrong and how would I troubleshoot this?
PowerShell is a bit stingy with error output by default, and I can't figure out what is going wrong from what it has printed here. Try using this function to get some more details:
http://blogs.msdn.com/b/powershell/archive/2006/12/07/resolve-error.aspx
Then I bet we can figure it out.
Here it is. I thought maybe it was rejecting the "True" and "False" values for the Custom Properties, so I changed them to $True and $False, but it didn't change the result.;
PS H:\> rver
PSMessageDetails :
Exception : System.ServiceModel.FaultException: Update failed, check fault information.
Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation,
ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOper
ationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOper
ationRuntime operation, Object[] ins, Object[] outs)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodC
all, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage r
etMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at SolarWinds.InformationService.Contract2.IInformationService.Update(String uri, PropertyBa
g propertiesToUpdate)
at SolarWinds.InformationService.Contract2.InfoServiceProxy.Update(String uri, PropertyBag p
ropertiesToUpdate)
at SwisPowerShell.SetSwisObject.InternalProcessRecord()
at SwisPowerShell.BaseSwisCmdlet.ProcessRecord()
TargetObject :
CategoryInfo : InvalidOperation: (:) [Set-SwisObject], FaultException
FullyQualifiedErrorId : SwisError,SwisPowerShell.SetSwisObject
ErrorDetails : Update failed, check fault information.
InvocationInfo : System.Management.Automation.InvocationInfo
PipelineIterationInfo : {0, 1}
MyCommand : Set-SwisObject
BoundParameters : {[Uri, swis://localhost/Orion/Orion.Nodes/NodeID=2374/CustomProperties], [Properties, System.Collect
ions.Hashtable], [SwisConnection, SolarWinds.InformationService.Contract2.InfoServiceProxy]}
UnboundArguments : {}
ScriptLineNumber : 46
OffsetInLine : 15
HistoryId : 166
ScriptName :
Line : Set-SwisObject $swis -Uri $uri -Properties $customProps
PositionMessage :
At line:46 char:15
+ Set-SwisObject <<<< $swis -Uri $uri -Properties $customProps
InvocationName : Set-SwisObject
PipelineLength : 1
PipelinePosition : 1
ExpectingInput : False
CommandOrigin : Runspace
00000000000000000000000000000000000000000000000000000000000000000000000000000000
Action : http://schemas.solarwinds.com/2007/08/informationservice/InformationService/UpdateInfoServiceFaultCont
ractFault
Code : System.ServiceModel.FaultCode
Message : Update failed, check fault information.
Reason : Update failed, check fault information.
Data : {}
InnerException :
TargetSite : Void HandleReturnMessage(System.Runtime.Remoting.Messaging.IMessage, System.Runtime.Remoting.Messaging
.IMessage)
StackTrace :
Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRp
c& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRu
ntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRu
ntime operation, Object[] ins, Object[] outs)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, Pr
oxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at SolarWinds.InformationService.Contract2.IInformationService.Update(String uri, PropertyBag prope
rtiesToUpdate)
at SolarWinds.InformationService.Contract2.InfoServiceProxy.Update(String uri, PropertyBag properti
esToUpdate)
at SwisPowerShell.SetSwisObject.InternalProcessRecord()
at SwisPowerShell.BaseSwisCmdlet.ProcessRecord()
HelpLink :
Source : mscorlib
We're going to have to follow this another level down. Could you reproduce the error again and look in C:\ProgramData\SolarWinds\InformationService\v2.0\Orion.InformationService.log? That should have the details.
You are trying to set quite a bunch of custom properties in your script, I assume all of these are valid custom properties.
However, there is also NodeID specified in the dictionary being passed to the Set-SwisObject cmdlet which is not correct. This is a readonly property of Orion.Nodes entity type, whereas the script is updating CustomProperties navigation property of the Orion.Nodes entity. The specification of which node's custom properties should be updated is a part of the SWIS URI you are passing to Set-SwisObject.
That was it. I removed the NodeID entry and the DisplayName and Description entries and it ran correctly.
Next item - I need to add interfaces, so can I add all three interfaces at once like this;
$newIfaceProps = @{
NodeID=$nodeId; # NodeID on which the interface is working on
InterfaceName="Ethernet0";
InterfaceIndex=1;
ObjectSubType="SNMP";
Status=0;
InterfaceName="Ethernet1";
InterfaceIndex=2;
ObjectSubType="SNMP";
Status=0;
InterfaceName="FastEthernet1";
InterfaceIndex=3;
ObjectSubType="SNMP";
Status=0;
}
$newIfaceUri = New-SwisObject $swis –EntityType "Orion.NPM.Interfaces" –Properties $newIfaceProps
$ifaceProps = Get-SwisObject $swis -Uri $newIfaceUri
*****************************************************************************************
Or do I need to add them separately like this;
# First interface
$newIfaceProps = @{
NodeID=$nodeId; # NodeID on which the interface is working on
InterfaceName="Ethernet0";
InterfaceIndex=1;
ObjectSubType="SNMP";
Status=0;
}
$newIfaceUri = New-SwisObject $swis –EntityType "Orion.NPM.Interfaces" –Properties $newIfaceProps
$ifaceProps = Get-SwisObject $swis -Uri $newIfaceUri
# Second interface
$newIfaceProps = @{
NodeID=$nodeId; # NodeID on which the interface is working on
InterfaceName="Ethernet1";
InterfaceIndex=2;
ObjectSubType="SNMP";
Status=0;
}
$newIfaceUri = New-SwisObject $swis –EntityType "Orion.NPM.Interfaces" –Properties $newIfaceProps
$ifaceProps = Get-SwisObject $swis -Uri $newIfaceUri
# Third interface
$newIfaceProps = @{
NodeID=$nodeId; # NodeID on which the interface is working on
InterfaceName="FastEthernet1";
InterfaceIndex=3;
ObjectSubType="SNMP";
Status=0;
}
$newIfaceUri = New-SwisObject $swis –EntityType "Orion.NPM.Interfaces" –Properties $newIfaceProps
$ifaceProps = Get-SwisObject $swis -Uri $newIfaceUri
You have to add interfaces separately. The New-SwisObject always creates a single entity of the given type, it always returns a single SWIS URI identifying the new entity. The dictionary you pass to the cmdlet contains the initial values for the new entity, and the fact that it is a dictionary implies that there cannot be duplicate items.
So far so good. That worked.
One more question (for now). When adding pollers to the interfaces, what value goes in place of the InterfaceID?
# register specific pollers for the node
# Interface Traffic
$poller = @{
PollerType="Poller_IT";
NetObject="I:"+$ifaceProps["InterfaceID"]
}
$pollerUri = New-SwisObject $swis -EntityType "Orion.Pollers" -Properties $poller
Here's my best guess how to do it. I add an interface and then add the pollers for that interface. Repeat this for each additional interface;
# add interface and pollers for Ethernet0
$newIfaceProps = @{
NodeID=$nodeId;
InterfaceName="Ethernet0";
InterfaceIndex=1;
ObjectSubType="SNMP";
Status=0;
}
$newIfaceUri = New-SwisObject $swis –EntityType "Orion.NPM.Interfaces" –Properties $newIfaceProps
$ifaceProps = Get-SwisObject $swis -Uri $newIfaceUri
# register specific pollers for Ethernet0
# Interface Traffic
$poller = @{
PollerType="Poller_IT";
NetObject="I:"+$ifaceProps["InterfaceIndex"] ##### I changed InterfaceID to InterfaceIndex. Is that right???? #####
}
$pollerUri = New-SwisObject $swis -EntityType "Orion.Pollers" -Properties $poller
# Interface Errors
$poller = @{
PollerType="Poller_IE";
NetObject="I:"+$ifaceProps["InterfaceIndex"] ##### I changed InterfaceID to InterfaceIndex. Is that right???? #####
}
$pollerUri = New-SwisObject $swis -EntityType "Orion.Pollers" -Properties $poller
NetObject property should contain the InterfaceID (instead of InterfaceIndex). InterfaceID is the ID that Orion uses for identification of its interface objects, whereas InterfaceIndex is the SNMP index on the device.
Where does the InterfaceID come from? Is it automatically defined when an interface is added? Do I have to interrogate Orion to get it? If so, how would I do that?
InterfaceID is generated by the system once you create a new Orion.NPM.Interfaces entity. When the script reads the properties of the new entity, based on the returned URI, the properties ($ifaceProps) already contains the InterfaceID property and its value.
Is there a document that describes the properties for the different entity types? There is a table in the documentation that describes the properties for the Orion.Nodes entity type, but I don't see one for the Orion.Pollers entity type. I see an entry called Status that's set to 0. If the interface is up, shouldn't that be set to 1?Where would I find that? If there isn't one, can you give me a list of the properties and their possible values? Are there others I might need?
The SDK comes with a reference for the schema (listed as "Orion SDK/Schema Documentation" on the start menu), but it doesn't have descriptions - just a list of the entities and the properties.
For Nodes.Status, the Orion.Status entity has details about the set of possible values. '0' corresponds to "Unknown". If the node was just added and has not been polled for the first time yet, it will still be in "Unknown" status. Once it has been pinged, its Status should go to '1', which is "Up".
I added a Cisco 831 router node with Custom Properties and the Response Time poller (Poller_RT) poller and Cisco Poller (Poller_CR), and added three interfaces each with a Traffic poller (Poller_IT) and an Errors poller (Poller_IE) but it's not working right. If I look at node details, there is a lot of information missing, the interfaces don't exist and Response Time stats are the only thing displayed. There are rendering errors for Average CPU Load & Memory Utilization, Min/Max/Average of Average CPU Load, and Current Cisco Buffer Misses .
Does anyone really successfully add nodes, interfaces, and pollers using PowerShell?
I can see from your sig that you are on NPM 10.2. The names of the pollers have changed in 10.2. You can get documentation on the new poller names and some background on the change in the recently-released Orion SDK 1.4. Sorry for the inconvenience.
Once you install the Orion SDK 1.4 package (at the link in Tim's post), you can find it in the Technical Reference pdf file (there's also a shortcut in Start Menu) - page 28, chapter "Available Poller Types".
Let me know if I need to post this in a different thread, but is there a document that describes the improvements/differences between 1.3 and 1.4? I have looked at the 1.4 documentation and this SDK board, but cannot find it.
Thanks!
No, unfortunately we don't have a document listing the changes from 1.3 to 1.4, but it would definitely be helpful. We will provide a "what's changed" section for the next SDK update and in the future.
