MEC is THE conference for all things Exchange and Exchange Online. Last year’s MEC in Orlando, Florida was a triumphant return after a 10 year hiatus. It was a week-long celebration of Exchange, with lots of deep dive sessions on Exchange and Office 365. MEC 2014 promises to be of equal quality in a fantastic city, Austin! I can taste the BBQ now…
Join me for an onslaught of awesome at MEC 2014!
Active Directory is directory service based on X.500 directory services, which has been around since the 1980s. Lightweight Directory Access Protocol (LDAP) is an application protocol created to query X.500 directory services, and it still functions today as a method to query Active Directory.
A lot of the attributes that are found in Active Directory were carried over from X.500 directory services (for example, commonName
, and photo
), but some were not. I particularly lament the fact that AD did not implement the favouriteDrink
Active Directory’s schema includes some “new” attributes that did not exist in the X.500 implementation. For example, AD added the jpegPhoto and thumbnailPhoto attributes in addition to the photo attribute. All of this begs the question, “What’s the difference and how do Microsoft products use them?”
- thumbnailPhoto is single valued, stores the photo using the JPEG File Interchange Format, and has a upper-Range of 102,400 bytes (100 KB).
- jpegPhoto is multivalued, stores photos using the JPEG File Interchange Format, and doesn’t enforce an upper-Range.
- photo is multivalued, stores photos encoded in G3 fax format, and doesn’t enforce an upper-Range.
If you upload a photo to Exchange 2013, does that write back
to thumbnailPhoto in AD? Yes, see same articles for more detail.
Does the “photo” attribute in AD get used at all? Ever? Not by Exchange, Lync or SharePoint. The fact that it uses G3 fax encoding (do any of you kids even know what a G3 fax is?) makes it pretty much useless for modern day computing needs, but who knows what the NSA is doing with it.
Thanks to my colleague and fellow Lync MCM, Greyson Mitchem, for the great questions and blog suggestion.
Some customers may want to only publish Outlook Web App for internal users. The following configuration will allow OWA and Exchange Control Panel (ECP) access for internal users on the corporate network, but block external access from the Internet. Users who connect to the corporate VPN (for example, DirectAccess, AnyConnect, or most any other VPN) from the Internet will also have access.
Blocking OWA externally does not affect ActiveSync or EWS clients. External Outlook Anywhere clients may be unable to manage their voicemail settings if they use Exchange Unified Messaging, since this relies on OWA.
These settings work for both Exchange 2010 and Exchange 2013. Let’s get started.
- Provide the CAS with an additional private IP address. You can either add this additional IP to the existing NIC or add another NIC to the server. If you chose to add another NIC, configure the IP address and subnet, but do not configure a default gateway. In this example, I will just add another IP address [192.168.1.31] to the existing NIC [192.168.1.30].
- If you have a load balanced set of CAS servers, you will need to create a new VIP on the load balancer to load balance the new CAS IP addresses. Do not publish this VIP or IP address to your reverse proxy solution (TMG/ISA) or NAT it to a public IP address.
- Create a new A record in your internal DNS, for example owa.contoso.com, that points to the new VIP or IP address on your single CAS server. You should be able to ping owa.contoso.com. Do not publish this A record in your external DNS.
- Create a new website in Internet Information Services (IIS) Manager called “Internal OWA-ECP”. Enter the IP address of the VIP on the hardware load balancer or the new IP address of your single client access server. Configure the new website’s binding to use HTTPS and the correct SSL certificate, as shown in the example below:
- Create new Exchange OWA and ECP virtual directories using the following cmdlets from the Exchange Management Shell (EMS):
New-OwaVirtualDirectory -WebSiteName “Internal OWA-ECP” -InternalUrl https://owa.contoso.com/OWA -ExternalURL $Null
New-EcpVirtualDirectory -WebSiteName “Internal OWA-ECP” -InternalUrl https://owa.contoso.com/ECP -ExternalURL $Null
Remove-OwaVirtualDirectory “servername\owa (Default Web Site)” -confirm:$false
Remove-EcpVirtualDirectory “servername\ecp (Default Web Site)” -confirm:$false
- At this point internal users can access OWA and ECP, but external users cannot. External users will get a 404 – Page cannot be found error when trying to access OWA from the Internet using either https://mail.contoso.com/owa or https://owa.contoso.com/owa.
- You may also want to create a custom error page for your external users instead of a non-friendly “404 – File or directory not found.” error message when trying to access OWA.
- Create a custom web page called NoExternalOWA.htm with the error detail you want and copy this file to the %systemdrive%\inetpub\wwwroot folder. An example might say, “Outlook Web App is only available for internal clients. Please connect using VPN or connect to the local network.“
- In IIS Manager, select the Default Web Site and double-click Error Pages.
- Double-click the 404 error and configure it to Respond with a 302 redirect to https://,<your CAS FQDN>/NoExternalOWA.htm.
It’s important to note that OWA and ECP are tightly integrated. You won’t be able to logon to ECP without publishing OWA in the same website. If you remove only the ECP virtual directory from the Default Web Site OWA users will not be able to access their mailbox options, such as out of office settings from the Internet. I mention this because some organizations may want to try to block ECP from the Internet to prevent access to the Exchange Admin Console (which uses ECP).