LogicMonitor PowerShell module

I see that you've added this to Github . I've created two PRs to address issues I've been having with 1.0.0.26. I'm assuming the Public directory scripts are "bundled" when releases are created and uploaded to PowerShell Gallery. 

@mhashemi awesome stuff !

@mhashemi Impressive work - thanks for sharing!

Thank you for this!

@mhashemi thank you for creating this.  One question/issue.... should Update-LogicMonitorDeviceProperties support updating any system properties?  I tried to use this to update system.displayname and though the command says successful, nothing is changed.  In addition if I do system.foo, it says it works but actually doesn't.  However, any other property name (e.g. foo.system) works fine.  There is something about system.X properties that the update cmdlet (or API) doesn't seem to like.  Thoughts?

@mhashemi also, just FYI (though I don't need to use it at the moment) Get-LogicMonitorServiceProperties does not seem to work for me.  I would also think a nice compliment to this would be a new Update-LogicMonitorServiceProperties cmdlet (if you get time for it)... though the first issue I mentioned I would think is more valuable to me.  Thanks in advance!

@mhashemi I looked at the verbose output of your command and it actually it looks like the issue is that you are using the PATCH method which only allows updating of custom properties.  If you were to change this to a PUT and instead use the path for properties, it would allow any property to be updated. 

https://www.logicmonitor.com/support/rest-api-developers-guide/devices/update-device-properties/

Your experience is interesting, because I update the displayName property of our new collectors several times a week. In the script we use to deploy collectors, I use the following code:

$BlockLogging = $true # Just used for this example, to prevent the steps from being written to the event log.

$collectorProperties = @{"displayName" = "testdevice"; "hostGroupIds" = "<a valid group ID>"}

Foreach ($keyValuePair in $collectorProperties.GetEnumerator()) {
    Try {
        $lmResponse = Update-LogicMonitorDeviceProperties -AccessId $lmAccessId -AccessKey $lmAccessKey -AccountName <account> -DeviceId <device ID> -PropertyNames $keyValuePair.Key -PropertyValues $keyValuePair.Value
    }
    Catch {
        $message = ("{0}: Unexpected error updating the property: {1} on {2}. The value should be: {3}. The specific error is: {4}." -f (Get-Date -Format s), $keyValuePair.Key, $hubLongName, $keyValuePair.Value, $lmResponse)
        If ($BlockLogging) {Write-Host $message -ForegroundColor Red} Else {Write-Host $message -ForegroundColor Red; Write-EventLog -LogName Application -Source $EventLogSource -EntryType Error -Message $message -EventId 5417}
    }
}

If you put the displayName property into a hash table like I did, do you have the same problem?

I'll try to find some time to create the other cmdlet you suggested.

Oh, you don't need the hash table. When I run with the property capitalization, the cmdlet works fine. For "display name", you need to use "displayName".

Update-LogicMonitorDeviceProperties -AccessId $lmAccessId -AccessKey $lmAccessKey -AccountName <account name> -DeviceId <id> -PropertyNames displayName -PropertyValues <new name>

Thank you very much for the response.  You are right, it does work if I change the case.  Interestingly if I don't have the proper case, the command still says successful but I guess in the backend it's really not.  I will go ahead and make sure to use that case for the display name and will need to see how I can verify the case for other properties if/when the issue comes up.  Any way to catch that in error handling?  Thanks again for creating this though - it's something the product badly needed.