Not too long ago, it was the first day of school, then it was the first NFL game and we just passed the first day of fall. As seasons change, I am reminded of the things that I should do but often don’t. Either I forget or avoid. So it is for Business Continuity/Disaster Recovery (BCDR) efforts. About 10 years ago, I wrote a blog post with some points about DR (Disaster Recovery - Microsoft Tech Community) then, about seven years ago, I posted a DR ‘reminder’ (Disaster Recovery – A Reminder - Microsoft Tech Community). Those were both ‘pre-cloud’ – which seems so long ago. In any event, a post from me around BCDR for cloud components is well past due.
NOTE: Service availability is one aspect of BCDR, as is data availability. For the most part, those two elements are solid when it comes to SaaS – those are two of the value props of the SaaS model. However, in this post, I’m focusing on recovering from accidental or malicious deletions of configurations in some of your key Microsoft cloud services.
You get a call that ‘something is going on’ – people aren’t getting blocked when they should be. People aren’t getting prompted when they should be. Where you’d normally see your org’s logo on the sign in pages, you see the Microsoft logo. You recall that moments ago, you didn’t get prompted when you went to check email via OWA this morning. Your stomach turns.
You pop open the Azure portal and immediately notice you don’t get MFA’d. Your stomach turns again but more deeply. Your face gets hot. Your brain races as you ask yourself “Did I do something?” You open the AAD Conditional Access portal spot … there are only a few ‘default’ policies listed. There are normally a dozen or more policies with your custom naming standard. You rub your eyes to see if you’re just not seeing it but the emptiness remains. You refresh the portal page. You verify the tenant name … still blank. You quickly jump over to the MEM portal … many of the Intune policies and settings are gone, too. You check out the Defender for Cloud Apps (aka MCAS) policy page; your custom CASB policies are gone. It’s like you’re signing in to a brand new M365 trial.
Before you tackle the ‘who/what/when/where’ questions from management to explain what happened, you need to get back to a functional run-state. That won’t be too tough, thankfully, as you have nightly exports from the various M365 services. Or you have a weekly calendar reminder to run manual exports, every Friday when you first get into the office, right? Or you have Word docs with screen captures of the portal pages that you update the first Tuesday of every month, right? Or an XLS with the settings? Or you have a chicken-scratch Notepad file from when you first setup the policies?
Or, perhaps you don’t; perhaps you have nothing more than a vague visual memory of what you’d see when you’d look in the portals; a general idea of the various policies and what they did – but only sparse memories of a few of the myriad settings across the services. Oh, and the portal UIs have changed considerably since you setup those policies years ago (if it even was you who set them up). It’s gonna be a loooong day(s).
Ok, back to reality … whew.
An ounce of prevention (or planning) is worth a pound of cure. Just do something. It doesn’t need to be perfect. The only thing worse than a mass-deletion event is one without any sort of recoverability planning and desired settings references/materials. Staring at a blank portal page, trying to recall from memory what had been setup previously is no bueno. Plus, management will be asking ‘why weren’t we better prepared to recover from this?’ Have a solid answer vs a ‘deer in the headlights’ stare.
Sadly, as of today, there isn’t a ‘backup now’ or ‘recover now’ button in the portals but there is some good news; since these are SaaS capabilities, there are no servers to restore or infrastructure to recover/establish. It’s basically entering configuration information in web forms.
Here are a few ideas on possible BCDR for your M365 services (you may find/have others – if so, great! Share what’s worked/not worked for you in the comments)
Explore the various options “discoverable” in the dynamic auto-fill query box – I guarantee you’ll be giddy at some of the things you’ll find:
NOTE: You might not have the proper permissions to access certain elements from Graph, even if you’re using a GA account:
It’s an easy fix, right from within Graph Explorer, but be sure you understand what ‘Consent’ means – and also realize that your global AAD settings might restrict or block these consent actions:
NOTE: MDCA (Defender for Cloud Apps aka MCAS) doesn’t seem to have similar graph exposure. You can export the ‘whole’ portal config, policies and IP list into a single JSON file via Settings but I don’t know what that includes/leaves out, and there isn’t a way to re-import it for recovery.
Regardless, you can easily get screen captures of your custom policies from the portal.
A few notes about the visual branding elements of the various services/portals, and the Company Portal for Intune:
With BCDR topics, you have to think well outside of typical ‘day to day’ operations. Make sure you have a plan, the plan is documented and vetted/tested and updated every month/quarter/year.
Here are a few more “table-top exercises” and thoughts related to BCDR:
Sharing IT horror stories is a pretty fun past-time of ‘the job’ but in the heat of an incident or outage, there is VERY little fun. Do yourself a favor (and your org), take some time in the next week and review/setup exports of your key configurations. You’ll sleep a bit better once you do.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.