Question about Employee Terminations and shared documents in OD4B

Silver Contributor

We have an employee who was terminated back in December.

 

He had a file in his OD4B account that was shared with multiple users.

 

The user's claim they have been able to access that shared document up until around July, but are now no longer able to see or access it (as if it has finally been deleted).

 

It would be my expecation that if he was terminated December 15, then no later than January 15, those documents would no longer be accessible by other users.  

 

Can anyone shed any insight on this situation?

8 Replies
Being terminated doesn't imply immediate disable/deletion of the underlying account, have you checked when exactly that happened? The Audit logs might be of some help. Also the notification email that the manager should have received for the pending deletion of ODFB site.

The account was disabled in Active Directory on December 1 of 2015, not sure where else to check online to confirm whether or not everything terminated correctly, but don't have a reason to suspect it didnt.

 

We have an Exchange Transport Rule that cc's me whenever those OneDrive emails go out.  For some unknown reason, the manager, nor I ever even received a termination email regarding OD4B for that particular user.

 

I questioned if maybe the manager field was blank for some reason near that date, but no one seems to think so.

 

They swear they could access the document very recently (and now I've got to come up with answers where there don't appear to be any).  And of course it was a critical document, bleh...

 

Why is was in a user's OD4B is another matter......

 

You mention that you disabled the account in December. The OneDrive cleanup job does not process disabled accounts, only deleted accounts. And - that is only if the account is deleted in AzureAD (in case you had some kind of sync issue not processing the delete).
Also - check what your tenant is set to for -OrphanedPersonalSitesRetentionPeriod (part of the Set-SPOTenant parameters) - the default is 30 days but it can go up to a whole year.
So OK...that's how it should work, but we also have a lot of examples where the OneDrive cleanup process doesn't work and we end up with a bunch of orphaned OneDrives - maybe that is what happened here as well. Or maybe it was just a case where an admin finally deleted the disabled account and kicked-off the deletion process a lot later than expected.

Poor choice of words.  We disable accounts by moving them to a non-syncing OU (de facto deleting it from AAD).  This is how we've always done it, and the cleanup job seems to have worked for everyone else.  

 

Our setting is 30 days, i havent seen that setting before, and it look like we can technically take it up to 10 years.

 

May have to consider that.

I've also seen cases where the creation and deletion of OneDrive sites has gotten "stuck" in the queue until someone noticed or a support call was opened. once someone on the Microsoft Operations team takes a look at the particular tenant the queue becomes "un-stuck" and OneDrives are created and deleted normally. As Adrian says I suspect that is what happened in your case. Someone finally hit the reset button in July and the site finally got deleted.

I just learned that Microsoft released a setting a few months ago, where we can configure how long after a user account is deleted before their OneDrive site is deleted.

 

Check out this KB article: https://support.microsoft.com/en-us/kb/3042522 

 

In particular, the option is the -OrphanedPersonalSitesRetentionPeriod parameter for the Set-SPOTenant command.

 

Here's a blog post explaining further: https://jinkang.us/2016/08/11/onedrive-for-business-configurable-retention-period-for-orphaned-onedr...

 

This is actually great news.  We're going to set our OneDrive retention policy to match our personal file shares on premise.

Hi,

Thanks for this info. 

So if -OrphanedPersonalSitesRetentionPeriod is set for 90 days,  the users A will be able to access those doucments shared by another user B with user A for a period of 90 days even if  the Azure AD account of User B is deleted from Azure AD(soft delete). Is my understanding correct?

 

Or what is the reason User A is able to see and access the documents of User B shared with User A  ( under "Shared with me" Section) even after the User B account is deleted from Azure AD.

 

Another requirement i have is , if I as admin want to preserve the ODB documents of user ( including deleted and all versions)   and also the ODB site for say a period of 10 years or indefinitely since their last modfied date even after user's Azure AD account is deleted, which option should I use , the ediscovery ( in Place hold), Preservation Policy , -OrphanedPersonalSitesRetentionPeriod. I am totally confused . 

The requirements are as follows:

1. Admin should be able to restore any ODB document(s)  of user which is deleted including any/all versions when the user is still active or inactive ( Azure AD account is deleted, user left the company). The  documents to be restored are less than 10 years old, meaning we ant to reatin all documents and their version for 10 years since last modified date

2. Admin shoud be able to restore and transfer the ODB site of a user , who has left the company and his/her Azure AD account is deleted to another new user so that new user uses this site as his/her ODB site.

 

Would appreciate any help on these.

Thanks

 

The preservation hold over-rides the ODFB settings for orphaned site retention so if you set up a preservation hold policy that is forever then the ODFB will never be deleted. The preservation hold retains the deleted and changed items(if versioning is enabled) in the preservation hold library seperate and apart from the Document library that is ODFB.

 

That being said, the way that ODFB works unless you name the new user the same as the deleted user then the ODFB will never be able to be assigned to a new user as their own ODFB. This is the same issue that occurs when you change the UPN of the user, ODFB then sees that the name has changed and does not exist

example: jdoe@contoso.onmicrosoft.com (ODFB site is jdoe_contoso_onmicrosoft_com)

becomes

jdoe@contoso.com (ODFB site is jdoe_contoso_com)

So ODFB recreates the site and there is no data in the new site.

 

You can however, assign the user as a site collection admin on the ODFB site which will give them access to the data which can then be moved from the deleted users ODFB to the new users ODFB site.