It didn't start with a support ticket.
It started with a recommendation inside Microsoft Secure Score.
While exploring Microsoft Defender and reviewing security recommendations in my lab tenant, I noticed a
suggestion to enable Microsoft 365 audit log search. The recommendation looked straightforward enough, and I
assumed it would be a quick configuration change.
As it turns out, that assumption was wrong.
When I opened Microsoft Purview Audit, the portal informed me it was unable to determine whether user and
administrator activity was being recorded. A button labeled "Start recording user and admin activity"
appeared prominently on the page.
Naturally, I clicked it.
Instead of enabling auditing, Microsoft displayed an error.
At first, I assumed the issue was isolated to Purview. I've learned over the years that a single portal can
occasionally present misleading information, so I opened Microsoft Defender and navigated to the
corresponding audit experience there.
Defender produced the same behavior.
That was the first clue that I wasn't dealing with a user interface issue.
When multiple Microsoft portals report the same problem, it's usually worth digging a little deeper before
assuming the issue is cosmetic.
I moved to PowerShell.
One of the advantages of working with Microsoft 365 is that most services expose configuration through
administrative command-line tools. Rather than trusting a message displayed in a web page, I wanted to see
what the tenant configuration actually looked like.
The first command revealed something interesting.
Unified Audit Log ingestion was disabled.
That immediately improved the quality of the problem statement. Instead of saying "Audit doesn't work," I
could now say "Unified Audit Log ingestion is disabled." Those two statements may sound similar, but one is
a symptom while the other is a specific configuration state.
The error message being returned by Microsoft suggested an organizational customization problem and
instructed me to run a command called Enable-OrganizationCustomization.
That sounded reasonable, so I verified the current tenant state.
The tenant reported that organizational customization had already been enabled.
Just to be certain, I ran the command anyway.
Microsoft responded by informing me that the operation was unnecessary because the organization had already
been customized.
At that point, the investigation became more interesting.
The audit enablement process was claiming the tenant required organizational customization, while Exchange
Online was simultaneously reporting that organizational customization had already been completed.
Both statements could not be true.
This is one of the most important moments in troubleshooting.
Many administrators continue searching for additional fixes when they encounter contradictory evidence. They
keep changing settings, rerunning commands, or searching forums in the hope that another hour of
investigation will reveal the answer.
Sometimes that's the right decision.
Sometimes it isn't.
For me, the contradiction was the signal.
I had verified the tenant configuration. I had verified the error. I had confirmed the recommendation was
valid. I had confirmed the prerequisite was already satisfied.
At that point, additional troubleshooting wasn't likely to generate new information.
It was time to open a support case.
One lesson I've learned through experience is that support requests should focus on evidence rather than
frustration.
Nobody benefits from submitting a ticket that says something is broken.
Support engineers need information they can use.
In this case, my ticket was concise. Unified Audit Log ingestion was disabled. The tenant was not
dehydrated. Organizational customization was already enabled. Yet the enablement process continued reporting
a dehydration-related error.
The goal wasn't to explain every step I had taken.
The goal was to provide enough evidence to eliminate the most obvious troubleshooting paths before the first
support call even occurred.
Shortly afterward, a Microsoft support engineer contacted me.
After reviewing the information and performing several backend actions, the engineer asked me to try
again.
This time, the error was gone.
A follow-up check in PowerShell confirmed that Unified Audit Log ingestion was now enabled.
The issue had been resolved without any additional configuration changes on my side.
The support engineer later explained that several internal diagnostics and service-side actions had been
performed to help the configuration propagate correctly across the platform.
That detail was important.
The issue wasn't caused by a missing permission, an overlooked setting, or an incorrectly configured
command. The problem existed somewhere beyond the boundary of what a tenant administrator could directly
control.
The experience reinforced something I've encountered repeatedly throughout my career.
Good troubleshooting isn't about knowing every answer.
It's about understanding when you've gathered enough evidence to make an informed decision about the next
step.
Sometimes that next step is another command.
Sometimes it's another test.
And sometimes the correct answer is recognizing that you've reached the boundary between tenant
administration and Microsoft's responsibility.
For all the jokes we make about opening support cases, there are situations where Microsoft is the only
organization with access to the systems capable of resolving the problem.
The challenge isn't determining whether to contact support.
The challenge is knowing when you've done enough homework before making the call.
In this case, the support ticket wasn't the end of the troubleshooting process.
It was simply the next logical step.
And sometimes that's exactly where good troubleshooting leads. 🐦🐦