Forum Discussion
Solved
Exchange Online Shared Mailboxes deleted after deleting disabled users from local AD
We have Office 365 Business Premium and user Azure AD Connect to sync our local AD.
Today we planned to delete 12 disabled user accounts from our Active Directory. I went to Exchange Online and converted the remaining user mailboxes to shared mailboxes. Once this was done, we deleted the disabled user accounts from our local AD. After doing a full sync with `-PolicyType Initial`, all 12 shared mailboxes had been deleted.
In the EAC, I can see them under mailboxes > user mailboxes > deleted mailboxes, but restores fail with an error message 'User not found' (see blow).
I already created a ticket, but I'd like to discuss this behaviour. Is this intended and if so, why? How am I supposed to delete user accounts from our local AD? If this is a bug, how could this have slipped through Quality Assurance?
Error message:
Fehler bei Proxybefehl 'Undo-SoftDeletedMailbox -DisplayName:'xxx' -Name:'xxx' -SoftDeletedObject:'b0a2e3d2-4ec8-4f25-a5e7-ae7b6652a8a0' -WindowsLiveID:'xxx@yyy.onmicrosoft.com' -Confirm:$False' an Server AM3PR01MB0694.eurprd01.prod.exchangelabs.com: Serverversion 15.20.0282.0000, Proxymethode PSWS: Cmdlet-Fehler mit folgender Fehlermeldung: Microsoft.Exchange.Management.Tasks.RecipientTaskException: User not found ---> System.ServiceModel.FaultException`1[Microsoft.Online.Administration.WebService.UserNotFoundException]: Given user not found. Server stack trace: at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message) Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at IBecWebService.ChangeUserPrincipalName(ChangeUserPrincipalNameRequest request) at Microsoft.Exchange.Management.BecWebService.BecWebServiceHelper.<>c__DisplayClass31_0.<ChangeUserPrincipalName>b__0() at Microsoft.Exchange.Management.BecWebService.BecWebServiceHelper.InvokeWithRetry[TResponse](Action operation) at Microsoft.Exchange.Management.BecWebService.BecWebServiceHelper.ChangeUserPrincipalName(ChangeUserPrincipalNameRequest request) at Microsoft.Exchange.ProvisioningAgent.BecWebServiceLiveIdManager.InternalRenameMember(NetID netID, SmtpAddress newMemberName, SmtpAddress originalMemberName) --- End of inner exception stack trace --- at Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl) at Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target, Boolean reThrow) at Microsoft.Exchange.Provisioning.ProvisioningLayer.<>c__DisplayClass9_0.<SetLogMessageDelegateImpl>b__1(LocalizedException ex, ExchangeErrorCategory category) at Microsoft.Exchange.ProvisioningAgent.BecWebServiceLiveIdManager.TranslateAndThrowBecException(Exception e) at Microsoft.Exchange.ProvisioningAgent.BecWebServiceLiveIdManager.InternalRenameMember(NetID netID, SmtpAddress newMemberName, SmtpAddress originalMemberName) at Microsoft.Exchange.ProvisioningAgent.BecWebServiceLiveIdManager.RenameMember(NetID netID, SmtpAddress newMemberName, SmtpAddress originalMemberName) at Microsoft.Exchange.ProvisioningAgent.WindowsLiveIdProvisioningHandlerForNew.PreInternalProcessRecord(IConfigurable writeableIConfigurable) at Microsoft.Exchange.Provisioning.ProvisioningLayer.PreInternalProcessRecord(Task task, IConfigurable writeableIConfigurable, Boolean checkProvisioningLayerAvailability) at Microsoft.Exchange.Configuration.Tasks.NewRecipientObjectTask`1.PreInternalProcessRecord() at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__92_1() at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)..
Here is the support article from Microsoft outlining what you were trying to do (with the warning not to delete the user) as well as the steps to recover if you did delete the user - https://support.office.com/en-us/article/Convert-a-user-mailbox-to-a-shared-mailbox-2e122487-e1f5-4f26-ba41-5689249d93ba
I'm also not aware of it being a license violation based on everything I've seen on the topic. I know all the users that access the shared mailbox must have a license, but not aware of any violations of using a shared mailbox to preserve a mailbox, especially if you need to continue receiving email to said mailbox. Here is another good article on the topic as well https://practical365.com/exchange-online/shared-mailboxes-vs-inactive-mailboxes-departed-users/. Still doing some looking into the licensing issue, so I'll update the thread as well if I can find any more details around it.
The behavior is intended because by converting a mailbox to a shared mailbox, that in itself does not disassociate it from the original AD object.
You should also be aware that converting a former employee to a shared mailbox is a license violation.
You should instead convert it to an inactive mailbox, read the article here for more info:
- I have no knowledge of it being a license violation. If it really is a violation, I would be interested where I could read up on that. The only information I have is this:
"Your shared mailbox can store up to 50GB of data without you assigning a license to it. After that, you need to assign a license to the mailbox to store more data."
Source: https://support.office.com/en-us/article/Create-a-shared-mailbox-871a246d-3acd-4bba-948e-5de8be0544c9
I also remember that I have a couple of shared mailboxes from 2015 and 2016 where I did exactly this: Convert to shared mailbox and delete the user account.
Inactive mailboxes are not an option for as as our employees still need access to their mailboxes and folder structure. And frankly, I don't see why I should pay for something like that.Are you talking about a user synced from on premises AD with AD connect with the mailbox in Exchange online that was disabled, then you converted to shared mailbox and deleted the on premises object?
That would result in the mailbox being moved to deleted mailboxes because the object is gone. In a hybrid scenario you still need the object to sync to keep the mailbox active.
