Jet Mariano

Tag: Microsoft 365

  • Litigation Hold in M365 (Complete Guide + Best Practices)

    Title:

    Litigation Hold in M365 — What It Is and How to Do It Right

    Introduction

    Litigation Hold preserves mailbox and OneDrive data for legal or compliance needs. I’ve used it in Monster Energy, PIMCO, Church projects, and Martin.

    What Litigation Hold Does

    • Keeps deleted emails
    • Preserves edited messages
    • Locks OneDrive items
    • Prevents irreversible deletion
    • Meets legal retention requirements

    How to Enable (GUI)

    M365 Admin Center → Users → Mailbox → Litigation Hold → Enable

    How to Enable (PowerShell)

    Set-Mailbox [email protected] -LitigationHoldEnabled $true -LitigationHoldDuration 3650

    Best Practices

    • Keep at least 5 years
    • Church uses 20 years
    • Store the reason in the notes
    • Never disable without GC/Legal approval
    • Use eDiscovery to search preserved data
    • Document everything

    Common Misunderstandings

    ❌ Litigation Hold is NOT retention policy
    ❌ Litigation Hold is NOT backup
    ✔ Litigation Hold is legal preservation

    Conclusion

    Use Litigation Hold carefully.
    Once enabled, treat that mailbox as evidence.

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

  • Terraform for M365 & Azure (With Real Examples)

    Title:

    Terraform for M365 and Azure — Infrastructure-as-Code Made Simple

    Introduction

    Terraform is one of the most powerful tools for managing cloud environments because it lets you declare what you want and Azure builds it. No guessing. No clicking. No forgetting what you changed.

    Even if M365 doesn’t support Terraform natively for all workloads, you can still automate Azure AD, Conditional Access, Groups, SPNs, Networking, Key Vault, and App Registrations through the Microsoft Graph provider.

    I used IaC principles while supporting Church systems — Terraform makes environments repeatable, auditable, and consistent.

    1. Installing Terraform

    choco install terraform

    2. Azure Login Block

    provider "azurerm" {
  features {}
}

provider "azuread" {
}

    3. Creating an Azure Resource Group

    resource "azurerm_resource_group" "rg1" {
  name     = "M365AutomationRG"
  location = "WestUS2"
}

    4. Creating an Azure AD Group

    resource "azuread_group" "security_group" {
  display_name     = "M365-Automation-Admins"
  security_enabled = true
}

    5. Creating an App Registration + Secret

    resource "azuread_application" "app" {
  display_name = "Terraform-Automation-App"
}

resource "azuread_service_principal" "sp" {
  application_id = azuread_application.app.application_id
}

resource "azuread_application_password" "sp_secret" {
  application_object_id = azuread_application.app.id
  display_name          = "secret1"
}

    6. Conditional Access via Terraform (Yes, possible!)

    Uses the Microsoft Graph Terraform provider.

    resource "msgraph_conditional_access_policy" "block_non_us" {
  display_name = "Block Non-US IP"
  state        = "enabled"

  conditions {
    users {
      include_users = ["all"]
    }
    locations {
      include_locations = ["All"]
      exclude_locations = ["US"]
    }
  }

  grant_controls {
    operator         = "OR"
    built_in_controls = ["block"]
  }
}

    7. Create an M365 Group (Unified Group)

    resource "msgraph_group" "m365_group" {
  display_name     = "Engineering Team"
  mail_nickname    = "engineering"
  security_enabled = false
  mail_enabled     = true
  group_type       = ["Unified"]
}

    8. Create Azure Key Vault

    resource "azurerm_key_vault" "kv" {
  name                = "m365-keyvault-prod"
  location            = azurerm_resource_group.rg1.location
  resource_group_name = azurerm_resource_group.rg1.name
  tenant_id           = data.azuread_client_config.current.tenant_id
  sku_name            = "standard"
}

    Conclusion

    Terraform is the “blueprint” of modern cloud administration.
    Clicking creates inconsistencies — IaC creates reliable, repeatable deployments.

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

  • Email Retention in M365 (Best Practices)

    Email Retention in Microsoft 365 — How to Keep What Matters

    Introduction

    Email retention ensures messages are kept for the correct amount of time for:

    • business
    • legal
    • compliance
    • industry regulations

    Monster, PIMCO, the Church, and Martin all used different retention needs.

    Retention Policy Basics

    Retention can:

    • Delete after X years
    • Keep and then delete
    • Keep forever
    • Auto-apply by keyword or location

    Example Retention Policies

    1. Keep 7 Years, Then Delete

    New-RetentionCompliancePolicy -Name "7 Years Email"
New-RetentionComplianceRule -Name "7YearEmailRule" -Policy "7 Years Email" -RetentionDuration 2555 -RetentionAction Delete

    2. Keep Forever

    GUI:
    Compliance → Data Lifecycle → Retention → Forever

    3. Auto-Apply to Executives

    New-RetentionComplianceRule -Name "ExecRetention" -Policy "ExecForever" -UserGroupFilter "JobTitle -eq 'Executive'"

    Best Practices

    • Always include shared mailboxes
    • Use Labels for sensitive groups
    • Never auto-delete without approval
    • Align with CIS security
    • Document your retention plan

    Conclusion

    Good retention protects the company — and the user.
    It ensures you keep what matters and nothing more.

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

  • The Evolution of Microsoft Exchange: From 5.0 to Exchange Online (EXO)

    A Technical History Through the Tools, Upgrades, and Real-World Administration That Shaped Modern Email

    Email administration today looks nothing like it did in the mid-1990s. What began as a system of flat files and small IS databases has evolved into a globally distributed, cloud-secure service powered by modern authentication, forensic automation, and layered identity protections.

    This article covers the full evolution — from Exchange 5.0 → 5.5 → 2000 → 2003 → 2007 → 2010 → 2013 → 2016 → Hybrid → Exchange Online — through the practical tools and real operational practices that defined each era.

    It also highlights legacy repair tools (ISINTEG, ESEUTIL), the emergence of PowerShell, and modern security controls such as DKIM, DMARC, and real-time EXO policies.

    1. Exchange 5.0 — The GroupWise Era & The Limits of Early Messaging

    When Exchange 5.0 existed, Novell GroupWise was still considered the enterprise email standard. Capacity was limited and reliability required constant hands-on administration.

    Key Characteristics

    • Basic directory service
    • Small private and public folder stores
    • No Active Directory yet
    • No PowerShell
    • 16GB database ceiling
    • Frequent corruptions under heavy load

    Real Tools Used

    🔧 ISINTEG — Logical Database Repair

    Example usage:

    ISINTEG -pri -fix -test alltests

    🔧 ESEUTIL — Physical Database Repair

    Soft recovery:

    ESEUTIL /r E00 /l "E:\logs" /d "E:\mdbdata"

    Hard recovery:

    ESEUTIL /p "E:\mdbdata\priv.edb"

    Defrag/whitespace removal:

    ESEUTIL /d "E:\mdbdata\priv.edb"

    White space mattered because the database could never exceed the size limit, and defrags were essential to survive weekly growth.

    2. Exchange 5.5 — The First True Enterprise Version

    Exchange 5.5 replaced GroupWise in many organizations because it solved the two biggest weaknesses:

    Major Improvements

    • Larger database limits
    • Internet Mail Connector (IMC) matured
    • Directory replication across sites
    • Better MAPI stability
    • More predictable backups

    This was the version where large organizations first began to trust Exchange for hundreds or thousands of users.

    Database limitations still required:

    • Regular whitespace removal
    • Offline defrags
    • ISINTEG repairs

    3. Exchange 2000 / 2003 — Active Directory Arrives

    The introduction of Active Directory changed everything.

    Now Possible

    • Kerberos authentication
    • Unified Global Address List
    • Recipient policies
    • Improved SMTP stack
    • Better routing groups

    Tools of the Era

    • ESEUTIL still required
    • ISINTEG for logical repair
    • Streaming file (.STM) management
    • COM+ based transport pipeline

    Disaster recovery still required:

    • Hard repairs
    • Log replays
    • Offline maintenance windows

    4. Exchange 2007 — PowerShell Revolutionizes Email Administration

    Exchange 2007 was the turning point. This version introduced:

    Major Innovations

    • PowerShell (EMS)
    • Role-based server architecture
    • Database Availability Groups (DAGs begin later)
    • Transport rules
    • Modern SMTP pipeline

    Example PowerShell Operations

    Bulk mailbox creation

    Import-Csv users.csv | % {
  New-Mailbox -UserPrincipalName $_.UPN -Name $_.Name -Alias $_.Alias
}

    Transport rule creation

    New-TransportRule -Name "Block EXE" -AttachmentExtensionMatchesWords ".exe" -RejectMessageReason "Executable blocked"

    Database health

    Get-MailboxDatabaseCopyStatus *

    PowerShell replaced ISINTEG as the primary troubleshooting interface.

    5. Exchange 2010 / 2013 — High Availability & Hybrid Era

    These versions supported:

    • DAGs with multiple copies
    • Outlook Anywhere (RPC over HTTPS)
    • Cross-forest migrations
    • Massive mailboxes (50GB+)
    • First large-scale hybrid deployments

    Database Whitespace Management

    Modern approach:

    Get-MailboxDatabase -Status | ft Name,AvailableNewMailboxSpace

    To reclaim all space:

    1. Create new database
    2. Move mailboxes
    3. Remove old database
    4. Mount clean database

    Multi-region examples

    • Databases per region (NA/APAC/EMEA)
    • Public folder migrations
    • CAS/Hub/MBX role separation

    6. On-Prem to Cloud Migrations — AWS WorkMail, Exchange 2010, Hybrid, EXO

    Organizations with large global footprints began migrating:

    Migration Examples

    • From AWS WorkMail → Exchange 2013 HA → EXO
    • From Exchange 2010 datacenters → Hybrid → EXO
    • From Exchange 2013 → EXO using HCW and staged cutover

    Challenges Solved by EXO

    • No more ESEUTIL
    • No more ISINTEG
    • No more DAG patching
    • No more weekend downtimes
    • Automatic redundancy
    • Modern authentication
    • Better malware scanning

    7. Exchange Online — The Modern Cloud Era

    Today, administrators rely on:

    • Exchange Online PowerShell v3
    • Graph API
    • Defender for O365
    • Purview eDiscovery
    • Modern connectors
    • DKIM / DMARC enforcement
    • Real-time spam intelligence
    • Modern auth for SMTP

    How to Rotate DKIM 2048-bit Keys

    Admin Center → Security → Email Authentication → DKIM → Rotate Keys

    Verify in PowerShell

    Get-DkimSigningConfig | fl Domain,Selector1CNAME,Selector2CNAME

    Keys should be:

    • 2048-bit
    • Rotated regularly
    • Protected from unauthorized access

    **8. Real-World Security Hardening in EXO

    (Including the Kill-Switch Scripts)**

    Last-generation threats require immediate defensive controls.
    These are sanitized versions of the two emergency scripts used to block impersonation attacks:

    🛑 Kill Switch Transport Rule (Blocks All External Sender Impersonation)

    New-TransportRule -Name "KILL-SWITCH" `
-FromScope NotInOrganization `
-SentToScope InOrganization `
-SetHeaderName "X-Blocked" `
-SetHeaderValue "EmergencyBlock" `
-StopRuleProcessing $true `
-Enabled $true `
-Mode Enforce

    🛑 Block-All Impersonation Rule

    New-TransportRule -Name "BLOCK-IMPERSONATION" `
-HeaderMatchesMessageHeader "From" `
-HeaderMatchesPatterns ".*@yourdomain\.com" `
-SentToScope InOrganization `
-FromScope NotInOrganization `
-RejectMessageReasonText "External sender attempted domain impersonation" `
-StopRuleProcessing $true

    After the event is over, disable:

    Disable-TransportRule "KILL-SWITCH"
Disable-TransportRule "BLOCK-IMPERSONATION"

    9. Why Exchange Online Beats Every On-Prem Version

    No More:

    • Database corruption
    • ESEUTIL repair weekends
    • ISINTEG logical rebuilds
    • Streaming file failures
    • Whitespace management
    • RPC failures
    • CAS array dependency

    Instead You Get:

    • Multi-region HA
    • Continuous patching
    • DKIM / DMARC alignment
    • Modern authentication
    • Real-time message trace
    • Defender Safe Links/Safe Attachments
    • Purview forensic tools
    • 24/7 cloud threat intelligence

    10. Summary

    This blog ties together:

    • The original on-prem tools (ISINTEG, ESEUTIL)
    • The arrival of AD
    • The PowerShell revolution
    • The hybrid era
    • The modern cloud security stack
    • DKIM rotation
    • EXO forensic investigation
    • Emergency transport rule defense

    It shows why the move from Exchange 5.0 to EXO was inevitable — every stage improved reliability, scalability, administration, and security.

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

  • Exchange Online Throttling Policies: Why They Exist, When to Modify Them, and How to Justify Changes

    Introduction

    Exchange Online throttling policies exist for one core reason — to keep the Microsoft 365 ecosystem healthy, stable, and resistant to abuse.
    Throttling protects the service from:

    • Excessive load
    • Misconfigured applications
    • Compromised accounts sending thousands of emails
    • Bulk operations that can degrade tenant performance

    It’s not a punishment.
    It’s Microsoft’s way of guaranteeing fairness across millions of tenants.

    But in real production environments — especially at the enterprise, hybrid, or application-integration level — default throttling limits can sometimes block legitimate business-critical operations.
    And when that happens, you must know:

    1. Why throttling exists
    2. How to detect throttling
    3. When it’s justified to modify limits
    4. How to request changes with Microsoft support

    This is one of the topics principal-level interviewers love because it shows deep operational understanding.

    Why Throttling Exists in Exchange Online

    Microsoft enforces throttling to prevent:

    1. Service Abuse

    A single compromised account can send 10,000+ spam emails within minutes.
    Throttling slows these bursts so EOP can react and block the session.

    2. Tenant Misconfigurations

    Common misconfigurations that trigger throttling:

    • Line-of-business apps sending too many messages too quickly
    • Applications reusing connections improperly
    • Legacy services using Basic Auth patterns
    • Scripts or PowerShell modules pulling data too fast

    3. System Stability

    If every tenant could push unlimited requests, the shared service collapses.
    Throttling ensures:

    • CPU fairness
    • Bandwidth fairness
    • Queue stability
    • Storage and transport efficiency

    How to Detect Throttling Events

    You will usually see:

    📌 Error Examples

    • Server Busy
    • Backoff due to throttling policy
    • TooManyConcurrentConnections
    • Exceeded message submission rate limit
    • SendAsDenied triggered by backlog saturation

    📌 Where You See These

    • Exchange message trace
    • Transport logs
    • Application logs
    • SMTP client logs
    • EOP reports
    • PowerShell scripts returning "ProcessingStopped"

    📌 Behavioral Symptoms

    • Messages stuck in Outbox
    • Applications retrying endlessly
    • High SMTP queue latency
    • Inconsistent delivery within seconds-to-minutes range

    When It Is Appropriate to Modify Exchange Online Throttling

    This is key.
    You never change throttling “because someone wants faster emails.”
    You change throttling for business justification only, such as:

    1. Application Mailbox Accounts

    These accounts often need higher:

    • MaxSendRate
    • RecipientRateLimit
    • MessageRateLimit

    Examples:

    • ERP systems
    • CRM systems
    • Manufacturing systems (Backflush, MES, D365)
    • Monitoring systems
    • Ticketing systems (ServiceNow, Jira, Zendesk)

    2. Hybrid Exchange Servers

    Hybrid servers may require adjusted:

    • PowerShell concurrency
    • EWS limits
    • MRS (Mailbox Replication Service) migration speeds

    Especially during:

    • Large cutovers
    • Fast-track migrations
    • Bulk mailbox moves

    3. Automated Services Needing High Burst Throughput

    Scenarios where default throttling causes issues:

    • Finance systems sending thousands of statements
    • HR systems sending open enrollment packets
    • Email marketing systems using authenticated SMTP
    • Daily reporting engines generating PDFs for hundreds of users

    How to Justify Throttling Changes to Microsoft Support

    This is where senior-level experience shows.

    Microsoft will not modify throttling unless you prove:

    1. Operational Need

    Explain what system is being blocked.

    2. Business Impact

    Show examples:

    • Delayed invoices
    • Delayed purchase orders
    • Delayed system alerts
    • Delayed manufacturing workflows

    3. Technical Evidence

    Provide logs showing:

    • Backoff errors
    • Submission rate failures
    • EWS throttling hits
    • Application retry loops

    4. Confirmation That It’s Not Spam

    Show the account is app credentialed, not user-driven.

    5. You Have Already Tuned the Application

    Microsoft wants evidence that:

    • Retry logic exists
    • Connection reuse is efficient
    • Burst sending is controlled

    If justified, Microsoft raises throttling for:

    Specific service accounts only
    (Never the whole tenant.)

    They may change:

    • Recipient rate limits
    • Message burst limits
    • EWS or Graph concurrency
    • PowerShell session limits

    Common Interview Question: “Why Not Remove Throttling Entirely?”

    Perfect answer:

    “Because throttling is part of Microsoft’s multi-tenant stability and security model.
    Without it, one tenant’s misconfiguration or compromised account could degrade the entire service.
    Changes should be scoped, justified, temporary, and monitored.”

    PowerShell: Checking Throttling Policy Assigned to a Mailbox

    Get-ThrottlingPolicyAssociation -Identity [email protected]

    PowerShell: View Existing Throttling Policies

    Get-ThrottlingPolicy | fl Name,MessageRateLimit,RecipientRateLimit

    PowerShell: Create a Dedicated Policy for an App Mailbox

    Set-ThrottlingPolicyAssociation -Identity [email protected] -ThrottlingPolicy AppMailboxPolicy

    Conclusion

    Throttling is not the enemy.
    It’s a guardrail.

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

  • Why RFC Email Standards Are Not Enough: A Real Look at Modern Email Security

    🛡 How Email Spoofing REALLY Works (With a Safer Example)

    Even though RFC standards gave us SPF, DKIM, and DMARC, the core SMTP protocol is still trust-based. That means attackers can abuse the protocol whenever a mail server is misconfigured or doesn’t enforce authentication.

    SMTP actually has two places where the “sender” can be declared:

    1. MAIL FROM (SMTP envelope)
    2. From: (message header inside DATA)

    Both of these can be forged.

    Here is a safe, fictional example showing what a spoofing attack looks like when the attacker controls their own SMTP server. NONE of this uses real domains or copyrighted examples.

    Example: Attacker Spoofing a CEO Email (Fictional Domain)

    S: 220 mail.hacker-smtp.test Ready
    C: HELO mail.hacker-smtp.test
    S: 250 Hello
    C: MAIL FROM:[email protected]
    S: 250 Ok
    C: RCPT TO:[email protected]
    S: 250 Accepted
    C: DATA
    S: 354 End data with .
    C: Subject: Immediate Action Required
    C: From: [email protected]
    C: To: [email protected]
    C:
    C: Hi Bob,
    C: Please review this file urgently:
    C: https://malicious-link.test
    C:
    C: Thanks,
    C: Jane
    C: .
    S: 250 Message accepted
    C: QUIT
    S: 221 Closing connection

    What happened here?

    • The attacker never touched the real domain’s server.
    • No SPF, DKIM, or DMARC was involved.
    • They simply declared themselves as [email protected].
    • The receiving system, if unprotected, trusts the SMTP envelope + header.

    This is why:

    • Email security must be enforced on the RECEIVING side.
    • SPF/DKIM/DMARC without an email security gateway (ProofPoint, Barracuda, Cisco, etc.) is NOT enough.

    🛡 Why SPF and DKIM Alone Can Be Faked

    Attackers don’t guess your DNS records—
    They retrieve them using public DNS queries.

    Example: How Hackers Pull Your DKIM Public Key

    nslookup -type=txt selector1._domainkey.yourdomain.com

    Example: How Hackers Retrieve Your SPF Policy

    nslookup -type=txt yourdomain.com

    Your actual records are public by design.

    Attackers do not break DKIM or SPF—
    they simply copy what’s public and send email from a server you do not control.

    This leads to the two main spoofing paths:

    Two Ways Attackers Deliver Spoofed Email

    1. Using Their Own SMTP Server

    • Full control
    • Can impersonate envelope sender and header
    • Can ignore security standards
    • Can replay your SPF/DKIM values
    • Can build reputation over time

    2. Using Someone Else’s SMTP Server

    • Open relay servers
    • Misconfigured mail servers
    • Free public spoofing tools (many exist)
    • Requires no authentication
    • Still bypasses SPF/DKIM because enforcement happens at the receiver

    🧩 Why You STILL Need ProofPoint or an SEG

    • RFC standards are voluntary
    • SPF/DKIM/DMARC are not enforcement engines
    • They only give a pass/fail signal
    • Your mail flow only becomes safe when paired with:
    1. ProofPoint BEC + EAC protection
    2. Malicious payload scanning
    3. Impostor Detection™
    4. Header anomaly detection
    5. Authentication-layer reputation scoring
    6. Threat intelligence for known bad SMTP sources

    No SPF/DKIM/DMARC setting—no matter how perfect—
    can stop a spoof that comes from an SMTP server across the world.

    Only a receiving enforcement engine can.

    Over the years I have worked with high end filtering solutions in multiple large enterprise environments. The dashboards have changed but their purpose has stayed the same.

    Their goal is to strengthen the RFC standards that are not strong enough on their own.

    Here are the RFCs that define the foundation of email authentication:

    • SPF — RFC 7208
    • DKIM — RFC 6376
    • DMARC — RFC 7489

    These standards are important but incomplete. Even with perfect configuration you can still get spoofing attempts, executive impersonation, phishing, and vendor fraud. The RFC by itself cannot stop the modern threat landscape.

    Below is a clear breakdown of why.

    Defense Wins Championships and Email Security Works the Same Way

    In basketball you cannot win with offense alone. You win when you have strong defense and efficient offense working together.

    Email follows the same pattern.

    SPF is offense
    DKIM is offense
    DMARC is offense

    They validate. They authenticate. They enforce the rule book.

    But attackers do not care about the rule book.
    They bypass these RFC standards every day.

    This is why you need a real defense layer.

    This is where filtering tools like Proofpoint or Barracuda add the protection the protocols cannot provide.

    Why SPF, DKIM, and DMARC Are Not Enough

    Even when perfectly configured these protocols only protect part of the message.

    SPF

    Checks the MAIL FROM envelope.
    Attackers spoof the visible Header From instead.

    DKIM

    Signs the headers.
    Attackers send unsigned mail from lookalike domains.

    DMARC

    Requires alignment.
    Attackers bypass alignment through friendly name tricks and unicode abuse.

    This is why even major companies with mature security still deal with spoofing.

    The RFCs do not cover every modern attack vector.

    What Third Party Filtering Tools Actually Do

    Filtering solutions provide the defense layer that SPF, DKIM, and DMARC cannot offer.

    They detect:

    • impersonation
    • behavior anomalies
    • malicious intent
    • lookalike domains
    • CEO fraud
    • malicious URLs
    • dangerous attachments
    • unknown senders
    • unusual source locations
    • suspicious API behavior
    • threat reputation changes

    They analyze behavior rather than relying only on protocol alignment.

    Without this layer your domain becomes an easy target.

    What Happens When Security Is Too Tight

    When filters are over configured these are the problems you will see:

    • executive emails going to junk
    • vendors trapped in quarantine
    • delayed messages
    • business interruptions
    • unhappy management
    • slow communication
    • loss of confidence in IT

    Security must be layered not suffocating.

    The Five Layers of Modern Email Security

    This approach is what works in every large enterprise environment.

    1. User Training

    Teach users how spoofing works.
    Show them friendly name manipulation.
    Awareness reduces risk.

    2. Proper Microsoft 365 Configuration

    Connectors. Accepted domains. Transport rules.
    Everything must be configured correctly.

    3. SPF, DKIM, and DMARC

    The RFC standards still matter.
    Alignment must be correct.

    4. Third Party Filtering Solutions

    Proofpoint. Barracuda. Mimecast.
    They provide what the RFC cannot.

    5. APM Monitoring

    Dynatrace. Splunk. AppDynamics.
    These tools detect environmental issues that affect mail flow.

    APM identifies:

    • abnormal MAIL FROM attempts
    • spikes in DKIM failures
    • SMTP conversation problems
    • delays before Proofpoint
    • anomalies at the DNS level

    This gives early warning before a threat becomes a major issue.

    Final Thought

    Email is the number one attack surface in every company.
    The truth is simple.

    You get what you pay for.

    If you go cheap your domain becomes a soft target.
    You will deal with spoofing
    You will deal with ransomware
    You will deal with compromised accounts
    You will deal with vendor fraud

    If you invest in complete layered defense your organization becomes a bad target.

    This is how modern email security works today.

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

  • When Inbox Rules Go Rogue: A 10-Command Playbook to Stop Impersonation

    Macro ant on a leaf—small bug, big damage. Quiet inbox rules (forward/delete/hide) are how real-account impersonation starts. This post shows 10 PowerShell fixes to stop it fast.

    Excerpt
    Most “email impersonation” losses start quietly—rules that forward, delete, or hide mail. This playbook backs up evidence, stops the bleed, removes risky rules, clears forwarding, and verifies. Calm hands, clear steps.

    Intro
    Most “email impersonation” (BEC) starts in two ways:

    1. Real-account misuse—someone phishes a password/token and quietly adds inbox rules (forward, delete, hide) or enables mailbox forwarding.
    2. No-account spoofing—look-alike domains and weak SPF/DKIM/DMARC let crooks send as if they’re us.

    This post fixes bucket #1 fast. You don’t need Compliance Center/Purview to clean a single mailbox: run these in Windows PowerShell 5.1 to back up → stop all rules → remove risky patterns → clear forwarding → verify. The examples below target [email protected]. After cleanup, keep the door shut by disabling SMTP AUTH/legacy protocols and blocking external auto-forwarding. (For bucket #2, tighten SPF/DKIM/DMARC—that’s outside this quick fix.)

    Perspective
    There are no super heroes in IT—no capes, no instant rescues. When rules go rogue, heroics make noise; runbooks make progress. The job is to protect people’s work with boring, proven steps.

    Practice (today, not someday)

    • Connect (read-only) — open a secure session to Exchange Online for the mailbox you’re fixing. Import-Module ExchangeOnlineManagement -RequiredVersion 3.9.0 -Force Connect-ExchangeOnline -UserPrincipalName [email protected] -ShowBanner:$false $mbx = "[email protected]"
    • Backup rules to CSV (read-only) — take a snapshot so you have evidence and an easy rollback reference. $ts = (Get-Date).ToString('yyyyMMdd-HHmm') Get-InboxRule -Mailbox $mbx | Select Name,Enabled,Priority,From,SentTo,SubjectContainsWords,MoveToFolder,ForwardTo,RedirectTo,DeleteMessage,StopProcessingRules | Sort Priority | Export-Csv "$env:USERPROFILE\Desktop\$($mbx)-InboxRules-$ts.csv" -NoTypeInformation -Encoding UTF8
    • Disable all rules (change) — safe stop; nothing runs while you fix things. Get-InboxRule -Mailbox $mbx | Disable-InboxRule -Confirm:$false
    • Remove delete rules (change) — get rid of any rule that silently deletes messages. Get-InboxRule -Mailbox $mbx | Where-Object {$_.DeleteMessage} | ForEach-Object { Remove-InboxRule -Mailbox $mbx -Identity $_.Name -Confirm:$false }
    • Remove hide/stop rules (change) — remove rules that hide mail (Junk/Archive/RSS/Conversation History) or halt further processing. Get-InboxRule -Mailbox $mbx | Where-Object { $_.StopProcessingRules -or ($_.MoveToFolder -match 'Junk|Archive|RSS|Conversation History') } | ForEach-Object { Remove-InboxRule -Mailbox $mbx -Identity $_.Name -Confirm:$false }
    • Remove forward/redirect rules, focusing on external (change) — strip any rule that forwards or redirects mail, especially off-tenant. $internal = @('jetmariano.us') # add internal domains if needed $rules = Get-InboxRule -Mailbox $mbx foreach($r in $rules){ $targets=@() foreach($t in @($r.ForwardTo)+@($r.RedirectTo)){ if($t -is [string]){$targets+=$t} elseif($t.PrimarySmtpAddress){$targets+=$t.PrimarySmtpAddress.ToString()} elseif($t.Address){$targets+=$t.Address.ToString()} elseif($t){$targets+=$t.ToString()} } $external = $false foreach($addr in $targets){ if($addr -match '@'){ $domain = ($addr -split '@')[-1].ToLower() if(-not ($internal -contains $domain)){ $external = $true } } } if($external -or $targets.Count -gt 0){ Remove-InboxRule -Mailbox $mbx -Identity $r.Name -Confirm:$false } }
    • Clear mailbox-level forwarding (change) — turn off any top-level forwarding set on the mailbox. Set-Mailbox -Identity $mbx -DeliverToMailboxAndForward:$false -ForwardingSmtpAddress $null -ForwardingAddress $null
    • Verify list and count (read-only) — prove you’re clean; zero is ideal. Get-InboxRule -Mailbox $mbx | Sort Priority | Format-Table Name,Enabled,ForwardTo,RedirectTo,MoveToFolder,DeleteMessage -Auto (Get-InboxRule -Mailbox $mbx | Measure-Object).Count
    • Re-enable only safe movers (optional change) — if you truly want routine filing, turn on only simple move-to-folder rules. Get-InboxRule -Mailbox $mbx | Where-Object { $_.MoveToFolder -and -not $_.ForwardTo -and -not $_.RedirectTo -and -not $_.DeleteMessage -and -not $_.StopProcessingRules } | ForEach-Object { Enable-InboxRule -Mailbox $mbx -Identity $_.Name -Confirm:$false }
    • Disconnect (read-only) — close your session cleanly. Disconnect-ExchangeOnline -Confirm:$false

    Final Reflection
    The work narrowed down to steady steps. Not a clever hack—just patience, order, and protection of someone’s inbox.

    Pocket I’m Keeping
    Runbooks over heroics.

    What I Hear Now
    Be steady. Protect the work. I’ll show you the next step.

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

  • Restoring Delivery Safely: SCL-1 + Tenant Allow/Block List

    Message trace + quarantine check (redacted): verified deliveries and deployed a Priority-0 SCL-1 allow rule for [partner-domain]

    Excerpt

    When a trusted partner’s emails started landing in spam (or nowhere at all), I traced the path, set a top-priority allow rule, and used Defender’s Allow/Block list to force clean delivery—without exposing internal details.

    Intro

    Today’s note is for admins who wear the on-call hat. Messages from [partner-domain] weren’t reaching our users. Some were quarantined as spam; others never showed. I documented the exact, reversible steps I used to restore delivery while keeping our environment safe and auditable. All vendor names, mailboxes, IPs, and hostnames are redacted.

    Notes from {Speaker}

    • Symptom: Mail from [partner-domain] was flagged/filtered; end users reported “not delivered” or “went to Junk.”
    • Tools used: Exchange Admin Center, Microsoft 365 Defender, Exchange Online PowerShell.
    • Constraints: Multiple legacy transport rules; need a change that’s surgical, auditable, and easy to roll back.
    • Guardrails: Prefer allowlisting at the domain + spoof layer (not blanket bypass for everything). Keep headers/SPF/DKIM intact for future tuning.

    Perspective (direct quotes)

    “No decision is a decision—so we’ll choose the safe, reversible one.”
    “Top-priority SCL-1 with Stop processing beats noisy downstream rules.”
    “If spoof intelligence is tripping, meet it where it lives: Tenant Allow/Block.”

    Practice (today, not someday)

    1) Triage — see what actually happened

    Connect-ExchangeOnline -UserPrincipalName [me] -ShowBanner:$false
Get-MessageTrace -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) `
  -SenderAddress *@[partner-domain] |
  Select Received,SenderAddress,RecipientAddress,Status

# If quarantined:
Connect-IPPSSession
Get-QuarantineMessage -StartReceivedDate (Get-Date).AddDays(-2) `
  -EndReceivedDate (Get-Date) -SenderAddress *@[partner-domain]

    2) Create a top-priority transport rule to force deliver

    • Condition: Sender domain is [partner-domain]
    • Action: Set SCL to -1
    • Option: Stop processing more rules
    • Priority: 0 (top)

    PowerShell (redacted names):

    New-TransportRule -Name "Allow [partner-domain] (SCL-1)" `
  -SenderDomainIs "[partner-domain]" -SetSCL -1 -StopRuleProcessing $true -Priority 0

    3) Add an org-wide Allow (Defender)

    • Defender → Policies & rules → Tenant Allow/Block List
    • Domains & addresses → Add → Allow → [partner-domain]
    • If Message Trace shows Spoof/High Confidence Phish, also allow under Spoofing for the exact sending pair.

    4) (Optional) Anti-spam policy allow list

    • Anti-spam inbound policy → Allowed domains → add [partner-domain].

    5) Verify

    Get-TransportRule "Allow [partner-domain] (SCL-1)" |
  fl Name,Priority,State,SenderDomainIs,SetSCL,StopRuleProcessing

# Send a new test; re-run Get-MessageTrace to confirm Status = Delivered

    6) Longer-term hygiene (ask the sender)

    • Ensure SPF passes (include correct outbound hosts).
    • Turn on DKIM for their domain.
    • Align DMARC policy gradually (none → quarantine → reject) once stable.

    Final Reflection

    Most “email is broken” moments aren’t outages—they’re safety systems doing their job a bit too eagerly. The win is balancing protection with precision so real mail flows and risky mail doesn’t.

    Pocket I’m Keeping

    Put the SCL-1 allow rule with Stop Processing at the top. It’s decisive, reversible, and neutralizes noisy legacy rules downstream.

    What I Hear Now (direct quotes)

    “Measure twice, move to Priority 0 once.”
    “Don’t fight spoof intelligence—configure it.”
    “Document the rollback the same minute you deploy the fix.”

    • Microsoft 365 Defender — Tenant Allow/Block List (TABL)
    • Exchange Online — Transport rules (mail flow rules)
    • Message trace in the modern EAC
      (references listed for context; links omitted for privacy—add your preferred docs when publishing)

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

  • Beat the 99% Wall: Upgrade Windows 10 → 11 the Easy Offline Way (Do This Before Oct 5, 2025)

    When the upgrade sits at 99%… don’t panic. Go offline and run the ISO upgrade the smart way

    Windows 10 reaches end of life on Oct 5, 2025. After that, it won’t get security updates. If you stay on Win10, your machine is a sitting duck for malware and attackers. Don’t procrastinate.

    If Windows Update keeps failing—or hangs forever at 99%—use this clean, offline upgrade that skips the flaky “checking for updates” step.

    1) First, confirm your PC is Windows 11–ready

    Use Microsoft’s official checker:
    https://support.microsoft.com/en-us/windows/check-if-a-device-meets-windows-11-system-requirements-after-changing-device-hardware-f3bc0aeb-6884-41a1-ab57-88258df6812b

    Important: The most common blockers are the CPU and motherboard (TPM 2.0, UEFI/Secure Boot). If your device doesn’t meet Windows 11 requirements, it’s unsupported after Oct 5, 2025. Treat that Windows 10 PC as unsafe for internet use—either upgrade/replace the hardware, reassign it to offline tasks, or retire it.

    2) Prep (5–10 minutes)

    • Unplug non-essential USB devices (drives, printers, docks).
    • Ensure ≥30 GB free on C:.
    • Suspend BitLocker (if enabled): Control Panel → BitLocker → Suspend.
    • Temporarily disable third-party AV/VPN.
    • Clean Boot: msconfig → Services → Hide Microsoft services → Disable all; Startup → disable everything.

    3) Reset Windows Update & appraiser caches (PowerShell)

    Open PowerShell as Administrator and run:

    net stop wuauserv
net stop bits
net stop cryptsvc

ren "C:\Windows\SoftwareDistribution" SoftwareDistribution.old
ren "C:\Windows\System32\catroot2" catroot2.old

rd /s /q "C:\$WINDOWS.~BT"
rd /s /q "C:\$WINDOWS.~WS"
rd /s /q "C:\Windows\Panther"
md "C:\Windows\Panther"

net start cryptsvc
net start bits
net start wuauserv

    Then heal the image:

    DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

    4) Run the upgrade offline from ISO (no update checks)

    1. Download the official Windows 11 ISO (same edition/language/arch) from Microsoft.
    2. Right-click the ISO → Mount → note the drive letter (e.g., E:).
    3. Disconnect the network (unplug Ethernet / disable Wi-Fi).
    4. In elevated PowerShell, launch Setup with Dynamic Update disabled:
    Start-Process -FilePath 'E:\setup.exe' -ArgumentList '/auto upgrade /dynamicupdate disable /copylogs C:\$UpgradeLogs' -Verb RunAs -Wait

    (Optional quick blocker scan without upgrading):

    Start-Process -FilePath 'E:\setup.exe' -ArgumentList '/compat scanonly /dynamicupdate disable' -Verb RunAs -Wait

    5) If it still stalls

    • Drivers (most common):
      • Storage: Device Manager → Storage controllers → switch to Microsoft Standard controller (Update driver → Let me pick).
      • Display: use Microsoft Basic Display Adapter temporarily.
      • Remove extra language packs, old VPN clients, and heavy OEM utilities.
    • BIOS/Chipset: update from your PC maker’s support page.
    • Rerun the offline setup command.

    6) Pinpoint the exact blocker (2 minutes)

    If it fails again, run Microsoft SetupDiag and read the summary:

    mkdir C:\SetupDiag; cd C:\SetupDiag
.\SetupDiag.exe /Output:C:\SetupDiag\SetupDiagResults.log
    • Codes like 0xC1900101-0x… usually name a driver (oem*.inf)—remove/roll it back and retry.
    • Dynamic-Update/Appraiser errors → repeat Step 3 and ensure you’re truly offline with /dynamicupdate disable.

    7) After success

    • Re-enable BitLocker, AV/VPN, and normal startup apps.
    • Reconnect the network and run Windows Update to pull fresh drivers and features.

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

  • Marked in Time — Sep 24, 2025 Email Offboarding: Forward for 14 Days → Then Retire the Mailbox (No Shared Mailboxes)

    Clean handoff: 14-day forward then retired the mailbox. using powershell

    Excerpt

    A simple, low-risk offboarding pattern: enable a 14-day forward to the supervisor with an auto-reply, keep copies in the mailbox, then remove forwarding and retire the account. No shared mailboxes, no drama.

    Photo suggestion

    Something neutral and professional: a close-up of a keyboard lock icon, or a soft sunset over a temple (if you want to keep the page’s visual theme).
    Caption idea: “Quiet handoffs, clean closures.”

    Context (redacted)

    Policy: No shared mailbox conversions. For leavers, enable a 2-week mail forward to the supervisor, show a clear auto-reply, then delete the user so the mailbox soft-deletes and later hard-deletes. Team files live in SharePoint/Teams; local working data is archived to encrypted USB for short-term retention.

    Before (T0) — Enable 14-Day Forward + Auto-Reply

    Goal: Forward new messages for two weeks and keep a copy in the mailbox for audit/review; clearly inform senders.

    Replace with your addresses before running:
    $User = "[email protected]"
    $Supervisor = "[email protected]"

    # Admin sign-in
Import-Module ExchangeOnlineManagement -ErrorAction SilentlyContinue
Connect-ExchangeOnline

# Vars
$User       = "[email protected]"
$Supervisor = "[email protected]"
$Days       = 14
$Now        = Get-Date
$End        = $Now.AddDays($Days)

# Enable mailbox-level forwarding (keep a copy)
Set-Mailbox -Identity $User `
  -ForwardingSmtpAddress $Supervisor `
  -DeliverToMailboxAndForward $true

# Schedule auto-replies for the same window
$InternalMsg = @"
This mailbox is no longer monitored.
For assistance, please contact $Supervisor or call the main line.
"@

$ExternalMsg = @"
Thanks for your message. This mailbox is no longer monitored.
Please email $Supervisor for assistance.
"@

Set-MailboxAutoReplyConfiguration -Identity $User `
  -AutoReplyState Scheduled `
  -StartTime $Now `
  -EndTime $End `
  -InternalMessage $InternalMsg `
  -ExternalMessage $ExternalMsg `
  -ExternalAudience All

    Parallel housekeeping (same day):

    • Reset the user’s password, revoke sign-in sessions, and (optionally) block sign-in during the transition.
    • Transfer/confirm ownership of OneDrive/SharePoint/Teams files needed by the team.
    • Archive any local workstation data to an encrypted USB (BitLocker To Go) if policy allows.

    After (T+14) — Remove Forwarding → Retire Account

    Goal: Stop forwarding, disable auto-reply, and delete the user (soft-delete mailbox). Optionally hard-delete the mailbox once soft-delete is visible.

    Import-Module ExchangeOnlineManagement -ErrorAction SilentlyContinue
Connect-ExchangeOnline

$User = "[email protected]"

# Remove mailbox-level forwarding & auto-reply
Set-Mailbox -Identity $User -ForwardingSmtpAddress $null -DeliverToMailboxAndForward $false
Set-MailboxAutoReplyConfiguration -Identity $User -AutoReplyState Disabled

# Delete the user in Entra ID (do this in the portal or via Graph)
# Entra admin center → Users → select user → Delete
# After directory sync, the mailbox will be in "soft-deleted" state (up to 30 days)

# Optional: Permanently delete the mailbox once soft-deleted
$Soft = Get-Mailbox -SoftDeletedMailbox -ErrorAction SilentlyContinue |
        Where-Object {$_.PrimarySmtpAddress -eq $User}
if ($Soft) {
  Remove-Mailbox -PermanentlyDelete -Identity $Soft.ExchangeGuid -Confirm:$false
}

    Lessons Learned

    • Clarity beats complexity. Forward + auto-reply for a defined window avoids confusing senders and helps the team capture anything urgent.
    • Keep a copy while forwarding. It preserves context during the transition.
    • No shared mailbox needed. If policy prohibits it, you can still do a clean, auditable handoff.
    • Document the timestamps. Password reset, token revocation, forward on/off, user deletion, and any permanent mailbox purge.

    Pocket I’m Keeping

    • Short window, clear message, clean cutover.
    • Files belong in SharePoint/Teams; email is a temporary bridge.
    • Quiet, consistent process reduces friction and drama.

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

  • How to Bypass Spam Filtering for Internal Senders Using PowerShell

    Intro:
    When internal emails from trusted coworkers suddenly stop showing up in your focused inbox or fail to trigger your Outlook rules, it’s easy to miss critical messages. In my case, one sender was previously blocked due to a spoofing incident, and although removed from the block list, her messages were still bypassing my folder rules—buried in the inbox. Message Trace confirmed the emails were delivered, but not filtered correctly. Here’s how I resolved the issue using PowerShell.

    🔍 Problem Recap:

    Despite the sender being trusted and allowed, her emails:

    • Skipped my Outlook inbox rules
    • Did not show up in Focused Inbox or designated folders
    • Were confirmed delivered via Message Trace
    • Were previously on the Blocked Sender List, but later removed

    The Exchange Admin Center (EAC) didn’t offer the flexibility I needed to create an accurate spam bypass rule. So I switched to PowerShell.

    🛠️ Solution: Create a Transport Rule via PowerShell

    Instead of struggling with the limited dropdowns in the modern Exchange portal, I used the New-TransportRule cmdlet to create a spam filter bypass rule in just a few lines.

    Here’s how:

    Connect-ExchangeOnline -UserPrincipalName [email protected]

New-TransportRule -Name "Bypass Spam Filtering from Trusted Senders" `
  -From '[email protected]','[email protected]' `
  -SetSCL -1

    What it does:

    • Matches emails from the listed senders
    • Sets SCL (Spam Confidence Level) to -1, meaning “do not treat as spam”
    • Ensures messages bypass all anti-spam filters and go straight to your inbox

    ⚡ Why Use PowerShell?

    The new Exchange Admin Center UI (EAC) lacks direct options to set SCL or bypass spam filtering with precision. PowerShell:

    • Provides full control
    • Is faster and more reliable
    • Allows batch configuration
    • Gives access to legacy controls like -SetSCL

    🔐 Notes:

    • Email addresses in the example are redacted for privacy
    • Make sure you have the Exchange Online PowerShell v3 module installed
    • You can verify the rule with:
    Get-TransportRule "Bypass Spam Filtering from Trusted Senders" | Format-List Name, From, SetSCL

    Conclusion:
    PowerShell remains the most powerful tool in any IT administrator’s arsenal—especially when the GUI can’t keep up. If you ever run into stubborn mail delivery or spam issues, consider creating targeted transport rules using PowerShell. It’s fast, clean, and gets the job done without frustration.

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

error: Content is protected !!