83 votesplanned · 3 comments · Azure Monitor-Log Analytics » Active Directory Assessment Solution · Flag idea as inappropriate… · Admin →
An error occurred while saving the commentLars Villaume Jørgensen commented
The Detections preview currently shows events from the ATA event log which means that suspicious activities that has been investigated and marked as dismissed is shown in OMS as suspicious activity with severity critical while they in the ATA console is not. maybe the events in the ATA event log could be written written with different events ids so we can filter on open suspicious, resolved and dismissed suspicious activities.
7 votes0 comments · Azure Monitor-Log Analytics » Search UI and Language · Flag idea as inappropriate… · Admin →
Agreed, this seems frustrating. We’re planning on adding this feature.
6 votes0 comments · Azure Monitor-Log Analytics » Log Management and Log Collection Policy · Flag idea as inappropriate… · Admin →
Great feedback! One thing we’re looking into is local scoping of time and other filters within the solution. This would give you more control of what data is displayed.
93 votes9 comments · Azure Monitor-Log Analytics » Log Management and Log Collection Policy · Flag idea as inappropriate… · Admin →
The feature was delayed but has been picked back up and is now expected in late Summer 2020 as part of a project that will deliver several upgrades to the agents.
10 votes0 comments · Azure Monitor-Log Analytics » Agent Management (OnPrem components) / Connectivity / Setup · Flag idea as inappropriate… · Admin →
Hi, we are discussing this internally.
Today you have a way to do this, by overriding the rules that perform MP/IP download and import – there is an override MP here http://blogs.technet.com/b/momteam/archive/2015/02/06/notice-upcoming-url-change-for-opsmgr-reporting-to-opinsights.aspx
- you could keep them turned off in PROD and leave them enabled in QA/TEST – once you see a new MP has been updated in the test environment, you can remove the override in prod/let the update run/then block it again.
We are determining how to make this more polished.
Also see the similar idea http://feedback.azure.com/forums/267889-azure-operational-insights/suggestions/7161777-intelligence-pack-updates
Thanks for the idea, Daniele.
What would be the purpose of having such information? What would be the use cases of such information when the user is unable to revert the changes?