Brad Dickinson | How Background Office 365 Processes Cause Confusion

The content below is taken from the original (How Background Office 365 Processes Cause Confusion), to continue reading please visit the site. Remember to respect the Author & Copyright.

Some Fraying Edges in the Office 365 service

Typically, system designers attempt to keep background processing hidden from end users. No need exists for a user to understand how server maintenance happens or what needs to be done to ensure databases stay in good health. Office 365 usually delivers service with no fuss to its users, but recently I have noticed some instances when background processes have made themselves felt. Although these are not serious issues, they are a worrying sign of a lack of attention to detail.

SharePoint’s App

Since mid-November, I have been complaining to Microsoft about the way that “app@sharepoint” shows up in Delve as the author of many documents (Figure 1). I was told that the problem was fixed in early December, but it came back and has remained constant since.

Figure 1: Odd app@sharepoint document owners – at least, according to Delve (image credit: Tony Redmond)

What Microsoft Support Says

My tenant is not the only one affected by the problem. I have heard from many others who experience the same issue, including several who have reported the issue to Microsoft Support. One response received from Microsoft Support and reported on the Microsoft Tech Community is:

“The Account app@sharepoint is related to the SharePoint Applications (Auditing logs/Virus), it is a system account, belongs to the SharePoint Farms infrastructure, it was created to run on all Site Collections/Personal sites to collect auditing information. When the user provides some changes for his own Site Collection, or enables features or activates the site Auditing logs, his own account does not have the write permissions on the SharePoint Farm and this account it will be used to run and collect all the necessary information to be provided to the customer. Microsoft has set up a few security accounts to run in all Farms, in order for our customer to do some tasks, and get the required information. Also it is necessary for user security, for these accounts to always track the Site Collection searching for viruses that can be uploaded into SharePoint. Microsoft will not change that, all Farms have the same configuration and this same system account, and all Site Collections will use this account if they need to do it.”

The answer reveals that app@sharepoint is a system account. System accounts should stay invisible to users because users do not care what system accounts do. We learn that the account is used when specific administrative operations need elevated permissions. OK, but that is not a reason to replace document authors with a system account. Finally, app@sharepoint appears to be used by processes that check for viruses that might be uploaded to SharePoint site collections. It is still no reason to hijack documents.

Keep Maintenance Hidden

The point is that Microsoft should be able to hide the seamy side of datacenter operations from the sight of normal users. It is one thing when tenant administrators get sight of stuff that they should not see; it is quite another when Delve presents users with a view appearing to tell them that their documents are now under the control of a random app. What is worrying is that Microsoft has not been able to fix the problem in over two months. That is simply unacceptable.

Perhaps the coming move to the http://bit.ly/2kmaA4h root will make Delve work properly. That move is supposed to free Delve and give the application a distinct identity of its own. We shall see whether the new identity discards some of the rubbish of the past.

Strange Accounts Show Up in Audit Events

It would be nice if strange Delve names were the only thing to worry about, but they are not. I have configured activity alerts to report any time that a user account is added to my tenant. An alert fired yesterday and reported that an account called [email protected] added a user. Further investigation via the audit log proved that the added account was valid, but I had added it (for a shared mailbox), not that strange account.

Diving deeper into the audit log, I established that this was not the only time that exo_evo_migration had added an account. Indeed, the activities of this account were joined by another called fim_password_service from the same support.onmicrosoft.com domain (Figure 2), this time to update my own account a few days ago.

Figure 2: Odd account names show up in the Office 365 Audit log (image credit: Tony Redmond)

I checked with Microsoft and discovered that the mysterious accounts are system accounts that should not turn up in audit events, especially when they replace the name of the real person who executes the action. Although I do not know for certain, it seems likely that these system accounts are used to synchronize updates between Azure Active Directory and the set of workload directories running inside Office 365. Pure speculation on my part – or a reasonable guess.

A Need for Clean-Up

Office 365 is a huge and complicated infrastructure that depends on many automated background processes to keep all the parts moving together. Anyone who has built computer systems realizes the need for system or service accounts to get things done and it is unsurprising to discover that Microsoft uses such accounts inside Office 365. In fact, I would be shocked if no system accounts were used.

But that is no reason to cause tenant administrators to worry when strange and unexplainable events show up. Who is this app@sharepoint person and why do they own user documents? Why are accounts in another Office 365 tenant adding and updating users in my domain? The fear of data loss or compromise is intense today and seeing odd things show up where they should not occur is always likely to cause concern.

How Background Office 365 Processes Cause Confusion