Home / Blog
Notes from the field
Field notes from two decades in the Microsoft stack — securing and governing Microsoft 365: identity and Zero Trust, data protection, and getting tenants ready for AI.
Making a tenant Copilot-ready: the data-security work nobody budgets for
Microsoft 365 Copilot doesn't break your permissions — it exposes them. It can surface anything a user is already able to reach, which means every oversharing sin of the last decade — the "Everyone" link, the wide-open SharePoint site, the mislabeled HR folder — becomes a one-prompt discovery. The readiness work is unglamorous and essential: find and remediate oversharing before you switch Copilot on, not after the first awkward search result.
The toolkit is real now: Microsoft Purview's Data Security Posture Management for AI shows you what sensitive data Copilot can see, sensitivity labels and DLP keep it from leaking through the AI, and SharePoint Advanced Management — Restricted SharePoint Search, oversharing and data-access-governance reports — closes the gaps. The pattern I run: baseline the exposure, remediate the worst permission and label problems, restrict search while you clean up, then enable Copilot in stages. The AI is the easy part; the data hygiene underneath it is the job.
Entra ID Governance in practice: access reviews people actually complete
Least privilege is easy to say and hard to keep. Access sprawls — people change teams, projects end, guests linger — and a year later half your sensitive groups are full of accounts nobody can account for. Entra ID Governance is the machinery that keeps it honest: entitlement management packages access into requestable, time-bound bundles; access reviews put a recurring, low-effort yes/no in front of the right approver; and lifecycle workflows handle joiner-mover-leaver so offboarding isn't a manual scramble.
The failure mode is reviews nobody does — a quarterly wall of four hundred names that gets rubber-stamped in one click. Scope them tightly to what matters (privileged roles, guest access, the crown-jewel groups), route each to the person who actually knows, and auto-remove on no response so inaction fails safe. Governance that runs itself is the only kind that survives a busy organization — and it's exactly the access hygiene a Copilot rollout depends on.
Sensitivity labels and DLP your users won't fight
Information protection dies on contact with a taxonomy nobody understands. The version that sticks is small: three or four labels a person can actually reason about — Public, Internal, Confidential, Highly Confidential — sensible defaults, and auto-labeling doing the heavy lifting so classification isn't a decision every user makes fifty times a day. Roll DLP the way you roll Conditional Access: in test/audit mode first, watch what it would have blocked, tune out the false positives, then enforce.
The trap is treating data protection as a compliance checkbox instead of a risk exercise. Tie every label and rule to something real — regulated data, contracts, source code — and you get controls people accept because they map to how the business already thinks about its information. Get this right and you've also done most of the groundwork for the question everyone's now asking: is this tenant safe to point AI at?
Conditional Access without locking yourself out
Conditional Access is the highest-leverage control in Entra ID and also the fastest way to lock every admin out of a tenant at 2am. Two rules I never skip. First, keep a break-glass account excluded from every policy — cloud-only, a long random password in the vault, exempt from the risky rules. Second, ship every new policy in report-only mode, read the sign-in logs for a few days, and only then flip it on.
Build from a baseline before you get clever: require MFA for all users, block legacy authentication outright (it's the quiet backdoor around MFA), and require compliant or hybrid-joined devices for privileged roles. Layer risk-based policies on top once the fundamentals hold — not before. Conditional Access rewards a staged rollout and punishes the big bang.
Raising your Secure Score without punishing users
Microsoft Secure Score is a useful compass and a terrible destination. Chase the number blindly and you'll switch on controls that generate help-desk tickets faster than they generate security. The sequence that works: kill legacy authentication first (the single biggest quiet risk), enable MFA with sensible trusted-location and device exceptions so it isn't a daily tax, and turn on the Defender for Office 365 protections that run invisibly.
Then take the higher-friction items one at a time, each with a short comms plan, rather than flipping twenty switches over a weekend and fielding the fallout on Monday. Security that users route around isn't security — it's theater with a worse login experience.
Hybrid identity, done right: Azure AD Connect and ADFS without the 2 a.m. surprises
Almost every Microsoft 365 project starts with identity, and the ones that go sideways usually do so because directory sync was treated as an afterthought. The fundamentals that save you: pick the sign-in model deliberately — password hash sync is the pragmatic default, and it keeps cloud logins working when on-prem has a bad day in a way ADFS never will — scope Azure AD Connect to sync only the objects you actually want in the cloud, and fix on-prem UPNs and duplicate proxy addresses before the first sync, not after.
The failure I saw most often wasn't technical, it was trust: ADFS put the whole company's cloud login on a pair of on-prem servers, and when they hiccuped, everyone noticed. Where it made sense I moved clients to managed authentication and kept federation only where a hard requirement demanded it. Get identity boring and dependable first — every control you layer on later, from MFA to Conditional Access to governance, is only as solid as the directory underneath it.
Back pressure in Exchange 2007, 2010 and 2013
Back pressure is Exchange's built-in resource-protection mechanism on Hub Transport and Edge Transport roles. When disk space, memory, or queue database utilization crosses a threshold, the transport service throttles or stops accepting new connections to protect message delivery for what's already queued.
There are three states — Normal, Medium, and High — with increasingly aggressive restrictions on which connections get accepted. The most common real-world trigger is low free disk space on the drive hosting the message queue database; Exchange needs roughly 4GB free there as a floor. Watch for Event IDs 15004–15007 in the event log, which flag utilization-level changes. In nearly every case seen in the field, the root cause traces back to disk space on the database drive.
OWA login: "Your account has been disabled"
A recurring issue: users suddenly can't log into Outlook Web App and get an "account has been disabled" error, even though nothing was actually changed in Active Directory. This is typically caused by stale cached AD information about a mailbox — sometimes following a mailbox deletion and reattachment to a new account SID, sometimes with no obvious trigger at all.
The fix in both cases: run Clean-MailboxDatabase –Identity <Database Name> in the Exchange Management Shell. This forces a rescan of AD and refreshes the disconnected-mailbox status for the target database.
Exchange 2013 SP1's late-breaking transport agent bug
Shortly after Exchange 2013 SP1 shipped, a bug surfaced that broke third-party transport agents — the mechanism anti-spam and anti-malware products (TrendMicro, Symantec, Exclaimer, and others) use to hook into Exchange's message flow. A malformed XML comment in an assembly redirection policy file, introduced during a late security fix, caused the Global Assembly Cache to reject those agents entirely.
Microsoft published a PowerShell-based fix quickly, and the underlying issue was corrected in the next cumulative update. The broader lesson: it's difficult for any vendor to validate every third-party product that might touch Exchange's transport pipeline before a release ships, which is part of why staying a patch or two behind "bleeding edge" on production mail systems remains reasonable practice.
Exchange best practices checklist
A punch list worth running through on any Exchange environment: store logs on a separate physical drive from databases (RAID 5 for databases, RAID 1/10 for logs); split mailboxes across at least two databases rather than one; keep individual databases under roughly 100GB and mailbox sizes under 5GB; run inbound and outbound spam filtering; lock receive connectors down to known-good IPs; enforce send/receive size limits; and use a proper SSL SAN certificate for OWA.
Beyond that: enable OWA and Outlook Anywhere, disable open relay, and make sure SPF and Autodiscover DNS records are correctly published internally and externally. On the operational side — set Application log size to at least 40MB, move the TEMP path and pagefile off the C: drive, run the Exchange Best Practices Analyzer, weigh the tradeoffs of circular logging (it can cost you a full day of mail if a dirty shutdown hits at the wrong moment), and confirm every CAS-related DNS name (ECP, OWA, ActiveSync, OAB) is configured correctly, since a single misconfigured entry causes disproportionate client-side pain.
