Microsoft KB3124557: MS16-010: Security update in Microsoft Exchange Server to address spoofing: January 12, 2016

First thing to be aware of is that this update definitely does come down through WSUS, which was my first mistake (I’m so used to Exchange updates being full-blown CUxx-style, download-the-entire-ISO-again that I didn’t expect this to show up).

We have a 3-node DAG, and of course I hit “install all updates” on all 3 nodes. Meaning Exchange services got disabled (and I mean disabled. not just stopped) on all nodes. My thinking for this was that as Node 1 wasn’t managing any mailbox databases, I could patch it (not realising it had an Exchange update), reboot it, move some DBs, then reboot the other two nodes one at a time, juggling DBs as necessary.

Once I saw what was going on, I cancelled the update which is a bad idea, because it neither continued to install the patch nor rolled back the patch by re-enabling and starting Exchange services. So after cancellation, I had 3 nodes, none of which had the patch and all of which had Exchange disabled.

At this point, my “bads” were a) I should have checked whether the updates included anything for Exchange and b) not cancelled the update jobs.

To make matters worse, I’ve got 2 mailboxes but they’re both in the same mailbox database, and this database was on mounted on Node 3 which still had all of its services disabled. So when I logged on to ECP with my admin account, all I got was a blank screen.

After raising an incident, and then getting a phone call from Microsoft ( it turns out that basically all I had to do was switch all the services to automatic on Node 3, and then start them. Suddenly, I could get to ECP, my mailboxes were accessible etc etc (and yes, I should have been using PowerShell, not ECP).

Exchange 2013 public folder migration error

When migrating our public folders for the first time (from 2007 – 2013), I hit this error:

Property expression “xxx yyy” isn’t valid. Valid values are…

etc etc. Having found some things online, it seems that this is a fault with the alias having space in it, which isn’t allowed. One site talked about using ADSIEdit which I though was a bit extreme so just used this instead:

Set-MailPublicFolder -Identity “xxx yyy” -Alias “xxxyyy”.

If you get two Exchange PowerShell screens open- one on the legacy system , one on 2013- run

Get-MailPublicFolder | FL “Alias”

on the 2013 box, and use the Set-MailPublicFolder on the legacy box. The 2013 server will flag up all the folders that have this space-in-the-alias-name fault, and then you can just copy and paste the folder names into the legacy server. This seems to have sorted the error out as it’s now performing the migration.