It probably isn’t.
Not because your intentional security configuration is wrong — but because underneath it, there’s a layer of sharing decisions nobody made deliberately. Links that were created and never expired. Guest accounts provisioned for a contractor six months ago and never disabled. SharePoint libraries with default permissions that nobody changed because nobody knew the default was the problem.
Microsoft Copilot respects Microsoft’s permissions model exactly. It won’t surface a file to someone who doesn’t have access. The problem is that in most Microsoft 365 environments, more people have access to more files than anyone intended — and nobody audited it before turning on a tool that can search and summarize everything.
The most common blind spot I see across Microsoft 365 environments isn’t a misconfiguration someone made deliberately. It’s the configuration nobody changed.
“People in your organization” links are often set as the org-level default — and many tenants have never changed it. When a user shares a document in SharePoint or OneDrive, the default link type in tenants that haven’t been hardened is one that grants access to any authenticated member of the organization. The user clicks share, copies the link, pastes it into an email, and sends it to one person. What they actually created is a link that any colleague can redeem.
The default permission on those links is Edit, not Read. The employee who shared a budget document with their manager didn’t intend to give any colleague who receives that link write access to a budget spreadsheet. But that’s what the link does.
Here’s how the exposure plays out. That link is in an email. The email gets forwarded — to a broader team, to someone cc’d by mistake, to a distribution list. Any org member who clicks it can redeem it and gain access. Once they do, Copilot can surface that document for them. An employee who was never supposed to see that file asks Copilot a question about budgets. Copilot finds it. Copilot answers with it.
No one breached anything. The permissions worked exactly as configured. That’s the problem.
Shared links are visible when you know to look. Stale guest accounts are quieter.
Every contractor, vendor, and partner who was granted guest access to your Microsoft 365 tenant is still there until someone removes them. Most organizations provision guest accounts when the relationship starts and forget them when it ends. The account stays active. The group memberships stay intact. The SharePoint library permissions set up for that engagement are still assigned.
Copilot with Graph access traverses your SharePoint environment without distinguishing between an active employee and a guest account that hasn’t been used in eight months. If the permissions say accessible, it’s accessible.
The engineers in your organization who manage Microsoft 365 already know this. The audit hasn’t happened because it’s not on the priority list — and it won’t be until leadership makes it one.
Getting ready for Copilot isn’t a one-time project. It’s a posture shift that requires ongoing discipline. Here’s what the organizations that do it right actually change:
Harden the global sharing configuration. Set the default link type to Specific people. Change the default permission to Read. Microsoft changed the out-of-the-box default to Specific people in July 2024 — but any tenant created before that may still be running the old default, and even new tenants need this verified. These two settings stop new oversharing before it accumulates. They don’t fix what’s already there — but they stop it from getting worse.
Set link expiration policies. Sharing links should have a maximum lifetime. External links especially. Most tenants have no expiration configured, which means links created three years ago are still live and still granting access.
Audit and disable unused guest accounts. Pull the guest account report, filter for accounts with no sign-in activity in 90 days, and disable them. Then make this a quarterly process, not a cleanup you do once before a Copilot rollout.
Disable resharing. If you send someone a link, they shouldn’t be able to forward it to someone else and extend that access further. This is often enabled by default.
Require admin consent for third-party applications. Any app requesting Microsoft Graph permissions to read SharePoint or OneDrive data — including AI tools and the third-party model providers now available through Copilot — should require explicit approval before it gets access.
Treat least privilege as a standing operating principle, not a project. Every permission decision should start with the question: does this person actually need this access? That mindset doesn’t take hold from the engineering team up. It has to come from leadership down.
Permission sprawl in Microsoft 365 has always been a governance problem. Most organizations have tolerated it because the practical consequences were manageable — the occasional file accessible to someone who shouldn’t have it, noticed when it caused a problem.
Copilot changes the consequence, not the root cause.
A forgotten “People in your organization” link used to mean one document was more accessible than intended — a risk that materialized only if someone stumbled across it. With Copilot, the risk materializes the moment that link gets forwarded to someone who wasn’t supposed to have it. They redeem it. They have access. Copilot can now answer their questions using content they were never meant to see.
The data exposure risk here isn’t about Microsoft reading your files or an LLM provider training on your content. It’s internal. It’s an employee in one department using Copilot to surface information from another department that was never meant to be shared — because someone sent an email with the wrong default link three years ago.
That’s the AI readiness problem. It isn’t glamorous. It’s an audit and a settings review and a governance conversation that most organizations have been deferring. The right time to have it is before you roll out the tool that makes the consequences visible.
Getting ready for Copilot or trying to understand where your Microsoft 365 permissions actually stand? I’m happy to walk through what a readiness assessment looks like.
]]>In a typical enterprise environment, an architecture decision is evaluated on performance, cost, reliability, and operational complexity. In healthcare, every one of those dimensions has a compliance overlay. The question isn’t just “does this work?” — it’s “does this work and can we audit it and is it covered by our BAAs and can we explain it to a HIPAA compliance officer who doesn’t care about the technical elegance?”
I’ve spent six years making those decisions in a healthcare IT environment, and the patterns that held up consistently were the ones that treated compliance as a first-class architectural constraint — not something layered on afterward.
The most consequential architecture decision in a Microsoft-first healthcare environment is not what Azure services you use. It’s how you structure identity.
Entra ID (formerly Azure AD) is the foundation for everything. Access to M365, access to Azure resources, Conditional Access policy enforcement, device compliance through Intune — all of it runs through Entra ID. If your identity architecture is loose, your compliance posture is loose, regardless of how well everything else is configured.
In a healthcare environment, this means:
Conditional Access policies are non-negotiable, not optional. Every user accessing PHI-adjacent systems needs MFA. Compliant device requirements should be enforced wherever clinically feasible. Location-based policies add a meaningful layer of control for systems with access to sensitive data.
Privileged Identity Management (PIM) for administrative access. Standing admin privileges are a HIPAA risk. Just-in-time elevation with approval workflows and audit logging gives you the access control story auditors want to see.
Group-based licensing and access provisioning. In a 12-person IT organization, manual licensing and access management doesn’t scale and doesn’t produce the consistent audit trail you need. Dynamic groups based on HR attributes keep provisioning accurate without manual maintenance.
The identity architecture is where healthcare compliance either holds together or falls apart. Get this right before building anything else on top of it.
One of the more impactful projects I delivered at Premier Health was building the Azure infrastructure that enabled a clinical data analytics solution.
The business problem: clinical staff were waiting unacceptable amounts of time to generate reports that directly informed care decisions. The underlying cause was a combination of legacy on-premises infrastructure and data spread across systems that didn’t communicate efficiently.
My role was the infrastructure layer:
Designing the Azure environment that a cloud analytics solution could actually run on in a HIPAA-regulated context. That meant: storage architecture with the right access tiers, networking and private endpoints, Entra ID integration for role-based access control, encryption at rest and in transit, and the audit logging configuration that HIPAA requires. In healthcare, none of this is optional — it’s table stakes before you can run anything clinical on top of it.
The compliance architecture work is what makes the project possible. You can have the best analytics platform in the world; if the infrastructure underneath it can’t pass a HIPAA audit, it doesn’t get deployed.
The outcome: the clinical reporting solution went live on infrastructure that was compliant, auditable, and operationally maintainable by a small IT team. Clinical staff got faster access to the data they needed to make care decisions.
The lesson: in healthcare IT, the infrastructure and compliance layer isn’t the interesting part of the project — but it’s the part that determines whether the project happens at all.
Healthcare organizations accumulate data at scale. Clinical records, imaging, diagnostic data — retention requirements are long, access patterns are predictable, and storage costs compound over time.
Most healthcare environments have significant data on the wrong storage tier: high-cost active storage for data that hasn’t been accessed in years, simply because migrating it requires effort and no one has owned the work.
Azure’s cold storage tiers exist for exactly this use case.
The architectural pattern is straightforward: classify data by access frequency and retention requirement, then implement lifecycle policies that automatically transition data to Archive or Cold access tiers as it ages. Build the policy once, and the cost reduction is ongoing.
In practice, implementing this across an environment with years of accumulated data that had never been tiered produced $1,500 per month in storage savings — $18,000 annually — from a one-time architecture effort. That’s not transformational, but it’s the kind of defensible, documented savings that build credibility with finance and fund larger initiatives.
The operational discipline required: data classification. You cannot implement effective tiering policies without knowing what data you have, how old it is, and what your retention obligations are. In a healthcare environment, that classification work is also required for HIPAA compliance — so the compliance work and the cost optimization work are the same work.
Not every Azure cost problem has an optimization solution. Sometimes the right answer is elimination.
Azure Virtual Desktop is a useful service for specific use cases: providing secure remote access to desktop environments, supporting contractors or vendors who need access to internal systems, enabling BYOD scenarios in regulated environments.
It is not the right answer for every remote access requirement, and the costs add up quickly when it’s deployed beyond its appropriate use case.
After auditing our AVD environment against actual usage patterns, the finding was clear: the deployment was substantially oversized relative to actual utilization, and a significant portion of the use cases it was solving could be addressed through better Conditional Access policies and Intune-managed devices at a fraction of the cost.
Eliminating the over-deployed AVD environment and replacing the legitimate use cases with appropriate alternatives produced $79,000 in annual savings.
The principle: before optimizing an Azure service, ask whether the service is solving the right problem. Sometimes the most cost-effective architectural decision is the decommission.
The most useful feedback mechanism I’ve found for cloud architecture in healthcare is the compliance audit.
An auditor reviewing your HIPAA technical controls is, in effect, reviewing your architecture. They’re asking: where is PHI stored? Who can access it? How do you know who accessed it? What happens if someone’s credentials are compromised? How would you detect unauthorized access?
If your architecture has gaps, the audit finds them. If your architecture is solid, the audit is documentation.
The organizations I’ve seen struggle with HIPAA audits are usually the ones that built the technical controls first and tried to map them to compliance requirements afterward. The ones that pass audits cleanly built the compliance requirements into the architecture from the beginning.
The questions to design against:
If you can answer those questions clearly, with evidence, your architecture is in good shape. If you can’t, the audit will tell you where the gaps are — ideally before the external auditor does.
Healthcare cloud architecture is not fundamentally different from enterprise cloud architecture. The services are the same. The principles are the same.
What’s different is the weight of compliance requirements, the consequences of getting it wrong, and the need to translate technical decisions into outcomes that clinical and executive stakeholders understand.
The architects who thrive in regulated environments are the ones who see compliance not as a constraint on architecture but as a design requirement — one that, when taken seriously, produces systems that are more auditable, more secure, and easier to defend when it matters.
Building cloud infrastructure in a healthcare environment? The compliance requirements are real but navigable. I’m happy to talk through the specifics.
]]>I’ve watched technically strong engineers step into IT management roles and struggle — not because they couldn’t architect the systems, but because the job changed and they didn’t realize it. The problems that mattered most weren’t architecture problems. They were people problems, budget problems, communication problems, and operational discipline problems.
I’ve also watched people with less technical depth succeed at the manager and director level because they understood something essential: at some point, your value shifts from your own output to the output of the organization you lead.
This post is about that shift — what it actually looks like, why it’s hard, and what it means for anyone building toward executive-level IT leadership.
When you’re an individual contributor, your output is largely under your control. You design the system, write the script, configure the service. When you have a productive day, you know it.
When you’re leading a 12-person IT organization — as I did in a healthcare environment — your output is the team. You move at the speed of other people’s growth, which is slow, non-linear, and only partially under your influence. The feedback loop on your decisions stretches from weeks to years.
This is uncomfortable if you’re used to the fast feedback of technical work. The instinct is to drop into the technical problems because that’s where you can see immediate impact. You know the answer. You can fix it faster than explaining it to someone else.
That instinct is worth resisting.
Every time you solve a problem that someone on your team could have solved — even more slowly, even less elegantly — you’ve chosen your own short-term productivity over their long-term capability. Do that consistently and you’ve built a team that waits for direction instead of developing judgment.
The shift to make: from being the best technical resource in the room, to being the environment in which good technical decisions get made without you.
Nobody tells you how much of IT leadership is non-technical.
In a healthcare environment, I spent significant time on:
None of that is architecture work. But all of it directly determines whether your IT organization earns the trust and resources it needs to do good technical work.
The leader who is only comfortable with technical problems will treat everything else as distraction. The leader who understands that these are the job will develop the operational and organizational skills that define executive effectiveness.
Owning a budget is clarifying in a way nothing else is.
When you have budget accountability, cost stops being an abstract concern and becomes a concrete one. You stop thinking “that’s expensive” and start thinking “is that the best use of these dollars compared to the alternatives?” You develop instincts about where money gets wasted, what vendors actually deliver value, and how to make a business case that leadership will approve.
Managing cost in a healthcare IT environment taught me that the discipline of cost optimization is almost entirely operational, not technical. Most waste exists because no one owns the outcome. Licenses accumulate because there’s no process to reclaim them. Environments stay up because decommissioning requires effort and no one has assigned the work.
When I eliminated a $79K annual Azure Virtual Desktop environment and documented $48K in licensing savings through a rigorous audit, the technical work was straightforward. What made it possible was having the organizational authority to own the outcome, the budget visibility to identify the waste, and the stakeholder relationships to make the change without friction.
Technical skill got me to the point where I could identify those opportunities. Budget ownership and operational authority are what let me capture them.
One of the most undervalued skills in IT leadership is the ability to move fluently between technical detail and business framing.
Most technical people can explain what they built. Fewer can explain why it matters to someone who doesn’t care about the technology.
When I presented the case for a cloud analytics platform at Premier Health, the conversation with clinical leadership wasn’t about the underlying architecture. It was about: clinical staff currently wait [X amount of time] to generate reports that inform patient care decisions. This solution reduces that to [Y amount of time]. Here’s what that’s worth to the organization.
The technical architecture enabled the outcome. The business case got the investment approved.
This translation capability — understanding the technical depth well enough to be credible with engineers, and understanding the business impact well enough to be credible with executives — is what separates IT leaders who get resources from those who complain about not having them.
The discipline to develop: every significant technical initiative should have a clear answer to “what business problem does this solve, and how will we know we solved it?”
The most durable thing a leader builds is a team with the judgment to operate effectively without constant direction.
This means investing in people in ways that don’t pay off immediately:
In a healthcare IT environment, this also means building the operational documentation and processes that survive personnel transitions. A 12-person team running HIPAA-compliant operations cannot be dependent on any individual’s knowledge. The organization needs to be able to function when someone leaves, gets sick, or moves on.
That kind of institutional durability is an executive concern, not a technical one. It requires thinking about the organization as a system — one that needs to be reliable and resilient, just like the infrastructure it manages.
The engineers I’ve seen struggle in leadership roles tend to have one thing in common: they still measure their own value by their personal technical output.
The leaders I’ve seen succeed at the manager and director level share a different orientation: they measure their value by the outcomes the organization achieves, and they’re willing to do whatever the organization needs — technical or otherwise — to drive those outcomes.
That’s a mindset shift, not a skill upgrade. And it’s one worth making deliberately, before a leadership role forces the issue.
The technology is usually the easy part. The operational and organizational work is where it gets hard — and where the real leverage is.
I write about technology leadership and cloud architecture from the perspective of someone building toward operational executive roles — connecting technical decisions to business outcomes, and sharing what I’ve learned along the way. Get in touch if you’re navigating a similar path.
]]>Most organizations don’t have a cost problem because they chose the wrong services or instance types. They have a cost problem because no one owns the outcome. Engineers provision resources without cost visibility. Finance tracks spend but can’t influence decisions. Waste accumulates because there’s no accountability.
The pattern is consistent: tooling gets added, dashboards get built, but nothing changes. Costs continue to climb.
Fixing cloud spend is not a tooling problem. It’s an operational discipline problem.
I’ve applied the framework below across healthcare and managed services environments and documented over $127K in annual savings — from licensing audits, environment rationalization, and storage tier optimization — without changing any core architecture. The work is organizational, not technical.
Cloud cost optimization is mostly behavioral, not technical.
If the people creating resources don’t understand cost, and the people tracking cost can’t enforce change, optimization will fail. It doesn’t matter how advanced the tooling is.
The foundation requires four things to be true simultaneously:
Without all four, everything else is noise.
Before anything can be optimized, it has to be understood. In practice, most environments lack even basic visibility.
The common failure point is tagging.
Without consistent tagging, there is no way to attribute cost. You cannot answer basic questions like:
Once tagging is enforced and tied to accountability, cost visibility becomes actionable instead of theoretical. A useful forcing mechanism: route untagged spend to a separate cost center owned by the VP of Engineering. Nothing motivates tagging compliance faster than a CFO asking questions.
At the same time, enable anomaly detection early. Unexpected spend is common — forgotten GPU clusters, misconfigured autoscaling, runaway data transfer — and catching it quickly prevents avoidable loss.
This phase is less about optimization and more about creating a reliable view of reality. You cannot improve what you cannot see.
Once visibility exists, the first meaningful reductions come from removing waste that should never have existed.
Typical patterns in almost every environment:
| Waste Category | Common Cause |
|---|---|
| Idle compute running indefinitely | No lifecycle policy |
| Detached storage still accruing cost | Forgotten after instance termination |
| Snapshots with no retention limit | Default settings never changed |
| Temporary infrastructure never cleaned up | No ownership, no expiry |
| Non-production environments running 24/7 | No scheduled shutdown |
These are not complex problems. They are operational gaps.
Cleaning this up does not require architectural changes. It requires discipline, communication, and enforcement. This phase consistently produces fast, defensible cost reduction — typically 15–25% of total spend — with minimal risk.
Real-world example: A licensing audit in a healthcare environment identified $48,000 in annual spend on unassigned or inactive licenses — accounts that had accumulated through turnover, role changes, and service trials that were never cleaned up. In the same environment, an Azure Virtual Desktop deployment audit found a $79,000 annual cost with utilization patterns that didn’t justify the deployment; the legitimate use cases were addressed through better Conditional Access policies at a fraction of the cost. Neither required new tooling. They required visibility and the willingness to act on what the data showed.
After waste is removed, the next step is aligning pricing models with actual usage.
Cloud providers charge a premium for flexibility. Most production workloads are not fully variable — they have predictable baselines. You are paying on-demand rates for stability you already know you need.
Optimizing this layer involves:
A critical sequencing note: commit to pricing after rightsizing, not before. A common and expensive mistake is locking in commitment-based discounts before workloads are properly sized. That locks in inefficiency at a discount — you still overpay, just less visibly.
Done correctly, this phase can reduce cost 30–70% on committed workloads without changing any architecture — only how it is paid for. Azure Reserved Instances alone offer up to 72% savings versus on-demand pricing on eligible VM families.
The deeper savings require engineering changes. This is where effort increases and trade-offs become real.
Common high-impact areas:
Data transfer costs are frequently the hidden driver of bills that don’t respond to compute optimization. Poor resource placement, cross-AZ traffic, and uncompressed origin responses are typical culprits. Audit data movement before assuming compute is the problem.
Storage tiering is consistently overlooked. Not all data is hot. Object storage lifecycle policies and archival tiers exist for a reason — use them. Most environments keep years of data on the highest-cost tier by default. In a healthcare data environment, implementing lifecycle policies that moved clinical data older than 90 days to cold storage tiers produced $1,500 per month in immediate, ongoing savings — from a one-time configuration effort against data that had been accumulating for years.
Managed service economics cut both ways. Sometimes managed services save money once operational overhead is factored in. Sometimes they’re egregiously overpriced at scale compared to self-hosted alternatives. Evaluate each category on its own merits rather than applying a blanket policy.
Over-engineered systems carry overhead that compounds. A distributed system with more moving parts than the problem requires costs more to run and more to maintain. Simplicity is a cost optimization strategy.
These optimizations are selective, not universal. Focus effort where it materially impacts total spend, not where it’s technically interesting.
Most cost optimization efforts fail because they are treated as one-time projects instead of ongoing operational practices. The cost comes back. Sometimes faster than it left.
Sustainable outcomes require structural change:
When cost becomes part of how systems are built and operated, improvements persist. When it doesn’t, regression is guaranteed — usually within two quarters of the project being declared complete.
Cloud cost optimization is not a technical challenge. It is an operational one.
If ownership, visibility, and accountability are not in place first, no amount of tooling or architectural sophistication will produce lasting results. I’ve seen organizations spend six figures on FinOps platforms while their bill continued to grow — because the platform couldn’t fix the fact that no one was accountable for the outcome.
Get the operational foundation right. The technical optimizations are straightforward once you do.
The question to answer before starting any cost reduction effort: Who is accountable for this number, and what can they actually change? If you can’t answer that clearly, start there.
Have a cost problem that’s resisted previous optimization attempts? The cause is almost always organizational, not architectural. I’m happy to talk through it.
]]>The people doing the work need files from multiple tenants. They don’t know or care what a tenant boundary is — they just want access. What they get instead is repeated MFA prompts every time they cross a tenant boundary, a confusing login experience that varies depending on which subsidiary’s resources they’re trying to reach, and IT fielding a steady stream of access requests and guest account issues.
The obvious fixes are all expensive in different ways. License users in every tenant they need access to — now you’re paying for the same person three times. Consolidate the tenants — a project that takes months, disrupts operations, and may not be feasible if the subsidiaries need to remain operationally distinct. Use guest access everywhere — you’ve just traded licensing cost for management burden and you still haven’t fixed the MFA friction.
There’s a fourth option. It’s just not the first thing most people reach for.
The holding company I worked with had subsidiaries on separate M365 tenants. Each subsidiary had its own SharePoint environment with files that holding company staff needed to access regularly — not occasionally, not for a specific project, but as part of their normal workday.
Two things were non-negotiable:
The goal was a single sign-on experience with a single access point, where holding company staff could reach files in any subsidiary SharePoint without re-authenticating.
Cross-tenant synchronization starts in Entra ID. You configure a sync from the holding company tenant outbound to each subsidiary tenant. The holding company’s users are provisioned in each subsidiary tenant as B2B collaboration users with member-level access — not guests. They show up in directory search, they’re manageable at the tenant level, and when someone leaves the holding company, the sync removes their presence in every subsidiary automatically. No manual guest account cleanup across four tenants.
Inbound MFA trust is what eliminates the re-authentication problem. In each subsidiary tenant’s cross-tenant access policies, you configure inbound trust to accept MFA claims from the holding company tenant. When a synced user completes MFA in their home environment — the holding company tenant — that authentication is honored when they access resources in any subsidiary. The subsidiary tenants aren’t skipping MFA. They’re trusting that it already happened, which it did, in the right place.
The SharePoint landing page is the piece that makes this feel like a single system to the end user. Each subsidiary has its own SharePoint site with its own content. In the holding company tenant, we built a SharePoint hub that functions as the access point — tiles and links out to the relevant subsidiary SharePoint sites, organized the way the business is organized. Users log in once, land on the holding company SharePoint, and navigate to files in any subsidiary from there. The underlying tenant boundaries are invisible.
Before: a user needs a document in a subsidiary’s SharePoint. They navigate to an unfamiliar URL, get prompted to sign in again, get an MFA challenge they weren’t expecting, and either complete the friction or submit a help desk ticket asking why they need to log in twice.
After: they go to the holding company SharePoint landing page they already have bookmarked. They see tiles for each subsidiary’s content area. They click through. The files are there. No additional sign-in. No second MFA prompt. The tenant boundary is invisible.
For IT, the management surface simplifies. User provisioning and deprovisioning is managed in one place — the holding company tenant. The sync handles propagation. Offboarding a user removes their access across all subsidiary tenants as part of the standard process, not as a separate checklist item.
This architecture is not a permanent set-it-and-forget-it configuration. A few things to maintain:
The cross-tenant access policies and sync scope need to match organizational reality. If a subsidiary is acquired, divested, or restructured, the identity trust relationship needs to be updated. Trust that outlives the organizational relationship that justified it becomes an unnecessary access vector.
Scope the sync carefully. Not every holding company user needs to be provisioned in every subsidiary tenant. Sync the users who actually need access to each tenant’s resources. The principle of least privilege applies at the tenant level, not just the file level.
The SharePoint landing page architecture requires governance like any other SharePoint environment — someone needs to own it, keep the links current, and manage what gets surfaced where. It’s not complex, but it’s not self-maintaining.
Running a multi-tenant M365 environment and dealing with cross-tenant access friction? The licensing and authentication architecture matters more than most people realize before they’ve tried to untangle it. Happy to talk through the specifics.
]]>The solution is well understood. SharePoint Online, as part of Microsoft 365, provides the document management, collaboration, and accessibility that file servers don’t. The technology is available. Most organizations already have the licensing.
The migration doesn’t happen — or happens badly — because it’s treated as an IT project.
IT can migrate the files. IT cannot migrate the behavior. And behavior is what determines whether the new environment works.
The visible costs of file servers are the storage infrastructure, the backup systems, and the VPN access that remote work made more expensive and more fragile. These are real but not the primary cost.
The invisible costs are larger.
Knowledge accessibility. Files on a shared drive are only accessible to people who know where to look and who have been given explicit permission to look there. Institutional knowledge lives in folder structures that made sense to the person who created them years ago. New employees spend weeks learning where things are. People who leave take navigational knowledge with them.
Version chaos. “Final,” “Final_v2,” “Final_USE THIS ONE,” “Final_ACTUALLY FINAL” — every organization with file servers has this problem. The cost isn’t just the frustration; it’s the time spent confirming which version is current, the errors that come from working on the wrong version, and the meetings that exist primarily to establish which document is the authoritative one.
Collaboration friction. Two people cannot edit the same document simultaneously on a file server. The workflow becomes: download, edit, re-upload, notify. Or email the document back and forth. Or put it in a Teams chat. The result is version proliferation and collaboration that’s slower and more error-prone than it needs to be.
Remote access dependency. File servers were designed for on-premises access. Remote access requires VPN, which is a performance and security overhead that became much more expensive when remote work normalized. Organizations that didn’t address this before 2020 discovered the hard way how brittle file server-dependent workflows are.
None of these costs show up cleanly in IT budgets. They show up in productivity, in employee frustration, and in the quiet organizational dysfunction that comes from people working around their tools rather than with them.
The technical migration — moving files from a file server to SharePoint — is not the hard part. Tools exist. The process is well-documented. Microsoft provides migration tooling that handles the mechanics.
Migrations fail for organizational reasons:
Migrating the folder structure instead of redesigning it. The instinct is to replicate the existing shared drive structure in SharePoint. This is the worst outcome — it preserves all the organizational dysfunction of the file server, minus the benefits of SharePoint’s search, metadata, and collaboration features. If you migrate a broken folder structure, you get a broken SharePoint.
No information architecture decision before migration. SharePoint is not just a place to store files. It’s a platform for organizing and surfacing information. How you structure site collections, document libraries, and metadata determines how usable the result is. This is a design decision that requires input from the people who will use it — not just IT.
Treating it as a project with an end date. The migration might have an end date. The adoption work doesn’t. People who’ve been using shared drives for years will default back to old behaviors unless there’s consistent reinforcement, training, and — most importantly — leadership that uses the new environment visibly.
No champions outside IT. A SharePoint migration that is owned entirely by IT will be perceived as an IT initiative that was done to people, not with them. The organizations that succeed have champions in each business unit — people who were involved in the design, understand the value, and can support adoption within their teams.
The starting point is not file inventory. It’s stakeholder conversations.
Who are the heaviest users of the current shared drives? What do they actually need to do with documents — who needs to access them, who needs to create and edit them, how do they need to find them? What does the governance model look like — who is accountable for keeping content current and organized?
The answers to those questions drive the information architecture. The architecture drives the migration design. The migration is the last step, not the first.
The technical implementation — site structure, library design, permissions through security groups rather than direct assignments, metadata taxonomy, search configuration — follows from knowing what the organization actually needs rather than from copying what it had.
The permissions model deserves particular attention. File server permissions tend to accumulate complexity over years of individual exceptions. A SharePoint migration is an opportunity to clean this up: move to security group-based permissions managed through Entra ID, establish a governance model for who can create new sites and libraries, and document the model so it can be maintained.
A successful SharePoint migration is visible in how people work, not in a dashboard.
People stop emailing documents back and forth because co-authoring in SharePoint is easier. Remote workers stop complaining about VPN because SharePoint is browser-accessible from anywhere. Search starts returning useful results because files are named and organized consistently. Onboarding new employees takes less time because institutional knowledge is findable rather than requiring someone to walk you through the folder structure.
The technology enables all of this. But the technology doesn’t create it on its own. The information architecture decisions, the adoption work, and the organizational commitment to using the new environment — these are what separate a file migration from a transformation.
That’s why this is a leadership problem. IT can build the right platform. Leadership has to make the organizational decision to actually use it differently.
Planning a SharePoint migration or trying to revive one that stalled? The organizational design questions are usually where the project is stuck. I’m happy to think through the approach.
]]>At that point, you’re not running a scalable business. You’re running a collection of individual consulting relationships, each requiring its own institutional knowledge, each carrying its own risk of configuration drift. Growth makes it worse, not better.
The operational problem isn’t lack of capability. It’s lack of standardization.
In a managed services environment, the hidden cost isn’t the time spent on each task — it’s the cognitive overhead of managing environments that don’t conform to a standard.
When every client is configured differently, every support interaction starts with “let me check how this tenant is set up.” Onboarding a new team member means teaching them the quirks of each environment rather than handing them a playbook. A security incident in one tenant triggers a manual audit of all tenants, because there’s no automated way to know which ones have the affected configuration.
The deeper problem is that configuration drift is invisible until it isn’t. Tenants that were set up correctly at onboarding accumulate changes — admin settings toggled for troubleshooting, security defaults modified for a specific use case, licensing changes that create coverage gaps. Without a system to detect and surface drift, you’re operating on the assumption that things are still configured the way you think they are.
That assumption fails at the worst possible times.
The CyberDrain CIPP (CyberDrain Improved Partner Portal) platform addresses the core operational problem directly: it provides a single management interface across all Microsoft 365 tenants, with the ability to deploy standardized configuration templates and monitor for drift from those standards.
The operational shift this enables:
Standardized onboarding templates. Rather than configuring each new client tenant from scratch, onboarding becomes a matter of applying a baseline template — conditional access policies, security defaults, licensing assignments, Teams settings, Exchange configurations — and then customizing from a known starting point. The work shifts from configuration to exception management.
Drift detection and alerting. When a setting changes in a client tenant — whether through admin error, a vendor making changes, or a user with elevated privileges — CIPP surfaces that deviation from the standard. You know the configuration drifted before the client does, and before it becomes a security issue.
Cross-tenant operations at scale. Tasks that previously required logging into each tenant individually — password resets, license assignments, security group changes — can be executed from a single interface across multiple tenants simultaneously.
The operational impact was most visible in two places.
First, onboarding. The time to stand up a new client environment dropped significantly, and more importantly, the result became consistent. The first hour after a new client signs isn’t figuring out what they need — it’s applying what we already know they need, plus their specific requirements on top.
Second, the reactive-to-proactive shift. Drift detection changed the nature of client interactions around security and compliance. Instead of responding to configuration issues when clients notice something wrong, the conversation becomes: “We detected a change to your conditional access policy last week — here’s what it was, here’s why it matters, here’s what we did.” That’s a fundamentally different client relationship.
From a business perspective, that shift matters beyond the operational efficiency. Clients who see proactive management perceive more value in the relationship. The same technical work — catching a configuration change — lands differently when you surface it before it causes a problem.
CIPP is a tool. The underlying principle — that scalable MSP operations require standardization before automation, and monitoring before incidents — applies regardless of tooling.
Any MSP managing more than a handful of client environments needs to answer two questions honestly: Do we have a defined standard that every client environment should conform to? And do we have visibility into which environments have drifted from that standard?
If the answer to either question is no, growth is working against you. Every new client adds complexity rather than leverage, and the team that felt manageable at 20 clients feels overwhelmed at 50.
Standardization isn’t a constraint on serving clients well. It’s what makes serving clients well at scale possible.
Managing Microsoft 365 environments across multiple clients or tenants? The standardization and drift detection problems are solvable. I’m happy to compare approaches.
]]>In conversations about automation and infrastructure as code, the tools that get attention are usually the ones with cloud-native integrations, declarative configurations, and CI/CD pipelines. PowerShell — the workhouse of Microsoft-first environments — tends to get positioned as a legacy automation tool rather than a strategic capability.
That framing is wrong, and expensive.
In a Microsoft-first environment — M365, Azure, Entra ID, Intune — PowerShell is not just the most practical automation tool. It’s often the only tool that provides the access depth the work requires. And in a managed services context, where you’re operating across multiple client environments, the discipline of PowerShell automation is what separates teams that scale from teams that hire more people to keep up with volume.
The promise of automation is usually framed as time savings: “this task takes 45 minutes manually, but 2 minutes with the script.” That framing undervalues what automation actually delivers.
The real value of automation is operational consistency.
When a process runs from a script, it runs the same way every time. The same security groups get assigned. The same licenses get applied. The same compliance policies get attached. The same documentation gets generated. There’s no variation because someone was rushing, forgot a step, or applied the process slightly differently than the last person who did it.
In an MSP context, where you’re onboarding users and managing configurations across multiple client environments with different standards, that consistency is the difference between an operation that scales and one that depends on institutional knowledge that walks out the door when someone leaves.
At ClowdCover, building consistent PowerShell-based provisioning workflows reduced onboarding time by 25%. The reduction in hours was real, but the more important outcome was that the process became reliable enough to delegate — any team member with the script could execute an onboarding without tribal knowledge.
The Microsoft Graph API and the Exchange, SharePoint, Teams, Intune, and Azure PowerShell modules provide comprehensive programmatic access to the Microsoft ecosystem. In practice, this means you can automate nearly any administrative operation that you’d otherwise perform manually.
The highest-leverage automation targets in M365 and Azure:
User lifecycle management. New user creation, license assignment, security group membership, Intune enrollment trigger, Teams membership — all driven from a single script that takes HR attributes as input and produces a fully provisioned user as output. The same script handles offboarding: license reclaim, group removal, mailbox conversion, account disable, litigation hold if required.
Lifecycle automation is particularly high-value in healthcare and regulated environments because it produces the audit trail that compliance requires. Every provisioning and deprovisioning event is logged in the script execution record, which is something auditors look for.
License management and reporting. M365 licensing is expensive and consistently over-provisioned. A weekly script that queries assigned licenses against last sign-in data and flags accounts that haven’t been active in 30+ days gives you continuous visibility into licensing waste. The same query, run before a licensing audit, is the starting point for meaningful cost reduction.
When I ran a systematic licensing audit using this approach, the output was $48,000 in annual savings from reclaiming licenses on accounts that had accumulated through turnover, role changes, and service trials that were never cleaned up. The script took a few hours to write. The savings were immediate and permanent.
Security posture reporting. Entra ID and Microsoft 365 Defender expose security configuration data through PowerShell and the Graph API. A weekly report that surfaces accounts without MFA, devices out of compliance with Intune policy, or sign-in risk flags gives the IT team the visibility to act before a problem becomes an incident.
In a healthcare environment, this reporting is also the evidence base for compliance conversations. Being able to pull an MFA adoption report on demand — showing percentage of users enrolled, broken down by department — is the kind of data that makes HIPAA compliance conversations concrete rather than theoretical.
Azure resource tagging and cost attribution. Cost governance in Azure depends on accurate tagging. A script that audits resources against your tagging standard and reports on untagged or incorrectly tagged resources — run weekly and piped to a shared dashboard or email report — keeps tagging compliance from drifting. Cost attribution is only as good as the tagging it’s based on.
The failure mode for PowerShell automation isn’t writing scripts that don’t work — it’s writing scripts that work initially and then become unmaintainable.
Scripts that no one understands get abandoned when they break. Scripts that only one person understands create single points of failure. Scripts that work in one environment and fail in another create incidents when someone runs them in the wrong context.
The practices that produce maintainable automation:
Write for the person who inherits the script, not for yourself. The most valuable comment in a script isn’t “this does X” — it’s “this does X because of Y, and if you change it you’ll break Z.” Business context and operational reasoning belong in comments. The code says what it does; the comments say why.
Parameterize everything that might vary across environments. Client name, tenant ID, license SKU, group naming convention — these belong in parameters or a configuration section at the top of the script, not scattered throughout the logic. A script that requires editing the body to run against a different client is a script that will eventually run against the wrong client.
Build in error handling and logging. A script that fails silently is worse than a script that doesn’t exist. Every significant operation should produce output that tells you whether it succeeded, and failures should be logged with enough context to diagnose. In an MSP context, this also means your client-facing reporting can be driven from the script’s own output.
Version control your scripts. Scripts that live in a shared network folder with names like provision-user-FINAL-v2-USE THIS ONE.ps1 are an operational risk. Even basic version control — a Git repository, even a simple one — gives you change history, the ability to roll back, and a canonical source of truth.
One insight from building MSP-scale automation: you cannot automate what isn’t standardized.
If every client has a different licensing model, a different group naming convention, and a different onboarding checklist, you cannot build a single provisioning script that works across clients. You build one script per client, which means the automation hasn’t reduced your operational complexity — it’s just encoded it differently.
This is where automation becomes a business conversation, not just a technical one. The discipline of building reusable, cross-client automation requires working with clients to standardize the configurations and processes the automation depends on. That’s a client management conversation, a sales conversation, and an operational design conversation — not just a scripting conversation.
The organizations that get the most leverage from automation are the ones that use the automation requirement as a forcing function for standardization. The discipline makes the operation more consistent and more scalable, not just faster.
For IT leaders building the case for automation investment — whether that’s time to build scripts, tooling, or dedicated resources — the ROI framing that works with executives is not hours saved per task.
It’s this:
Every manual process that runs from a script is a process that no longer depends on specific individuals, runs consistently at any scale, and produces an audit trail. That’s not a time savings. That’s organizational capability.
In a healthcare environment, the audit trail argument alone often carries the investment decision. In a managed services environment, the scaling argument does. The combination — consistent, auditable, scalable operations — is the strongest case for treating automation as an operational priority rather than a nice-to-have.
The tooling investment is modest. The PowerShell modules and Graph API access are included in your Microsoft licensing. What requires investment is the engineering discipline to build automation that’s maintainable, the organizational discipline to standardize the processes it runs, and the time to build the library of scripts that covers your operational baseline.
That investment pays back quickly, and it compounds.
Running Microsoft 365 or Azure in an MSP or enterprise environment? PowerShell automation is where operational leverage lives. I’m happy to compare notes.
]]>They happen because someone shared a file the wrong way. Because a terminated employee’s account wasn’t deprovisioned on the same day their badge was deactivated. Because a vendor relationship existed without a signed BAA because procurement didn’t flag it. Because audit logs existed but no one was actually reviewing them.
The technology can be configured correctly, and an organization can still fail an audit — because the compliance posture is not the configuration. It’s the operational discipline that keeps the configuration meaningful over time.
I spent six years owning the IT compliance posture in a healthcare environment. Here’s what I learned about what it actually takes.
The most dangerous framing in healthcare IT compliance is treating it as a project.
Projects have completion dates. You implement the controls, you document them, you pass the audit, you move on. But HIPAA doesn’t have a completion date. The threat landscape changes. Personnel turn over. New systems get added. Vendors change their practices. Each of these events is a potential gap in your compliance posture if you’re not actively maintaining it.
The organizations that maintain clean compliance postures treat it as a continuous operational discipline:
None of these require expensive tooling. They require process discipline and the organizational authority to enforce it consistently.
M365 is the dominant productivity suite in healthcare, and Microsoft’s HIPAA BAA covers most M365 services. That coverage is meaningful — but it doesn’t configure compliance for you.
The M365 features that matter most for HIPAA operational compliance:
Data Loss Prevention (DLP) policies. PHI takes many forms — patient names with diagnoses, dates of birth with account numbers, Social Security Numbers. DLP policies can detect and block sharing of PHI patterns through email, Teams, and SharePoint. The default policies Microsoft provides are a starting point; the policies that protect your specific organization require customization based on your data patterns.
The critical configuration decision: block vs. audit. A block policy stops the sharing attempt. An audit policy logs it and notifies. In my experience, starting with audit-then-block gives you visibility into existing sharing patterns before enforcement, which prevents the operational disruption that comes from blocking workflows people didn’t know were non-compliant.
Retention policies and litigation holds. HIPAA requires a 6-year retention period for compliance documentation — policies, procedures, and training records. Medical record retention periods are governed by state law and vary, but are typically longer. M365 retention policies can enforce both, automatically preventing premature deletion and managing accumulation. Litigation hold capability is essential for legal and compliance purposes and should be tested before it’s needed.
Microsoft Defender for M365. Phishing and business email compromise are the leading vectors for healthcare data breaches. Defender’s anti-phishing, safe links, and safe attachments controls are not optional in a healthcare environment — they’re table stakes. The configuration that matters most: impersonation protection for executive and clinical leadership, whose email accounts are the highest-value targets.
Communication Compliance. For organizations subject to additional regulatory oversight or with specific compliance requirements, Communication Compliance provides the supervisory review capability that HIPAA-covered entities sometimes need. This is not a universal requirement, but it’s one to understand before an auditor asks whether you have it.
The most important security control in a Microsoft-first healthcare environment is Conditional Access.
A correctly configured Conditional Access policy answers the auditor’s core access control questions: who can access clinical systems, from what devices, under what conditions, and what happens when those conditions aren’t met?
The policies that matter most in a healthcare environment:
Require MFA for all users accessing clinical systems. This is not optional. The authentication event creates the audit record that demonstrates the person accessing the system was verified at the time of access. Multi-factor authentication is the most effective single control against credential-based compromise.
Require compliant or Microsoft Entra hybrid joined devices. A compliant device policy ensures that devices accessing clinical systems meet a minimum security standard: encrypted, up to date, managed by Intune. This prevents the scenario where a personal device — potentially compromised, potentially shared — accesses patient data without any organizational visibility.
Block legacy authentication protocols. Basic Auth doesn’t support MFA. Any device or application authenticating via Basic Auth — including IMAP and POP3 clients that haven’t been migrated to OAuth2 — is a gap in your MFA coverage regardless of how well your Conditional Access policies are configured. Blocking Basic Auth and requiring Modern Authentication closes that gap. Microsoft has been deprecating Basic Auth for Exchange Online protocols since 2022.
Implement risk-based Conditional Access for high-risk sign-ins. Entra ID evaluates sign-in risk in real time based on factors like impossible travel, anonymous IP usage, and known malicious IP ranges. A risk-based policy that requires step-up verification for high-risk sign-ins catches credential compromise scenarios that static policies miss.
The configuration of these policies is not the hard part. The hard part is maintaining them as the organization changes — new applications added to the tenant, new devices types introduced, new vendor access requirements. Conditional Access policy drift is a real operational risk.
Operational discipline required: a quarterly policy review, documented, that verifies the policy set still matches the current environment and access requirements.
Healthcare organizations work with dozens of vendors who have some level of access to systems containing or adjacent to PHI. Each of those relationships requires a Business Associate Agreement.
The compliance failure mode I’ve seen most often: a vendor relationship exists without a current, signed BAA because the relationship predated the compliance program, or because procurement didn’t understand the BAA requirement when the contract was signed.
The operational fix is process, not technology:
Every new vendor relationship involving access to organizational systems goes through a review that includes: does this vendor have access to PHI? If yes, is a BAA in place? If no BAA exists, the relationship doesn’t proceed until one is executed.
That process needs to exist independently of any individual’s knowledge of the requirement — which means it needs to be documented, communicated to everyone involved in procurement and vendor onboarding, and owned by someone with the authority to stop a vendor relationship that hasn’t met the requirement.
At Premier Health, building that process into the vendor onboarding workflow eliminated the category of risk entirely. The BAA question became automatic, not exceptional.
HIPAA audits — whether OCR audits or third-party assessments — are fundamentally documentation reviews. The auditor wants to see:
The organizations that struggle with audits are usually the ones where controls exist technically but aren’t documented consistently, or where the documentation reflects an earlier state of the environment that doesn’t match what’s actually deployed.
The audit readiness discipline: treat every control change as a documentation event. When a Conditional Access policy changes, document why. When an access review happens, document the results. When a vendor BAA is signed, file it. The documentation burden is light if you do it continuously; it’s overwhelming if you try to reconstruct it before an audit.
Compliance is ultimately a leadership problem, not a technical one.
Technical controls can be configured correctly and still fail if leadership doesn’t enforce them consistently. If a senior clinical staff member is exempt from MFA because they complained loudly enough, the MFA policy has a hole. If a vendor relationship bypasses the BAA process because a department head wants to move fast, the vendor management process has a hole.
The IT leader’s job is to build the processes, configure the controls, and then hold the line when the organization pushes back — which it will.
The most useful thing I’ve found for holding that line: framing compliance requirements as organizational protection, not IT bureaucracy. The controls exist to protect the organization, the patients, and the staff — not to create friction. When that framing is consistent and credible, the compliance culture develops. When it’s absent, compliance becomes an adversarial relationship between IT and the rest of the organization.
The bottom line: HIPAA compliance in a cloud environment is achievable and maintainable. The technology — M365, Azure, Entra ID — provides the controls. What keeps those controls meaningful is the operational discipline to maintain them, the process to enforce them, and the leadership to make the organization take them seriously.
Get the process right. The technical configuration is the easier part.
Operating Microsoft 365 or Azure in a healthcare environment? The compliance requirements are real, but there are clear patterns that work. I’m happy to talk through specifics.
]]>Not the polished, certification-guide kind. The kind that come from being accountable for a HIPAA audit, from watching a licensing decision turn into a six-figure overspend, from trying to explain to a CFO why the Azure bill doesn’t match the forecast, from being the person whose phone rings when something stops working at 2am.
This blog is where I share those opinions.
This is a practitioner’s blog. I’m not a vendor advocate, not a conference speaker optimizing for applause, and not a consultant selling frameworks that work great in PowerPoint. I’m someone who has spent the better part of a decade doing this work in healthcare and managed services environments, and I write about what I’ve found to be true in practice.
This is about the intersection of technology and leadership. Cloud architecture isn’t just a technical discipline — it’s an organizational one. The decisions that shape your infrastructure are shaped by budget cycles, compliance requirements, vendor relationships, team capabilities, and executive priorities. I can’t write honestly about cloud architecture without writing about those things too.
This is not vendor-neutral marketing. My background is Microsoft-first — Azure, Microsoft 365, Entra ID, Intune, Defender. I’ll write about what I actually work with, what works, what doesn’t, and when the Microsoft way is the right way versus when it isn’t.
I’ve resisted starting a blog for a while. Partly because the internet already has more infrastructure content than anyone can read. Partly because writing takes time I could spend building things.
But I keep finding myself in conversations — with engineers early in their careers, with IT managers navigating their first healthcare compliance audit, with architects trying to make a cost optimization case to leadership — where I wish I had a place to point people. Where I could say: here’s how I’ve thought about this, here’s what worked, here’s what I wish I’d known before we spent three months going in the wrong direction.
This blog is that place.
I’ve spent years operating at the intersection of technical depth and business accountability — owning budgets, driving cost outcomes, making compliance calls, and building teams that outlast any individual. That’s the lens this blog is written from. Writing in public is how I articulate and pressure-test ideas that I’m already living in the work.
I’ll write in six areas where I have genuine, hands-on depth:
Azure Architecture: Entra ID, cold storage design, analytics infrastructure, cost governance, and the architecture decisions that matter in regulated environments. The real trade-offs, not the vendor diagrams.
Microsoft 365: Exchange Online, Teams, SharePoint, Intune, Defender — governance, compliance, and the operational discipline required to run M365 in a way that’s actually secure and auditable.
Healthcare IT & Compliance: HIPAA isn’t a checkbox — it’s an operational posture. I’ve spent six years in a healthcare environment and I’ll write about what compliance actually looks like in practice, what auditors actually look for, and how to build systems that hold up.
IT Leadership: Budget ownership, team development, stakeholder communication, hiring, and the shift from technical expert to operational leader. The skills that matter at the manager and director level are different from the ones that make you a great engineer, and that gap is rarely discussed honestly.
FinOps & Cost Optimization: Cloud cost is one of the most misunderstood problems in enterprise IT. I’ve documented over $127K in savings across licensing audits, environment rationalization, and storage optimization. I’ll share frameworks and tactics that have actually moved the needle.
Security & Identity: Entra ID, Conditional Access, MFA strategy, Fortinet, and zero-trust foundations in environments where compliance requirements make security non-negotiable.
I’m not the most senior person in any room, and I don’t pretend to be. What I am is someone who has owned outcomes — budgets, compliance postures, team performance, cost numbers — and has had to develop both technical depth and operational breadth to do that well.
The perspective here is practitioner to practitioner. If you’re an IT manager, a senior cloud architect, or a technical leader working through the same problems in healthcare or managed services, I think you’ll find something useful.
If this resonates, subscribe via RSS or check back regularly. I write when I have something worth saying.
Let’s get into it.
]]>