All posts by jaapwesselius

Setting Calendar permissions right after mailbox creation

Customer is running Exchange 2013 with approx. 2500 mailboxes. When looking at calendars and sharing information through the availability service only the availability (free, busy or tentative) is shown. No details are shown by default.

Customer now request to publish more information so that users that want to schedule a meeting can see the details of other user’s appointments. This should not only be configured for existing users, but new users should receive this setting directly when provisioned.

For example, when configuring this for a user called Kim Akers (kima@exchangelabs.nl) for all users you can use the following Exchange PowerShell command:

Set-MailboxFolderPermission kima:\Calendar -User Default -AccessRights Reviewer

When scheduling a meeting with Kim Akers I can now see her appointment details in Outlook, and I can open the appointment to see all details (read-only) of this appointment as shown in the following two screenshots:

image

image

Note. Check the Set-MailboxFolderPermission article on Microsoft TechNet for all details regarding the permissions that can be assigned.

Continue reading Setting Calendar permissions right after mailbox creation

DKIM in Office 365

Microsoft has implemented DKIM, DMARC and SPF in Exchange Online, the only thing you have to do is enable it. The only thing for DKIM you have to do is create two CNAME records in DNS and enable DKIM in the Exchange Admin Center.

DKIM CNAME records

The CNAME records you have to create for DKIM look like this:

selector1._domainkey.contoso.com
selector2._domainkey.contoso.com

Selector1 and selector 2 are the 2 selector tags (in Office 365 these will always be selector1 and selector2), the _domainkey is a default tag that will be added. Of course you have to replace the contoso.com with your own domain.

The CNAME records have to point to the following locations:

selector1-contoso-com._domainkey.contoso.onmicrosoft.com
selector2-contoso-com._domainkey.contoso.onmicrosoft.com

Continue reading DKIM in Office 365

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

Cisco Email Security Appliance and DKIM Signing

In a previous blogpost, I already discussed DKIM signing with Exchange 2016:  SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part II

Exchange out-of-the-box does support SPF checking, but DKIM signing/verifying and DMARC verifying are not supported. There are free 3rd party tools for DKIM Signing that can be found on GitHub, but at the moment of writing this tool only supports DKIM Signing, but does not support DKIM verifying. I have to admit that DKIM signing with this tool works very well.

I already explained earlier that I’ve installed and configured a Cisco Email Security Appliance (ESA, previously known as IronPort) appliance in my lab environment, and this is installed like this:

image

Figure 1. My testlab Exchange environment.

All outbound SMTP mail is via the ESA. The FQDN of the ESA is smtphost.exchangelabs.nl, of course it has a public IP address with a corresponding PTR record.

Continue reading Cisco Email Security Appliance and DKIM Signing

Cisco IronPort and Exchange 2016

If you have been following my blogs over the years you should be aware that I’ve always been using Exchange Edge Transport servers in front of my Mailbox servers for message hygiene purposes. My last (well known) environment looked like this:

image

There are two Mailbox servers (Exchange 2013 and Exchange 2016) and two Edge Transport servers (also Exchange 2013 and Exchange 2016). MX records point to both Edge Transport servers and there are two Edge Synchronizations. And the Edge Transport servers were capable for DKIM signing (as posted in a previous blogpost), but lacked DKIM verification and DMARC validation.

The most important part in the Edge Transport server is the Real Time Blocklist, configured to use Spamhaus for connection filtering. While this works pretty well (there still is quite some spam that gets delivered into mailboxes) there is always room for improvement. I have been looking at cloud solution, but they didn’t always deliver what was expected.

A couple of my customers are using Cisco Email Security Appliance (previously known as IronPort) solutions on-premises and are happy with it, so time to start testing a Cisco Email Security Appliance (ESA) in my own environment. Continue reading Cisco IronPort and Exchange 2016