Removing your last exchange on-premise servers after migrating to exchange online

One question that comes up constantly from clients is “Once we move all mailboxes to exchange online, we can remove all our exchange servers, right ?”


To which we answer “no – for these reasons….” but its something that has a great deal of trouble sticking…. as the same question gets asked over and over again… sometimes by the same client, sometimes even by the same people.

I stumbled across this today – an article written a few months back which nicely lays out the possible scenario’s

well done to the authors for laying it out plainly!

We don’t really work with any places that will be in scenario 1 anytime soon… but scenario 2 and 3 are spot on… with 3 being the most common scenario for our clients.

O365 ATP recommended config analyser

Came across this after following a post on linked in – checked it out – and its pretty bloody good.

Run the tool – it will spit out a report with recommendations for O365 Advanced threat protection…

The recommendations it spits out are of a pretty good quality

its not perfect (these things rarely are) – for example, after setting up DKIM and verifying, i find that it still reports an issue with DKIM – but it isn’t clear what the issue is – but it remains a good checklist enabler.

Exchange 2010 to 2016 mail flow stops with “421 4.4 2 connection dropped due to socket error”

Had a client ring today with a mail flow issue.

They are most of the way through their migration to 2016, but mail flow stopped with the error “421 4.4 2 connection dropped due to socket error” on the exchange 2010 side – when trying to relay to exchange 2016. This occurred after patching – but i’m not 100% on which patches they applied – and didn’t really have the time to find out.


Long story short – enabled TLS 1.2 on the Exchange 2010 (on a 2008 R2 OS) as per

then restarted the transport service – and mail stated flowing again.

While this is known for Exchange 2019 on Server 2019, where TLS 1.2 is the default – i wasn’t aware this was being retro-fitted……  not a bad thing…. and its only going to catch out the people that are lagging behind… still, considering how many people are lagging behind – this quick post might help!

Exchange migration and AdminSDProp

I recently did a piece of work for a client – moving from Exchange 2010 to 2016. Nothing too exciting…. but they did have an interesting issue.

Once migrating some of test mailboxes, inheritance in AD had to be enabled for a few admin accounts before they could connect via outlook and activesync – to be expected (yes yes, i know admin accounts shouldn’t have mailboxes, but we all know that some clients still do this – and thats not the focus of this post)

What was interesting, was that on further investigation – every account has AdminCount set to “1” and had inheritance disabled – not something to handle manually..

On further investigation, it was found that via some group nesting, all users were members of print operators.

Groups with AdminCount=1 can be located utilising the powershell

Get-ADGroup -LDAPFilter “(admincount=1)”

The client did not want to immediately reverse this due to potential client impacts – and while i disagreed – excluding a group from AdminSDHolder was not something i had looked into before – so i was interested.

A short amount of googling later – and reading a long list of articles, we decided to exclude “print operators” from AdminSDHolder. Two of the better articles (for reference) around this were:

The condensed version of the overall solution is:

  • In order to exclude a group from AdminSDHolder, you can utilise ADSIEdit to modify  the property dsHeuristic under “CN=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,DC=YourDomain,DC=com”
  • The value can be calculated depending what groups you wish to exclude, the 2nd linked technet social post above has a really nice explanation
  • in my case, i needed to it to “0000000001000004” (without the quotes)
  • Once this is done, clear the AdminCount property from the appropriate group (in my case, this was “print operators” + another group within the long-line of nesting this client had)
  • Re-run the powershell – “Get-ADGroup -LDAPFilter “(admincount=1)” to verify the groups no longer show up
  • Once this is done, we need to remove the “adminCount” from each of the affected user accounts and enable inheritance – to do that, you can run the below script


$users = Get-ADUser -ldapfilter “(objectclass=user)” -searchbase “<DN of path you wish to use for your search base>”
#$users = Get-ADUser -Identity <username> ‘ Use this for testing on a single user first

#Get domain values
$domain = Get-ADDomain
$domainPdc = $domain.PDCEmulator
$domainDn = $domain.DistinguishedName

#HashTable to be used for the reset
$replaceAttributeHashTable = New-Object HashTable

$isProtected = $false ## allows inheritance
$preserveInheritance = $true ## preserve inheritance rules

ForEach($user in $users)
# Binding the users to DS
$ou = [ADSI](“LDAP://” + $user)
$sec = $ou.psbase.objectSecurity

Set-ADUser -identity $user -clear adminCount

if ($sec.get_AreAccessRulesProtected())
#Changes AdminCount back to &lt;not set&gt;
Get-ADuser $user.DistinguishedName -Properties “admincount” | Set-ADUser -Remove $replaceAttributeHashTable -Server $domainPdc
#Change security and commit
$sec.SetAccessRuleProtection($isProtected, $preserveInheritance)




Active Directory 2019 and Exchange 2019 – what’s new

The short answer is – not much.

Exchange 2019 was released a few weeks back, but was effectively un-usable, as Exchange 2019 requires Windows Server 2019…. and Windows server 2019 got pulled from release (like Windows 10 1809) due to some issues.

Windows Server 2019 was re-released a few days ago, which allowed nerds everywhere (including me) to put Server 2019 and Exchange 2019 into a test environment.

The most striking thing that is immediately noticeable is that everything looks the same…. The install process, the GUI, the management, all looks the same as it did in 2016. To me, this is a good thing – while Microsoft of the past seemed to believe that moving functions between areas was good – some consistency is nice to have too.


Active Directory

First appearances indicate there is nothing new in AD 2019, the installation process and management is exactly the same as 2016.

While installing, there is not even an option to set the forest and domain functional level to “2019” – only 2016.

A quick look at the schema version indicates it has increased and quick google finds this article

So, while there is something new in the schema, its an incredibly small update….. and there are no new features or functionality of any type to focus on.


Exchange 2019

Exchange 2019 is a bit the same as AD, everything appears to be the same as Exchange 2016, from the install process to the management interface.

A google comes up with this

Should you upgrade to Exchange Server 2019?

So there are some changes and feature updates – but these updates may not have an impact/matter to your organization.


I found these two releases interesting overall as

  • AD is the core of many enterprise networks
  • Exchange is a core business application

To see a new release of both of these products with very minimal improvements I think demonstrates where all Microsoft’s development effort is going (which, to be fair, we already knew)


Migration of public folders to exchange 2013/2016

I’ve done a few of these…. but most corporates (at least that I’ve dealt with) use public folders quite lightly – if at all…. so the migrations have been quite simple.


Recently, I was tasked with moving a smaller business (through a partner) from 2007 to 2013 then 2016.

The mailbox move from 2007 to 2013 went flawlessly.

Then we came to their public folders…. approx. 400GB – from which they apparently run a lot of their business.

Ran through the (painful) process of removing trailing spaces, backslashes, dead permissions etc… not hard – just slow, manual and annoying.

There is an article here that talks about the hassle of migrating PF’s –

On the first migration attempt, the extent of these corrupt items and oversize items was discovered (3000 corrupt items and hundred’s of items that were oversize) – then discussed with the business.

So here we have the first fucking boomingly huge issue with public folder migration…. there are no powershell commandlets to help you get the size of items (you can get the size of folders, but that’s not helpful) that will be considered oversize… so you cannot identify these items prior to migration. To add to that, even if you could identify them, there is no nice way to say “export these items to PST, then delete” or as part of the migration batch “migrate all large items”

The next issue here is that through the GUI, you can see a list of skipped items and why they were skipped (corruption or oversize) – there doesn’t appear to be way to get this information via powershell so you nicely export it and give it to the customer (or sort it yourself)

The business stated that corrupt PF’s weren’t vital, but the large items were needed.

Even after lifting the size limit to 500MB, there were still lots of items that were too large.

I tried to accommodate these large items and found the exchange migration mailbox (a default database which I leave in the default location) – which should only ever be used in transit, proceeded to grow, fill up the disk that logs were on and cause a dirty shutdown and corruption…  so I haven’t my lesson there…. if a client is using PF’s as a file store for items of 500mb over – refuse to migrate until these items are removed…. (unfortunately you need run a “dummy migration” then look at the skipped items list to identify these items!)

Anyway – long story short – the moral of this, very annoyed, story

Public folder migration to Exchange 2013/2016 sucks. It has clearly been put in as an after-thought to appease some organisations – and is only suitable for light users of PF’s

If a customer is a heavy public folder user, do not change the default “large item” size to accommodate them. Refuse to migrate them and notify them the items will be lost.


Exchange 2013/216 receive connector selection process

On a recent gig, the local tech wanted some more detail on the receive connector selection process… I explained the whole “most defined” IP set wins (i.e. will be selected over, but was unable to find any TechNet articles to back that up.

Fortunately, this guys nails it, with a good explanation and examples…

good work Mark Gossa.


KB3124557 sets exchange 2013/2016 services to disabled

A patch for exchange 2013 and 2016 sets all exchange services (and IISAdmin and W3SVC) to disabled after installing

Its not a disaster, just simply set all the services back to automatic, start them, and away you go….

Still, the joke conspiracy from a mate of mine a while back of “The marketing team are forcing the exchange team to fuck up updates, as a way of pushing people to exchange online”, based on the amount of botched updates, is becoming more and more plausible.

Handy list of antivirus exclusions for MS products

I am still very much of the opinion that file level anti-virus does not belong on servers such as exchange, SQL, SCCM etc… however, for places that flat-out refuse to apply logic – and want anti-virus on everything, this is a very good starting point to apply the mountains of exclusions required.