There are 28 entries in this Category.

Updating Exchange Server Certs Error Free

One of the most dreaded events that Administrators loath is the updating of SSL certificates in their environment. The process of creating the CRL plus requesting and obtaining the certificate typically is THAT bad, but it’s the application and restart of services then validation of the environment that can be a challenge.

Exchange is no exception, however with many moving parts between client access and mail transport, ensuring we hit each of the key components.

We’ve installed the certificate on the server using the DigiCert tool and ran the necessary Powershell command to assign the certificate

[PS] C:\Windows\system32>Get-ExchangeCertificate | fl Thumbprint,CertificateDomains,IsSelfSigned,Services

Thumbprint         : A3F7F37A3BA1ADC1AAD2AD1A4FC7CCDE2018A1E0
CertificateDomains : {,,}
IsSelfSigned       : False
Services           : IMAP, IIS, SMTP

Thumbprint         : 438F27DB3B7BE7C827A3DACD9D26F27EC2FD7852
CertificateDomains : {s,}IsSelfSigned       : True
Services           : POP, SMTP

Thumbprint         : 25D280F5E9D0E5D629717250F73192C7FF88FA49
CertificateDomains : {WMSvc-SHA2-EX1}
IsSelfSigned       : True
Services           : None

Thumbprint         : E0335F09160EA7B611B38549A399F3EF6AC4AAEA
CertificateDomains : {Federation}
IsSelfSigned       : True
Services           : SMTP, Federation

Enable-ExchangeCertificate -Thumbprint A3F7F37A3BA1ADC1AAD2AD1A4FC7CCDE2018A1E0 -Services POP,IMAP,IIS,SMTP

Reference for certificate update

While client access for our mailboxes in the Cloud works just fine, when we go to perform SMTP relay from the on-premises Exchange server out to Office 365 it fails and we see the following errors in the Application log:

Source: MSExchangeTransport
Event ID: 12014

Microsoft Exchange could not find a certificate that contains the domain name <I>CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc, C=US<S>, OU=IT, O=”Company, LLC”, L=Minneapolis, S=MN, C=US in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Default Frontend EXGSRV01 with a FQDN parameter of I>CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc, C=US<S>, OU=IT, O=”Company, LLC”, L=Minneapolis, S=MN, C=US. If the connector’s FQDN is not specified, the computer’s FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

Source: MSExchangeTransport
Event ID: 12035

Exchange was unable to load certificate I>CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc, C=US<S>, OU=IT, O=”Company, LLC”, L=Minneapolis, S=MN, C=US. More information: Is FrontEnd Proxy enabled: false. Original backend Server: Send Connector Name from the original request: Outbound to Office 365.

So while we updated the Exchange services, we missed an important step of updating the mail transport components that handle the TLS connection (since just about every provider forces its usage today – Microsoft being no exception).

The fix is simple: update the primary Receive and Send Connectors with the certificate name from our new cert & restart the Microsoft Exchange Transport service

$cert = Get-ExchangeCertificate -Thumbprint A3F7F37A3BA1ADC1AAD2AD1A4FC7CCDE2018A1E0

$tlscertificatename = “<i>$($cert.Issuer)<s>$($cert.Subject)”

Set-ReceiveConnector “EX1\Default Frontend EX1” -TlsCertificateName $tlscertificatename

Set-SendConnector -Identity “Outbound to Office 365” -TLSCertificateName $tlscertificatename

Restart-Service MSExchangeTransport

In some cases, the binding for https the Default Web Site can cause errors where login failures are seen as well. You will want to ensure that both https references have the public certificate references, then perform an IISRESET.

Exchange Server 2016 Exchange Administrative Center cannot login

Finally, to test that mail flow is working, we want to send a test email message thru Exchange – we can do this thru Powershell to force a message thru the Receive connector, over to the Send connector to Office 365, and then to the user mailbox.

Import-Module servermanager
Add-WindowsFeature telnet-client

telnet EX1 25
mail from:
rcpt to:
subject: this is a test message
sending a test message via telnet

Get Exchange Install Path, Version and Role

I’ve been fighting for a while to find a GOOD script that can do everything from one machine and still work on Exchange 2010 while supporting Exchange 2013/2016. I spent the day working on this sucker so i can send it off to a client to perform an assessment without physically touching the environment and here it is. Enjoy!

Update: I’ve taken my whole script and put it out on my GitHub – check it out!

#Get Exchange Server Versions
#Be sure Powershell Remoting is enabled
#To enable on each server run winrm quickconfig
#Created by Chris Blackburn

$exchangeservers = Get-ExchangeServer

$report = @()

foreach ($srv in $exchangeservers)

$srv = Get-ExchangeServer $srv

$server = $srv.Name
if ($srv.AdminDisplayVersion -match “Version 14”) {$ver = “V14”}
if ($srv.AdminDisplayVersion -match “Version 15”) {$ver = “V15”}

Write-Host “Checking $server”

$installpath = $null

$installpath = Invoke-Command –Computername $server -ScriptBlock {$env:ExchangeInstallPath} -ErrorAction STOP
Write-Warning $_.Exception.Message
$installpath = “Unable to connect to server”

Write-host “Install Path is: ” + $installpath
$Path = $installpath + “Bin\ExSetup.exe”
$fileversion = (Get-Command $Path).FileVersionInfo
Write-Host “File Version is: ” + $FileVersion.fileversion

$serverObj = New-Object PSObject
$serverObj | Add-Member NoteProperty -Name “Server Name” -Value $server
$serverObj | Add-Member NoteProperty -Name “Install Path” -Value $installpath
$serverObj | Add-Member NoteProperty -Name “Server Role” -Value $srv.serverrole
$serverObj | Add-Member NoteProperty -Name “Server Version” -Value $fileversion.fileversion

$report += $serverObj

Clear-variable srv
Clear-variable server
Clear-variable installpath
Clear-variable ver

$report | export-csv exchangeversions.csv -notype

Migrating Public Folders from 2010 to 2016

A little over 5 years ago I wrote a blog on how to migrate public folders from Exchange 2007 to 2010, hoping that that would be the last migration path that would be needed for the long standing public folder system. Surprise! Exchange 2013 brought along “Public Folder Mailboxes”, which brought new life into the age old structure, and killed off the dreaded replica process in lieu of DAG replication. On top of this new process has brought some new headache, as well as some old ones that have been around since Exchange 2003. We’re going to try and tackle those problems before we get down to the actual process of migration.

But let’s jump ahead before we come back and look at the age old issue of public folder migrations: mail-enabled public folders. The issue that has stemmed back to the older days of Exchange is how the Alias field allowed use of what are now seen as invalid characters. Sure the Technet article for migrating public folders gives us a script for searching for forward slashes but not invalid characters, which you may still see from environments migrated from Exchange 2003


When you mail-enable a public folder pre-Exchange 2010, it would create these as Public Folder objects in Active Directory under the Default naming context | Microsoft Exchange System Objects. As you can see on the left in the Public Folder Management Console, the mail enabled public folders, indicated by a folder with an envelope on it, correspond to the object on the left in AD.


If we open Exchange Powershell on Exchange 2010, we can find these any folders with illegal characters rather quickly:

Get-MailPublicFolder -ResultSize Unlimited | Where-Object{$_.alias -match ‘\s’}

Error: Property expression “RA (Malcolm) 2009-19” isn’t valid. Valid values are: Strings formed with characters from A to Z (uppercase or lowercase), digits from 0 to 9, !, #, $, %, &, ‘, *, +, -, /, =, ?, ^, _, `, {, |, } or ~. One or more periods may be embedded in an alias, but each period should be preceded and followed by at least one of the other characters. Unicode characters from U+00A1 to U+00FF are also valid in an alias, but they will be mapped to a best-fit US-ASCII string in the e-mail address, which is generated from such an alias.

This can quickly return a LOT of errors that correspond not only to illegal characters. Some of these are completely normal and have to do with the original Offline Address Book and it’s traditional Public Folder distribution method.

image Continue reading “Migrating Public Folders from 2010 to 2016” »

Exchange Online 2016 Hybrid Guidance & Architecture

After doing quite a few Exchange Online hybrid deployments, I decided that it was time to do what I do best – build a design template so I don’t have to continue to reinvent the wheel for each project. I’ve done this for Exchange, Active Directory and SCCM audit documentation, but those are stories for another day…

In a typical scenario we’re taking an existing, highly available Exchange 2010 environment that is protected behind their own spam filtering devices (so this could change and be a services, no problems) and adding a secondary Exchange hybrid server dedicated for this purpose – be it Exchange 2013 or even Exchange 2016. I’ve deployed a few of these already and they work great, think Exchange 2013 SP2 but with better results. More of that in a moment.

But you ask “why not just run Hybrid on the existing Exchange servers? The biggest one is that the Hybrid wizard on Exchange 2010 hasn’t gotten any better since SP3. Sure the Cumulative Updates have fixed some bugs but with Exchange Online running on the Exchange 2016 build, the gap is getting wider in regards to the success rate of being able to run thru the Hybrid Wizard the first 5-6 times without having to go back and fix issues (or create new ones).

Or, let’s say that eventually you’ll be migrated to Exchange Online, you’ll have your MX records flipped, most likely using Exchange Online Protection (and the rest of the stack), but may still have that need to run some mailboxes on-premises, or you want a nice GUI to provision your users / groups (yes, you CAN run without a Hybrid server but we’re talking a LOT of Powershell), or you have a LOT of SMTP endpoints and switching them all to the Cloud for relay just doesn’t make sense. Having a newer version of Exchange in the environment that’s NOT on extended support.makes the most sense.

There are some “gotchas” however: as of Exchange 2013 CU8 Microsoft has introduced their new hybrid wizard – and let me tell you this thing it’s amazing. Of course now with Exchange 2016 its built in.


Once of the previous “gotchas” with Exchange 2013 hybrid was the requirement to flip all of the CAS traffic over on day one to make things work/ Now, with Exchange 2016, this is no longer a requirement. More on that over at the Technet blog. The only thing you have to remember is that if you keep your existing Exchange 2010 environment, and still have Autodiscover pointed there, you’re going to run into a few issues: free/busy will be broken, migration batches will be broken, however mail flow will still work, and the only way to move a mailbox is thru New-MoveRequest.

This is because when you create the organization relationship, even in Exchange 2016, it does NOT use the organization FQDN you’ve specified but instead populates with the typical autodiscover URL.


To fix this, you need to run:

Get-OrganizationRelationship | Set-OrganizationRelationship -TargetAutodiscoverEpr ""

There are a few instances that have been documented as well where you also need to run:

Get-OrganizationRelationship | Set-OrganizationRelationship -TargetSharingEpr ""

There’s also a great blog post that goes into troubleshooting Authentication on the Exchange 2010 side as well, where Negotiate authentication (which is there by default but against best practice) can cause Cloud -> On-Premises authentication issues.

So you’ve seen some pretty compelling reasons to deploy Exchange 2016 for your hybrid environment. Whether it be in a Federated or Synchronized identity model, and with in conjunction with AD Connect for directory synchronization, you can get setup with hybrid easer than ever.

Also Microsoft has recently updated the Exchange Hybrid Product Key Distribution wizards so you can finally deploy Exchange 2016 in an Exchange 2010 environment as your Hybrid server and be covered under Microdot proper licensing and support. You can grab your key at:


So without further adieu, here is version 2 of my EO Hybrid architecture.


Deep Dive in On-Premises Public Folder Hybrid with Exchange Online

Public Folders have been on the way out ever since Exchange 2007 but there are still organizations that are slow to migration to “better” options (IE, Shared Mailboxes or Sharepoint sites).

Previous processes required migration before moving mailboxes however the Hybrid process will allow the migration of end user mailboxes up to Exchange Online while at the same time providing additional time for moving the data to other options.

The biggest “gotcha” of this scenario requires the configuration of the CAS role to be added to the server hosting the public folder database

The key comment in the Technet blog spelling this out starts with:

The addition of the CAS role will ensure public folder replica referrals happen appropriately if a folder a user is accessing does not have a local replica in the PFDB.

Exchange Online uses RemotePublicFolderMailboxes on the on-premises server with the public folder database in conjunction with the Client Access Server role.
We also need a dedicated mailbox database and mailbox because of how RPC client traffic is relayed thru this role.
In an Exchange 2010 CAS array environment, mailbox databases are stamped with the array name. This won’t work in routing RPC client access traffic properly, thus the separate database.

I had the priviledge of setting this up in an Exchange 2010 hybrid environment and wanted to share a few “gotchas” I encountered.
Let’s take our Mailbox server with the Public folder database, OCEX04


Continue reading “Deep Dive in On-Premises Public Folder Hybrid with Exchange Online” »

Exchange Recipient Types and Office 365 – Setting Active Directory attribute values

In doing some digging for a recent post on Online Archives I found that I had to dig around multiple places on the internet (primary Technet blogs) to find exactly what each of the Active Directory attribute values around Exchange recipient types mean.


So instead of multiple places, here they are all in one!

Continue reading “Exchange Recipient Types and Office 365 – Setting Active Directory attribute values” »

Enabling Exchange Online Archive give error “Primary mailbox is located on an on-premises server”

So I’m deep in the throws of an Office 365 project, and after going thru the process of setting up Exchange Hybrid with on-premise ADFS, testing mailflow, and performing a mailbox move, the next step was working on Retention Policies to migrate email older than 1 year from their Primary Mailbox with 50gb storage to their Online Archive with 100GB of storage.

I tried to enable the archive from the Exchange Online portal as well as thru Exchange online Powershell but didn’t have any luck. With Powershell I was getting the message:

"Can't enable the archive for user because their primary mailbox is located on an on-premises server. To enable a cloud-based archive mailbox for this user, you must use your on-premises Exchange admin center or Exchange Management Shell."

I found this particularly odd because, well, the mailbox WASN’T on-premises any more nor was there any kind of archive mailbox enabled for my test acount.

After digging for hours (which is typically the catalyst for most of these posts) I came across a solution through the Office 365 community which detailed out adjusting the source AD user’s object on-premises attributes in order for the Archive to come online. Again, since this was a hybrid identity design, on-premises Active Directory was the source of truth and directory synchronization was in place to populate the objects in Azure AD / Office 365.

First, we need to modify the msExchArchiveName attribute to reflect the archive name (this can be whatever we want), as well as modify the msExchRemoteRecipientType to 3.

We’ll leave the msExchRecipientDisplayType and msExchRecipientTypeDetails as is – you can find what these means in a post I made here.

Once completed, force a Dirsync

Once complete, we run the Exchange Online powershell to see that the Get-Mailbox command to see the archive has been created

And that Outlook shows our online archive (with the name that we provided)


Using Office 365 & Exchange Online for SMTP Relay

My current client is getting ready to migrate off of FOPE smarthosts to EOP and there were some questions around how this process goes. And thankfully I can say it’s pretty easy – just point your smarthosts to your MX record, found in the Office 365 portal.

Without delving too much into the process, a fellow O365 admin Mark Kean has written a great blog post on how this process works:

NOTE: You don’t have to setup anther Inbound Connector in Office 365 – this way you avoid needing another SSL certificate. Just use the Hybrid Mail Flow Inbound Connector and add your on-premise IP into the Sender IP Addresses list for the same results.

This process allows you to continue to use onsite applications, MTAs, copiers, etc to process messages from on premise. And you don’t have to setup the arduous SMTP relay through via TLS and with an existing account. This relies on the traditional, allowed IP address method to blanket accept everything sent.

I’m happy to say that it even allows you to relay messages from address that don’t even exist in the organization. So lets say you want to send out messages from on an internal mailing system and that mailbox doesn’t exist. EOP processes these messages with no problem.

There’s another great Technet article I like to refer customers to who have questions on the different email methods EOP allows. The article references multi-function devices but this encompasses any number of devices:

Exchange Online message limits – not that cut and dry!

Update 4/15/15 – Office 365 has increased the allowed maximum message size to 150 MB, giving Office 365 administrators the ability to set the maximum message size of their choosing from 1 MB up to 150 MB. The default maximum message size for Office 365 mailboxes is still 25 MB, and they don’t plan on to changing the setting on existing accounts.
More at

I’m currently on project finishing an Office 365 migration (yay – I’m finally back together with my true love: messaging!) and we’re in the process of migrating their 50+ domains off of FOPE, as they were initially a Wave 14 tenant, and over to EOP.  Technically, they were automatically migrated to EOP as part of the upgrades in Q3/Q4 2013, however they still have their MX records pointing to either the or domains, so traffic is being first routed thru FOPE before it makes it to EOP. And if you may or may not know, it’s crunch time and Microsoft wants everyone off by June 1 (if you have an O365 domain):

As part of determining the impact these MX record changes will have on message flow, the big one is around accepted message size. In FOPE, if a message went over the size limit you could have it qurantined and the messaging administrator could release it to the mailbox, granted your Receive Connector allowed it, and your MaxReceiveSize on your mailbox matched according.

A large debate has come up around Exchange Online limits, as detailed below:

In talking with my collegues, there was a lot of confusion around message limits, and in talking with with my contacts in Microsoft, I can finally clear the air on what these limits are. And it’s actually simpler than you think :mrgreen: Continue reading “Exchange Online message limits – not that cut and dry!” »

Highlight: Exchange 2013 Installation Troubleshooting

I’ve had quite a bit of traction on my Exchange 2013 Liftoff! Part 1.5, Installation Troubleshooting post and have even been able to personally help a few people dig in on repairing an install. I’m happy to say I’ve been able to expound on the post with some fresh information, and will throw out that I’d love to continue in growing this post with information to help someone else. So go over and check it out 😎