Jeff J.

Microsoft is retiring the standalone Share to Teams experience in #Outlook for users who don’t have the Teams desktop app installed. This change removes the web-based sharing dialog and aligns Outlook with the Teams client for a consistent and modern experience across platforms. https://topedia.net/Ycigoo

4

let's see how this works when creating new resources in private access modes, are outbound rules preconfigured for different service types to deploy successfully ? i.e batch , AKS, etc..

2

Most organizations assume every inbound email must pass through their MX record. That assumption is no longer always true in Microsoft 365. And the first time many admins discover this, it feels like finding a side door in a building you thought had one entrance. Here’s the reality 👇 If one Microsoft 365 tenant sends email to another Microsoft 365 tenant, Exchange Online can route that message directly across Microsoft’s backbone instead of performing a public MX lookup. In other words: Your MX record may never be consulted. Now before the pitchforks come out — this isn’t an RFC violation. RFC 5321 defines how mail should flow across the public internet. Once a message is already inside Microsoft’s cloud, Microsoft treats delivery as internal platform routing. From a SaaS efficiency standpoint, it makes total sense: • Lower latency • Reduced internet exposure • Higher reliability • Optimized internal routing But from a security and architecture standpoint… this is a BIG mindset shift. Why this matters: Many organizations still rely on third-party gateways (Proofpoint, Mimecast, Cisco, Barracuda, etc.) as their “front door” for: • Phishing protection • Sandboxing • DLP enforcement • Journaling and compliance Those controls assume: “All inbound mail comes through our gateway.” Direct tenant routing quietly breaks that assumption. This isn’t a bug. This isn’t a misconfiguration. This is the cloud redefining the perimeter. The old model: Perimeter security → Gateway → Mail server The Microsoft 365 model: Identity + platform security → Mailbox → User Microsoft’s expectation is clear: Security moves closer to the mailbox, powered by Defender for Office 365 and platform-native controls. For IT leaders, the takeaway is simple: Never assume your cloud architecture behaves the way it did on-prem. Because in the cloud, the “front door” might not be the only door anymore. #Microsoft365 #ExchangeOnline #CyberSecurity #CloudSecurity #EmailSecurity #ITLeadership #Office365 #EnterpriseIT #PhillipPittman

4

"We need to address our technical debt." I've said this sentence from both sides of the desk now, and let me tell you - it hits different depending on which chair you're sitting in. As an engineer, I meant: "Our network was designed for 200 users and we're at 1,500. I'm spending 3 hours troubleshooting issues that should take 30 minutes because nothing is documented. We have 'temporary' workarounds from 2019 that are now load-bearing architecture. And I'm one failure away from a resume-generating event." What my manager heard: "Engineers want to waste time making things perfect when everything works fine." Now I'm the manager. And I finally get why this conversation is so hard. Here's what I'm learning: → Engineers are usually right about technical debt. When they say something is fragile, it is. → But managers are juggling delivery pressure, budget constraints, and leadership asking "why are we rebuilding things that work?" → The temporary fix is NEVER temporary. Every single one becomes permanent infrastructure. → By the time technical debt is visible to non-technical people, you're in crisis mode. The time to fix it was months ago when engineers were raising "abstract concerns." → You can't defer maintenance forever. Systems that don't get maintained fail. It's not "if" - it's "when" and "how badly." The thing nobody tells you: Technical debt compounds like financial debt. That shortcut that saved 2 weeks in Year 1? It's costing you 3 weeks per project in Year 3. Your velocity drops 50% but you can't point to one cause - it's death by a thousand shortcuts. What's working for me: 70/20/10 rule - 70% features, 20% technical debt/maintenance, 10% learning. That 20% is non-negotiable. It's our insurance policy against future crises. New blog: Technical Debt - what engineers wish managers understood, and what managers need to know about prioritizing, communicating to leadership, and balancing debt with delivery ↓ https://lnkd.in/e5XMgxqs How are you handling technical debt in your org? Are you ahead of it or playing catch-up? Drop a comment - I'm still figuring this out.

47

9 Comments

We can create firewall policies with NAT rules for Source Network Address Translation on outgoing traffic. It will work by changing the source IP address of the traffic using a pool of SNAT from the internal network. Thus, the destination VM will see as source IP address, an internal "safe" IP address. https://lnkd.in/eMdQWm8y

5

Data Recovery Insights: Learning from Mistakes The Day I Stopped Believing in Backups (and Started Believing in Recovery) I stopped believing in backups the day Sydney deleted a .tfw file. Sydney was the sysadmin hired to replace the sysadmin who left in 2011. I was told to train him. Then he became my boss. One day, he deleted a small file used by TeleForms — something he “thought we didn’t need.” Within minutes, Data Processing went dark. TeleForms wouldn’t start. Production halted. His fix? Dig through fifty Iron Mountain tapes to find one with that file on it. Hours later, after sorting, labeling, restoring, and praying, he found it. The system came back… but the lesson stuck. See, we already had Compellent Fluid Data — before Dell ever bought them — with Data Instant Replay snapshots sitting right there, waiting to be used. But Sydney didn’t understand SANs. I did. That became my thing — block-based storage, Fibre Channel fabrics, instant recovery. I even got invited to Sidepath for Compellent training where the instructor said, “Wow. You could teach this class.” Not bragging. Just facts. Because when you’ve lived through broken systems, you learn the difference between: ·        A backup (a copy of what was) ·        A recovery plan (a way back to now) Backups are reactive. Recovery is architected. Sydney had backups. I had block storage. When his tape finally worked, it proved one thing: Backups don’t save systems. People who understand systems do. Fast-forward to today — SANs, snapshots, replication, cloud — it doesn’t matter what stack you’re using. The best “backup” is still someone who knows how to restore sanity. Final Thoughts I can already hear the comments, “Snapshots are availability tools, not resilience tools.” Or “They shorten your RTO, not your RPO.” “They give you a quick undo, not a clean slate.” Better yet, “Backups — real, off-array, immutable backups — are your safety net when: A firmware bug wipes your metadata. A junior admin formats the wrong volume. A crypto-worm hits your SAN management interface. A datacenter flood turns your “five-minute restore” into “five-month insurance claim.” I’m not saying your love for block-based recovery is wrong; it’s just incomplete. Snapshots save hours. Backups save companies. The trick is knowing when each applies. Use snapshots for operational recovery. Use backups for survival. You don’t need faith in backups — you need discipline in validating them. The day you skip a test restore is the day you start gambling instead of engineering.” And to that, I say you’re right. Which is why I sometimes end up with 3–5 copies of the same file scattered across PowerStores, Azure Blob, and my laptop… because, you know — redundancy. 😅

2

Intune Suite is evolving into a comprehensive endpoint management platform, and starting July 2026, it will be included in Microsoft 365 E3/E5 licenses. Security Risk Advisors blog highlights key features like Advanced Analytics and Enterprise App Management, and how they can simplify operations while reducing costs. Check it out for actionable insights! https://lnkd.in/giA57XDE

7

1 Comment

Excellent research by 中堂優也 and another reminder that Intune is not, in any way, considered to be a security control/boundary by Microsoft. Although… “Microsoft Intune and Microsoft Entra work together to secure your organization through device compliance policies and Conditional Access.” https://lnkd.in/eRX6K7Nx #Microsoft #Intune #OuttaTune #SecurityResearch I should also add that although the advice to require MFA for device join is worthwhile, I need to point out that Device Registration Service allows Public Client OAuth2.0 Flows aka Resource Owner Password Credentials aka basic authentication and so is a CA bypass. You can however hunt for and detect suspicious device join using ROPC - I wrote some KQL for it here https://lnkd.in/eV77zYNE

13

1 Comment