Transferring email accounts

[APMerry]

How do people handle the transfer and sharing of important mailboxes? For example our facilities manager is leaving and there's a lot of communication history that will be useful to the new facilities manager.

 

I will generally convert the old mailbox into a shared mailbox and give the new employee access to it for an agreed amount of time before it's deleted.

 

How do you handle this kind of situation?

[Warwick_Tech]

when old the user has been deleted they will sit in limbo for 30 days, depending on your retention policy this is the window you have to transfer their mailbox in it's entirity:

 

Restore a Users Mailbox

https://learn.microsoft.com/en-us/purview/restore-an-inactive-mailbox

------------

 

Login to Exhange Online

 

Connect-ExchangeOnline

--

 

Find Mailbox DistinguishedName or ExchangeGUID

 

Get-Mailbox -InactiveMailboxOnly | select Name,DistinguishedName,ExchangeGuid,PrimarySmtpAddress | Export-CSV C:\Temp\Mailboxes.csv -NoTypeInformation

 

--

 

$inactiveMailbox = Get-Mailbox -InactiveMailboxOnly -Identity [iD String]

 

In the previous command, use the value of the DistinguishedName or ExchangeGUID property to identify the inactive mailbox.

 

--

 

$inactiveMailbox.LegacyExchangeDN

 

--

 

OPTIONAL: Add="X500:" to Attribute editor, Proxy Addresses in local AD - Wait for Azure to Sync

 

--

 

New-MailboxRestoreRequest -SourceMailbox $InactiveMailbox.DistinguishedName -TargetMailbox [target user@domain] -TargetRootFolder "[Custom Foldername]" -AllowLegacyDNMismatch

 

 

=====

If you recieve an error about duplicate entires, find the current users alternate Identity via PS:

 

Get-Mailbox -Identity "[user@domain]"

[MatthewL]

Our take would be previous staff member saves important information needed to say shared area or such then account is closed and mailbox wiped.

 

Never give access to any mailbox in that situation, also if something personal hasnt been cleared and new staff member finds it big can of worms in my opinion.

[jmak]

I appreciate this is easier to say than implement: important data shouldn't be in email mailboxes.

 

This went irrecoverably wrong when the facilities manager wasn't issued with a role based mailbox when they started. The best you can do now is ask the person leaving to save important contacts, attachments and if necessary email messages in a file share. You could set up the role based email account now and ask the person leaving to forward any messages they think might be useful to the new address.

 

It's a really bad idea to give access to the email account of someone else - even if they've left.

[Alex0x7F]

First we hide the user from global address list, then convert mailbox to shared, but we definitely wouldn't give access to the new employee. Setup an automatic response saying "I no longer work for XXXX, any queries please contact [email protected]".

 

In some cases, line managers may be given access to the mailbox but this is rare.

[enjay]

Ideally, the person would copy stuff elsewhere first or forward it on to their replacement. If this isn't practical, we ask the employee to clear out anything personal from it as we may share their mailbox with the new person or their HOD, although we very rarely actually share it. If the circumstances of their departure were a bit messy, we might retain access to the mailbox within IT and conduct directed searches ourselves if the HOD says "please can you look for an email about X from Y around Z date". Ultimately though, it is a school account so "belongs" to the school.

[robintech]

Our take would be previous staff member saves important information needed to say shared area or such then account is closed and mailbox wiped.

 

Never give access to any mailbox in that situation, also if something personal hasnt been cleared and new staff member finds it big can of worms in my opinion.

 

I'll admit we still do that but trying to avoid it. SharePoint groups are so much easier now when the old owner has been using it properly, new owner has all the files, emails (and email aliases), things like Microsoft Forms, automated flows, calendars, external services that sync using that group add them to SSO so they can sign into it.