As part of an ongoing Exchange 2010 to 2016 migration, I had to replace the self-signed certificate with a certificate from the customers PKI. Everything went fine, the customer had a suitable template, we’ve added the necessary hostnames and bound IIS and SMTP to the certificate. The mess started with an iisreset /noforce… Bild von Oskars Zvejs auf Pixabay The iisreset took longer than expected. After that, I tried to login into the ECP, entered username and password and got an error.

Exchange has known the concept of internal and external URLs for the different services (Outlook Web Access, OAB, EWS, ActiveSync etc) since Exchange 2007. And it’s still confusing people. The internal URL is the URL, that is used to access the desired service from the intranet. The external URL represents the URL that is used to access the service from the internet. Best practice is to use the same URL (the external) for both, use a certificate from a public CA, and use split DNS to access the external domain from the inside of your network.

When dealing with Microsoft Exchange restore requests, you will come across three different restore situations: a database a single mailbox a single mailbox item (mail, calendar entry etc.) Restoring a complete database is not a complicated task, but restoring a single mailbox, or a single mailbox item, is. First, you need to restore the mailbox, that includes the desired mailbox, into a recovery database. Then you can restore the mailbox, or the mailbox items, from the recovery database.

Sometimes you have to check when the last backup of an Exchange mailbox database was taken. This is pretty simple, because the timestamps of the last full, incremental and differential backup is stored for each mailbox database. You can check these attributes using the Exchange Control Panel (ECP), or you can use the Get-MailboxDatabase cmdlet. Backup successful, but no timestamp? Take a look at this output. As you can see, there’s no timestamp for the last full, incremental and differential backup.

Microsoft Exchange heavily relies on Microsoft .NET Framework. Because of this, Microsoft provides a matrix for the supported Microsoft .NET Frameworks. Mostly unknown is the fact, that Exchange doesn’t support the every Microsoft .NET Framework, and this is causing trouble sometimes. Some admins simply install the latest .NET releases because “it doesn’t hurt”. Well… it hurts! Changes for .NET Framework 4.6.1 Microsoft has changed the support policy for .NET Framework 4.

After deploying a new Microsoft Exchange organization with Exchange 2016, or after deploying a Microsoft Exchange 2016 into an existing organization, you might notice a strange behaviour regarding the Offline Address Books (OAB). [PS] C:\Windows\system32>Get-OfflineAddressBook Name Versions AddressLists Standard-Offlineadressliste {Version2, Version3, Version4} {\Globale Standardadressliste} Standard-Offlineadressliste (Ex2013) {Version4} {\Globale Standardadressliste} Huh?! Where does this Exchange 2013 OAB come from? As you can see in the cmdlet output, there’s no Exchange 2013 in this organization.

Another bug in Exchange 2016 CU2. The Role of a new receive connector is greyed out. You can select “Front-End-Transport”. This is a screenshot from a german Exchange 2016 CU2. [caption id=“attachment_3051” align=“alignnone” width=“510”] Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0[/caption] Solution Use the Exchange Management Shell to create a new receive connector. Afterwards, you can modify it with the Exchange Control Panel (ECP). [PS] C:\Windows\system32>New-Receiveconnector -Name “Client Frontend Dummy” -RemoteIPRange (“192.