A regional broadcasting company came to us with a problem that looked like a technical one. Fifteen internet radio stations. A Linux-based streaming infrastructure running on Amazon EC2. Media libraries in the gigabytes. Listeners across multiple markets. And a team that managed daily operations inside Microsoft 365 — Exchange Online for email, SharePoint Online for files, Microsoft Teams for communication.
The infrastructure worked. The streams played. But the environment was fractured. Compute on AWS. Identity and productivity on Microsoft. Backup handled manually. Disaster recovery undefined. Every operational decision that touched both sides required a context switch — different portals, different vendors, different support paths, different billing relationships.
That is not a technical problem. That is a business risk.
This is the story of how we resolved it — and why the decision was about more than where the servers live.
Before we touched a single configuration file, we asked the question every CIO and owner should ask before any infrastructure decision: what problem are we actually solving?
The answer had four parts.
Operational fragmentation. The team managing the stations had no unified view of their environment. Streaming infrastructure on Amazon EC2. Business data on Microsoft 365. Two vendor relationships. Two support queues. Two billing cycles. No single pane of glass.
Business continuity exposure. There was no formal backup policy for the compute layer. If a virtual machine failed, recovery depended on manual processes and institutional memory — neither of which is a continuity strategy.
Ecosystem misalignment. Microsoft 365 was already the operational backbone of the business. Exchange Online handled all organizational email. SharePoint Online housed internal documents. The compute infrastructure — the part that generated revenue — was on a different platform entirely.
Cost visibility. Amazon EC2 pricing for Linux compute instances is well-documented, but it does not include the operational overhead of managing a fragmented environment. When you account for the time spent context-switching between platforms, the real cost of staying on AWS was higher than the invoice suggested.
This question deserves a direct answer, because it is the question every CIO, IT Director, and Finance leader should be asking before approving any migration.
We did not move to Azure because AWS is inferior. Amazon EC2 is a mature, capable compute service. We moved to Azure because the organization had already made its strategic cloud decision — and it was Microsoft.
When your identity platform is Azure Active Directory, your email is Exchange Online, your documents are in SharePoint Online, and your collaboration runs in Microsoft Teams, your compute infrastructure belongs in Azure. Not because of sentiment. Because of integration.
| Capability | AWS Approach | Microsoft Azure Approach |
|---|---|---|
| Identity | Separate IAM configuration | Native Azure AD integration |
| Monitoring | CloudWatch — separate portal | Azure Monitor — unified portal |
| Backup | Manual or third-party | Azure Backup — built into portal |
| Support | AWS Support plan | Single Microsoft support relationship |
| Billing | Separate AWS invoice | Unified Microsoft billing |
| Compliance | Separate compliance posture | Unified compliance across M365 + Azure |
For an organization already operating inside Microsoft 365, Azure is not a migration destination. It is the completion of a decision already made.
The streaming infrastructure for fifteen radio stations now runs on two dedicated Microsoft Azure Virtual Machines — both running Debian Linux, both Trusted Launch enabled, both inside the Microsoft Azure ecosystem.
The choice of Linux was deliberate. The streaming software stack — CentovaCast, SHOUTcast, and the AutoDJ layer — runs on Linux. Moving to Azure did not mean moving to Windows. Azure Virtual Machines support Linux natively, and the operational behavior of the stack is identical to what ran on Amazon EC2. The migration was a lift of workloads, not a rewrite of them.
What changed was everything around the workload.
Backup and Recovery. Both virtual machines are now protected by Azure Backup with Enhanced Policy — automated backups every four hours, thirty-day retention, instant restore capability, and application-consistent snapshots. The organization went from no formal backup policy to enterprise-grade protection in the same portal they use for everything else.
Business Continuity. Recovery Services Vaults are now configured for both virtual machines. A failure scenario that previously would have required manual intervention and undocumented institutional knowledge now has a defined recovery path with measurable recovery time objectives.
Networking. Network Security Groups replace ad-hoc firewall rules. Inbound access is explicitly defined — only the ports the streaming infrastructure requires are open. SSH is locked down. The attack surface is documented and controlled.
Monitoring. UptimeRobot monitors every station, every control panel, and every website — with a public status page available to the operations team and stakeholders at a single URL. Azure Monitor provides the infrastructure layer underneath.
There is a conversation that happens in every organization considering a cloud migration, and it usually sounds like this: we already have Microsoft 365, so why are we paying for infrastructure somewhere else?
It is the right question. And the answer is almost always: you should not be.
Microsoft’s integrated cloud strategy is not marketing language. It is a technical and operational reality. When compute lives in Azure and productivity lives in Microsoft 365, the organization gains unified identity, unified compliance, unified support, and the cost predictability of Reserved Instances.
This is what an ecosystem looks like. Not a collection of services from different vendors stitched together with manual processes. An integrated environment where identity, compute, storage, backup, compliance, and productivity share a common platform, a common management plane, and a common support relationship.
If your organization is running workloads on Amazon EC2 and operating inside Microsoft 365, here are the four questions worth answering before your next budget cycle:
The organization in this case study is now operating fifteen live radio stations on Microsoft Azure Virtual Machines, protected by automated backup, monitored in real time, and fully integrated with the Microsoft 365 environment their team uses every day.
The streams are live. The infrastructure is documented. The recovery posture is defined.
That is what completing the decision looks like.
“I’ve spent my career asking ‘what if’ when everyone else was asking ‘how much.’”
The ‘what if’ here is: what if your infrastructure and your business platform finally lived in the same ecosystem? The answer is not a technical one. It is an operational one.
The most dangerous email your organization will receive this year may not come from a stranger. It may come from Microsoft — and it may be a trap.
On May 19, 2026, The Spamhaus Project published an alert that had been building for months. Scammers had found a way to send spam — convincing, structured, fraudulent spam — from msonlineservicesteam@microsoftonline.com. That is not a lookalike domain. That is not a spoofed address. That is the legitimate Microsoft email address used to deliver two-factor authentication codes, account alerts, and critical security notifications to millions of Microsoft 365 users worldwide.
The same day, TechCrunch Security Editor Zack Whittaker confirmed he had received multiple similarly structured emails across different accounts, all originating from that same legitimate Microsoft address. Subject lines mimicking PayPal fraud alerts. Links to scam sites. Bitcoin transaction confirmations. All arriving from an address your mail filters are configured to trust.
Microsoft acknowledged the inquiry. As of publication, the company has not confirmed whether the abuse has been stopped.
As a Microsoft Cloud Solution Provider and IT Consultant whose clients operate Microsoft 365 environments every day, I want to explain exactly what happened, why your standard defenses did not catch it, what the security frameworks say about this class of attack, and what you need to do right now.
This is not a credential compromise. No one hacked Microsoft. No password was stolen. The attack exploits a design flaw in Microsoft’s automated notification system — specifically, the degree of customization Microsoft allows when a new account is created.
The attack chain is straightforward:
| Step | What Happens |
|---|---|
| 1 | Attacker registers a new Microsoft account — no special access required |
| 2 | Attacker sets the account name, display name, or organization name to malicious text |
| 3 | Microsoft’s automated notification system sends a legitimate email using that text |
| 4 | The email originates from msonlineservicesteam@microsoftonline.com |
| 5 | SPF, DKIM, and DMARC checks all pass — the email is technically authentic |
| 6 | The recipient receives what appears to be a legitimate Microsoft alert |
The malicious content never touches Microsoft’s email body templates. It rides inside a field Microsoft trusts — and that trust is inherited by every mail security tool in your stack.
SPF passes. The email originates from Microsoft’s mail servers. SPF is designed to verify the sending server — and this server is legitimate.
DKIM passes. The email is cryptographically signed by Microsoft. The signature is valid.
DMARC passes. Both SPF and DKIM align with the microsoftonline.com domain. DMARC has nothing to flag.
Reputation filters pass. msonlineservicesteam@microsoftonline.com has one of the highest sender reputations in enterprise email. It delivers MFA codes. Blocking it would break authentication workflows for millions of organizations.
The attack does not try to impersonate Microsoft. It uses Microsoft. That distinction is the entire reason it works.
| Technique | ID | How It Applies |
|---|---|---|
| Phishing | T1566 | Primary delivery mechanism — fraudulent content via email |
| Compromise Accounts: Email Accounts | T1586.002 | Abuse of legitimate account infrastructure |
| Application Layer Protocol: Mail Protocols | T1071.003 | SMTP as the attack delivery channel |
| Masquerading | T1036 | Content masquerades as legitimate Microsoft notification |
Two SCuBA baselines are directly relevant to this attack:
Exchange Online Baseline (EXO)
| Control | Requirement | Relevance |
|---|---|---|
| MS.EXO.1.1 | External sender warning banners enabled | Flags microsoftonline.com as external to your tenant |
| MS.EXO.8.1 | Inbound anti-spam filtering enabled | Mail flow rules that flag known-abused sender patterns |
Microsoft Defender for Office 365 Baseline (DEFENDER)
| Control | Requirement | Relevance |
|---|---|---|
| MS.DEFENDER.1.1 | Preset security profiles enabled | Standard and Strict presets add behavioral analysis |
| MS.DEFENDER.2.1 | Safe Links enabled for all users | URL scanning on links in message body |
| MS.DEFENDER.4.1 | Anti-phishing policies configured | Impersonation protection and mailbox intelligence |
Run ScubaGear against your tenant today:
Install-Module -Name ScubaGear
Invoke-SCuBA -ProductNames exo, defender, aad
| Control Family | Control | Application |
|---|---|---|
| Access Control | AC-2 | Account management — unrestricted account creation enabled this attack |
| System and Information Integrity | SI-8 | Spam and malicious content protection |
| Awareness and Training | AT-2 | User awareness training specific to this attack pattern |
Step 1 — Deploy a targeted mail flow rule in Exchange Online.
New-TransportRule -Name "Flag Microsoft Notification Spam" `
-From "msonlineservicesteam@microsoftonline.com" `
-SubjectOrBodyMatchesPatterns "BTC","Bitcoin","not you\?","Call \+1","PayPal order" `
-SetSCL 9 `
-SetHeaderName "X-Suspicious-Notification" `
-SetHeaderValue "True" `
-Comments "Flags abused Microsoft notification emails per Spamhaus advisory May 2026"
Step 2 — Brief your users today.
If you receive an email from Microsoft about a PayPal transaction, Bitcoin purchase, or any unexpected account activity — do not call the phone number in the email and do not click any links. Navigate directly to microsoft.com or the relevant service to verify. Report suspicious emails to IT immediately.
Step 3 — Verify your Defender for Office 365 preset security profiles are active.
Step 4 — Run ScubaGear against your tenant and review every control marked as failing in the EXO or DEFENDER baselines.
Step 5 — Review your anti-phishing policy configuration. Ensure mailbox intelligence, impersonation protection, and spoof intelligence are all enabled.
Step 6 — Add this attack pattern to your security awareness training.
Step 7 — Review your incident response runbook. Verify that your IR process includes a clear path for users to report suspicious emails.
As a Microsoft Cloud Solution Provider, I manage M365 tenants for organizations that depend on Microsoft’s infrastructure for every email, every document, every meeting, and every authentication event in their business.
This incident reinforces something I have been saying for years: the security of your Microsoft 365 environment is not Microsoft’s responsibility alone. The shared responsibility model is real. Microsoft secures the platform. You are responsible for how that platform is configured, how your users are trained, and how your organization responds when the platform is abused — even when the abuse is not your fault.
The organizations that have not invested in that posture are relying on the assumption that trusted senders are safe senders. This incident is a direct refutation of that assumption.
“I’ve spent my career asking ‘what if’ when everyone else was asking ‘how much.’”
The ‘what if’ here is: what if the email your employee just acted on came from Microsoft, passed every authentication check, and was still a scam? The time to answer that question is before it happens — not after.
The conversations that matter most in a boardroom aren’t about technology. They’re about survival. And the technology questions executives can’t answer are the ones that determine whether the business survives.
I have spent over two decades walking into organizations — boardrooms, leadership meetings, budget conversations — where the technology discussion goes one of two ways.
Either the executives are overwhelmed and don’t know where to begin. Or they believe they are covered because they pay for cloud services, have an IT team, and haven’t experienced a major incident yet.
Both positions carry the same risk.
The organizations that are genuinely prepared are not the ones with the largest IT budgets. They are the ones where leadership — the CEO, the board, the CFO — can answer three specific questions clearly, with documented evidence, before a crisis begins.
Most cannot.
These three questions come directly from the Infrastructure Placement Framework — the open-source enterprise IT framework built and maintained by 4TH AND BAILEY. They map to Modules 4, 5, and 8 of the framework. They are not technical questions. They are leadership questions — and the answers determine whether an organization survives what is coming.
This is the cyber resilience question. And it is not a firewall question.
On July 19, 2024, a routine security update from CrowdStrike caused 8.5 million Windows systems to crash globally. The damage exceeded 10billion.DeltaAirlinestookfivedaystorecover,losingover10 billion. Delta Airlines took five days to recover, losing over 10billion.DeltaAirlinestookfivedaystorecover,losingover500 million. There was no cyberattack. No malicious actor. No password failure. A trusted vendor made a routine change — and organizations that had not answered this question in advance paid for it in days of downtime and hundreds of millions in losses.
In February 2026, ransomware hit the University of Mississippi Medical Center. All 35 clinic locations closed statewide. Epic went offline. Surgeries were canceled. Chemotherapy appointments were canceled. Nine days of partial shutdown followed.
These two events share one thread: the organizations affected were not unprepared because they lacked technology. They were unprepared because they had never answered three foundational questions before the crisis began.
How do we protect our data? Most organizations believe their data is protected because they pay for a cloud service. That belief is wrong. The vendor’s responsibility ends at the platform boundary. Your data — how it is backed up, encrypted, versioned, and recoverable — is your responsibility.
How do we keep operating if a vendor goes offline? Only 22% of healthcare organizations fully recovered from a ransomware attack in less than a week. Nearly 40% took more than a month. Recovery speed correlates directly with the quality of preparation.
How do we move our data if a platform stops serving us? Vendor lock-in accumulates quietly. The time to build a vendor exit runbook is before you need one.
Module 4 of the Infrastructure Placement Framework is the structured starting point.
This is the AI governance question. And for most organizations, the honest answer is no.
AI is now embedded in virtually every productivity tool employees use daily — Microsoft 365 Copilot, Google Gemini, Salesforce Einstein, GitHub Copilot, and hundreds of other tools with AI features enabled by default. Employees are not waiting for IT policy. They are using these tools right now, in every department, across every level of the organization.
Shadow AI — employees using unapproved AI tools without oversight — is present in virtually every organization. Client data entered into public AI systems. Proprietary processes described in chat prompts. Legal strategy, financial projections, and personnel decisions processed through tools whose data handling policies most organizations have never reviewed.
The regulatory environment is catching up. NIST AI RMF 1.0, NIST AI 600-1, and NIST IR 8596 have established the standards framework. Most organizations have no policy, no inventory, and no idea what data has already entered public AI systems through employee usage.
Three things every organization needs before the end of this quarter:
A shadow AI audit that identifies which AI tools are in use, by whom, and what categories of data have been processed through them.
An AI acceptable use policy that defines approved tools, prohibited data types, and accountability — in plain language every employee can follow.
An AI vendor evaluation rubric that assesses every AI tool against data handling, security, and compliance standards before it is adopted organizationally.
Module 5 of the Infrastructure Placement Framework delivers all three — built on NIST standards.
This is the business continuity question. And the emphasis is on the word exactly.
Not “we have a plan.” Not “IT handles that.” Not “we back everything up.”
Exactly how. In what order. By whom. How fast. And when did you last test it?
The data is unambiguous:
Most organizations have a version of a disaster recovery plan. Almost none have a genuine business continuity plan. These are not the same document.
A Business Continuity Plan is strategic. It keeps the entire organization operating across all functions during and after any disruption.
A Disaster Recovery Plan is tactical. It restores IT systems and infrastructure after a technical failure. It is a component of the BCP — not a replacement for it.
The plan that has never been tested is not a plan.
Module 8 of the Infrastructure Placement Framework provides the complete BCDR structure — business impact analysis, BCP and DRP templates, ransomware playbook, breach notification guide, and tabletop exercise scripts for all six scenarios.
The Infrastructure Placement Framework is open source, vendor-neutral, and free to use under Creative Commons Attribution 4.0.
Three ways to engage:
Self-assessment. Fork the repository at github.com/4thandBailey/infrastructure-placement-framework and work through the modules relevant to your situation.
Guided assessment. Start a conversation at 4thandbailey.com/contact. Most guided assessments identify three to five immediately actionable findings.
Full engagement. 4TH AND BAILEY designs, builds, and deploys the infrastructure changes, governance structures, security controls, and policy frameworks the assessment identifies.
“I’ve spent my career asking ‘what if’ when everyone else was asking ‘how much.’”
The ‘what if’ is no longer hypothetical. The question is whether your organization is ready for it.
]]>Some problems need room to breathe before the architecture reveals itself. Tonight, lo-fi beats created that room — and a complete personal brand emerged from it.
I have been going back and forth on my personal brand for quite some time.
The domain trust-lionel.com existed. The idea existed. The work existed. What didn’t exist was a platform that felt right — one that could showcase not just a polished marketing site but actual proof of work. Thought leadership that lived on the open web, not locked inside someone else’s ecosystem.
LinkedIn is an echo chamber. The algorithm rewards engagement loops within your existing network. A well-optimized post can surface for someone in Singapore or Berlin who has never heard of you — but only if you own the platform it lives on.
GitHub gave me that platform.
No login required. LinkedIn quietly throttles content visibility for non-logged-in users. A GitHub Pages site is fully open, fully crawlable, and fully shareable — a link works for everyone, everywhere, no friction.
SEO ownership. When you publish on LinkedIn or Medium, they own the SEO value. Your content builds their domain authority. With GitHub Pages on trust-lionel.com, every article, framework, and thought leadership piece builds my domain authority permanently. That compounds over time in a way that LinkedIn posts never will.
Escaping the echo chamber. The open web doesn’t have an algorithm. It has Google. And Google rewards consistent, well-structured, keyword-rich content on domains with growing authority. That’s a game I can win by simply doing the work and documenting it.
Starting from a GitHub account with no public repositories, here is what exists as of May 16, 2026:
The Profile (github.com/trust-lionel)
LMO4TH to trust-lionel — brand cohesion across every platformahr-ki-tekt — one word, phonetic, stops people mid-scrolltrust-lionel.com · LinkedIn · Reddit · @4thandBaileyThe Banner
The Website (trust-lionel.com)
sitemap.xml submitted to Google Search ConsoleDNS
trust-lionel.com to GitHub’s serverswww to trust-lionel.github.ioSimplicity is sophistication. The bio is one word. ahr-ki-tekt. No explanation. No elaboration. The simplicity is the statement.
Own your platform. Every commit to trust-lionel.com builds my domain authority. Every post on LinkedIn builds theirs. The math is simple.
Authenticity in details. The server rack LEDs were originally blue. I changed them to green because green is the industry standard for active and healthy ports. Nobody might notice. But the people who would notice are exactly the audience I am trying to reach.
The architecture is the message. The data center banner doesn’t just look good — it tells you what I do before you read a single word. Visual language that only someone who understands enterprise IT would recognize instantly. For everyone else, it just feels like depth and expertise.
I came into tonight with a domain and a vision. I left with a fully realized personal brand on the open web — built on GitHub, powered by Astro.build, scored by lo-fi, and finished before sunrise.
The work was always there. It just needed the right architecture to live in.
That’s the difference between having something to say and having a place to say it.
]]>I enjoy working with different computing platforms. When using my MacBook Pro — switching between PowerShell and Terminal — I often forget commands like Flush DNS Cache. Rather than reaching for my notes every time, I opened Xcode and built the solution.
MacSysTools is a native macOS system administration application built specifically for macOS Tahoe (26.x) running on an Intel MacBook Pro.
It provides a clean, professional graphical interface for common macOS Terminal commands — eliminating the need to remember complex command syntax or open Terminal manually. Every tool is one click away, with live output streaming, native sudo elevation, and a UI that feels indistinguishable from a first-party Apple application.
The core philosophy: encode the knowledge of what command to run and when, not just how. The app handles version detection, privilege elevation, output parsing, and error display — the user selects a tool and clicks Run.
Repository: github.com/trust-lionel/macsystools
Liquid Glass. macOS Tahoe introduced the most significant visual redesign since Big Sur, built around a new material called Liquid Glass. SwiftUI gets this automatically and correctly — Electron required undocumented private APIs that could break with any macOS point release.
Native performance. The MacSysTools app bundle is approximately 8MB. An equivalent Electron app would be roughly 150MB due to the bundled Chromium runtime.
Finder, Spotlight, and Dock integration. A SwiftUI app built with Xcode produces a proper .app bundle the OS recognizes natively — it appears in Spotlight search, pins to the Dock, and launches in under a second.
| Component | Version |
|---|---|
| Mac | MacBook Pro Intel (x86_64) |
| macOS | Tahoe 26.x |
| Xcode | 26.4.1 (17E202) |
| Swift | 6.3.1 |
| Interface | SwiftUI |
| Deployment Target | macOS 26.0 |
| Bundle ID | com.lionelmosley.MacSysTools |
| Tool | Command | Sudo |
|---|---|---|
| Flush DNS Cache | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder | Yes |
| nslookup | nslookup -type=[A/MX/TXT…] [hostname] [server] | No |
| Wi-Fi Diagnostics | networksetup -getinfo Wi-Fi && airport -I | No |
| Ping Host | ping -c [count] [hostname/IP] | No |
| Traceroute | traceroute [hostname/IP] | No |
| Renew DHCP Lease | sudo ipconfig set en0 DHCP | Yes |
| Tool | Command | Sudo |
|---|---|---|
| Purge Memory | sudo purge | Yes |
| Disk Permissions | diskutil verifyPermissions / | Yes |
| Clear System Logs | sudo rm -rf /private/var/log/asl/*.asl | Yes |
| Rebuild Spotlight | sudo mdutil -E / | Yes |
| Show Open Ports | sudo lsof -i -n -P | grep LISTEN | Yes |
| Clear Font Cache | sudo atsutil databases -remove && sudo atsutil server -shutdown | Yes |
| Tool | Command | Sudo |
|---|---|---|
| Kill Process | killall [process name] | No |
| Firewall Status | /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate | No |
| Gatekeeper Status | spctl --status | No |
| Clear App Cache | rm -rf ~/Library/Caches/* | No |
| Tool | Command | Sudo |
|---|---|---|
| Clear Xcode Derived Data | rm -rf ~/Library/Developer/Xcode/DerivedData | No |
| Show Hidden Files | defaults write com.apple.finder AppleShowAllFiles -bool true && killall Finder | No |
| Edit /etc/hosts | open -e /etc/hosts | No |
| System Information | system_profiler SPHardwareDataType SPSoftwareDataType | No |
| Tool | Command | Sudo |
|---|---|---|
| Enable Screen Sharing | sudo launchctl enable system/com.apple.screensharing | Yes |
| Enable Remote Login | sudo systemsetup -setremotelogin on | Yes |
| Enable File Sharing | sudo launchctl enable system/com.apple.smbd | Yes |
This project is a good example of how I think about problems. The frustration wasn’t Terminal — Terminal is powerful. The frustration was the cognitive overhead of remembering syntax for commands I use infrequently. The solution wasn’t a notes app or a cheat sheet. The solution was encoding the knowledge into a tool that eliminates the question entirely.
That’s the difference between a workaround and an architecture.
]]>