Category: Weekly Blog

Weekly blog series featuring real-world IT solutions, cloud security strategies, automation projects, and development tutorials to help professionals build resilient, scalable environments.

  • 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.

  • DKIM Security: How Signing and Key Rotation Stop Email Spoofing

    Introduction

    DKIM (DomainKeys Identified Mail) is one of the most effective ways to verify that an email truly came from your organization. But many companies misunderstand one crucial truth:

    DKIM is only as strong as the protection of its private key.

    If attackers obtain your DKIM private key, they can sign email that appears cryptographically legitimate — even if it comes from a malicious server. This is why key length, rotation, and protection matter just as much as turning DKIM “on.”


    Section 1 — What DKIM Actually Does

    DKIM works by attaching a digital signature to every outbound message.
    It ensures:

    • The message hasn’t been altered
    • The sender is authorized
    • The domain identity can be verified

    The core elements are:

    1️⃣ DKIM Selector (s=)

    Identifies which key is used.
    Example:
    s=mail2025;

    2️⃣ DKIM Domain (d=)

    The domain signing the message.
    Example:
    d=example-corp-secure.com;

    3️⃣ Public Key (Published in DNS)

    Stored in a TXT record:
    mail2025._domainkey.example-corp-secure.com

    4️⃣ Private Key (kept hidden on the mail server)

    This is the key attackers target.
    It signs every outbound message.


    Section 2 — Why Private Keys Must Be 2048-bit Minimum

    Attackers today can break 1024-bit DKIM keys.

    • Cloud computing
    • GPU farms
    • Distributed cracking

    This is why Microsoft and major ESPs recommend 2048-bit keys.

    Weak DKIM = forged trust.


    Section 3 — Why You Must Rotate DKIM Keys Regularly

    Even a strong key becomes weaker over time:

    • Keys leak
    • Keys get copied
    • Keys get exposed in old backups
    • Misconfigured systems reuse keys
    • Bad actors gather DNS data for months

    Weekly or monthly rotation is considered best practice in regulated industries like banking.

    Rotation protects your domain even if an attacker manages to obtain an older key.


    Section 4 — How an Attacker Exploits DKIM

    If the private key is stolen:

    • They can sign malware
    • They can sign phishing
    • They bypass SPF failures
    • They pass DKIM alignment
    • They pass DMARC alignment
    • Email goes straight to inbox

    This is why DKIM alone is not enough.


    Section 5 — Why DKIM Matters

    • Prevents email tampering
    • Builds domain trust
    • Enables DMARC “reject” mode
    • Protects your brand
    • Reduces false positives
    • Ensures message integrity

    But DKIM is only strong if the private key is protected and rotated.


    Conclusion

    Most executives think DKIM is “set it and forget it.”
    But email security today requires:

    • Strong 2048-bit DKIM keys
    • Regular rotation
    • Tight private key protection
    • Monitoring through Proofpoint and EOP
    • DMARC enforcement

    This is not optional anymore — especially for banks.


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

  • DMARC (Domain-based Message Authentication, Reporting & Conformance)

    Introduction

    DMARC (Domain-based Message Authentication, Reporting & Conformance) is the control system that tells receiving email servers what to do when a message fails SPF or DKIM. Without DMARC, attackers can spoof your domain freely.


    Section 1 — What DMARC Does

    DMARC:

    • Protects your domain from spoofing
    • Defines how mail servers should handle failures
    • Provides visibility into fraud attempts
    • Supports brand protection
    • Enables full enforcement (“p=reject”)

    Section 2 — DMARC Tags and Their Meaning

    1️⃣ v=DMARC1

    Protocol version. Always DMARC1.

    2️⃣ p= (Policy)

    Tells receiving servers what to do:

    • p=none → Monitor only
    • p=quarantine → Send failures to spam
    • p=reject → Block failures entirely (best practice for banks)

    3️⃣ rua= (Aggregate Reports)

    Where daily XML reports are delivered.
    Example:
    rua=mailto:[email protected]

    4️⃣ ruf= (Forensic Reports)

    Receives detailed failure samples (PII-sensitive).
    Example:
    ruf=mailto:[email protected]

    5️⃣ fo= (Failure Options)

    Controls what triggers forensic reporting.
    Common:
    fo=1 → Send forensic report on any SPF/DKIM failure.


    Section 3 — Example of a DMARC Record

    v=DMARC1;
    p=reject;
    rua=mailto:[email protected];
    ruf=mailto:[email protected];
    fo=1;
    adkim=s;
    aspf=s;
    

    adkim=s and aspf=s enforce strict alignment — critical for banks and regulated industries.


    Section 4 — Why DMARC Matters

    • Blocks domain impersonation
    • Reduces malware/phishing impact
    • Protects customers from fraud
    • Shields executives from spoofing
    • Enables brand trust
    • Essential for financial institutions

    Conclusion

    A strong DMARC policy (“reject”) is one of the strongest defenses against email spoofing — but only when SPF and DKIM are configured properly and regularly monitored.


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

  • Why PowerShell Still Beats Purview for Real Forensics: Speed, Depth, and No UI Limits

    Introduction

    Microsoft Purview is Microsoft’s compliance, audit, and eDiscovery platform for Microsoft 365. It provides GUI-driven tools for administrators to perform searches, create holds, review data, and respond to legal and compliance requirements.

    But here’s the reality that senior M365 engineers know:

    Purview is powerful, but it is not complete.
    It has strict limits, throttles, and boundaries designed for safety and performance — not deep forensic analysis.

    This is why serious investigations always end up in PowerShell, where engineers can bypass GUI limitations, perform deeper searches, and collect evidence with precision.


    Section 1 — What Purview Is (in plain English)

    Purview provides:

    • Content search
    • eDiscovery (Standard & Premium)
    • Litigation holds
    • Audit logs
    • Labeling and retention
    • Insider risk scanning
    • Communication compliance

    It is designed for:

    • Legal teams
    • Compliance officers
    • HR investigations
    • Corporate governance
    • High-level reporting

    And for these purposes, Purview works very well.


    Section 2 — The Hidden Limitations of Purview

    Here are the real limits engineers face:

    1. Sending & Rate Limits

    Purview actions follow the same throttling limits as Exchange Online.
    You cannot pull unlimited messages instantly.

    2. eDiscovery Query Limits

    Each Purview search query is limited to:
    10,000 characters
    This is a major limitation for complex filters.

    3. Maximum Export Sizes

    Large exports (multiple gigabytes) often fail or time out.
    This is why forensic engineers break searches into chunks.

    4. Maximum Holds Per Mailbox

    A mailbox can only have:
    25 holds total
    More than 25 affects performance, indexing, and mailbox health.

    5. External Recipient Limits

    Purview cannot override existing mailbox restrictions.

    6. Tenant-Wide Limits

    Even Premium eDiscovery has:

    • Search concurrency limits
    • Workflow throttling
    • Processing delays
    • Indexing dependency (if an item isn’t indexed, Purview can’t see it)

    7. Purview is not real-time

    It depends on indexing engines.
    Indexing delays = missing results.

    8. Purview cannot reveal everything

    For true forensics you often need:

    • Message trace logs
    • Transport logs
    • Historical mailbox snapshots
    • DeletedItems and RecoverableItems subfolders
    • Soft delete and hard delete content
    • Hidden folders
    • Unindexed items

    Purview cannot provide all of that.


    Section 3 — Why PowerShell is Superior for True Forensics

    When Microsoft engineers or financial institutions perform real investigations, they do not rely on Purview alone. They rely on PowerShell because PowerShell can do what Purview cannot.

    1. Access Every Folder (Including Hidden Ones)

    PowerShell can query:

    • Inbox
    • Sent
    • DeletedItems
    • RecoverableItems
    • Purges
    • Versions
    • Subfolders not visible in Outlook
    • Unindexed items

    Purview can’t.


    2. No GUI query limit

    There is no 10,000-character query restriction in PowerShell.

    Pattern searches can be huge, detailed, and layered.


    3. Deep Header and Message Metadata Extraction

    PowerShell can extract:

    • X-MS-Exchange-Organization-AuthAs
    • X-MS-Exchange-CrossTenant-*
    • Original client IP
    • Authentication results
    • Message submission type
    • Connector source
    • Spam confidence level (SCL)
    • Envelope sender
    • Message ID tracking

    Purview provides only summarized metadata.


    4. Instant, Real-Time Search

    PowerShell does not wait for indexing.
    You can search unindexed items directly.

    This is critical in security incidents.


    5. Mailbox Timeline Reconstruction

    With PowerShell you can reconstruct:

    • When the message was received
    • When it was moved
    • If rules redirected it
    • If a compromised mailbox forwarded it
    • If the user deleted it
    • If it was purged

    Purview cannot reconstruct movement history.


    6. PowerShell is scripting + automation

    You can automate:

    • Large case collections
    • Exports
    • Multi-mailbox searches
    • Pattern scans
    • Complex filters
    • Timeline reconstruction

    Purview cannot automate eDiscovery at the same level.


    Section 4 — When to Use Purview vs PowerShell

    Use Purview for:

    • Legal holds
    • HR requests
    • Basic content searches
    • Governance
    • Compliance reporting
    • Policy enforcement

    Use PowerShell for:

    • Security incidents
    • Ransomware investigations
    • BEC (Business Email Compromise)
    • External spoofing investigations
    • Compromised mailbox analysis
    • Hidden folder discovery
    • Deep metadata extraction
    • Multi-mailbox timeline reconstruction

    Most senior email engineers agree:

    Purview is the “legal view.”
    PowerShell is the “truth view.”


    Conclusion

    Purview is an essential tool for compliance and legal workflows — but it is not a forensic engine.
    Its GUI limits, throttles, and reliance on indexing mean that it can never replace the precision, speed, and depth of PowerShell.

    This is why real investigations — especially in financial institutions and regulated organizations — always rely on PowerShell for final answers.


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

  • Quick “Reflexes” Using PowerShell to Block Bad Actors: Emergency Transport Rules + Layer 3/7 Firewall Controls

    In modern cloud environments, threats don’t wait for meetings, approvals, or planning sessions.
    Sometimes an attack hits so fast that your only advantage is instinct, experience, and the ability to act immediately.

    Last month, I experienced exactly that — a coordinated impersonation attempt from multiple bad actors in Europe using public cloud hosting (GCP) as their relay. They created their own connectors and attempted to impersonate internal executives and accounting contacts.

    The attack bypassed standard controls because:

    • They used legitimate cloud IP ranges
    • They generated perfect SPF/DKIM passes
    • Their mail flow looked “clean” until you read the headers
    • They used crafted envelope senders + forged display names

    The only way to stop them instantly — before users were tricked — was to drop two transport rules at highest priority using PowerShell.
    These acted as “circuit breakers” until perimeter firewall rules could be deployed.

    Below is the exact PowerShell approach, redacted and rewritten for general use.


    🚨 Reflex Script #1 — Emergency “Kill Switch” Rule

    Purpose: If attackers are impersonating an internal address like [email protected], this rule blocks any external sender who uses that address in the envelope from or header from.

    # Connect to Exchange Online
    Connect-ExchangeOnline
    
    # Create emergency kill-switch rule
    New-TransportRule -Name "KILL SWITCH: Block external spoofing of noreply" `
    -FromScope External `
    -HeaderContainsMessageHeader "From" `
    -HeaderContainsWords "noreply@" `
    -SetSCL 9 `
    -StopRuleProcessing $true `
    -Priority 0
    

    What this rule does instantly:

    • Stops external senders pretending to be noreply@
    • Sets SCL=9 so the message is quarantined or rejected (depending on policy)
    • Stops evaluation of all other rules — making it hit within milliseconds

    🚨 Reflex Script #2 — Block ALL External Senders Using a Protected Address

    Attackers often rotate payloads or try other internal addresses.
    This second rule blocks all attempts — even if they change tactics.

    New-TransportRule -Name "BLOCK ALL External From Protected Address" `
    -FromScope External `
    -SenderAddressMatchesPatterns "noreply@", "billing@", "alerts@" `
    -SetSCL 9 `
    -StopRuleProcessing $true `
    -Priority 1
    

    You can modify the patterns depending on the address being abused.


    🛡️ Why This Worked Instantly

    These scripts bypass the UI delay and:

    • Apply before EOP content filters
    • Hit prior to Safe Links/Safe Attachments
    • Trigger even if messages pass SPF/DKIM/DMARC
    • Intercept mail before it reaches the user’s mailbox
    • Provide time to analyze, trace, and escalate

    This is why reflex PowerShell is critical for senior-level engineers — the GUI is too slow during live attacks.


    🔐 Permanent Fix: Layer 3 / Layer 7 Firewall Enforcement

    Once the immediate threat was stopped with PowerShell, the permanent fix required:

    Layer 3 (IP-based blocklists)

    Blocking:

    • Abused GCP IP ranges
    • Known threat actor networks
    • Anonymous compute nodes

    Layer 7 (Application-layer filtering)

    Policies included:

    • Block SMTP traffic from unknown hosts
    • Block unauthorized connector-based submissions
    • Strict URL filtering for phishing redirectors
    • Geo-blocking regions with no business presence

    Once these firewall measures were active, the PowerShell Kill Switch rules were safely disabled to avoid unnecessary mail flow impact.


    💡 Lessons Learned

    1. Bad actors are fast — you must be faster.
    2. Transport rules + PowerShell are your instant “circuit breakers.”
    3. SPF/DKIM/DMARC are not enough when attackers leverage cloud infrastructure.
    4. Layer 3 and Layer 7 controls create the “permanent seal.”
    5. Instant response + longer-term architecture = real protection.

    This is the type of real-world, battle-tested example that hiring panels want to hear.
    Not theory — lived experience.


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

  • How I Protected VIP Mailboxes in Exchange: My Experience Creating Shielded, Hidden, and Restricted Email Objects

    Intro

    In every organization — commercial, government, or religious — there are individuals whose roles require an extra layer of protection. These may include executives, legal teams, board members, or other high-visibility leaders. Their mailboxes must be shielded from noise, protected from internal misuse, and hardened against external threats.

    This blog shares how I implemented a VIP Exchange Protection Model in one of the most globally distributed environments I’ve ever worked in.
    All sensitive details are removed — but the principles and methods remain the same.


    Why VIP Mailboxes Need Extra Protection

    VIP users face unique risks:

    1. They are targets for impersonation

    Attackers attempt to spoof high-level leaders to gain authority over employees.

    2. They receive a high volume of inbound email attempts

    Even legitimate internal senders may unintentionally overwhelm their inboxes.

    3. They must focus on mission-critical responsibilities

    Unfiltered communication equals distraction and risk.

    4. Their mailboxes contain sensitive or privileged information

    Unauthorized access can lead to catastrophic consequences.

    The goal of the VIP model is simple:

    Only authorized individuals should be able to see, email, or discover these mailboxes.


    My VIP Protection Model (Redacted & Generalized)

    Below is the exact approach I used, without exposing private organizational information.


    1. Hide VIP Mailboxes From the Global Address List (GAL)

    This prevents the general population from seeing their email addresses.

    Set-Mailbox "VIP Mailbox" -HiddenFromAddressListsEnabled $true
    

    This ensures the mailbox exists — but only administrators know where it is.


    2. Restrict Who Can Email VIPs (Allow Lists Only)

    Instead of blocking all users, I inverted the model:

    Only a hand-selected, approved list of senders can email VIPs.

    I used:

    • Transport Rules
    • Moderation
    • Recipient Restrictions

    Example allow-list logic:

    Set-Mailbox "VIP Mailbox" -AcceptMessagesOnlyFrom @("Assistant1","Assistant2","SecurityOffice")
    

    If anyone outside this list tried to email the VIP:

    • The message was blocked,
    • Logged,
    • And optionally forwarded to a monitored mailbox for review.

    3. Prevent External Email Delivery Entirely

    For VIP mailboxes that should never receive external messages:

    Set-Mailbox "VIP Mailbox" -RequireSenderAuthenticationEnabled $true
    

    This enforces authenticated internal senders only.

    No anonymous sender.
    No spoofed external mail.
    No leakage.


    4. Apply Enhanced Anti-Impersonation

    This included:

    • DMARC alignment enforcement
    • Anti-spoofing engines (such as ATP / Defender)
    • Display name protection (“VIP Name Protection”)
    • Proofpoint Impostor Protection (in environments where I managed Proofpoint)

    I ensured VIP names could not be spoofed internally or externally.


    5. Enable Strict Audit Logging

    For VIP mailboxes:

    • Every access
    • Every folder action
    • Every send
    • Every delegate assignment

    …was logged and reviewed.

    Set-Mailbox "VIP Mailbox" -AuditEnabled $true
    

    This protected the VIP and the organization.


    6. Controlled Delegation

    VIP mailboxes should not have multiple delegates or dynamic permission assignments.

    Only essential individuals were allowed:

    • Executive assistants
    • Chiefs of staff
    • Security-approved personnel

    Least privilege.
    Zero trust.
    No exceptions.


    7. Role-Based Access Control (RBAC) For Admins

    Even administrators require controlled boundaries.

    I created RBAC roles to ensure:

    • Only specific admins could view or manage VIP mailboxes
    • No accidental changes
    • No unauthorized mailbox access

    This is premium-level Exchange governance.


    The Result

    By combining:

    • Hidden GAL entries
    • Sender allow-lists
    • External blocking
    • Anti-impersonation intelligence
    • Transport rules
    • Controlled delegation
    • RBAC
    • Audit trails

    …I built a VIP Exchange Protection Framework that:

    • Reduced risk
    • Eliminated unwanted emails
    • Protected sensitive correspondence
    • Honored the mission of the organization
    • Allowed leaders to focus on their responsibilities
    • Created a safer communication ecosystem

    This experience became one of the defining technical and spiritual stewardship assignments of my career.


    Final Reflection

    Protecting VIP mailboxes goes beyond technology — it’s stewardship, trust, and responsibility.

    When you guard a mailbox, you are guarding:

    • time,
    • focus,
    • privacy,
    • and the ability of leaders to do their work without distraction.

    Implementing this model taught me:

    Security is an act of service — not just configuration.

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

  • Email Spoofing Explained: How Attackers Do It and How DMARC Blocks Them

    Introduction

    Email is built on trust — and the original SMTP protocol (from 1982) was never designed with modern threat actors in mind. Attackers now exploit loose RFC rules, misconfigured servers, and public DNS to spoof legitimate senders and bypass basic filtering.

    This blog explains how spoofing actually works, why SPF/DKIM alone are not enough, and why DMARC alignment + Proofpoint is essential for stopping real-world business email compromise (BEC) attacks.


    1. Email Spoofing 101 — Why SMTP Allows It

    SMTP does not validate who the sender truly is.
    An attacker can control:

    a) The SMTP Envelope (“MAIL FROM”)

    Used for return-path, bounce messages, and SPF checks.

    b) The Email Header (“From:”)

    What the human sees in Outlook, Gmail, iPhone Mail.

    Both can be forged.
    That means an attacker can send:

    MAIL FROM: <[email protected]>
    From: Jane Doe <[email protected]>
    

    …even though they do not own that domain.


    2. Step-by-Step: How Attackers Use SMTP to Forge Email

    (Everything below uses neutral demonstration domains to avoid referencing any real organization.)

    S: 220 mail.fake-sender.net SMTP Ready
    C: HELO mail.fake-sender.net
    S: 250 Hello
    C: MAIL FROM:<[email protected]>
    S: 250 OK
    C: RCPT TO:<[email protected]>
    S: 250 Accepted
    C: DATA
    S: 354 Start mail input
    C: Subject: Urgent – Please Review
    C: From: [email protected]
    C: To: [email protected]
    
    Hi Bob,
    Please review this document:
    https://malicious-link-example.net/file
    
    Thanks,
    Jane
    C: .
    S: 250 Message accepted
    C: QUIT
    S: 221 Goodbye
    

    Important:
    This is exactly how attackers craft spoofed email — the same RFC-compliant commands a normal email client uses.


    3. How Attackers “Harvest” SPF and DKIM Using DNS

    Attackers don’t guess your DNS settings.
    They simply query them publicly, like anyone else on the internet.


    Example: Retrieving DKIM Keys

    nslookup -type=txt selector1._domainkey.victim-of-spoofing.com
    

    This returns the DKIM public key, which attackers use to craft more believable spoofing attempts (not to break DKIM, but to mimic structure).


    Example: Retrieving SPF Records

    nslookup -type=txt victim-of-spoofing.com
    

    Result:

    "v=spf1 include:_spf.example-email.net -all"
    

    Attackers now know:

    • what legitimate sending systems you use
    • how strict your SPF policy is
    • which vendors to impersonate

    SPF & DKIM are public, and attackers rely on that.


    4. Why SPF and DKIM Alone Are Not Enough

    SPF checks the envelope (MAIL FROM).
    DKIM checks the message integrity.

    But both fail in these common scenarios:

    SPF Fails When:

    • A scammer spoofs only the header From
    • Email is forwarded
    • Attackers use free SMTP servers with permissive policies

    DKIM Fails When:

    • Sender uses a domain with no DKIM at all
    • Attackers spoof domains they do own
    • Emails pass through weak relays

    This is why companies get spoofed even with “perfect” SPF/DKIM.


    5. DMARC Alignment — The Real Line of Defense

    DMARC requires:

    ✔ SPF Alignment

    Envelope domain must match header From domain.

    ✔ DKIM Alignment

    DKIM signature domain must match the header From.

    If neither aligns, DMARC instructs receivers to:

    • none — monitor only
    • quarantine — send to spam
    • reject — block outright

    Reject is where spoofing finally dies.


    6. Two Ways Attackers Deliver Spoofed Email

    This is critical for interview-level mastery:

    1️⃣ Using Their Own SMTP Server

    Attackers set up a server where:

    • they control all DNS
    • they can configure any RFC behavior
    • they can impersonate any domain

    This allows highly believable spoofing.

    2️⃣ Using Vulnerable Third-Party SMTP Servers

    Attackers often search for:

    • misconfigured mail relays
    • open SMTP relays
    • free spoofing services

    Both methods work unless DMARC reject + Proofpoint is in place.


    7. Why Proofpoint Completes the Protection

    Even with DMARC reject, attackers still spoof:

    • VIP names (“Display Name Spoofing”)
    • Lookalike domains (e.g., companny-secure.com)
    • Legitimate cloud providers that DMARC trusts
    • OAuth-compromised accounts (EAC)

    Proofpoint adds:

    • Identity threat intelligence
    • Imposter protection (BEC Defense)
    • Lookalike domain analysis
    • Behavioral anomaly detection
    • URL rewriting + sandboxing
    • Real-time classification

    Without Proofpoint, DMARC is only half of the defense.


    Conclusion

    Attackers rely on the weaknesses of SMTP’s original design, public DNS records, and domains they control. That’s why spoofing is still one of the most common and dangerous forms of cyberattack worldwide.

    The only way to fully protect executives, employees, and customers is:

    ✔ SPF
    ✔ DKIM
    ✔ DMARC (reject)
    ✔ PLUS Proofpoint’s identity + behavioral controls

    This is the combination that stops real-world BEC/EAC attacks.


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

  • How BEC (Business Email Compromise) and EAC (Email Account Compromise) Work, and How Proofpoint + EAC Controls Stop Them

    Introduction

    BEC (Business Email Compromise) and EAC (Email Account Compromise) are the two most financially damaging email-based attacks today.
    They bypass traditional spam filters, they target humans—not firewalls—and they abuse trust instead of malware.

    Microsoft 365 alone cannot fully protect against these attacks.
    That’s why organizations use Proofpoint, DMARC alignment, and strict authentication controls—to verify identity, stop impostors, and prevent fraudulent requests from reaching inboxes.

    This blog explains:

    • How BEC works
    • How EAC happens
    • What attackers exploit
    • Why RFC email standards make impersonation easy
    • How Proofpoint + EAC controls shut these attacks down

    Perfect material for any advanced interview panel.


    What Is Business Email Compromise (BEC)?

    BEC is when attackers pretend to be:

    • your CEO,
    • your CFO,
    • your HR director,
    • a vendor,
    • or someone with financial authority

    …with the goal of manipulating employees into:

    • wiring money
    • changing direct deposit info
    • sending W-2s
    • releasing confidential documents
    • approving purchases

    🔸 The key point:

    BEC uses identity deception, not malware.
    No attachments.
    No links.
    Just social engineering in a clean email.


    How BEC Works (Step-By-Step)

    1. Reconnaissance

    Attackers scrape:

    • LinkedIn
    • Company directory leaks
    • Press releases
    • Vendor invoices
    • Social media

    They map who communicates with whom.

    2. Identity Impersonation

    They spoof:

    • Display names
    • Envelope sender
    • Reply-To address
    • SPF-valid lookalike domains

    Example:
    [email protected]
    [email protected]

    3. Thread Hijacking

    They do this by compromising a vendor mailbox and replying inside an existing email chain.

    4. Social Engineering

    The attacker sends a “clean” request:

    • “Are you available?”
    • “I need this wire sent ASAP.”
    • “Can you update this banking information?”

    5. Financial Fraud

    Once the attacker has the employee’s trust — the money is gone.


    What Is Email Account Compromise (EAC)?

    EAC is when the attacker actually logs in to a real mailbox.

    Not spoofing.
    Not faking.
    Real access.

    How they gain access:

    • MFA fatigue
    • Password reuse
    • Legacy protocol with no MFA
    • OAuth token theft
    • Malware stealing credentials
    • Phishing pages identical to Microsoft login

    Once inside, attackers:

    • Set up hidden forwarding rules
    • Delete MFA alerts
    • Change mailbox rules
    • Hijack vendor threads
    • Sit silently and wait for financial conversations

    EAC is dangerous because the attacker uses your real domain, your real mailbox reputation, your real account.

    This is why simply having SPF, DKIM, and DMARC does not stop EAC.


    Why Proofpoint Is Needed (Beyond RFC Email Standards)

    RFC email standards allow spoofing by design.

    Attackers can:

    • abuse SMTP commands
    • spoof the “MAIL FROM”
    • spoof the “From:” header
    • use free SMTP servers
    • harvest SPF/DKIM values via nslookup
    • build near-perfect domain clones

    Example:

    nslookup -type=txt _dmarc.victim-domain.com
    nslookup -type=txt selector._domainkey.victim-domain.com
    

    Attackers see your exact SPF/DKIM configuration.
    They spoof accordingly.

    This is why relying on RFC standards alone is not enough.


    How Proofpoint Stops BEC and EAC

    1. Identity Protection

    Proofpoint checks:

    • display name anomalies
    • domain lookalikes
    • impossible travel
    • VIP impersonation attempts
    • internal vs external identity mapping
    • “Reply-To mismatch”
    • “Header vs Envelope mismatch”

    Microsoft EOP can do part of this,
    Proofpoint does it with far more accuracy.


    2. Vendor Fraud Protection

    Proofpoint fingerprints:

    • vendor sending behavior
    • previous conversation style
    • writing style
    • IP reputation

    If a vendor mailbox is compromised, Proofpoint detects the “change in sending personality.”

    This is one of the strongest EAC protections in the industry.


    3. DMARC Enforcement + Lookalike Domain Defense

    Proofpoint enforces:

    • Domain alignment
    • Display name behavior
    • Header-from authentication
    • Cross-identity matching

    Lookalike domains” examples (generic only):

    • company-secure.com
    • companny.com
    • c0mpany-support.com
    • company-mailservice.com

    These would pass traditional email filters.


    4. URL and Payload Isolation

    Even if links look clean, Proofpoint re-writes and detonates them.

    Although BEC rarely has links, EAC-based phishing almost always does.


    5. Machine Learning on Human Behavior

    Proofpoint analyzes:

    • who talks to whom
    • frequency
    • direction
    • urgency phrases
    • tone manipulation

    If the CEO normally never emails accounting at 10:30 PM on a Friday — the message gets flagged.


    Real-World Example (Anonymized)

    A vendor’s mailbox was compromised.
    The attacker replied inside an existing thread asking to update bank account numbers.

    Microsoft EOP didn’t block it — it came from a legitimate vendor domain.

    Proofpoint flagged:

    • anomalous IP
    • unusual writing style
    • “conversation thread hijacking detected”
    • vendor identity risk score

    Proofpoint blocked the message before it reached the user’s mailbox.

    This is exactly why companies invest in Proofpoint.


    Conclusion

    BEC and EAC are no longer “IT problems.”
    They are financial crimes, costing billions worldwide.

    Microsoft 365 gives strong baseline protection,
    but attackers today use identity manipulation, social engineering, and thread hijacking that bypass traditional signals.

    Proofpoint closes those gaps with:

    • identity defense
    • behavioral AI
    • vendor fraud detection
    • DMARC enforcement
    • mailbox compromise detection
    • impersonation protection

    © 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.

  • 💻 Path to Become a Developer (Ivy Falls)

    From coding late nights to building real solutions — proof that persistence pays off.
    DeveloperJourney #IvyFalls #NoBandAidFix

    Introduction: The Path Is the Practice

    My journey to development and infrastructure followed the same rhythm — discipline by day, learning by night.
    While working full-time at All Electronics Corporation in Van Nuys (1990–1995), I woke at 4 A.M. to catch two LA Metro buses from Western and 3rd Street to my 6:30 A.M. shift, then sometimes worked evenings at the Taco Bell drive-thru in Glendale.

    I wasn’t chasing titles; I was chasing understanding. At All Electronics, I became obsessed with the Integrated Circuit (IC) — the heartbeat of every computer. There was no Internet back then — only library books and endless curiosity. I crashed my own PCs, rebuilt them, and soon began fixing computers for free for anyone who needed help.

    Back then, I used to dream of a day when I wouldn’t have to wait for the bus in the rain just to get home. Years later, those same dreams became reality — not through luck, but through faith, discipline, and persistence. The rides changed — from buses to a BMW, an Audi, and now a Tesla — but what never changed was the purpose: to keep moving forward.

    Those early mornings and late nights opened the door to my first IT role at USC as a PC Specialist, then to GTE (now Verizon), Aerospace, and eventually to my own IT consulting business serving clients large and small across California and beyond.


    Season of Refinement

    While working full-time at USC, I entered what I call my season of refinement.
    By day I supported campus systems and users; by night I was a full-time student at Los Angeles City College (LACC) and a weekend warrior at DeVry University, studying Management in Telecommunications.

    It was during this time that Microsoft introduced the MCSE (Microsoft Certified Systems Engineer) program.
    One of my LACC professors encouraged me to earn it, saying, “Once you have that license, companies will chase you.”
    He was right — that MCSE became my ticket to GTE, my first step into enterprise-scale IT.

    My tenure at GTE was brief because Aerospace came calling with a six-figure offer just before Y2K — an opportunity too great to refuse.
    After Aerospace, I founded my own consulting firm — Ahead InfoTech (AIT) — and entered what I now call my twelve years of plenty.

    One of my earliest clients, USC Perinatal Group, asked me to design and implement a secure LAN/WAN connecting satellite offices across major hospitals including California Hospital Medical Center, Saint Joseph of Burbank and Mission Hills, and Hollywood Presbyterian Hospital.
    We used T1 lines with CSU/DSU units and Fortinet firewalls; I supplied every workstation and server under my own AIT brand.

    Through that success I was referred to additional projects for Tarzana and San Gabriel Perinatal Groups, linked by dedicated frame-relay circuits — early-era networking at its finest.
    Momentum carried me to new partnerships with The Claremont Colleges and the City of West Covina, where I served as Senior Consultant handling forensic and SMTP (email) engineering.

    Word spread further. An attorney client introduced me to an opportunity in American Samoa to help design and build a regional ISP, and later to a contract with Sanyo Philippines.
    During this period Fortinet was still new, and I became one of its early resellers. I preferred building AIT servers and workstations from the ground up rather than reselling mass-produced systems.
    DSL was just emerging, yet most clients relied on dedicated T1 lines — real hands-on networking that demanded patience and precision.

    Those were the twelve years of plenty — projects stretching from Los Angeles hospitals to overseas data links.
    By the time AWS launched in 2006 and Azure in 2010, I was already managing distributed networks and data replication.

    When I returned to Corporate America, my first full-time role was at Payforward, where I led the On-Prem to AWS migration, building multi-region environments across US-East (1a and 1b) and US-West, complete with VPCs, subnets, IAM policies, and full cloud security.
    That’s when I earned my AWS certifications, completing a journey that had begun with cables and consoles and matured in the cloud.

    Education, experience, and certification merged into one lesson:
    Discipline comes first. Validation follows.
    Degrees and credentials were never my starting line — they became the icing on the cake of years of practice, service, and faith.


    My Philosophy: Code Like a Craftsman

    Photography taught me patience. Martial Arts taught me form. IT taught me precision.
    All three share one secret: the art lies in repetition with awareness.

    As Ansel Adams said:

    “When words become unclear, I shall focus with photographs. When images become inadequate, I shall be content with silence.”

    Coding feels the same. When logic becomes unclear, I focus. When code seems inadequate, I find peace in understanding.


    The Developer Path

    1️⃣ Core Web Skills

    HTML | CSS | JavaScript (ES6+) | Git | GitHub
    Learn Free: freeCodeCamp | Traversy Media

    2️⃣ Frontend Framework

    Master React or Next.js.
    Courses: Max Schwarzmüller Udemy | Colt Steele Bootcamp | Jonas Schmedtmann JS Course

    3️⃣ Backend & APIs

    Choose Node.js or Python (Flask / FastAPI).
    Watch: Corey Schafer | Course: Angela Yu 100 Days of Code

    4️⃣ DevOps for Developers

    Learn Docker, GitHub Actions, and Cloud Deployments.
    Watch: TechWorld with Nana

    5️⃣ Labs & Simulators

    No hardware? Use Whizlabs Labs | Replit | Microsoft Sandboxes

    6️⃣ Portfolio

    Build three apps (CRUD, API, SPA) + README + screenshots + a short blog for each.


    Final Reflection

    From library nights in Koreatown to pushing code in the cloud, this path proves that curiosity and consistency still change lives.
    Keep learning, keep building, and remember — every keystroke is one more kick toward mastery.
    This blog will continue to grow as technology changes — come back often and build along with me.


    🪶 Closing Note

    I share this story not to boast but to inspire those still discovering their own path in technology.
    Everything here is told from personal experience and memory; if a date or detail differs from official records, it’s unintentional.
    I’m grateful for mentors like my LACC professor, who once told me to look up a name not yet famous — Bill Gates — and earn my MCSE + I.
    He was right: that single decision opened countless doors.

    I don’t claim to know everything; I simply kept learning, serving, and sharing.
    My living witnesses are my son, my younger brother, and friends who once worked with me and now thrive in IT.
    After all these years, I’m still standing — doing what I love most: helping people through Information Technology.


    ⚖️ Legal Disclaimer

    All events and company names mentioned are described from personal recollection for educational and inspirational purposes only. Any factual inaccuracies are unintentional. Opinions expressed are my own and do not represent any past or current employer.

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

  • 🖥️ Path to Become an Infrastructure Engineer (Ivy Falls)

    From Customer Service Rep to PC Specialist, Network Engineer, System Administrator, DevSecOps, and now Infrastructure Engineer — a journey built on faith, discipline, dedication, and gratitude.

    Introduction: The Path Is the Practice

    My story didn’t begin with servers or certifications.
    It began at All Electronics Corporation in Van Nuys, California, where I worked full-time from 6:30 A.M. to 3:00 P.M., taking two Metro buses and walking a block from the station — rain or shine — from December 1990 to late 1995.

    I woke as early as 4 A.M. to catch the first bus at Western and 3rd Street in Los Angeles, sometimes heading straight to my evening shift at the Taco Bell drive-thru in Glendale.
    Those were humble, exhausting days that taught me discipline and grit — lessons that would shape every part of my career.

    At All Electronics, I became fascinated by the IC — Integrated Circuit, the heart of every desktop computer. I wanted to understand it, not just sell it.

    Back in my Koreatown apartment, I turned curiosity into calling.
    No Google. No YouTube. No AI.
    Just library books and endless nights of self-study. I intentionally crashed my computers and rebuilt them until every fix became muscle memory.

    Once confident, I started offering free repairs and computer lessons to friends, relatives, and senior citizens — setting up printers, fixing networks, and teaching email basics. Those acts of service opened the door to my first full-time IT job at the University of Southern California (USC) as a PC Specialist.

    I still remember waiting at the bus stop in the dark, dreaming of the day I wouldn’t have to ride in the rain. Years later, those same dreams became reality — not through luck, but through faith, discipline, dedication, and gratitude.
    The rides changed — from buses to a BMW, an Audi, and now a Tesla — but what never changed was the purpose: to keep moving forward while staying grounded in gratitude.


    Season of Refinement

    While working full-time at USC, I entered what I call my season of refinement.
    By day I supported campus systems and users; by night I was a full-time student at Los Angeles City College (LACC) and a weekend warrior at DeVry University, studying Management in Telecommunications.

    It was during this time that Microsoft introduced the MCSE (Microsoft Certified Systems Engineer) program.
    One of my professors at LACC encouraged me to earn it, saying, “Once you have that license, companies will chase you.”
    He was right — that MCSE became my ticket to GTE (now Verizon), my first step into enterprise-scale IT.

    My tenure at GTE was brief because Aerospace came calling with a six-figure offer just before Y2K — an opportunity too good to refuse.
    After Aerospace, I founded my own consulting firm — Ahead InfoTech (AIT) — and entered what I now call my twelve years of plenty.

    One of my earliest major clients, USC Perinatal Group, asked me to design and implement a secure LAN/WAN connecting satellite offices across major hospitals including California Hospital Medical Center, Saint Joseph of Burbank and Mission Hills, and Hollywood Presbyterian Hospital.
    We used T1 lines with CSU/DSU units and Fortinet firewalls; I supplied every workstation and server under my own AIT brand.

    Through that success I was referred to additional projects for Tarzana and San Gabriel Perinatal Groups, linked by dedicated frame-relay circuits — early-era networking at its finest.
    Momentum led to new partnerships with The Claremont Colleges and the City of West Covina, where I served as Senior Consultant handling forensic analysis and SMTP/email engineering.

    Word spread. One attorney client introduced me to an opportunity in American Samoa to help design and build a regional ISP, and later to a contract with Sanyo Philippines.
    During this period Fortinet was still new, and I became one of its early resellers.
    Refusing to rely on mass-produced systems, I built AIT servers and workstations from the ground up for every environment.
    DSL was just emerging, yet most clients still relied on dedicated T1s — real hands-on networking that demanded precision and patience.

    Those were the twelve years of plenty — projects that stretched from local hospitals to overseas data links, from LAN cables to international circuits.
    By the time AWS arrived in 2006 and Azure followed in 2010, I had already been building and managing distributed networks for years.

    When I returned to Corporate America, my first full-time role was at Payforward, where I led the On-Prem to AWS migration, designing multi-region environments across US-East (1a and 1b) and US-West, complete with VPCs, subnets, IAM policies, and full cloud security.
    That’s when I earned my AWS certifications, completing a journey that had begun with physical servers and matured in the cloud.

    Education, experience, and certification merged into one lesson:
    Discipline comes first. Validation follows.
    Degrees and credentials were never my starting line — they were the icing on the cake of years of practice, service, and faith.


    My Philosophy: One Discipline, Many Forms

    Whether in Martial Arts, IT, or Photography, mastery comes from repetition, humility, and curiosity.
    As Ansel Adams wrote:

    “When words become unclear, I shall focus with photographs. When images become inadequate, I shall be content with silence.”

    Everyone can take a photo; not everyone captures a masterpiece.
    Everyone can study tech; not everyone understands its rhythm.
    Excellence lives in awareness — the moment when curiosity meets purpose.


    The Infrastructure Engineer Path

    1️⃣ Foundations

    Learn the essentials: Windows Server, Active Directory, DNS/DHCP, GPOs, Networking (VLANs, VPNs), Linux basics, and PowerShell.
    Free Resources:

    2️⃣ Cloud Platforms

    Start with AZ-104 Azure Administrator.
    Use free tiers to lab: Azure | AWS | GCP.
    Courses:

    3️⃣ Automation & DevOps

    Learn IaC (Terraform/Bicep), Docker, Kubernetes, and CI/CD.
    Watch TechWorld with Nana.

    4️⃣ Labs & Simulators

    No hardware? Try:

    5️⃣ Portfolio

    Document every lab, build diagrams, post scripts on GitHub, and write short lessons learned.


    Final Reflection

    From bus stops to boardrooms, from fixing desktops to deploying clouds — the principles never changed: serve first, learn always, and build things that last.
    This blog will continue to evolve as technology changes — come back often and grow with it.


    🪶 Closing Note

    I share this story not to boast, but to inspire those still discovering their own path in technology.
    Everything here is told from personal experience and memory; if a date or detail differs from official records, it’s unintentional.
    I’m grateful for mentors like my LACC professor, who once told me to look up a name not yet famous — Bill Gates — and earn my MCSE + I.
    He was right: that single decision opened countless doors.

    I don’t claim to know everything; I simply kept learning, serving, and sharing.
    My living witnesses are my son, my younger brother, and friends who once worked with me and now thrive in IT.
    After all these years, I’m still standing — doing what I love most: helping people through Information Technology.


    ⚖️ Legal Disclaimer

    All events and company names mentioned are described from personal recollection for educational and inspirational purposes only. Any factual inaccuracies are unintentional. Opinions expressed are my own and do not represent any past or current employer.

    © 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.

  • Exchange Online: Mailbox Used/Quota/Available (Redacted)

    Excerpt

    Exchange Online sometimes reports mailbox sizes with “Unlimited” wrappers that break simple math. Today I built a one-liner-friendly PowerShell snippet that returns Used GB, Quota GB, and Available GB—even when EXO wraps values in Unlimited<T>.

    Intro

    I needed the available mailbox size for [mailbox]@[domain] without exposing tenant internals. The usual TotalItemSize parsing failed because EXO returned Unlimited<ByteQuantifiedSize>. Here’s the redacted approach that works reliably and falls back cleanly.

    Notes from {Speaker}

    • Context: Exchange Online + PowerShell; target was [mailbox]@[domain].
    • Constraint: TotalItemSize and ProhibitSendQuota show Unlimited wrappers or localized strings.
    • Goal: Get UsedGB / QuotaGB / AvailableGB with no tenant secrets.

    Perspective (direct quotes)

    “If it’s Unlimited<T>, ask for .Value—and always guard with IsUnlimited.”
    “When objects don’t expose bytes, regex the (123,456 bytes) pattern as a fallback.”

    Practice (today, not someday)

    Use this redacted snippet. It works with Get-EXO* and falls back to classic cmdlets:

    # EXO connection (redacted UPN)
    Connect-ExchangeOnline -UserPrincipalName [me] -ShowBanner:$false
    
    $upn = '[mailbox]@[domain]'   # e.g., [email protected]
    
    try {
      $stat = Get-EXOMailboxStatistics -Identity $upn -ErrorAction Stop
      $mbx  = Get-EXOMailbox           -Identity $upn -PropertySets Quota -ErrorAction Stop
    
      $usedBytes = if ($stat.TotalItemSize.PSObject.Properties.Name -contains 'Value') {
        [int64]$stat.TotalItemSize.Value.ToBytes()
      } else {
        [int64](([regex]::Match($stat.TotalItemSize.ToString(), '\(([\d,]+)\sbytes\)')).Groups[1].Value -replace ',','')
      }
    
      $quotaBytes = if ($mbx.ProhibitSendQuota -and `
                        ($mbx.ProhibitSendQuota.PSObject.Properties.Name -contains 'IsUnlimited') -and `
                        -not $mbx.ProhibitSendQuota.IsUnlimited) {
        [int64]$mbx.ProhibitSendQuota.Value.ToBytes()
      } elseif ($mbx.ProhibitSendQuota.ToString() -notmatch 'Unlimited') {
        [int64](([regex]::Match($mbx.ProhibitSendQuota.ToString(), '\(([\d,]+)\sbytes\)')).Groups[1].Value -replace ',','')
      } else { $null }
    }
    catch {
      $stat = Get-MailboxStatistics -Identity $upn
      $mbx  = Get-Mailbox           -Identity $upn
      $usedBytes  = [int64](([regex]::Match($stat.TotalItemSize.ToString(), '\(([\d,]+)\sbytes\)')).Groups[1].Value -replace ',','')
      $quotaBytes = if ($mbx.ProhibitSendQuota.ToString() -match 'Unlimited') { $null }
                    else { [int64](([regex]::Match($mbx.ProhibitSendQuota.ToString(), '\(([\d,]+)\sbytes\)')).Groups[1].Value -replace ',','') }
    }
    
    $usedGB  = [math]::Round($usedBytes/1GB, 2)
    $quotaGB = if ($quotaBytes) { [math]::Round($quotaBytes/1GB, 2) } else { $null }
    $availGB = if ($quotaBytes) { [math]::Round(($quotaBytes-$usedBytes)/1GB, 2) } else { $null }
    
    [pscustomobject]@{
      Mailbox            = $upn
      UsedGB             = $usedGB
      QuotaGB            = $quotaGB
      AvailableGB        = $availGB
      StorageLimitStatus = $stat.StorageLimitStatus
    }
    

    Final Reflection

    EXO’s objects are powerful but quirky. Guarding for IsUnlimited, using .Value.ToBytes(), and keeping a regex fallback turns a flaky one-off into a repeatable tool.

    Pocket I’m Keeping

    Parse what’s there, not what you expect.” When APIs return wrapped or localized strings, a small fallback (regex for (#### bytes)) saves the day.

    What I Hear Now (direct quotes)

    “Measure in bytes, report in GB.”
    “Handle Unlimited first, then do math.”
    “One clean object out—every time.”

    Link to the Script

    Microsoft Exchange Online PowerShell (Get-EXOMailbox, Get-Mailbox) — official docs

    © 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: msconfigServicesHide Microsoft servicesDisable 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.

  • Cloning a VM with PowerShell and VMware PowerCLI


    Intro

    When you need to quickly spin up a test or lab machine, cloning an existing VM can save hours compared to building from scratch. VMware PowerCLI brings the full power of vSphere management into PowerShell. Here’s a simple walkthrough.


    Step 1 — Install VMware PowerCLI

    Open PowerShell as administrator and run:

    Install-Module -Name VMware.PowerCLI -Scope CurrentUser
    Import-Module VMware.PowerCLI
    

    This installs the official VMware module and loads it into your session.


    Step 2 — Connect to vCenter

    You’ll need credentials for your vCenter server.

    Connect-VIServer -Server <vcenter-server.domain> -User <username> -Password '<password>'
    

    Step 3 — Clone an Existing VM

    Pick the source VM, target VM names, host, and datastore. Example:

    # Define source VM
    $sourceVM = "Base-Win10-VM"
    
    # Clone to new VM
    New-VM -Name "Test-VM01" -VM $sourceVM `
           -VMHost (Get-VMHost -Name <target-host>) `
           -Datastore (Get-Datastore -Name <datastore-name>) `
           -Location (Get-Folder -Name "VMs")
    
    • -VM points to the existing machine you’re cloning.
    • -VMHost pins the new VM to a specific ESXi host.
    • -Datastore chooses where to store the VM’s disks.
    • -Location defines the vCenter folder for organization.

    Step 4 — Power On the New VM

    Start-VM -VM "Test-VM01"
    

    Final Reflection

    PowerCLI makes cloning fast, repeatable, and scriptable. Instead of clicking through vSphere UI screens, you can prepare test VMs with a single command.


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

  • Marked in Time — Fixing a “Sender not allowed” DL (redacted)

    Excerpt
    Our all-hands list rejected internal senders after we allowed two external addresses. Here’s what happened, how to fix it cleanly in Exchange Online, and a PowerShell snippet you can reuse.


    Intro
    Two days ago, I could email everyone@[redacted].com just fine. Today, my message bounced: “this group only accepts messages from people in its organization or on its allowed senders list.” We’d recently added two partner addresses (s@[partner].com, j@[partner].com) so they could email the DL. That change flipped the DL into strict allow-list mode—blocking even internal senders who weren’t explicitly listed. Here’s the minimal, durable fix.


    Straight line (what happened)
    • Symptom: NDR when sending to everyone@[redacted].com from an internal account.
    • State check showed:
    – RequireSenderAuthenticationEnabled: False
    – AcceptMessagesOnlyFromSendersOrMembers: {} (and earlier, it contained only the two partner GUIDs).
    • Root cause: Delivery management was saved in “only these senders” mode; membership/ownership doesn’t matter in that state.
    • Goal: Let all internal, authenticated users send; allow only specific externals; block the rest.


    Fix (clean model)

    1. Let internal, authenticated users send to the DL (no hard allow-list on the group).
    2. Enforce external restrictions with a transport rule that allows only the partner exceptions.

    Commands (PowerShell — Exchange Online)

    Connect

    Connect-ExchangeOnline -ShowBanner:$false
    

    Allow internal, authenticated senders (clear hard allow-list)

    Set-DistributionGroup everyone@[redacted].com `
      -AcceptMessagesOnlyFromSendersOrMembers $null `
      -RequireSenderAuthenticationEnabled:$true
    

    Create the external block rule with an allow-list

    # remove if an older copy exists (safe if none)
    Get-TransportRule "Block external to Everyone (except allow-list)" -ErrorAction SilentlyContinue |
      Remove-TransportRule -Confirm:$false
    
    New-TransportRule "Block external to Everyone (except allow-list)" `
      -FromScope NotInOrganization `
      -AnyOfToHeader "everyone@[redacted].com" `
      -ExceptIfFrom "s@[partner].com","j@[partner].com" `
      -RejectMessageReasonText "External senders are not allowed for this list."
    

    Verify

    Get-DistributionGroup everyone@[redacted].com |
      fl PrimarySmtpAddress,RequireSenderAuthenticationEnabled,AcceptMessagesOnlyFromSendersOrMembers
    
    Get-TransportRule "Block external to Everyone (except allow-list)" |
      fl Name,State,FromScope,AnyOfToHeader,ExceptIfFrom
    

    Update the allow-list later

    # add another partner
    Set-TransportRule "Block external to Everyone (except allow-list)" `
      -ExceptIfFrom @{Add="newuser@[partner].com"}
    
    # remove a partner
    Set-TransportRule "Block external to Everyone (except allow-list)" `
      -ExceptIfFrom @{Remove="j@[partner].com"}
    

    Smoke tests
    • Internal sender → everyone@[redacted].com: delivers.
    • External sender (not on list): NDR with “External senders are not allowed…”
    • Allowed partner (s@[partner].com or j@[partner].com): delivers.


    Why not leave the DL in allow-list mode?
    Because it’s brittle. Every internal sender must be explicitly added, which guarantees future bounces and admin toil. Using RequireSenderAuthenticationEnabled for internal mail + a transport rule for externals gives you clarity and control.


    Final reflection
    Small toggles can have outsized effects. DL delivery settings look simple, but one checkbox can silently change who’s “allowed.” The durable pattern is: authenticate inside, whitelist outside, and verify with a quick trace.


    Pocket I’m keeping
    • Always snapshot DL settings before/after a change.
    • Prefer transport rules for external policy; don’t hard-gate internals via allow-lists.
    • Add a ready-to-run “add/remove external exception” snippet to the runbook.


    What I hear now
    Clarity beats cleverness. Make the rule obvious enough that the next admin can read it and know exactly who can send and why.

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

error: Content is protected !!