Forum Discussion
Back-up tools for Office 365
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.
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).
- TonyRedmondJun 13, 2018MVP
Robse wrote:
For clarity on Holds:
https://techcommunity.microsoft.com/t5/SharePoint/SharePoint-and-Exchange-Online-eDiscovery-Transitioning-to/td-p/41492TR; 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.