Photos, Exchange, And The File System

Posted on 1 CommentPosted in 2013, 2016, Exchange Server, Office 365, owa

On an Exchange 2013 and later server this is a folder called photos that gets created after installation and can contain a couple of user photos for some of your users. How does it get there and what does it contain?

The photos folder appears (on 2016 anyway) when the user uploads a photo (via OWA). Two images are created one 96square and the other 648square. They are made in a folder unique to the user and on the mailbox server that contains their active mailbox at the time of upload.

To reproduce this, login to OWA. Determine which server is currently the active server for that mailbox and then access the file system of that server. You are looking for “C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess” though it will be wherever Exchange Server was installed if not the C: drive. If anyone has uploaded photos already via this server then you will see a folder named photo. You can delete this folder without impact (unless someone is actively uploading a photo at that exact time).

In OWA, click the photo icon top right and then click Change:

image

image

Click Upload photo and select a photo. I’ve used the sample pictures that are installed on Windows 7 in this example:

image

At this point a copy of the photo is uploaded to a web service on Exchange Server. Click Save above your chosen photo. At this point the photo folder in the ClientAccess folder on the server that is active for your mailbox is created. Inside this folder you will see a subfolder called _domain.com-UNIQUEID. Inside this folder will be two subfolders called HR96x96 and HR648x648. Inside each of these will be the JPEG file that was created at the time of saving the upload. The size of each will match the folder name and the name of the file will be _Alias-UNIQUEID. If the user deletes their photo then a 0 byte JPEG file will be created in the folder.

Note that these two photos are not a cache of the photo for the Exchange Server to download to other users. They are just used during uploading the photos. Once uploaded they are resized using this file system location and then stored in their respective locations. The 96×96 photo (at less than 100Kb) is stored in the Active Directory and the 648×648 image is stored in the Exchange 2013 or later mailbox for use by Exchange, Skype for Business and SharePoint.

If there are policies and privacy laws that state the caching of images on the file system must be avoided, then you should be able to delete the photo upload cache at your convenience.

The photo folder does not appear on another server when viewing that user with a photo in their mailbox. Requesting the photo is done via owa/service.svc and not AFAIK from a file on the file system.

Deleting the folder after the fact did not impact my test users photo (as its now in the mailbox and not read from the file system). If this mailbox is later migrated to Office 365, then the photo will migrate with the mailbox as it is part of the mailbox. If the photo stored in AD is less than 100kb then it will be synced to Azure AD.

Managing Office 365 Groups With Remote PowerShell

Posted on 2 CommentsPosted in Azure, cloud, exchange, exchange online, groups, IAmMEC, mcm, mcsm, MVP, Office 365, owa, powershell

Announced during Microsoft Ignite 2015, there are now PowerShell administration cmdlets available for the administration of the Groups feature in Office 365.

The cmdlets are all based around “UnifedGroups”, for example Get-UnifiedGroups.

Create a Group

Use New-UnifiedGroup to do this. An example would be New-UnifiedGroup -DisplayName “Sales” -Alias sales –EmailAddress sales@contoso.com

The use of the EmailAddress parameter is useful as it allows you to set a group that is not given an email address based on your default domain, but from one of the other domains in your Office 365 tenant.

Modify a Groups Settings

Use Set-UnifiedGroup to change settings such as the ability to receive emails from outside the tenant (RequireSenderAuthenticationEnabled would be $false), limit email from a whitelist (AcceptMessagesOnlyFromSendersOrMembers) and other Exchange distribution list settings such as hidden from address lists, mail tips and the like. AutoSubscribeNewMembers can be used to tell the group to email all new messages to all new members, PrimarySmtpAddress to change the email address that the group sends from.

Remove a Group

This is the new Remove-UnifiedGroup cmdlet.

Add Members to a Group

This cmdlet is Add-UnifiedGroupLinks. For example Add-UnifiedGroupLinks sales -LinkType members -Links brian,nicolas will add the two names members to the group. The LinkType value can be members as shown, but also “owners” and “subscribers” to add group administrators (owners) or just those who receive email sent to the group but not access to the groups content. To change members to owners you do not need to remove the members, just run something like Add-UnifiedGroupLinks sales –LinkType owners -Links brian,nicolas

You can also pipe in a user list from, for example a CSV file, to populate a group. This would read: Add-UnifiedGroupLinks sales -LinkType members -Links $users where $users = Get-Content username.csv would be run before it to populate the $users variable. The source of the variable can be anything done in PowerShell.

Remove Members from a Group

For this use Remove-UnifiedGroupLinks and mention the group name, the LinkType (member, owner or subscriber) and the user or users to remove.

To Disable Group Creation in OWA

Set-OWAMailboxPolicy is used to create a policy that is not allowed to create Groups and then users have that policy applied to them. For example Set-OWAMailboxPolicy “Students” –GroupCreationEnabled $false followed by Set-CASMailbox mary –OWAMailboxPolicy Students to stop the user “mary” creating groups. After the policy is assigned and propagates around the Office 365 service, the user can join and leave groups, but not create them.

Control Group Naming

This feature allows you to control the group name or block words from being used. This is easier to set in the Distribution Groups settings in Exchange Control Panel rather than via PowerShell. To do this EAC use Recipients > Groups and click the ellipses icon (…) and select Configure Group Naming Policy. This is the same policy for distribution groups. You can add static text to the start or end of name, as well as dynamic text such as region.

Admins creating groups are not subject to this policy, but unlike DL’s if they create groups in PowerShell the policy is also not applied and so the -IgnoreNamingPolicy switch is not required.

Exchange OWA and Multi-Factor Authentication

Posted on 14 CommentsPosted in 2010, 2013, Azure, exchange, IAmMEC, MFA, MVP, owa, smartphone

Multi-factor authentication (MFA), that is the need to have a username, password and something else to pass authentication is possible with on-premises servers using a service from Windows Azure and the Multi-Factor Authentication Server (an on-premises piece of software).

The Multi-Factor Authentication Server intercepts login request to OWA, if the request is valid (that is the username and password work) then the mobile phone of the user is called or texted (or an app starts automatically on the phone) and the user validates their login. This is typically done by pressing # (if a phone call) or clicking Verify in the app, but can require the entry of a PIN as well. Note that when the MFA server intercepts the login request in OWA, there is no user interface in OWA to tell you what is happening. This can result in user disconnect and stops the use of two-way MFA (receive number by text, type number into web application type scenario). Therefore to that end, MFA directly on the OWA application is not supported by the Microsoft Exchange team. Steps for setting up ADFS for Exchange Server 2013 SP1 or later are at https://technet.microsoft.com/en-us/library/dn635116(v=exchg.150).aspx. Once this is in place, you need to enable MFA for ADFS rather than MFA for OWA. I have covered this in a separate post at http://c7solutions.com/2016/04/installing-azure-multi-factor-authentication-and-adfs.

To configure Multi-Factor Authentication Server for OWA (unsupported) you need to complete the following steps:

Some of these steps are the same regardless of which service you are adding MFA to and some slightly different. I wrote a blog on MFA and VPN at http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication and this contains the general setup steps and so these are not repeated here. Just what you need to do differently

Step 1

See http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication

Step 2: Install MFA Server on-premises

This is covered in http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication, but the difference with OWA is that it needs to be installed on the Exchange CAS server where the authentication takes place.

Ensure you have .NET 3.5 installed via Server Manager > Features. This will install the .NET 2.0 feature that is required by MFA server. If the installation of the download fails, this is the most likely reason for the failure, so install .NET 3.5 and then try the MFA Server install again.

The install of the MFA server does not take very long. After a few minutes the install will complete and then you need to run the Multi-Factor Authentication Server admin tools. These are on the Start Screen in More Apps or the Start Menu. Note that it will start the software itself if given time:

image

image

Do not skip the wizard, but click Next. You will be asked to activate the server. Activating the server is linking it to your Azure MFA instance. The email address and password you need are obtained from the Azure multi-factor auth provider that was configured in Step 1. Click the Generate Activation Credentials on the Downloads page of the Azure MFA provider auth management page.

image

The credentials are valid for ten minutes, so your will differ from mine. Enter them into the MFA Server configuration wizard and click Next.

MFA Server will attempt to reach Azure over TCP 443.

Select the group of servers that the configuration should replicate around. For example, if you where installing this software on each Exchange CAS server, then you might enter “Exchange Servers” as the group name in the first install and then select it during the install on the remaining servers. This config will be shared amongst all servers with the same group name. If you already have a config set up with users in it and set up a new group here, then it will be different settings for the users. For example you might have a phone call to authenticate a VPN connection but use the app for OWA logins. This would require two configs and different groups of servers. If you want the same settings for all users in the entire company, then one group (the default group) should be configured.

image

Next choose if you want to replicate your settings. If you have more than one MFA Server instance in the same group select yes.

Then choose what you want to authenticate. Here I have chosen OWA:

image

Then I need to choose the type of authentication I have in place. In my OWA installation I am using the default of Forms Based Authentication, but if you select Forms-based authentication here, the example URL for forms based authentication shown on the next page is from Exchange Server 2003 (not 2007 or later). Therefore I select HTTP authentication

Next I need to provide the URL to OWA. I can get this by browsing the OWA site over https. The MFA install will also use HTTPS, so you will need a certificate and have this trusted by a third party if you want to support user managed devices. Users managing their own MFA settings (such as telephone numbers and form of authentication) reduces the support requirement. That needs the User Portal, the SDK and the Mobile App webservice installed as well. These are outside the scope of this blog. For here I am going to use https://servername/owa.

image

Finish the installation at this time and wait for the admin application to appear.

Step 3: Configure Users for MFA

Here we need to import the users who will be authenticated with MFA. Select the Users area and click Import from Active Directory. Browse the settings to imports group members, or OUs or a search to add your user account. Once you have it working for yourself, add others. Users not listed here will not see any change in their authentication method.

Ensure that your test user has a mobile number imported from the Active Directory. If not add one, choosing the correct country code as well. The default authentication for the user is that they will get a phone call to this number and need to press # before they can be logged in. Ensure that the user is set to Enabled as well in the users area of the management program.

Step 4: Configure OWA for MFA (additional steps)

On the IIS Authentication node you can adjust the default configuration for HTTP. Here you need to set Require Multi-Factor Authentication user match. This ensures that each auth attempt is matched to a user in the users list. If the user exists and is enabled, then do MFA for them. If disabled, then the setting for Succeed Authentication on the advanced tab comes into play. If the user is not listed, authentication passes through without MFA.

image

Change to the Native Module tab and select OWA under Default Web Site only. Do not set authentication on the Backend Web Site. Also enable the native module on ECP on the Default Web Site as well:

image

Then I can attempt a login to OWA or ECP. Once I successfully authenticate my phone rings and I am prompted to press #. Once I press # I am allowed into Exchange!

Group Policy Import To Fix Google Chrome v37 Issues With Exchange Server and Microsoft CRM

Posted on 2 CommentsPosted in 2010, 2013, Chrome, crm, Dynamics, exchange, exchange online, Group Policy, IAmMEC, Office 365, owa

A recent update to Google Chrome (37.0.2062.120) removed the ability to support modal dialog boxes. This are dialogs that require your attention and stop you going back to the previous page until you have completed the info required – these are very useful in workflow type scenarios.

Google claim that as 0.004% of web sites use them (from Google anonymous statistics gathering that you can opt into in Chrome) they are justified in removing support for them – but they have not removed other things that have the same level of support!

With this version of Chrome (or the Chromium open source browser) there is a work around until April 30th 2015 that will allow modal dialogs to work again. Without this work around clicking links in OWA and ECP in Exchange 2010 and OWA and EAC in Exchange Online and Exchange 2013 will not popup. This can cause issues such as the inability to attach files in OWA and to create objects in ECP/EAC for the administrator. Popups in Microsoft CRM also do not work.

As a work around you could use a different browser, but if Chrome works for you (or does not in this case) and you are joined to a domain then you can download the following GPO export file and import it into your Active Directory to enable modal dialogs to work again in Exchange Server, Office 365 and Microsoft CRM products.

To download and import this GPO file to enable Chrome modal dialog box functionality to resume (until 30th April 2015, when Google stop allowing the work around) follow these steps:

  1. Download Google Chrome Show Modal Dialog Before 30 April 2015.zip
  2. Copy to a domain controller and expand the zip file. Ensure the contents of the zip file are not placed directly on your desktop as you cannot import from the desktop directly, so if you expand the zip to the desktop then copy the one folder that was created into a new subfolder.
  3. Start Group Policy Management MMC admin tool.
  4. Expand Forest > Domain > Your Domain > Group Policy Objects.
  5. Right click “Group Policy Objects” and choose New
  6. Create a new GPO called “Chrome and Chromium Modal Dialog Box Allow”:
    image
  7. Right click “Chrome and Chromium Modal Dialog Box Allow” GPO that you just made and choose Import Settings
  8. Proceed through the import wizard. You do not need to backup this new GPO on the second page of the dialog as the new GPO is empty.
  9. On the third page of the wizard browse to the parent folder containing the contents of the download above:
    image
  10. Click Next and you should see one backed up GPO listed:
    image
  11. Click Next to import this. If you click View Settings first a web page will open showing you that this GPO sets two registry keys for the computer and two registry keys for the user. These set SOFTWARE\Policies\Chromium\EnableDeprecatedWebPlatformFeatures and Software\Policies\Google\Chrome\EnableDeprecatedWebPlatformFeatures (for both Chromium and Chrome browsers) with a reg key (type string) 1:ShowModalDialog_EffectiveUntil20150430
  12. Proceed with Next and then Finish and the import will begin:
    image
  13. Click OK.
  14. Now link the GPO object to the root of your domain so it impacts all users and to the root of any OU that blocks inheritance. Import to other domains as above or link from this domain depending upon your current policy for managing GPO cross domains.
  15. Delete the zip and folder you downloaded. They are not needed any more.

Enabling Exchange 2013 to Filter OneNote and Publisher Files

Posted on 1 CommentPosted in 2013, 64 bit, exchange, IFilter, owa, transport

Exchange Server 2013 includes the Search Foundation product to index and search most of the file types that needed IFilters installed for in previous versions including PDF files, so the Adobe IFilter is no longer needed. That said, it does not filter OneNote and Microsoft Publisher files.

To filter these files so that you can search them as part of your mailbox search, include them in discovery and compliance searches and to write transport rules that can act on the contents of these files you need to install the Microsoft Office Filter Pack 2010 and Service Pack 1 for Microsoft Office Filter Pack 2010 (KB 2460041) 64-bit Edition and then, once installed, set a few registry keys. The following script does the registry key steps for you, and needs running on all your Exchange 2013 Mailbox Servers. See http://marksmith.netrends.com/Lists/Posts/Post.aspx?ID=93 for steps to install the PDF filter on Exchange 2010 if you need to do that. This script is based on the work in that post and the original scripts from Microsoft to configure the IFilters in Exchange 2010 RTM.

Script for Install-IFilters.ps1

Download the Install-IFilters.ps1 here (which is a zip containing some test files as well – see below for testing steps. The PowerShell script is also shown below:

   1: # Script to enable indexing of OneNote and Microsoft Publisher filtering in Exchange 2013

   2: # Written by Brian Reid, C7 Solutions Ltd. www.c7solutions.com 14:27 21/11/2012

   3: # Based on a script by Mark Smith from Capex Global that installed PDF filtering for Exch2010

   4: # Note PDF filtering is included in Exchange 2013 and not needed as an extra install

   5:

   6: # The Microsoft Office 2010 Filter Pack needs installing before running this script: http://www.microsoft.com/en-us/download/details.aspx?id=17062

   7: # The Microsoft Office 2010 Filter Pack SP1 (x64) needs installing before running this script: http://www.microsoft.com/en-us/download/details.aspx?id=26604

   8: # This script has not been tested with the Microsoft Office Filter Pack 2013 release as it was not available at time of writing

   9:

  10: # This script will restart the Transport service and Microsoft Filtering Management Service. Mail-flow might be affected

  11: # by the first of these restarts. Existing items in the store will not be indexed

  12:

  13: $iFilterDirName = "C:\Program Files\Common Files\Microsoft Shared\Filters\"

  14:

  15: $KeyParent = "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\HubTransportRole"

  16: $CLSIDKey = "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\HubTransportRole\CLSID"

  17: $FiltersKey = "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\HubTransportRole\filters"

  18:

  19: # Filter DLL Locations

  20: $ONEFilterLocation = $iFilterDirName + "\ONIFilter.dll"

  21: $PUBFilterLocation = $iFilterDirName + "\PUBFILT.dll"

  22:

  23: # Filter GUIDs

  24: $ONEGuid    ="{B8D12492-CE0F-40AD-83EA-099A03D493F1}"

  25: $PUBGuid    ="{A7FD8AC9-7ABF-46FC-B70B-6A5E5EC9859A}"

  26:

  27:

  28: # Create CLSID and filters root registry keys if they do not exist

  29: Write-Host -foregroundcolor Green "Creating parent registry keys"

  30:

  31: New-Item -Path $KeyParent -Name CLSID -ErrorAction SilentlyContinue | Out-Null

  32: New-Item -Path $KeyParent -Name filters -ErrorAction SilentlyContinue | Out-Null

  33:

  34:

  35: # Create CLSIDs

  36: Write-Host -foregroundcolor Green "Creating CLSIDs..."

  37:

  38: New-Item -Path $CLSIDKey -Name $ONEGuid -Value $ONEFilterLocation -Type String | Out-Null

  39: New-Item -Path $CLSIDKey -Name $PUBGuid -Value $PUBFilterLocation -Type String | Out-Null

  40:

  41: # Set Threading model

  42: Write-Host -foregroundcolor Green "Setting threading model..."

  43:

  44: New-ItemProperty -Path "$CLSIDKey\$ONEGuid" -Name "ThreadingModel" -Value "Both" -Type String | Out-Null

  45: New-ItemProperty -Path "$CLSIDKey\$PUBGuid" -Name "ThreadingModel" -Value "Both" -Type String | Out-Null

  46:

  47: # Set Flags

  48: Write-Host -foregroundcolor Green "Setting Flags..."

  49: New-ItemProperty -Path "$CLSIDKey\$ONEGuid" -Name "Flags" -Value "1" -Type Dword | Out-Null

  50: New-ItemProperty -Path "$CLSIDKey\$PUBGuid" -Name "Flags" -Value "1" -Type Dword | Out-Null

  51:

  52: # Create Filter Entries

  53: Write-Host -foregroundcolor Green "Creating Filter Entries..."

  54:

  55: New-Item -Path $FiltersKey -Name ".one" -Value $ONEGuid -Type String | Out-Null

  56: New-Item -Path $FiltersKey -Name ".pub" -Value $PUBGuid -Type String | Out-Null

  57:

  58: # Setting permissions

  59: Write-Host -foregroundcolor Green "Granting NETWORK SERVICE read access to $KeyParent and child keys "

  60: $acl = Get-Acl $KeyParent

  61: $rule = New-Object System.Security.AccessControl.RegistryAccessRule ("NETWORK SERVICE","ReadKey","Allow")

  62: $acl.SetAccessRule($rule)

  63: $acl | Set-Acl -Path $KeyParent

  64:

  65: # Restarting required services

  66: Write-Host -foregroundcolor Green "Stopping Microsoft Exchange Transport service (this takes a few minutes)"

  67: Stop-Service "Microsoft Exchange Transport" | Out-Null

  68: Write-Host -foregroundcolor Green "Stopping Microsoft Filtering Management Service"

  69: Stop-Service "Microsoft Filtering Management Service" | Out-Null

  70: Write-Host -foregroundcolor Green "Starting Microsoft Exchange Transport service (this takes a few minutes)"

  71: Start-Service "Microsoft Exchange Transport" | Out-Null

  72: Write-Host -foregroundcolor Green "Starting Microsoft Filtering Management Service"

  73: Start-Service "Microsoft Filtering Management Service" | Out-Null

Testing Attachment Filtering

The download above contains the script and some test files for different document types. To test just create a transport rule where:

    • The sender is your mailbox.
  • Any attachment’s content includes “Testing IFilters”. (the files in the download include these words)

 

  • Generate an incident report and send it to your mailbox. Incident Reports are advanced transport rule actions.

 

If you create this rule before you run the script then you will get incident reports for the TXT file, DOCX file and the PDF file (note, you did not need to install the Adobe IFilter to get this functionality). But sending the ONE file and the PUB file before running the above script, even though you have the Microsoft Filter Pack installed, will not generate an incident report.

Once you have run the script, email yourself the ONE and PUB files and both should generate an incident report. From now on trasnport rules will process OneNote and Microsoft Publisher documents correctly, including any that match any Data Loss Prevention rules that you have enabled.

Installing and Configuring AD RMS and Exchange Server

Posted on 2 CommentsPosted in 2007, 2008 R2, 2010, active directory, certificates, exchange, exchange online, microsoft, networking, Office 365, organization relationships, owa, rms, server administrator

Earlier this week at the Microsoft Exchange Conference (MEC 2012) I led a session titled Configuring Rights Management Server for Office 365 and Exchange On-Premises [E14.314]. This blog shows three videos covering installation, configuration and integration of RMS with Exchange 2010 and Office 365. For Exchange 2013, the steps are mostly identical.

Installing AD RMS

This video looks at the steps to install AD RMS. For the purposes of the demonstration, this is a single server lab deployment running Windows Server 2008 R2, Exchange Server 2010 (Mailbox, CAS and Hub roles) and is the domain controller for the domain. As it is a domain controller, a few of the install steps are slightly different (those that are to do with user accounts) and these changes are pointed out in the video, as the recommendation is to install AD RMS on its own server or set of servers behind a IP load balancer.

Configuring AD RMS for Exchange 2010

The second video looks at the configuration of AD RMS for use in Exchange. For the purposes of the demonstration, this is a single server lab deployment running Windows Server 2008 R2, Exchange Server 2010 (Mailbox, CAS and Hub roles) and is the domain controller for the domain. This video looks at the default ‘Do Not Forward’ restriction as well as creating new templates for use in Exchange Server (OWA and Transport Rules) and then publishing these templates so they can be used in Outlook and other Microsoft Office products.

 

Integrating AD RMS with Office 365

The third video looks at the steps needed to ensure that your Office 365 mailboxes can use the RMS server on premises. The steps include exporting and importing the Trusted Publishing Domain (the TPD) and then marking the templates as distributed (i.e. available for use). The video finishes with a demo of the templates in action.

Creating GeoDNS with Amazon Route 53 DNS

Posted on 3 CommentsPosted in 2013, cloud, exchange, GeoDNS, https, load balancer, mcm, microsoft, MX, networking, owa, smtp, transport

UPDATE: 13 Aug 2014 – Amazon Route 53 now does native GeoDNS within the product – see Amazon Route 53 GeoDNS Routing Policy

A new feature to Exchange 2013 is supported use of a single namespace for your global email infrastructure. For example mail.contoso.com rather than different ones for each region such as uk-mail.contoso.com; usa-mail.contoso.com and apac-mail.contoso.com.
GeoDNS means that you are given the IP address of a server that is in or close to the region that you are in. For example if you work in London and your mailbox is also in London then most of the time you will want to be connected to the London CAS servers as that gives you the best network response. So in Exchange 2010 you would use your local URL of uk-mail.contoso.com and if you used the others you would be told to use uk-mail.contoso.com. For GeoDNS support you use mail.contoso.com and as you are in the UK you get the IP address of the CAS array in London. When you travel to the US (occasionally) you would get the US CAS array IP address, but this CAS array is able to proxy your OWA, RPC/HTTP etc traffic to the UK mailbox servers.
The same is true for email delivery via SMTP. Email that comes from UK sourced IP addresses is on balance a statistical likelihood that it is going to the UK mailbox. So when you look up the MX record for contoso.com from a UK company you get the UK CAS array and the email gets delivered to the CAS array that is in the same site as the target mailbox. If the email is for a user in a different region and it hits the UK CAS array then it is proxied to the other region seamlessly.
GeoDNS is a feature provided by some high-scale DNS providers, but not something Amazon Web Services (AWS) Route 53 provides – so how do I configure GeoDNS with Amazon Web Services (AWS) Route 53 DNS Service?
Quite easily is the answer. Route 53 does not offer GeoDNS but does offer DNS that directs you towards the closest AWS datacentre. If your datacentres are in regions similar to AWS then the DNS redirection that AWS offers is probably accurate.
To set it up, open your Route 53 DNS console, or move your DNS to AWS (it costs $0.50/month for a zone at time of writing, AWS Route 53 pricing here) and then create your global Exchange 2013 namespace record in DNS:

  1. Click Create Record Set and enter the name. In the below example I’m using geo.c7solutions.com as I don’t actually have a globally distributed email infrastructure!
  2. Select A – IPv4 or if you are doing IPv6 select AAAA.
  3. Set Alias to No and enter the IP address of one of your datacentres
  4. Select the AWS region that is closest to this Exchange server(s) and enter a unique description for the Set ID value.
  5. The entry will look something like this:
    image
  6. Save the Record Set and create additional entries for other regions. For the purposes of this blog I have created geo.c7solutions.com in four regions with the following IP addresses:
    Region IP Address Region
    us-east-1 1.2.3.4 Northern Virginia
    us-west-1 6.7.8.9 Northern California
    eu-west-1 2.3.4.5 Ireland
    ap-northwest-1 3.4.5.6 Singapore
    sa-east-1 4.5.6.7 Sao Paulo
    ap-southeast-1 5.6.7.8 Sydney
  7. The configuration in AWS for the remaining entries looks like the following:
    imageimageimage
  8. And also, once created, it appears like this:
    image

In addition to this blog, I’ve left the record described above on my c7solutions.com DNS zone. So depending upon your location in the world, if you open a command prompt and ping geo.c7solutions.com you should get back the IP address for the AWS region closest to you, and so get back an IP that represents a Exchange resource in your global region. Of course the IP’s I have used are not mine to use and probably will not respond to ping requests – but all you need to do is see it DNS returns the IP above that best matches the region that you are in.
I wrote this blog when in a hotel in Orlando and as you can see from the image below, it returns 1.2.3.4 which is the IP address associated with us-east-1.
image
But when I connected to a server in the UK and did the same ping geo.c7solutions.com I got the following, which show GeoDNS working when equating GeoDNS to AWS Latency DNS.
image
What do you get for your regions? Add comments and let us where you are (approximately) and what region you got. If enough people respond from enough places we can see if AWS can go GeoDNS without massive cost.
[Updated 13 Nov 2012] Added Sydney (ap-southeast-1) and fake IP address of 5.6.7.8
[Updated 27 April 2013] Added Northern California (us-west-1) and fake IP of 6.7.8.9

HTTPS Load Balancer Issues with Exchange 2010 SP2

Posted on 4 CommentsPosted in 2010, citrix, exchange, https, load balancer, loadbalancer, Netscaler, networking, owa, update, upgrade

When you install Service Pack 2 (and maybe SP1 too) on Exchange 2010 it resets the SSL flag on the root directory of the IIS website. You might have removed this setting for a number of reasons, mainly to do with having a HTTP to HTTPS redirect, but it can also be removed if you are doing SSL Offloading to a load balancer and that load balancer checks the state of the client access server by doing HTTP requests for the root home page. The Citrix Netscaler is one such load balancer that has this as a default setting.

The configuration documentation for the Citrix Netscaler (found here) does not discuss changing the load balancer to use a different directory on IIS to monitor the availability of the site, so when you install SP2 for Exchange 2010 and that update resets the root directory to require SSL, your load balancer thinks the site is offline and does not pass through any traffic!

image

image

To fix this issue in the short term, just uncheck the Require SSL option on the root of the Default Web Site on each of your Client Access Servers. Your load balancer should notice within a few seconds and service will resume, for example the Citrix Netscaler checks the root directory via the monitor properties every five seconds for a HTTP success code (and not a HTTPS success code!).

To fix this issue in the long term you should make a new virtual directory on each server covered by the load balancer and get the load balancer to look at this directory to determine if the service is up or down rather than looking at the root directory. Your virtual directory will not be reconfigured by future Exchange service packs (or indeed any other application that you are load balancing that might reset the SSL option on the root directory).

To complete these steps do the following:

1. Create a folder in the inetpub directory called “monitor” or similar (in the examples below the folder is called “netscaler_monitor”).

2. Place an index.htm file in this folder that is a very simple webpage that when browsed returns the page. If you want to make the page more complex to include code (so that issues with the code are picked up by the load balancer then this is fine). A simple page would look like the following:

<html><head>
<title>Netscaler Monitor for Exchange 2010title>
head><body>
<p>This page returns a success code to the netscalers if IIS is running. This page must always work over HTTP and never require an SSL connection.p>
body>html>

3. In IIS require SSL and then uncheck require SSL – this forces a setting into the IIS config file (applicationHost.config) that says that this folder must always be over HTTP and not require SSL. If you do not do this then this folder will take the setting from the parent folder, and as we have already seen, this will cause the monitor folder to require SSL when you apply the service pack.

This SSL change will result in the following configuration at the bottom of applicationHost.config, which can be added directly to the config file rather than in IIS Manager.

    <location path="Default Web Site/netscaler_monitor">
<system.webServer>
<security>
<access sslFlags="None" />
security>
system.webServer>
location>
configuration>

4. Update your load balancer so that it has a new monitor for checking the service state on the managed machine. This monitor would be something like the following for a Citrix Netscaler, each load balancer being different. This monitor checks HEAD /netscaler_monitor/ and expects to get back a 200 status code. You need to change the folder name to match, but ensure the / is before and after the folder name.

image

5. Change the configuration for each client access server in the load balancer so that it uses the new monitor rather than the default HTTP monitor.

image

6. Save your changes to the load balancer. The next time you service pack Exchange 2010 the resetting of the SSL flag on the root directory will not cause you any issues.

OWA and Moving Mailboxes to Office 365

Posted on Leave a commentPosted in 2010, ADFS, ADFS 2.0, certificates, exchange, exchange online, federation, Office 365, organization relationships, owa, powershell

Lets imagine a scenario where you are using an on-premises Exchange Server and users’ use Outlook Web App, and then you move some mailboxes to the Office 365 cloud with Hybrid Coexistence enabled. The user might not know their mailbox has been moved and so yesterday they went to https://mail.company.com/owa, but today they need to visit https://outlook.com/owa/company.com (where company.com is the domain name in your login name).
But becuase the user does not know that their mailbox has been moved when they visit https://mail.company.com/owa they get an error that their OWA URL is out of date.
To fix this, and provide the user with the correct URL (https://outlook.com/owa/company.com) then you need to set the TargetOwaURL property of the Organization Relationship that you have configured for your Office 365 service domain.

Set-OrganizationRelationship name -TargetOwaURL https://outlook.com/owa/company.com

Now when users login with an account that has been moved to the cloud they will be told that their mailbox has moved, and that they should visit https://outlook.com/owa/company.com.
Some organizations though have an issue with this URL – it does not mention the company name in the domain name bit, and a name such as http://webmail.company.com/owa would be preferred for mailboxes moved to the cloud. To present the user with this URL after they login to on-premises OWA or for a URL that you can just tell them to use you need to do two things:

  1. Create a CNAME record in DNS for webmail that has outlook.com as the target FQDN. The CNAME record can be anything that is not already in use for the domain (for example it could be mail if that is not in use).
  2. The TargetOwaURL property of the Organization Relationship needs to be http://webmail.company.com/owa. The TargetOwaURL must finish with /owa or the on-premises OWA redirect page will error and the domain name used must be the domain name in your login name.

The outlook.com server will take the CNAME value provided by the browser and do realm discovery on this name – that is it will redirect you to the correct login server for your domain.