Exchange Comulative Update Failure

Hay,

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
and
Id=MailboxComponent___05b48d0df742416f87cbe69d27751979

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

Well,
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
Then:
New-PSSession -ConnectionURI “$connectionUri” -ConfigurationName Micr …
And it tries all servers you’ve updated, and you end up with none functional EMS.

Ok,
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.

So,
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.
HTH,

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

Or

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.

HTH

What to Do? Exchange Server ContentIndexState Failed or Unknown with DAG

Yep, you’ve seen so many like this one, mostly they will suggest you to stop Exchange searching services, then delete the indexing folder (located inside the database folder) and then restart the searching services.

Well, that would work if you don’t have DAG.

Again, mostly you’ll find suggestions to use the update-mailboxdatabase with -catalogonly key

Yeah, that would work if any of the DAG members have a healthy catalog. Now what if all DAG members doesn’t have it?

You’ve two options, but both are risky and I have no responsibility what so ever happens to your data.

Option 1:

Remove one of the copies of the database from one DAG member

Delete the database folder copy from that member’s disk

Add the database copy again to the DAG member

Database index shows crawling for few hours, then healthy

Finally, you can use this new catalog to update other DAG members

Option 2 (have downtime):

Dismount all database copies on all DAG members

Shutdown Exchange searching services (two services) on all DAG members

Delete the catalog folder from all copies on all members

Restart Exchange searching services (two services) on all DAG members

All servers will start crawling

HTH

Reset Exchange Logs without Backup

USE THIS AT YOUR OWN RISK

You may come to a situation where the client is unable to use an Exchange aware backup solution, and for temporary situation, they cannot use the Windows backup. So basically you need to reset the Exchange LOGs without performing any actual backup.

This is applicable to Exch 2010 & 2013 on Windows 2008, 2008R2, 2012, and 2012R2
It works with single server, as well as DAG setups

Open elevated CMD

Run Diskshadow
Type “add volume E:”
(considering E: is the drive where LOG files exists)
Type “begin backup”
Type “create”
(This action will take some time, depending on the number of LOG files exist, and connection speed)
Type “end backup”

You should notice now the LOGs are being deleted

Make a full backup after this to protect the data