Custom permission to enable diagnostic setting in Entra ID
Custom permissions doesnt works when tried to enable diagnostic settings, in Microsoft Entra ID portal. Error: "does not have authorisation to perform action 'microsoft.aadiam/diagnosticSettings/write' over scope '/providers/microsoft.aadiam/diagnostic Settings/resourcename" Selective permissions that I applied to user account. My approach is to use custom role specific permissions. Appreciate your help to knows the right permission required. Regards, Rajkumar
PerfView: ASP.NET Core Stats View
In PerfView v3.1.10, released 02-May-2024, if a trace containing the needed events is opened, there is a new ASP.NET Core Stats view available that shows individual request information along with overall statistics. The events needed to construct this view are available in the .NET Profiler traces that are captured in AppServices (both Windows and Linux) and can be captured manually with other tools like PerfView and dotnet-trace. The view was modeled after the IIS Stats view. It also features clickable ActivityIds for requests so if there's a specific one you want to dig further into, you can click the ActivityId and it will open the Events window and show all events in the trace with that ID within the timeframe of the request.Lesson Learned #446: Simplifying SQLPackage Log Debugging with PowerShell
Handling massive SQLPackage diagnostic logs, like those spanning over 4 million rows, can be an overwhelming task when troubleshooting support cases. This article introduces a PowerShell script designed to efficiently parse through SQLPackage diagnostic logs, extract error messages, and save them to a separate file, thus simplifying the review process and enhancing the debugging experience.
User action logging for in meeting functions such as Spotlight
Hi all, Covering part of an old Uservoice item; we have a curious issue of aberrant spotlighting occurring during a meeting. It is suspected that a user is "playing with the controls" during the meeting. However we are seeking verification that this is not an issue and one simply of human factors and training. From the Debug logs/support files that can be generated in a call and are not encoded we can see the SpotlightMixin entries identifying the users transitioning into spotlight and/or being removed from spotlight. What appears to be omitted in the clear-text log is that of the userID initiating the request. Is there a simple way of identifying the requestor userID this within the toolset and capabilities available? Indeed are these details captured and audited? Naturally appreciate that there are other elements to aid the unwanted activity such as restricting presenters list etc. but interested to see if there is a simple way of identifying the requesting user. Any thoughts and guidance on this would be greatly appreciated. Thanks SJ
