Back-up tools for Office 365

---

Robse wrote:

For clarity on Holds:
https://techcommunity.microsoft.com/t5/SharePoint/SharePoint-and-Exchange-Online-eDiscovery-Transitioning-to/td-p/41492

 

TR; That article confirms the move away from workload-dependent processing of holds to Office 365-wide holds imposed through eDiscovery cases. However, Exchange in-place holds are still valid (you can still impose them) as they have to remain in place for as long as a customer's retention needs exist. The point is that you can put mailboxes and SharePoint/OneDrive content on hold if you need to retain content, and you can do so with a single policy. It's part of the drive to have a unified view of data governance across Office 365 (see https://www.petri.com/office-365-data-governance).

 

Difficult to argue, when you just repeat your points or find excuses for valid company scenarios.

 

TR: I could equally argue that you continually point to rogue admins as the justification for backups. I'm not finding excuses. What I am doing is pointing out that a great deal of functionality is built into Office 365 that tenants sometimes overlook because they simply don't know it exists. I have also attended a couple of recent sessions where presenters talked about scenarios as if no solutions exist, leading people along the line that the only possible solution is their software.

 

To me, it seems like four issues need to be reviewed.

 

1. User error.

2. Administrator error.

3. Rogue administrator.

4. Attack (malware, cyber ransom, etc.)

 

User error (someone deletes a message or document in error) can usually be taken care of with functions built into clients or Office 365, such as Recover Deleted Documents, by an admin with the recent cmdlets (https://www.petri.com/recovering-deleted-email-exchange-online) or with a content search if the mailbox is on hold. The same for deleted documents if they are not in the recycle bin - documents on hold can be recovered by an admin by a content search because they are in the site's Preservation Hold Library. Loss of metadata or some other element of a SharePoint library is harder to recover, so that might be a reason to use backup software. On the other hand, the investment might be better made in user education so as to avoid accidents.

 

Administrators can screw up and lose data. In some cases, like recovering an account or group removed in error, the error is recoverable. In others, it might not be. Backup software can help, but only if it copies the data that the administrator removes.

 

Rogue administrators can cause chaotic damage. However, as noted before, I am unsure as to how many incidents of this kind actually happen. Good HR and management processes, including auditing of admin actions and restriction of admin permissions so that people only have elevated rights for a defined period help to solve this problem. I note that Office 365 is in a preview of privileged access management https://techcommunity.microsoft.com/t5/Security-Privacy-and-Compliance/Announcing-preview-of-privileged-access-management-in-Office-365/ba-p/183743 that will bring customers some of the same capabilities Microsoft uses to restrict access to its administrators in the Office 365 datacenters. The feature will be available for Exchange Online first and then other workloads.

 

Malware can corrupt documents and messages and a backup can help. However, the need is somewhat reduced through the introduction of features like OneDrive restore (coming to SharePoint too, or so the rumour goes).

 

Perhaps the biggest advantage of backup software is the ability to restore data belonging to many users in an automated manner. While users can restore deleted messages or their OneDrive library, it's a manual process. Possible but painful when you have hundreds of users affected.

 

Your audits are funny. Congratulation to your audit logs, when a hacker deleted important documents with a stolen account.

 

TR: Audits are only part of the solution.

 

And please do not start with ATA, ATP, MFA, Conditional Access, etc. Yes, Yes, Yes, we all know about that. However, this is still not the point. The audit log will not get your data back.

 

TR: No, but it will tell you what happened and who did what. And that information is often necessary to prosecute offenders. But you are right to point out to the range of features available in Azure and Office 365 to limit the ability of attackers to penetrate a tenant to access and steal data.

 

Just to summarize:

You recommend native functionality, that was never build for backup & restore scenarios,

 

TR: No, I recommend that tenants understand the full breadth of the functionality built into Office 365 and understand how to use that functionality to meet their data governance needs.

 

hence, you're recommending workarounds. At the same time you complain about "workarounds" from 3rd party vendors, who use official Microsoft APIs for additional B&R scenarios, because these APIs are no dedicated Backup-APIs ("...lack of a suitable backup API for most of the Office 365 data sources"). At least I find this interesting...

 

TR: I have commented that a lack of backup APIs restrict ISVs from being able to copy data from some Office 365 workloads like Teams and Planner, absolutely. I also have pointed out that some APIs in use for backups (like Exchange Web Services) were never designed for the purpose. Without APIs designed to handle the transfer of large quantities of data from Office 365 to another cloud datacenter, there will always be compromises.

 

I respect your opinion. You're still not a fan of additional backup solutions. You still don't really see the need for it. And you are critical with the solutions, which are out there in the market. I'm fine with that!

 

TR: I am glad that I made your day.

 

Other contributors and I also shared our points. I'd leave this now to the reader to build their own opinion (and re-think their cloud backup strategy).

 

TR: Certainly. But don't expect me to stay silent about the state of backup software for Office 365 and to prompt customers to understand the features of the software they have already bought. That just isn't the right thing to do, so I won't be doing it.

---

For clarity on Holds:
https://techcommunity.microsoft.com/t5/SharePoint/SharePoint-and-Exchange-Online-eDiscovery-Transitioning-to/td-p/41492

Difficult to argue, when you just repeat your points or find excuses for valid company scenarios. Your audits are funny. Congratulation to your audit logs, when a hacker deleted important documents with a stolen account. And please do not start with ATA, ATP, MFA, Conditional Access, etc. Yes, Yes, Yes, we all know about that. However, this is still not the point. The audit log will not get your data back.

Just to summarize:

You recommend native functionality, that was never build for backup & restore scenarios, hence, you're recommending workarounds. At the same time you complain about "workarounds" from 3rd party vendors, who use official Microsoft APIs for additional B&R scenarios, because these APIs are no dedicated Backup-APIs ("...lack of a suitable backup API for most of the Office 365 data sources"). At least I find this interesting...

I respect your opinion. You're still not a fan of additional backup solutions. You still don't really see the need for it. And you are critical with the solutions, which are out there in the market. I'm fine with that!

Other contributors and I also shared our points. I'd leave this now to the reader to build their own opinion (and re-think their cloud backup strategy).

In-place holds aren't deprecated for Exchange. Instead, the in-place holds that are set by Exchange eDiscovery have been replaced by in-place holds set by Office 365 eDiscovery cases.

Litigation hold (equivalent to an in-place hold without a query) also remains intact and available.

Re. queries for auto-label policies - KQL is pretty extensive when it comes to finding documents. If you really want to lock down documents, then make them records and they can't be deleted by anyone (even Microsoft).

Re. soft-delete and realizing that groups have been deleted. I think that if they are important groups. their loss will be detected quickly. It's also very easy to script a check for deleted groups with PowerShell by querying either Azure Active Directory or the Office 365 audit log. I explain how in a Petri.com article. 

You keep on saying that an Admin could something. Yes, they could. But if they do, then consequences will flow. Admins can remove holds, permanently delete groups, and do all manner of things, and these actions are audited.  You can make the same argument for third-party software as well - someone has to have authority over the software and be able to change data.  I accept the argument that insurance is good, but insurance is often over-sold too.

Hey TonyRedmond,

you don't get my (our) point. Everybody knows (or should know) about the basic functionality. Our point is, companies should be totally aware of these capabilities and of course really use them. However, these are still basic functions, which work in your test tenant, but not for all productive company environments. Please respect this and do not ignore the thousands of companies out there, which need more than basic functionality for their intellectual property - their data!

Exchange:

In-Place Hold (copy-on-write) DEPRECATED!

-> Keep emails based on a query, as long as Search is not deleted, all new email matching criteria will go into this hold

Litigation Hold

-> Like In-Place hold, but for entire mailbox, without query (except for some filters)

What if Admin changes query or removes litigation?

SharePoint/OneDrive classification

- based on fixed keywords or one or a mixture of 82 pre-configured sensitive types

- make sure, these keywords or sensitives types will cover all content, even that, what will be created in the future?

- allow user to overwrite rules or not?

- Retention labels/policies cannot be changed after creation

- not possible to retain entire site collections or Groups/Teams

Soft Delete of Groups

- what if somebody realizes the deleted Group after 30 days?

- what if Admin uses this: Remove-AzureADMSDeletedDirectoryObject –Id <objectId> and permanently delete Group immediately?

Again, for many companies the basic functionalities are fine and that is great! Many others really need additional features.

… and for the rogue administrators (and all the other scenarios): Why do you have a car insurance? Because you plan to have an accident? Or because you just would like to be protected, but you hope you never need it?

My recommendation for everybody:

1. Re-think your cloud backup strategy -> define your organization's SLA's and B&R scenarios, you need to cover
2. Check, if native capabilities meet your SLA's
   a) if yes, go to #4
   b) yes with few acceptable limitations, go to #4, but note down limitations and make your colleagues aware of this
   c) no, go to #3
3. Check 3rd party vendors in the market, if they can satisfy your SLA gaps
4. Monitor your backups and perform different restore scenarios on regular basis to make sure everything is working

Re. retention.

Simple. Just put all important mailboxes on hold. Either a time-limited or litigation hold. No add-on or any other process can remove content from a mailbox that is on hold. 

Auto-label policies can find and assign classification labels to documents based on keyword searches or if the document contains sensitive data types like credit card numbers. This is all basic Office 365 functionality.

Look, the FUD thrown out by backup companies talks a lot about rogue admins. I've got to say that in my 40 years in IT, I have never encountered such an admin. Yes, they do exist, and they do horrible things for unknown reasons, but they are not as common as the FUD makes out. And if Teams, Groups, etc. are deleted by an admin, they are soft-deleted and can be recovered within 30 days. Again, basic Office 365 functionality.

As to someone removing a label, they have to be a site owner to do that....

Thank you Oleg Melnikov. 

Clients should simply be aware of Microsoft capabilities and really re-think their cloud backup strategy. Just relying on "Microsoft is doing the backup" will fail. Microsoft is responsible for the Service. However, the client is responsible for their data. If your mentioned scenarios are not need from a client, fine. But if companies want to protect against this, they cannot do with native tools.

Additionally, TonyRedmond, what if a Office Add-In or any other service is accessing data and while doing the data get's corrupt. Your retention policy will not work.

In general, Retention policies need to be applied manually to each object or automatically with a rule, which match all documents. Do you know there is the same keyword in all you files to use it this way? Also, whenever you create and apply a retention label, you will never ever be able to change or delete it. Is this the flexibility we need in current dynamic times? Same for classification… This only applies for documents, but what about an entire column and the metadata stored in there? What about entire libraries, Sites, Groups, Teams, when the IT Admin deletes all of them by purpose? Sure, rare scenarios, but companies should be aware of them and think themselves, if they want to protect against this or not.

And Tony, you actually already answered yourself: when a user removes the label and deletes an item by purpose, then it's his fault. RIGHT! But how can a company protect against this scenario?" Additionally, "...and they better understand what they are doing" How many companies have you seen, where all employees totally understand their IT and know what they are doing?

Let us know, how we can get you ;-) We are not talking about specific solutions. We just talk about the considerations of certain scenarios and options to solve them. If companies have evaluated this and still are fine with what you've mentioned - great. If companies identify gaps in their SLAs with native capabilities, why do you want to ignore them?

Fair question.

Use retention policies to make sure that information is retained for a reasonable period, so if someone "loses" a message, you can always recover it. This protects against rogue admins too.

For SharePoint, put a classification label on important documents that has a retention period. People won't be able to delete the document because the label is there. And if they remove the label, then this is a pretty explicit deletion  and they better understand what they are doing.

Tony, why you do not consider backup as a necessity for O365? Microsoft provides good SLAs for infrastructure underlying O365. But if a user accidentally deletes a message in his Outlook - Microsoft might help you to restore it any time during next 48 hours. And if you need it now - you're out of luck.

Or even worse - if a rogue IT person decides to delete e-mails in few mailboxes.

Disclaimer: I work for Acronis (data protection company).

I don't consider backups to be a necessity for Office 365, but ISVs continue to offer these products and customers continue to buy, so I chatted with Spanning to find out what's happening in the Office 365 market, who's using cloud backups, and why. We also spoke about the challenges that backup vendors continue to have in coping with some of the unique aspects of Office 365.
https://www.petri.com/spanning-office-365-backups