There are all sorts of reasons that you might need to know specific, trackable data about the user and administrative activity in your M365 environment – keeping tabs on external users, compliance tracking, you name it – and the best place to find that data is in audit logs.
Today, we’ll look at what audit logs are, and the process for enabling and accessing these logs with native Microsoft tooling. Then we’ll look at how using CoreView as an alternative to native tooling dramatically simplifies keeping track of user events in your M365 environment can be.
Audit logs are an internal record of events that take place in your M365 environment. These events can be all sorts of things, such as administrative actions like changes in tenant configuration settings in Exchange and SharePoint, and user actions like page and file views throughout the system.
They are collected from services within your M365 environment independently from each other, and so they contain distinct information according to their source. For example, audit logs collected from SharePoint sites include the following information:
When audit logs are enabled, user and admin activity within your M365 environment is collected and stored for 90 days, and potentially longer depending on your license type.
Enabling audit logs within your organization requires distinct admin privileges. For example, the Audit Logs role is required to enable audit logs in Exchange Online. These privileges are assigned to global administrators by default. You can read more about the specific permissions levels required here.
Before you turn on audit logs in your M365 tenant, you’ll first need to confirm whether audit logging is currently enabled. To do so, you can run the following command in Exchange Online PowerShell:
Get-AdminAuditLogConfig | FL UnifiedAuditLogIngestionEnabled
A response of True to the above command indicates that audit logging is currently enabled. Conversely, a response of False indicates that logging is currently disabled for your M365 environment.
It is worth noting that SharePoint logging needs to be turned on separately for each site collection. This can be accomplished in an automated fashion with PowerShell; however, there are limitations to this approach. You cannot, for example, connect to an exposed endpoint to collect specific logs for custom reports. Additionally, when retrieving logs from SharePoint, logs from all other services will be ignored, and thus won’t be included in the search results.
You will be able to see audit logs in M365 audit log search results for specific services as soon as 30 minutes after setup, but it can take up to 24 hours for all services to begin storing logs.
You can access aggregated logs from these M365 services via the Microsoft Purview compliance portal. Alternatively, you can also use the Search-UnifiedAuditLog cmdlet in Exchange Online PowerShell to search this centralized collection of logs.
Your search results can be exported to a CSV file for additional processing as needed; however, log data retrieved in this format can be unwieldy as it will contain all manner of metadata that you will more than likely not need, and that will likely mask the data that you do need.
In addition to the above methods of accessing audit logs, you can also retrieve them programmatically via the available REST APIs.
With CoreView, you can enable logging from any application within your M365 tenant from a single, cloud-hosted UI, which dramatically reduces complexity and speeds up your IT team. Moreover, with CoreView’s perfect permissions, you can delegate the ability to enable and access audit logs to exactly the team members who need it, while simultaneously adhering to the principle of least privilege.
With permissions in place, your team will then be empowered to much more easily find the information you actually care about with CoreView’s automated reports and built-in log parsing.