Exchange DAG Database Offline Copy

This is mainly about copying large database to remote site with limited WAN bandwidth. Typically this is needed when an organization require DR site for Exchange but the number of users and/or changes on Exchange environment are relativly small.
For instance, an organization with (1,000+) mailboxes has a (35) Mbps WAN link to one of their offices. However, they can only allocate (18) Mbps for Exchange replication. Although daily changes usually do not exceed (25) GB, which is okay with such WAN link, the initial seeding of the databases (2+) TB cannot be done over WAN link.

I have done this several times in the past few years, but recently while I was doing it for one of our clients I noticed there was no refernce for it on the net. I found something for Exchange 2010 which is close to the procedure I’m having here, but I believe the followin steps are more accurate.

The last time this is applied was on Windows Server 2016 Standard and Exchange 2016 Standard. Yet it was tested with Windows Server 2008R2, 2012, 2012R2, and 2016 along with Exchange Server 2013 and 2016 both Standard and Enterprise editions.

The procedure basically must done within limited timeframe, and it cannot be done when servers on primary site have limited disk space and rely mainly on backup to keep free space.
During the process, the backup appliction will not be able to reset any logs until the new copy at DR site is up and running by getting into sync and healthy status for all databases.
Please make sure to read the full procedure then setup your plan accordingly.

1. DAG already extended and the server at DR site is joined.
2. No database copies on DR site created yet.
3. Have external storage attached, ready, and accessible from database owner(s).
4. Schedule and announce downtime.
It is important to calculate the size of databases and amount of time it needs to be copied to external storage.
5. Initiate backup to reset logs, or easier, run following procedure directly before you start execution

a. Add database copies to the DR server using PowerShell preventing seeding of data

Add-MailboxDatabaseCopy -SeedingPostponed -MailboxServer ExchMBX-DR -Identity ExchDatabaseName

This will create the database folders on DR server without contents.
Repeat the above command for all databases, but only for one server at DR.
Do NOT create copy on other servers at DR.
b. Dismount the databases on owner servers. Dismount each database on its own server.
c. Copy databases and logs from owner server(s) to the external storage.
You may need to stop “Information Store” service to get proper access to all files.
d. Start “Information Sotre” service if you have stopped it, then mount databases back.
e. Ship the external storage to DR site, connect and access it from Exchange server.
f. Stop “Information Store” service on DR server.
g. Copy data from external storage to respective path for each database.
h. Start ” Information Store” service.
i. Run powershell command to resume and copy delta logs from main site

Resume-MailboxDatabaseCopy ExchDatabaseName\ExchMBX-DR

Repeat the above command for all databases in DR.
j. Be patient and keep monitoring the status until it get healthy.
k. Run backup again and verify if logs are being reset.

Exchange Comulative Update Failure


During Exchange 2016 or Exchange 2013 server from one CU to another, you may run into strange set of errors.

Funny though, when you track those errors down you will probably end up removing OS patches and updates that actually needed and, even worse, that will not solve your issue.

I’m talkiing about tons of erros directly after the registry entries in the log file, something like:
Process execution failed with exit code 1072

Will, in my case, I had to do three things:

1. Re-confirm Schema, Forest, and Domain preparation is done using the “Setup” file from the CU I’m installing.
2. Un-install backup agent that is integrated with Exchange (in my case it was Veeam).
3. Run the setup time after time till it successfully completed. One server required (5) times, the other needed only (3).

Don’t forget to re-install the backup agent.

HTH some1

Exchange PowerShell Error

You start the Exchange Management Shell (EMS) after a regular Windows update, and boom, you’re end up with an error.
It says:
New-PSSession : Cannot find path ” because it does not exist
New-PSSession -ConnectionURI “$connectionUri” -ConfigurationName Micr …
And it tries all servers you’ve updated, and you end up with none functional EMS.

1st, you shouldn’t update all servers without fully test the update on single one first, you should already know that by now.
2nd, yes it is indeed one of Microsoft products updates caused the crash of another Microsoft product.
3rd, most likely you didn’t update the product itself to the latest version.
4th, yes there is a solution, but it will cost you restarts.

Check if you have the latest updates of Exchange, SharePoint, SQL, or any other application you have. And by checking I mean you check the version you have, and go to the website and find what is the latest version published and what is the latest update package (or cumulative update) is there.

If that is not an option, as I’m expecting from some Exchange and SharePoint admins, then you better start looking into each update installed on that day, and go read about it to find which one included modification and/or update of the PowerShell of the OS. You’ll need then to remove that update in order to test if the issue is gone, and if it’s not, then you’ll have to find the next update, and keep going till you find the one caused that issue.

Yes, I know it’s not much of a help.
However, you may want to check if the PowerShell 5.0 is installed on Exchange 2016 CU8 or earlier, or Exchange 2013 CU19 or earlier, then most likely you want to get back to PowerShell 4.x

Good luck,

Change Password on OWA Using UPN

Exchange 2013/2016 OWA allows users to change their passwords, and additionally, helps administrators to force users to change their passwords.
After first login, and when the user tries to use UPN on password change page, OWA will return an error saying username/password combination is not correct. Which is not true, but OWA tells the user to use the format domain\username not the UPN.
This is because the home directory (OWA Virtual Directory) is configured to use that format for authentication. Although it’s ok to use UPN to login, for some reason the DLL file responsible for the password change is not able to tolerate that format.
Changing OWA virtual directory authentication settings to use UPN format will solve this issue for your users.

Exchange 2016 Readiness Checks Error

I’m not an expert of Exchange, but I wasn’t able to find something clear in the documentation saying I must install new Exchange server (2016) on the same site as existing one (2013) and move it later!

Anyway, the list of errors I got in the Readiness Checks page wasn’t useful at all. However, looking at the ExchangeSetup log file was.

If you are receiving something like:

Global updates need to be made to Active Directory, and this user account isn’t a member of the ‘Enterprise Admins’ group


You must be a member of the ‘Organization Management’ role group or a member of the ‘Enterprise Admins’ group to continue

And you’re sure the account running the setup has these rights, then most likely you’re trying to install the first Exchange server of this version on AD site that has no Exchange servers at all.

My solution, actually it was a work around, was simply to move domain controllers to a site with Exchange servers, remove the subnet from AD Sites and Services, and reboot the new Exchange server.

After 15 minutes, just enough time for AD replication to take place, I logged in again to the server and started the Exchange setup, and it works just fine.