MilestoneSystemsInc / PowerShellSamples

A collection of samples for managing your Milestone XProtect VMS using MilestonePSTools in PowerShell
https://www.milestonepstools.com
MIT License
37 stars 12 forks source link

Get-VMSCameraReport MeetsRetentionPolicy for recently added devices #56

Closed thejurassic closed 1 year ago

thejurassic commented 2 years ago

Could we make the MeetsRetentionPolicy factor in newly added devices where they havnt been operating long enough to meet the retention policy? EG if retention policy is 30 days, but camera was only added 10 days ago, and we have last 10 days of recordings, then MeetsRetentionPolicy should be TRUE. If however it was added 10 days ago but only have recordings for last 5 days then should say FALSE.

thejurassic commented 2 years ago

Can I also get clarification on how MeetsRetentionPolicy is calculated?

If i have a camera that records on motion and is in a room that is rarely visited and so only has recordings for say 1 day every 14 days, is there a chance that this MeetsRetentionPolicy will be FALSE when it should be counted as TRUE? EG, if the retention policy is 30 days, but the only recordings that exist for a camera are from 2 days ago because in the last 30 days the only time the camera detected motion was 2 days ago. Would this show MeetsRetentionPolicy as FALSE becuase it thinks the earliest footage is 2 days ago instead of 30? OR is it smart enough to know that there WOULD have been recordings from 30 days ago if there was motion 30 days ago?

From the output im seeing, I'm guessing the answer is that it would consider the above scenario as MeetsRetentionPolicy is FALSE. Ive also got a similar issue where we had recording disabled on a few cameras but the recording server policy is 30 days and we only enabled recording on these cameras 10 days ago.

Any ideas how we could factor in the 3 scenarios ive listed into the MeetsRetentionPolicy property? I'm wanting to run this report daily but only alert us if MeetsRetentionPolicy is FALSE, and I dont want to be alerted in in these cases.

I understand it may be desired to leave the MeetsRetentionPolicy calculations as is.. Could we perhaps add another property in the resulting object for ShouldMeetRetentionPolicy where by it factors in:

  1. Newly added devices by checking if the Date Added is greater than the MediaDatabaseBegin Date and just make sure we have all recordings after this date
  2. Devices that have motion recording enabled, and then add have logic like
    • if there has been no motion events for the device between the retention start date and the MediaDatabaseBegin date then calculate based on the start date being the earliest motion detection event in this period, OR
    • If there has not been any "deleting footage due to storage full" events in this period then assume the device MediaDatabaseBegin date is start of retention date OR
    • Some other logic that you can think of that will work better
  3. Devices that have only recently had Recording turned on before the retention period start date, by checking the date that the recording was last turned on using this as the start date to make sure we have all recordings after this date

If we can have this proposed ShouldMeetRetentionPolicy property, then we can be alerted of any cameras that fail this check which means we wont suffer from alert fatigue.

Failing that, could you let me know how we could filter out the report to remove devices flagged as ShouldMeetRetentionPolicy =TRUE but meet the above conditions, and I can then process the output in my scripts to remove these before I alert on them. I guess I need to know how I can find the audit events for a device recording setting turned on/off, how to find motion events for a camera, how to find camera added events.

Many thanks, really like this powershell module :)

joshooaj commented 2 years ago

Hi Matt,

Great questions/requests here - you are correct that the Get-VmsCameraReport cmdlet assumes that you're not meeting the retention if the oldest image available isn't at least as old as "now minus 30 days" or whatever the retention is for that camera's storage. And this is definitely flawed in a few ways, including what you've described...

  1. Cameras added yesterday will say they don't meet retention settings, and our SDK unfortunately doesn't give me access to a "date added" property so I have no way to know how old a camera is. You'd have to write your own script, cache all the camera ID's and the date they were first discovered, and use that cache to help understand if a camera is new or not, and when it was added.
  2. Cameras that don't necessarily record at least a bit every hour are likely to be just under the configured retention in normal circumstances. 29.5 days could be perfectly normal. We could add some kind of threshold in the report, but that starts to get really opinionated and at that point I think it's better for folks to make their own reports using the cmdlets available in the module where business logic unique to your environment can be implemented.
  3. If evidence lock is used, a camera might have video available from 3 years ago, even though the retention is only 30 days. If that camera hasn't recorded in a month because the motion settings are out of whack, it would never show in the report because that property is specifically looking at the timestamp of the oldest recorded image. This one could be mediated by putting the media database cursor for the camera at "30 days ago" (or whatever the retention is) and then finding the first recorded sequence going forward in time and using that, instead of using Get-PlaybackInfo which will just tell us the first and last image in the database.

I can definitely implement a change for the third item in that list, but the first two I'm not sure what should be done to the existing cmdlet to make it more useful here, and in a way that is valuable to anyone using the cmdlet. I could probably add a sensitivity value for the retention column with a default value of maybe 24 hours, let people override it if they need to, and then only say a camera doesn't meet retention if it's short by more than that threshold?

For motion events, you could use Get-EventLine to look for motion events but I think you'll need to make sure those are retained for some number of days by going to Tools > Options in Management Client first. For audit logs, you could do something like this...

Get-VmsLog -LogType Audit -Tail -Minutes 5 | Where-Object 'Message Text' -like 'Recording disabled*'

<# Sample output
Message text  : Recording disabled on 'Camera 2'.
Permission    : Granted
Category      : Management
Source type   : Server
Source name   : Camera 2
User          : domain\username
User location : 192.168.1.101
#>