Yesterday a client asked me how he could find out, which of his users were the “worst offenders” for mailbox size. Normally a simple Get-MailboxStatistics command would be fine, and we would sort the results in descending order.
Solution
On one of the Exchange servers, launch the Exchange Management Shell.
Issue the following command:
Note: That’s all one command, replace the name PNL-MAIL-2019 with your Exchange server name.
Applicable To: This procedure works on all versions of Exchange Newer than Exchange 2010 SP1 (update rollup 8). If your Exchange server is OLDER than that you will need to use the following link;
The following procedure exports a user mailbox to a PST file on a network share.
Solution
Note: Not Even ‘Exchange Organisation Administrators” have the right to import / export mailboxes, you need to grant those rights to your user object, (or a better approach would be to create an admin account just for this purpose, then delete it when you are finished).
Create a file share on a drive with plenty of space, ensure the Exchange Trusted Subsystem has read / write access. And ensure the SYSTEM account has full control.
Note: Add “-IsArchive” to the end of the command for Archive Mailboxes. Note2: If the export repeatedly fails, add -BadItemLimit 200 to the end and try again, you can also use the -AcceptLargeDataLoss in exceptional circumstances
To view progress;
[box]
Get-MailboxExportRequest OR Get-MailboxExportRequest | Get-MailboxExportRequestStatistics
[/box]
When complete, you need to remove the move request(s);
[box]Get-MailboxExportRequest | Remove-MailboxExportRequest OR (If you still have movement requests running)
Get-MailboxExportRequest -Status Completed | Remove-MailboxExportRequest[/box]
Using Content Filters
You can specify a content filter to only export emails after a certain date all mail received after 01/01/17 e.g.
Or to export emails between two dates;[box]New-MailboxExportRequest -ContentFilter {(Received -lt ’31/12/2018‘) -and (Received -gt ’31/12/2017′)} -Mailbox {mailbox-alias} -FilePath {server-name}\{folder}\{file-name}.pst[/box]
Using IncludeFolders (and Exclude Folders)
You can specify IncludeFolders (or ExcludeFolders) to only export emails from certain folders, e.g.
Only export Inbox (and sub-folders) and Sent Items;
I had to do an SBS 2011, (Exchange 2010) to Exchange 2016 migration last week. The Exchange 2010 installation had not been updated for a long time, anyway common sense dictates that you should always upgrade the old Exchange server to the newest version first. But every time I did, the install launched, started, stopped, then rolled back the changes, and failed.
Setup wizard for Update Rollup {version} for Exchange server {version} Service Pack {version} {KB-version} ended prematurely because of an error. Your system has not been modified. To install the program at a later time , please run the installer again.
Solution
This is happening because the server has UAC (User Account Control) enabled. So the easiest way to bypass this problem is to use MSIEXEC to install the update. Open up an Administrative Command window.
Change to the directory the update is in, (in my case on the root of the server E: drive), then execute the following command;
[box]msiexec /update {File-Name}.msp[/box]
The install should now launch and complete without error.
Related Articles, References, Credits, or External Links
If your Exchange 2010 Server Stops working after a 6 to 12 hour window, then this is a known problem caused by last months (July 2018) security updates. You will also notice that the ‘transport service‘ becomes unresponsive.
Note: A reboot will temporarily fix the problem but the server then ceases to function after the same time.
Solution
Which update you need to uninstall, depends on your operating system (2008/2012)
As you are probably already aware this is because either an install/upgrade/uninstall has failed, and you are attempting to get the process going again, (or someone else has, and left it ‘broken’!)
This is happening because as Exchange performs installs/upgrades/uninstalls it creates some values in the registry as it progresses. And if you attempt to restart the process, it can see these entries, and that’s what causes the error.
So you simply need to remove them;
Open the registry editor (Windows Key+R > Regedit {Enter}).
Where you navigate to, depends on your version of Exchange;
[box]
HKLM\Software\Microsoft\ExchangeServer\v14\ (Exchange 2010)
HKLM\Software\Microsoft\ExchangeServer\v15\ (Exchange 2016 and 2013)
[/box]
Within all the sub keys (i.e. below v14 or v15) there will be a ‘Value’ thats within the role that was being installed/upgraded/uninstalled, when the process ‘fell-over’. That value will be called ‘Action‘ locate and delete it.
Also be on the lookout for a value called ‘Watermark’ if you see that, remove it also, and Exchange will start a fresh, install/upgrade/uninstall.
When you have checked all the sub keys, restart your install/upgrade/uninstall.
Related Articles, References, Credits, or External Links
This is Part-One of a migration from ‘on-premise’ Microsoft Exchange, to Office 365 (Exchange Online). I’m using my spare ‘test domain’ (.co.uk). And I’m using the 5 user E3 Office 365 subscription that the good folk at Microsoft let me have, as part of my MVP benefits.
Note: I’m using Exchange 2016, with a ‘full-hybrid’ migration into Office 365.
Step 1: Pre-Requisites
DNS: You will need access to the DNS records for your public domain, both to ‘prove’ it is your domain, and to divert mail flow, and client requests to Exchange online, rather than your on premise Exchange.
Licenses/Subscription: You need an office 365 subscription, and available licences for all the users you want to migrate. At time of writing the minimum subscription level that includes Exchange Online is E3. (Note that’s not strictly true, you do get Exchange online with E1, but you dont get any office products, so I’ve never seen an E1 licensed migration). You’ll need to have access to Office 365 with a ‘global administrator‘ account.
Backups: Not really a pre-requisite, but how are you going to backup your cloud mailboxes? As far as Microsoft is concerned, your online email gets deleted after its retention period, (amount of time after a user deletes it, i.e. up to 100 days). If your business continuity plan, requires you to keep mail ‘x‘ years, then you will need to think about Azure Backup, or a third party backup solution.
Existing Exchange: Unless you are going to use a third party migration tool, then your on premise Exchange needs to be at Exchange 2010. So if you’re still at Exchange 2007/2003/2000, then you need to either; 1) Upgrade your on-prem Exchange, 2) Do another on-prem migration before you start, or 3) Purchase a third part migration tool. Note: With Exchange 2007 you can add one Exchange 2010 Exchange server, then migrate.
Certificates: You MUST HAVE a certificate on your Exchange that is publicly singed by a third party certificate vendor. There’s no excuse to use self signed certificates these days, (for Exchange). For this exercise I bought a certificate for a year and it cost me less than ten dollars, thats half the price of a one users monthly licence for Office 365? WARNING even with a correctly setup PKI environment with publicly published CRLs etc, your own certificates wont work, and you wont find out what’s wrong, until you have migrated users, and carnage/downtime will ensue! BUY A CERTIFICATE: I’d recommend a wildcard cert for your public mail domain.
User UPN’s: I’ve already covered this before in the past, things will be a lot easier, if you change all your users UPN’s to match their Email addresses.
What most people fail to do is make sure both their AD domain, and existing Exchange is healthy, (just because everything appears to be working, doesn’t mean everything is healthy). Install the latest cumulative update for your on-premise Exchange server ,and dig into the logs to make sure everything is as it should be!
Mailbox Replication Proxy Service
MRS Proxy is at the same solution we use for ‘cross-forest’ mailbox migrations, and your on-prem Exchange will act as the MRS proxy for your mailbox migration. To enable MRS Proxy: Exchange Admin Center > Servers > Virtual Directories > EWS > Edit.
General > Enable MRS Proxy Endpoint > Save
You can also check the service is running, (Windows Key +R > Services.msc {Enter}).
Exchange 2010 Note: If you’re running Exchange 2010, you can enable MRS Proxy with the following PowerShell command;
[box]Set-WebServicesVirtualDirectory -Identity “EWS (Default Web Site)” -MRSProxyEnabled $true -MRSProxyConnections 50[/box]
Azure Active Directory Connector
You can download the Azure AD connector from Microsoft, it can be installed on any member server. It will replicate your users and groups etc, into Office 365. Download and execute the installer > Tick ‘I agree….’ > Continue.
Use Express Settings.
Note: You would only NOT use Express settings if you only wanted to replicate certain groups or sub domains, or if you wanted to use ADFS, (for example because you already had Azure secured services).
Provide your office 365 logon details > Next.
Provide logon details for your on-premise domain > Next.
You will probably only see your local domain, and it will be flagged ‘Not Added’ that’s fine, below you can see my public domain because it’s already been added to office 365, (I’ll cover that later) > Next.
Tick ‘Exchange hybrid deployment’ > Install.
Read and act on any warnings > Exit.
Note: If, (as above) it asks you to enable the ‘AD Recycle bin’, see the following post;
While doing a migration I needed to update all of a clients ‘Distribution’ groups with an additional mail domain. This is not normally a problem we can do that with an Email address policy, well yes you can if all the groups have ‘update email addresses based on policy’ ticked, (which is the default!) However this client had done everything manually. So that wasn’t an option.
Solution
Yes there’s only three below, but this client had over a hundred, and I wasn’t going to do them one by one. List all the Groups and their policy status by running the following command;
PeteNetLive is full of Exchange Migration walkthroughs, going all the way back to Exchange 2003. But what if you are migrating to another forest? Well for small migrations you can of course export mail from the old Exchange Server, and them import it into the new mailbox in the new domain/forest (usually via .PST files). I’ll provide links at the bottom of the page, if that’s what you would prefer to do.
Earlier this year, I got involved with a client that was migrating many domains into one, and this method seemed a better fit for them. The process/screenshots below are taken from my testing and proof of concept for this project.
As you can see, (above) I’ve got a source Exchange server, (Running Exchange 2010) in domaina.com, and I’ve got a target Exchange server, (Running Exchange 2016) in domainz.com
Note: You may guess from the server names, these are also domain controllers, (this is not recommended in a production environment!) My old Exchange server is also running Certificate Services, which will become apparent below.
Solution
The service that does all the ‘heavy lifting’, is the Microsoft Exchange Mailbox Replication Service. Out first task is to get it running on the legacy Exchange server. Open the Exchange Shell and execute the following command;
[box]Set-WebServicesVirtualDirectory -Identity “EWS (Default Web Site)” -MRSProxyEnabled $true -MRSProxyConnections 50[/box]
Ensure the service is running;
The front end of the MRS service is presented via IIS, and it’s secured with HTTPS, so it will use the certificate you have presented, (i.e the same one for OWA). Therefore the new (Target Exchange Server) needs to trust that certificate. If you have a publicly signed certificate from a third party vendor, then you don’t need to import anything you can skip this step.
The World is Full of People Who are Scared of Certificates! I have no idea why? For a certificate to work, you need to TICK TWO BOXES;
BOX ONE: You need the trust the Certificate Authority who issued the certificate, (this is printed onto the certificate, and in most cases can be extracted from the web certificate as well. This is the CA Certificate of the issuer, NOT the certificate you see in OWA.
BOX TWO: The certificate will have a name on it, it will be either the common name, or a subject alternative name (within the certificate), it will look something like, owa.your-domain.com, or *.your-domain.com for example. This must be resolvable via DNS, and also be the hostname you are looking at.
Below, I’m simply importing the Root CA Certificate, from DomainA into my Exchange server on DomainZ.
Note: Start > Run > mmc.msc > File > Add/Remove Snap-in > Certificates > Local Computer.
In production, I’d setup conditional forwarding between the two domains to handle DNS, but in this case I’m being lazy and just putting the FQDN of the Exchange 2010 server in the Exchange 2016’s hosts file, (old school eh!)
Providing you have done everything correctly, you should be able to ‘browse’ from Exchange 2016, to Exchange 2010, to the following URL, and not receive any certificate errors, it should look like this;
Note: If you get any certificate/untrusted errors, fix them before proceeding.
Pre-Staging the Cross Forest MailBox Migration
Actually moving the mailboxes is a ‘two-step‘ procedure, first you pre-stage the move, this creates a Mail User* in the new domain.
*Note: A Mail User is an a little bit like a Contact insofar as they both have external email addresses (i.e ‘username@domaina.com’, while the mail user is in domainz.com, (until the mailbox is migrated). The difference between a Mail user and a contact is, a mail user has a logon name and a password. Once migrated the Mail User is converted into a User Mailbox in the new domain, and the User Mailbox back in old domain gets converted into a Mail User with an email address of username@domainz.com for the mail user in domaina.com. This (while being cool) allows mail flow between the domains during migration. (Assuming your DNS is all setup correctly, of course).
The following procedure is carried out on the new Exchange server, open an Exchange Shell Window and execute the following command;
[box]$Rcred = Get-Credential[/box]
Then supply an administrative account in the SOURCE, (remote) domain.
Repeat the procedure, but this time use Lcred;
[box]$Lcred = Get-Credential[/box]
Then supply an administrative account in the TARGET, (local) domain.
Exchange has a script to do the do the staging for you, it’s in the Exchange install directory, in the ‘scripts’ folder. Mine is in the C: drive, but the path to yours may be different, (depending on how you installed Exchange). But once located, you need to change to the directory that the Prepare-MoveRequest.ps1 script is in i.e.;
Note: This assumes you have created the OU to migrate into! And, (as you can see in the example below,) I’m using the public email address of my user, not the internal one, (it doesn’t matter).
Execute Cross Forest Mailbox Migration
Now the mailboxes are ‘pre-staged’ we can select them for migration, in the new Exchange environment, Recipients > Migration >Add > Move to this forest.
Add.
Select the User(s) > Add > OK.
Next.
Enter the administrative credentials for the source domain > Next.
Enter the FQDN, of the legacy server, (use the SAME NAME that’s on the certificate) > Next.
Give the migration ‘Batch’ a name > Set the ‘target’ email domain > Select the target Exchange Database, (and Archive database if applicable) > Next.
Note: If you keep getting failed migrations, that say ‘FailedOther‘ then you can raise the bad item limit, and large item limits.
Select a user to get the mail notification > Select ‘Automatically Complete Migration Batch’ (or it will stop at 95% and you will have to complete this manually) > New.
You can now view progress in the ECP, (a big buggy and slow to update,) or by running ‘Get-MoveRequest | Get-MoveRequestStatistics‘
If there’s a problem, both the ECP (Exchange Control Panel) and EMS (Exchange Management Shell) should give you a clue. You can remove and rerun a migration on a failed user and nothing will break! Sometimes you need to raise the bad item limit or make sure the source mailbox isn’t too large before proceeding for example. (Use the search box at the top of the page, I’ve posted a lot of Mailbox Move problems).
Related Articles, References, Credits, or External Links
Seen when attempting to open the Exchange Management Console;
Exception calling “GetSteppablePipeline: with “1” argument(s): File C:\ProgramFiles\Exchange Server\v14\RemoteScripts\ConsoleInitialize.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see “get-help about_signing” for more details.”
Solution
This is usually caused by an update rollup, and can be easily fixed by running the following command at an administrative PowerShell session.
I had to do this today and realised, it’s been so long since I did it last, I’d forgotten how to do it. Before we go forward, please be clear, I’m talking about MAIL CONTACTS, these are Active Directory Objects that have an Email address, but DO NOT have a mailbox in your Exchange Organisation, and DO NOT have an Active Directory User. I point this out because you can have MAIL USERS that have an Active Directory User Object and have an External Email address (i.e. a Gmail or Hotmail address) associated with the MAIL USER object.
Traditionally mail contacts are used for listing outside mail addresses in your global address list, (like mail users do) but are also used to forward mail to as well.
Solution
I was exporting from Exchange 2010, from the EMC run the following command;
You can see my exported CSV list in, DisplayName, Name, PrimarySmtpAddress format. You will need to do some work with it in Excel to get it in > Name, Firstname, Lastname, ExternalEmailAddress format.
Once you have you CSV file ready, import it into the Target Exchange Server with the following command;
