Tag Archives: Exchange

Exchange 2016 CU7 and Exchange 2013 CU18

Microsoft has released its quarterly updates for Exchange:

  • Exchange 2016 CU17.
  • Exchange 2013 CU18.

It has been quiet around these updates, and they do not bring a whole lot of features.

Important to note is that the minimum Forest Functional Level (FFL) has been raised to Windows Server 2008 R2. Personally I think this is an indication that more exciting stuff is along the way, especially around Exchange 2016 (my personal expectation, don’t shoot the messenger :-))

There are schema changes in Exchange 2016 CU17, so when installing this update you have to execute the following commands:

Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms

When it comes to the .NET Framework, Microsoft is working on a new .NET Framework release (version 4.7.1). The upcoming quarterly update of December 2018 will support this version of the .NET Framework.

More information (well, not a lot more) can be found here: https://blogs.technet.microsoft.com/exchange/2017/09/19/released-september-2017-quarterly-exchange-updates/

 

create Shared Mailbox in Exchange Hybrid

Every now and then I get a question regarding creation of Room- or Shared Mailboxes in Office 365 when Exchange Hybrid is in place.There are multiple solutions available, but at the same time there are some restrictions as well. In this blog post I’ll discuss Room Mailboxes, Equipment Mailboxes and Shared Mailboxes.

Room Mailbox

To create a room Mailbox in your hybrid environment create a user account for this room mailbox first. In this example I’m going to create a Room Mailbox called ‘conference room 1st floor’ and have it created directly in Office 365 (for your information, I’ve tested this with Exchange 2010 hybrid as well as Exchange 2016 hybrid).

image

To create the Mailbox in Exchange Online, you can use the Enable-RemoteMailbox cmdlet in Exchange PowerShell. This will mail-enable the account in your on-premises environment and will automatically create a mailbox in Exchange Online the next time Azure AD Connect runs. For the Enable-RemoteMailbox cmdlet you need to use the -RemoteRoutingAddress (which should point to the Mailbox in Exchange Online) and for a Room Mailbox you have to use the -Room option. If you want to create a Shared Mailbox you can use the -Shared option, the result will be the same.

To create the Room Mailbox in Exchange Online we can use the following command:

Get-User -Identity Conference1 | Enable-RemoteMailbox -Room -RemoteRoutingAddress conference1@inframan.mail.onmicrosoft.com

image

When Azure AD Connect has run, the account has been provisioned in Azure AD and the Room Mailbox has been created. It is visible in Exchange Online EAC and permissions can be granted to other users can manage the Room Mailbox.

image

Resource (Equipment) Mailbox

To create a Resource (aka Equipment) Mailbox the process is very similar. First create a user account for the Equipment Mailbox in Active Directory and fill the appropriate attributes, like this:

av

To create the Equipment Mailbox directly in Exchange Online, execute the following in PowerShell (on your on-premises Exchange server):

Get-User -Identity AVEquipment | Enable-RemoteMailbox -Equipment
-RemoteRoutingAddress avequipment@inframan.mail.onmicrosoft.com

equipment

Again, when Azure AD Connect has run, the account is provisioned in Azure AD and the Mailbox is created in Exchange Online:

mbx

Shared Mailboxes

Createing Shared Mailboxes is a bit problematic, after all these years there’s still no option like -Shared when using the Enable-RemoteMailbox cmdlet in Exchange PowerShell so we have to figure out another way to create a Shared Mailbox in Exchange Online when using Azure AD Connect and a Hybrid environment.

<more to come soon>

 

Improve autodiscover performance

Autodiscover can be a lengthy process, especially if you are in a hosted environment or if your mailbox is in Office 365.

The autodiscover process consists of five different steps, it depends on your environment where autodiscover stops and returns the information. Autodiscover is using the following mechanisms:

  • Service Connection Point (SCP) in Active Directory. This is used by domain clients.
  • Root domain discovery, used by non domain joined clients or clients not being able to access Active Directory. All other steps are used by these clients as well.
  • Autodiscover.contoso.com (standard autodiscover mechanism)
  • Autodiscover redirect to autodiscover site (often used by hosting companies)
  • Autodiscover SRV records in DNS (sometimes used by hosting companies)
  • Autodiscover redirect to Office 365 (outlook.com)

If your mailbox is in Office 365, outlook will go through all these steps until it finds the information in Office 365. All steps will fail with the accompanying time-out and this will take quite some time. This can be seen in the Outlook Test Email AutoConfiguration option:

image

Continue reading Improve autodiscover performance

SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part III

In the previous two blog posts I have discussed SPF and DKIM as a way of validating the authenticity of email messages. SPF is using an SPF record in public DNS where all legitimate outbound SMTP servers for a domain are listed. A receiving SMTP server can check this DNS record to make sure the sending mail server is allowed to send email messages on behalf of the user or his organization.

DKIM is about signing and verifying header information in email messages. A sending mail server can digitally sign messages, using a private key that’s only available to the sending mail server. The receiving mail server checks the public key in DNS to verify the signed information in the email message. Since the private key is only available to the sending organization’s mail servers, the receiving mail server knows that it’s a legitimate mail server, and thus a legitimate email message.

As a reminder, my test environment is configured as follows:

image

There’s an Exchange 2016 CU2 Mailbox server hosting several Mailboxes, and there’s an Exchange 2016 CU2 Edge Transport server. Using Edge Synchronization all inbound and outbound SMTP traffic is handled by the Edge Transport server.

In the previous two blog posts an SPF record was created and implemented, and DKIM including a DKIM signing module on the Edge Transport server was implemented and functioning correctly.

This last blog in a series of three discusses DMARC, which is built on top of SPF and DKIM. Continue reading SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part III

SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part II

In the previous blogpost I have been discussing how SPF works and how it uses public DNS to validate the authenticity of the sending SMTP servers. When SPF is implemented correctly a receiving mail server can validate is the sending mail server is allowed to send email on behalf of the sender or his organization.

In this blogpost I will discuss DKIM signing as an additional (and more complicated, and more difficult to spoof) step in email validation.

As a quick reminder, here’s how my lab environment looks like:

image

There’s an Exchange 2016 CU2 Mailbox server hosting several Mailboxes, and there’s an Exchange 2016 CU2 Edge Transport server. An Edge synchronization will make sure that all inbound and outbound SMTP traffic is handled by the Edge Transport server.

In my previous blogpost an SPF record was created and implemented with the following value:

v=spf1 a:smtphost.exchangelabs.nl ~all

so receiving mail servers can validate that my Edge Transport server is allowed to send email on my behalf, and when mail is originating from another mail server it might well be a spoofed message.

But for now let’s continue with DKIM. Continue reading SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part II