Is it possible to configure the component properties when assigning an application with SwisPowerShell?

I have to assign monitors to an application where the port in use can be one of 27 options. In the past I have just created a different template for each port and assigned the corresponding one, but that method will be very hard in this case as I would have to create 27 monitors. Is there a way I can update the port field in the application component at the time of assignment? Alternately, updating it after assignment would also work I suppose. I see the method allows for Application Settings to be provided, but since there can be multiple components, I am unclear on how this would work. Thanks!

  • Had a look about-

    Yes you can do what you're trying to get done

    No not easy to edit that component port field in powershell as far as I can tell.


    There's a few ways of achieving this in a range of difficulties. 

    • 1)
      • Make a application template with a port monitor on it for port 1
      • duplicate 27 times changing the port once each time
        • You can powershell this by exporting the application, editing the xml, and reimporting but it's probably not faster
      • put all 27 in an application discovery, that way only the open port will be assigned
    • This is repeatable for as many servers as you have, but also if that port can change to one of the other 27 that's not ideal
    • 2)
      • Powershell monitor, tests all 27 ports, if at least 1 is up it's up
    • This will be slow to run
    • You can speed it up at cost
    • Works on both dynamic amounts of servers and dynamic ports

    etc

    Here's a powershell monitor which probably works :

    $target = '${IP}'
    $results = @()
    $resultsstring = ""
    $ports = @(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 17, 19, 20, 21, 22, 23, 24, 25, 443)
    
    foreach ($port in $ports)
    {
        $Result = Test-NetConnection -ComputerName $target -Port $port
        $line = [PSCustomObject]@{
            port   = $port
            result = $Result.TcpTestSucceeded
        }
        $results += $line  # Adds object to array"
        $resultsstring += '$port = $result
    '
    }
    
    #$results
    
    $successes = ($results | where-object -FilterScript{$_.result -eq $true} | Measure-Object).count
    
    
    
    if($successes -lt 1)
    {
        
        write-host "Statistic: $successes"
        write-host 'Message: No open port found - 
    $resultsstring'
        exit 0
    }
    
    
    if($successes -eq 1)
    {
        $openport = ($results | where-object -FilterScript{$_.result -eq $true}).port
        write-host "Statistic: $successes"
        write-host "Message: All Ok - $openport open"
        exit 0
    }
    
    if($successes -gt 1)
    {
        $openport = ($results | where-object -FilterScript{$_.result -eq $true}).port
        write-host "Statistic: $successes"
        write-host 'Message: Too many open ports found - 
    $resultsstring'
        exit 1
    }

  • I already have a script that will assign the correct monitors based on the system type. I was just hoping there was a way to avoid making the separate application template for each port. It sounds like there is no way to specify the port at the time of assignment. Your idea to do a script that runs from the Polling Engine is a good one though. I will think it over for a bit. Thanks!

    Edit: I forgot to mention that not all the ports will be in use. There are actually 57 total that we will have to check, but most likely only a handful of them would be used. There is a REST API I can use to get the port assignments. I typically just have a template for each port and assign the ones I need. This is just an extreme case so I wanted to see if there were any other options.  The script you suggested is good idea, but would have to also get those port assignments each time so not sure it is the best option in this case. I do appreciate your time though and thanks again! 

  • There's more wizardry possible, depends how often you'd reuse it really - You could have one application template that checks the total list of 57 (for example), then outputs that to message comma seperated, then in an alert could assign that message value to a property, disable the original, and enable something to look for specific ones. However it's not worth the work if the scenario changes all the time. I'm not suuuuper sure of your specific scenario but it feels specific enough that something clean is possible.