Outlook is Grim for Halloween 2017!

Akins IT • August 29, 2017
Connect with us

Attention anyone using Outlook 2007 or 2010!!! 


On Oct 31, 2017, RPC over HTTP will be deprecated in Exchange Online in favor of MAPI over HTTP, a modern protocol that was launched in May 2014. 


This change affects you if you are running Outlook 2007 because it won't work with MAPI over HTTP. (Also, Outlook 2007 is approaching the end of its lifecycle in Oct, 2017). Outlook 2007 and un-supported Outlook clients will be unable to connect to Office 365 mailbox on Oct 31, 2017. To continue email connectivity, please update your Outlook 2007 to a newer version of Outlook or use Outlook on the web before Oct 31, 2017. If you are running Outlook 2016, Outlook 2013, and Outlook 2010 clients, make sure that the latest cumulative update for the version of Office that you have is installed.


We have helped clients use a variety of methods to mass-deploy Office 2016, and can assist with patch management strategies also. This might be a good time to talk. I know from personal experience that the update process might be anything other than straightforward, most especially when throwing in variables such as third-party app vendor plugins and integrations with other suites of software. 


For those who know that PowerShell is a wonderful thing, and more importantly, know how to use it… here is how to identify if any of your users are connecting with Outlook 2007 clients, refer to the steps below:


1. Connect to Exchange Online using remote PowerShell


2. Enable mailbox auditing for the owner:

   ->For one mailbox:

        Set-Mailbox -Identity user@contoso.com-AuditOwner MailboxLogin -AuditEnabled $True

    ->For all mailboxes:

        Get-Mailbox | Set-Mailbox AuditOwner MailboxLogin -AuditEnabled $True


3. Search the audit log. To do this, run one of the following commands:

   ->For one mailbox:

        Search-MailboxAuditLog -Identity user@contoso.com-LogonTypes owner -ShowDetails | ? { $_.ClientInfoString -like "*Outlook*" } 


   ->For all mailboxes:

        Get-Mailbox | Search-MailboxAuditLog -LogonTypes owner -ShowDetails | ? { $_.ClientInfoString -like "*Outlook*" } | select MailboxOwnerUPN,Operation,LogonType,LastAccessed,ClientInfoString | export-csv .\OutlookConnections.csv 


Note: Mailbox auditing may take up to 24 hours to get enabled.

For more details, please refer to this KB.

By Shawn Akins October 20, 2025
October 20, 2025 — Early today, Amazon Web Services experienced a major incident centered in its US‑EAST‑1 (N. Virginia) region. AWS reports the event began around 12:11 a.m. PT and tied back to DNS resolution affecting DynamoDB , with mitigation within a couple of hours and recovery continuing thereafter. As the outage rippled, popular services like Snapchat, Venmo, Ring, Roblox, Fortnite , and even some Amazon properties saw disruptions before recovering. If your apps or data are anchored to a single cloud, a morning like this can turn into a help‑desk fire drill. A multi‑cloud or cloud‑smart approach helps you ride through these moments with minimal end‑user impact. What happened (and why it matters) Single‑region fragility: US‑EAST‑1 is massive—and when it sneezes, the internet catches a cold. Incidents here have a history of wide blast radius. Shared dependencies: DNS issues to core services (like DynamoDB endpoints) can cascade across workloads that never directly “touch” that service. Multi‑cloud: practical resilience, not buzzwords For mid‑sized orgs, schools, and local government, multi‑cloud doesn’t have to mean “every app in every cloud.” It means thoughtful redundancy where it counts : Multi‑region or multi‑provider failover for critical apps Run active/standby across AWS and Azure (or another provider), or at least across two AWS regions with automated failover. Start with citizen‑facing portals, SIS/LMS access, emergency comms, and payment gateways. Portable platforms Use Kubernetes and containers, keep state externalized, and standardize infra with Terraform/Ansible so you can redeploy fast when a region (or a provider) wobbles. (Today’s DNS hiccup is exactly the kind of scenario this protects against.) Resilient data layers Replicate data asynchronously across clouds/regions; choose databases with cross‑region failover and test RPO/RTO quarterly. If you rely on a managed database tied to one region, design an escape hatch. Traffic and identity that float Use global traffic managers/DNS to shift users automatically; keep identity (MFA/SSO) highly available and not hard‑wired to a single provider’s control plane. Run the playbook Document health checks, automated cutover, and comms templates. Then practice —tabletops and live failovers. Many services today recovered within hours, but only teams with rehearsed playbooks avoided user‑visible downtime. The bottom line Cloud concentration risk is real. Outages will happen—what matters is whether your constituents, students, and staff feel it. A pragmatic multi‑cloud stance limits the blast radius and keeps your mission‑critical services online when one provider has a bad day. Need a resilience check? Akins IT can help you prioritize which systems should be multi‑cloud, design the right level of redundancy, and validate your failover plan—without overspending. Let’s start with a quick, 30‑minute review of your most critical services and RPO/RTO targets. (No slideware, just actionable next steps.)
By Shawn Akins October 13, 2025
How a Zero-Day in GoAnywhere MFT Sparked a Ransomware Wave—and What Mid-Sized IT Leaders Must Do Now
By Shawn Akins October 13, 2025
The clock is ticking: Learn your options for Windows 11 migration, Extended Security Updates, and cost‑smart strategies before support ends.
More Posts