Storing email signatures in the Exchange mailbox

UPDATE: On Sept. 10 I received notice that this UserVoice item will be implemented in the near future. See Syncing Email Signatures Across Devices is soon to become a reality!!

A common complaint is that users must configure their email signatures every time they configure their mailbox on a new Outlook client or in OWA for the first time.

The current email signature behavior in Exchange and Exchange Online is that users must create new signatures every time they add a new mailbox in Outlook and in each of the Outlook apps. OWA already stores a text and HTML signature in the mailbox, but Outlook doesn't use it. OWA also does not provide for different signatures or a different reply signature like Outlook does. That's very inconsistent behavior.

In a recent discussion with the Exchange and Outlook product groups, the MVPs discussed a long-standing request - to store email signatures in the user's mailbox. Doing so will provide a centralized place to store and retrieve the signatures and provide consistency for the email clients that consume them (Outlook for desktop, Outlook on the web (OWA), and the Outlook apps (iOS and Android)). We are also requesting that signatures can be managed via PowerShell.

The product groups challenged us to show that customers want this by vote count on UserVoice. Please vote for the "Store Signatures in the mailbox" idea on UserVoice website to make your voice heard. I've written a spec for this feature, which I will be submitting to the PGs once the vote count gets higher. Our expectation is that this will work for both Exchange Server and Exchange Online.

Please up-vote this feature request and let's see if we can get this one done!

Read more ...

Fix for Certificate Error in Chrome - NET::ERR_CERT_COMMON_NAME_INVALID

It amuses me when Google dictates security policy.

Beginning with Chrome 58, the Chrome browser no longer uses the Common Name (CN) field to validate an SSL certificate. Instead, it only uses the Subject Alternative Name field.

This is in violation of RFC 2828 which states,

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

So someone in Google security said, "Hey! If RFC 2828 says the Common Name is deprecated, we should start making Chrome ONLY use the Subject Alternative Name! Existing practice, be damned." Never mind the fact that the RFC was written May 2000, and every other browser and app on the planet uses the Common Name field for single-name certificates.

Therein lies the problem. Most single name certificates and some wildcard certificates only have a Common Name and don't have use Subject Alternative Names. This causes Chrome 58 and later to display the following (incorrect) error. It even goes so far as to blame it on a server misconfiguration.

NET::ERR_CERT_COMMON_NAME_INVALID [missing_subjectAltName]

This same website (in this case, OWA) displays properly in all other browsers. If we look at the certificate, we see this is a wildcard cert for *.contoso.com issued by an internal certification authority (CA). The Details tab shows there is no Subject Alternative Name field for this cert.

Wildcard certificate details with only a Common Name (CN) field

To fix the error for your Chrome users, you'll need to regenerate the certificate to include a Subject Alternative Name. Here's how to do that using the Certificates MMC when you have an internal Certification Authority (CA).

From the web server, open MMC and add the Certificates snap-in, managing the Computer account. Then expand Certificates (Local Computer) > Personal > Certificates.

Right-click Certificates > All Tasks > Request New Certificate.

Choose Active Directory Enrollment Policy to use your existing internal CA.

Select the Web Server certificate template and click the link below it to enter more information.

Add the Common Name for the Subject Name, and the DNS name for the Alternative Name. They can be the same value. Chrome 58 and later only uses the DNS alternative name.

Enter a Friendly Name on the General tab.

Optionally, make the private key exportable on the Private Key tab and click OK.

Click Enroll to generate the new cert from the CA and install it on the web server.

The certificate will be installed. Click Details to view the new certificate.

On the Details tab we see the Subject Alternative Name is on the new cert.

Now you'll either need to configure IIS to use the new certificate (Web Site - Bindings) or reconfigure Exchange web services using the Enable-ExchangeCertificate cmdlet.

Read more ...

New Article: Reply or Reply All - Controls, Options, and Best Practices

Since the dawn of email, organizations have struggled with the way that users reply to emails. Confusion (or worse) occurs when emails include groups, CC, BCC, internal, and external recipients. Choosing to use Reply All may release confidential information to the wrong people or cause mail storms between senders and recipients – sometimes bringing email servers to their knees.

When is it appropriate to use reply or reply all? In this article on the ENow Exchange & Office 365 Solutions Engine Blog (ESE) I’ll explain the best practices, what can be done to control this for both Exchange Server on-premises and Exchange Online, and what you can do to help end-users.

Read more ...

How to Manage Distribution Groups from Office 365 in a Hybrid Environment

When on-premises distribution groups are synced to an Office 365 tenant via Azure Active Directory Connect, migrated users who are owners of the distribution group can't manage them in Outlook. Depending on the version of Outlook used, the user will receive an error message that resembles the following:

The action 'Update-DistributionGroupMember', 'Identity.Members', can't be performed on the object '<name>' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

-or-

Changes to the public group membership cannot be saved. You do not have sufficient permission to perform this operation on this object.

This happens because Outlook tries to update the same directory where the user's mailbox exists. If the mailbox is in Exchange Online this is the Exchange Online Directory Service (EXODS) directory, which syncs with Azure AD. Since EXODS is read-only in a hybrid environment using AAD Connect, the user receives the error.

Read more ...

How to Perform HTTP -> HTTPS Redirection in a Single Exchange Server Environment

HTTP to HTTPS redirection in Outlook Web App is a user convenience that many admins consider a necessity. It automatically redirects the user's browser to https://mail.contoso.com/owa if they enter http://mail.contoso.com, or simply mail.contoso.com. Without redirection, the user will get an HTTP 403 Forbidden error page, like the one below.

This happens because the SSL settings on the Default Web Site and all subdirectories are configured to require SSL.

In multi-server environments where load balancers are used, HTTP -> HTTPS redirection is normally performed on the load balancer. Most load balancers, such as KEMP or F5, automatically configure it when you deploy one of their Exchange server templates.

In single Exchange environments without a load balancer, you must configure redirection directly on the server itself. The steps below explain how to do this. I've used this method since Exchange 2007 and it works perfectly 100% of the time. Other methods I've seen on the Internet sometimes cause routing errors.

• Open Internet Information Services (IIS) Manager on the Exchange 2016 or Exchange client access server and navigate to Sites > Default Web Site.
• Double-click Error Pages and add a new custom error page for status code 403.4 that responds with a 302 redirect to https://mail.contoso.com/owa.

• Special note for Exchange 2016 - The Exchange team did a little number in the web.config file on Exchange servers to "improve performance", but it removes the custom error page behavior. So you'll need to do the following:
• Open the C:\inetpub\wwwroot\web.config file in Notepad.
• Remove the following line, and then save and close Notepad:

<remove name="CustomErrorModule" />

Note that this web.config edit will need to be made after every Exchange 2016 CU installation since setup overwrites this file.

That will handle the HTTP 403.4 - Forbidden: SSL is required error behavior in the browser. All that's left is to handle what happens when a user enters https://mail.contoso.com.

• Using Notepad, create a web page called default.htm in the C:\inetpub\wwwroot folder of the Exchange 2016 or client access server. Add the following three lines:

<html>
<meta http-equiv="REFRESH" content="0;url=/owa">
</html>

• Save and close Notepad, and then test redirection.

Read more ...

How to Change the From Address in OWA

If you have Send-As rights for another mailbox, you may want to send email as that other user from your own mailbox. You may also want to send as an Office 365 Group so that all replies to your message go back to that group.

This is easy enough to do in the Outlook client by clicking the From drop-down box and selecting the appropriate account or entering an email address. It's not quite that intuitive in Outlook Web App (OWA), but it can still be managed.

First, you need to display the From field for the message you are composing in OWA. Click the [...] ellipses button and select Show From:

Next, right-click From the email address and select Remove:

Now type in the email address of the user or Office 365 Group you want to send the email as:

Of course you need to have rights to send as the user for this to work properly, otherwise you will get an NDR saying, "You don't have rights to send as this user."

Note that the sent item will go into your Sent Items folder, not the user's who you are sending as.

Read more ...

How to Quickly Determine Exchange Server Versions

It's fairly easy to determine the version of Exchange Server running on a server using the Exchange Management Shell. The following cmdlet will display the Exchange version for each server in the organization, according to Active Directory:

Get-ExchangeServer | fl name,AdminDisplayVersion

The output will look something like this:



The AdminDisplayVersion value tells you the Exchange version using the following ww.xx.yyyy.zzz format:

MajorVersion | ServicePack | CumulativeUpdate/UpdateRollup | MinorVersion

For example, 14.3.0123.004 is Exchange 2010 Service Pack 3, 15.0.1178.004 is Exchange Server 2013 CU13, and 15.1.0466.034 is Exchange Server 2016 CU2. You can refer to Exchange Server Updates: build numbers and release dates to determine the exact version of Exchange is running. You can also run the Get-ExchangeServerBuildNumbers cmdlet in Exchange 2013 or Exchange 2016. This cmdlet scrapes the same webpage and displays the Product Names, Release Dates, and Build Numbers for every version of Exchange Server going as far back as Exchange Server 4.0 Standard Edition, released on June 11, 1996. Worth memorizing if you want to win one of Tony Redmond's famous Exchange trivia contests. :)

Note that Exchange 2013 CU4 was released as "Exchange 2013 Service Pack 1", but the ServicePack build number did not really increment until Exchange 2016 to 15.1, further demonstrating that Exchange 2016 is really just an incremental upgrade to Exchange 2013.

But what if you don't have easy access to EMS, or you want to check the version of the Exchange Server your mailbox is hosted on in Exchange Online for some reason?

If your on-prem Exchange 2013/2016 organization is using MAPI over HTTP (and you really should be) you can use the following URL to check which version of Exchange is running on the server hosting your mailbox:

https://<serverFQDN>/mapi/emsmdb/

For Office 365 use https://outlook.office.com/mapi/emsmdb/

The output will show the server version number, as shown below.



The cool thing about this method is that even works externally as long as Outlook Anywhere is published to the Internet. Keep in mind that the version returned is for the server hosting the mailbox being accessed, not the front-end client access proxy server. You can tell which front-end CAS your hitting by observing the Cafe server value.

Note that this method won't work if you haven't configured MAPI/HTTP or for mailboxes hosted on Exchange 2010 or earlier because they don't support MAPI over HTTP.

Read more ...

Redirection in Exchange 2013 CU6+ and Exchange 2016

Beginning with Exchange 2013 Cumulative Update 6, the Exchange 2013/2016 application itself performs redirection from the default website to the /OWA virtual directory. That means that if a user goes to https://server.contoso.com Exchange will redirect the user's browser to https://server.contoso.com/owa.

This 301 redirect behavior may affect load balancer health checks if your load balancer does not support direct URL health checking. Application-level health checks should normally be made directly to the https://server.contoso.com/<protocol>/healthcheck.htm URL. Citrix NetScaler load balancers, for example, perform healthchecks by connecting first to the default website and then performing a GET /OWA command. Since Exchange 2013 CU6 and later redirect the client (the load balancer) to the /OWA virtual directory this breaks that functionality.

The only reference to this new behavior is in the support article, Load balancer marks Exchange server as down in an Exchange Server 2013 Cumulative Update 6 environment. At the time of this writing, the article says this behavior applies to Microsoft Exchange Server 2013 Standard and Enterprise and that, "Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the 'Applies to' section." I have confirmed with the product team that this is by design, not a problem. It also applies to all versions of Exchange 2016 Standard and Enterprise, as well. Microsoft will be updating the support article soon to reflect this.

Note that this behavior does not redirect HTTP requests to HTTPS. You still need to perform these redirects from the server or the load balancer. My preference is to do this from the server(s).

Here's how I recommend implementing HTTP -> HTTPS redirection on Exchange Servers:

• Open Internet Information Services (IIS) Manager on the Exchange Server and select the server name.
• Double-click Error Pages.
• Click the Add action on the right and create a new error page for status code 403.4 that responds with a 302 redirect to https://server.contoso.com/owa as shown below.

Since the default website on Exchange servers is configured to require SSL, a user who tries to connect via HTTP will then get redirected to https://mail.contoso.com/owa, rather than getting an error page saying, "HTTP 403 Forbidden" and that SSL is required or you are required to log in.

With Exchange 2013 CU6 or later that's all you need to do. With older versions of Exchange you should create a default.htm file in the C:\inetpub\wwwroot folder with the following:

<html>
<meta http-equiv="REFRESH" content="0;url=/owa">
</html>

This will cause anyone who connects to https://mail.contoso.com to be redirected to https://mail.contoso.com/owa, which is now the default behavior with Exchange 2013 CU6 or later.

Read more ...

Introducing New-ExchangeWebsite for Exchange 2013

Microsoft recently announced support for adding additional virtual directories for OWA and ECP to Exchange 2013. I highly encourage you to read the blog post, Configuring Multiple OWA/ECP Virtual Directories on the Exchange 2013 Client Access Server Role, to understand when this is appropriate, what it entails, and associated caveats.

If you've already read that post, I'll summarize here. The reasons you may have for adding additional OWA/ECP virtual directories are:

• You want to separate admin and user ECP access to prevent access to the Exchange Admin Center from the Internet.

• You have different users within one organization who require a different OWA experience, such as a different Public/Private File Access or other policy or segmentation features.

The EHLO blog post does an excellent job explaining how you go about doing this. Basically, you add a secondary IP address to the Exchange 2013 server, create a new SSL website bound to that IP address, copy content from three different folders, set NTFS permissions, create new OWA and ECP virtual directories, and reconfigure the original OWA/ECP virtual directories to work as you want. Peesa cake. :)

Oh, - and this is very important - whenever you apply an Exchange cumulative update (CU) you need to completely undo everything you just did and reconfigure the settings all over again. Ugh. That's why I wrote the following PowerShell script to automate the process.

New-ExchangeWebsite.ps1 performs all the steps listed in the blog article in an automated fashion. If the script detects that an OWA_SECONDARY folder already exists, it removes that existing configuration before configuring the new website. Whenever you install the latest CU or replace the SSL certificate, all you need to do is run the script again with the proper parameters.

The goal of this script is to perform the exact same steps documented in the EHLO Blog post so you remain in a supported state. If Microsoft improves or changes these steps, I will update the script to match.

The script supports full PowerShell functionality just like a real cmdlet. For example, it supports Get-Help and -Verbose parameters.

Syntax:

New-ExchangeWebsite.ps1 [-NewWebsiteIP] <IPAddress> [-Thumbprint] <String> [[-DisableEacOnDefaultWebSite]<Boolean>] [[-DisableFbaOnDefaultWebSite] <Boolean>] [<CommonParameters>]

By default the script automatically disables Exchange Admin Center access and leaves Forms Based Authentication enabled on the Default Web Site.

-------------------------- EXAMPLE 1 --------------------------

PS C:\>New-ExchangeWebsite.ps1 -NewWebsiteIP 10.1.20.35 -Thumbprint 663F465DE17FD039979B8CE769118FA2A5AF157D

This command configures a new website named OWA_SECONDARY in IIS. It configures the website to use the IP address 10.1.20.35 and binds the SSL certificate with the specified thumbprint for HTTPS. It sets the necessary ACLs and copies all the required files and folders. Finally, it disables Exchange Admin Center access on the Default Web Site because that's the default setting and resets IIS.

-------------------------- EXAMPLE 2 --------------------------

PS C:\>New-ExchangeWebsite.ps1 -NewWebsiteIP 10.1.20.35 -Thumbprint 663F465DE17FD039979B8CE769118FA2A5AF157D -DisableFbaOnDefaultWebSite $true

This command is almost the same as the command in the previous example, except it also disables Forms Based Authentication on the Default Web Site.

-------------------------- EXAMPLE 3 --------------------------

PS C:\>New-ExchangeWebsite.ps1 -NewWebsiteIP 10.1.20.35 -Thumbprint 663F465DE17FD039979B8CE769118FA2A5AF157D -DisableFbaOnDefaultWebSite $true -DisableEacOnDefaultWebSite $false

This command is almost the same as the command in the previous example, except it does not disable Exchange Admin Center access on the Default Web Site.

Warning: Brain Must Be Engaged

Before you run the script, you must add a second IP address to the Exchange 2013 server and you must have a trusted SSL certificate installed with the correct FQDN for the new website (for example, eac.contoso.com or use a wildcard cert).

I wrote some basic error checking into the script. It must be run from EMS on an Exchange 2013 server, the IP address you specify must exist on the server and it must not be the only IP address, and the certificate thumbprint must be valid. If any of these conditions are not met, the script terminates. That said, you still need to be sure you specify the correct IP address for the new website and you must supply the correct SSL thumbprint (use the Get-ExchangeCertificate cmdlet for this).

If you decide to rename the folders or website after configuration all bets are off. Be smart, leave them alone.

You can download a ZIP copy of the script here. Comments? Questions? Leave them below.

Read more ...

How to Add Access to the Office 365 EOP Quarantine in Outlook and OWA

Exchange Online Protection (EOP) in Office 365 offers a quarantine feature for administrators and end-users. Administrators can view and release messages that were caught as spam for all users. End-users can view and release their own messages.

The administrative quarantine is accessed from the Office 365 Exchange Admin Center > Protection > Quarantine. Here you will see all the quarantined items for all users in the org.

Administrative Quarantine in the Office 365 Portal

The administrative quarantine is always available to EOP admins. The end user quarantine must be enabled and configured by the admin from Office 365 Exchange Admin Center > Protection > Content Filter, then click the Configure end-user spam notifications link on the right.

When enabled, end-users will receive an email from EOP listing all the new messages held in quarantine since the last notification.

The URL to the end-user quarantine is https://admin.protection.outlook.com/quarantine. In a hybrid scenario, even users without Office 365 licenses can access the end-user quarantine.

End-User Quarantine

That's all pretty cool, but wouldn't it be nice to access the quarantine directly from Outlook? Here's how you configure it:

• Open Outlook as the end-user.
• Right-click the user mailbox and select New Folder.

• Name the folder Quarantine or * Quarantine to have it placed higher in the folder list.
• Right-click the new folder and select Properties.
• Click the Home Page tab.
• Enter https://admin.protection.outlook.com/quarantine in the Address field and then click the checkbox for Show home page by default for this folder. Click OK.

• You will then see the sign on page for EOP within Outlook. After you sign in you can access your end-user archive.

End-User Quarantine within Outlook

Unfortunately you can't view the end-user quarantine using this method from OWA, but I have a work-around. 

• Send yourself an email with the subject of Quarantine and the link to https://admin.protection.outlook.com/quarantine in the body of the message.
• Drag the message from your Inbox to the Quarantine folder you created.

Now you have easy access to the end-user Quarantine from Outlook, OWA, and even mobile devices!

Read more ...