Tag Archives: Exchange

Exchange

Password Reset Tool and TMG

Leave a comment

In Exchange Server 2010 SP1 there’s the password reset tool, a tool you can use when a user’s password has expired, or when the administrator has reset a password and checked the user must change password at next logon option.

The password reset tool can be set with a registry key:

  1. Login to the CAS Server;
  2. Open the Registry Editor and navigate to HLKM\SYSTEM\CurrentControlSet\services\MSExchange OWA
  3. Create a new DWORD (32-bits) and name it ChangeExpiredPasswordEnabled
  4. Give this DWORD a value 1
  5. Restart the Internet Information Server using IISRESET

When you logon to the Client Access Server (with Forms Based Authentication) after a password reset the following form is presented:

image

Using the password reset tool from the Internet when published using TMG2010 is a different story. By default this is not working so some changes have to be made to the TMG’s web listener. Logon to the TMG Server and select the appropriate web listener. Select the Forms tab and check the Use customized HTML forms instead of the default. The custom HTML form set directory must be set to forms, this is the directory on the CAS server where forms are stored. Also check the Allow users to change their passwords option.

image

Now when a user’s password is reset with the user must change password at next logon option the password can be changed via TMG.

Exchange

File Share Witness (FSW) on non-Exchange Server

Leave a comment

Microsoft is shifting focus on Load Balancing solutions. During TechEd 2010 in Berlin it was announced that Windows Network Load Balancing (NLB) is no longer recommended (but still supported) and that the recommendation will be to use a hardware load balancer.

Another new recommendation is to use combined Exchange server with all three Server Roles, i.e. Hub Transport, Client Access and Mailbox Server Role when possible.

When using a Database Availability Group (DAG) you have to use a server outside the DAG as a File Share Witness (FSW). Normally an Exchange 2010 Hub Transport Server is recommended for FSW usage, but when using a two node DAG each with three Server roles an additional Hub Transport Server might not be available.

Continue reading File Share Witness (FSW) on non-Exchange Server →

Exchange

Autodiscover Redirect & SRV Record

5 Comments

When you have multiple primary SMTP domains in your Exchange 2010 environment you have to come up with a solution for autodiscover. Suppose we have an Exchange 2010 environment called exchange14.nl. The external URL would be something like webmail.exchange14.nl and the autodiscover FQDN would be autodiscover.exchange14.nl. In this you would need a UC certificate with both these names in it.

image

When there’s another (primary) SMTP domain in use in this Exchange 2010 environment we have to come up with something for the corresponding autodiscover record. When the SMTP domain called inframan.nl is also hosted in this environment, Outlook would look for a DNS record autodiscover.inframan.nl when Active Directory is not available, like on the Internet. Since this FQDN is not available in the SAN field of the certificate this would generate a client side certificate error, like “The name of the security certificate is invalid or does not match the name of the site.”

To avoid this there are two options that let Outlook redirect its autodiscover traffic. The first option is to use an HTTP redirection method; the second option is to use SRV records in the public DNS.

HTTP Redirection

When Outlook cannot find its corresponding autodiscover record, like autodiscover.inframan.nl in this example, Outlook will start looking for a redirection option. You can create an additional website in the Client Access Server that listens on port 80, intercepts redirection traffic and sends it to the original autodiscover URL. This 2nd website has an additional FQDN, using an additional IP address. For example, for autodiscover.exchange14.nl and webmail.exchange14.nl the IP address 178.251.192.9 is used. The 2nd website will be autodiscoverredirect.exchange14.nl and its IP address will be 178.251.192.12. Do not forget to add this FQDN and IP address to the public DNS!

On the Client Access Server open the Internet Information Server (IIS) Manager and create an additional website called autodiscoverredirect. Use a physical directory like c:\inetpub\autodiscoverredirect for this website and bind the website to the additional IP address.

image

In this website create a new Virtual Directory called autodiscover. Use Autodiscover for the alias and use a physical directory like c:\inetpub\autodiscoverredirect\autodiscover for this Virtual Directory.

image

Open the properties of the new Vdir and configure HTTP Redirect. Select the Redirect requests to this destination and enter https://autodiscover.exchange14.nl/autodiscover as the destination of the redirect.

image

The last step is to configure external DNS. Create a DNS entry for autodiscover.inframan.nl, but instead of assigning it an IP address create a CNAME record and point it to autodiscoverredirect.exchange14.nl

image

When testing with the Remote Connectivity Analyzer (http://www.testexchangeconnectivity.com) with a username called John Doe (john@inframan.nl) you’ll see the the autodiscover request originally destined for autodiscover.inframan.nl is redirected to autodiscover.exchange14.nl and the correct results are returned.

image

SRV Records in DNS

Instead of using the HTTP redirect option as described earlier it is also possible to use service records (SRV records) in the public DNS to access the autodiscover virtual directory when using another primary SMTP address.

Looking at the test environment there’s still a UC certificate on the Client Access Server with the FQDN’s webmail.exchange14.nl and autodiscover.exchange14.nl.

But instead of using an additional autodiscover entry in the SAN field of the certificate or creating an additional autodiscover redirect website it is also possible to use a service record. In this scenario, a service record in for inframan.nl needs to be created, pointing to the autodiscover FQDN for the original domain. This service record will be _autodiscover._tcp.inframan.nl and it points to autodiscover.exchange14.nl on port 443.

Entering the SRV record in public DNS can be a bit difficult, depending on the hosting provider you are using. In my case it is something like this:

image

When using NSLOOKUP (on the client) to check the SRV entry you’ll see that it looks good:

image

Now when checking with the Remote Connectivity Analyzer (www.testexchangeconnectivity.com) you’ll see that the autodiscover redirect options fails, but that the SRV option succeeds:

image

It is even more interesting, instead of using the autodiscover.exchange14.nl it is now possible to use the webmail.exchange14.nl FQDN in the SRV record. This way autodiscover no longer uses the autodiscover.exchange14.nl entry and it is now possible to use a standard SSL certificate and NOT a Unified Communications certificate. This standard certificate only contains the name webmail.exchange14.nl.

image

And testing with the Remote Connectivity Analyzer:

image

More information regarding the SRV option with autodiscover can be found on the Microsoft website: http://support.microsoft.com/kb/940881

Exchange

Change SMTP Header Information

1 Comment

Every message that is sent (over the Internet) has header information. This header contains all kinds of information regarding the message, where it comes from, sent to, time, message identifier etc. All mail servers use this information to process the messages.

But when you take a closer look you’ll see information in the header of a message about your internal network. For example, I’ve sent a message from my Hub Transport Server, throught my Edge Transport Server to an external recipient and this is what I seen in the header information: Continue reading Change SMTP Header Information →

Exchange

LUN Design and Hardware VSS

Leave a comment

This posting is written by Michel de Rooij, thanks for posting it here as well…

I had a question why you need to design seperate LUNs for Exchange database and log files when using a hardware based Volume Shadow Copy Service (VSS) backup solution, as mentioned in this TechNet article: Understanding Exchange 2010 LUN architecture

“To deploy a LUN architecture that only uses a single LUN per database, you must have a database availability group (DAG) that has two or more copies, and not be using a hardware-based Volume Shadow Copy Service (VSS) solution.”

The reason for this requirement is that hardware VSS solutions operate at the hardware level, i.e. the complete LUN. Therefor, if you put the Exchange database and log files on a single LUN, it will always create a snapshot of the whole LUN. This restricts your recovery options, since you can by definition only restore that complete LUN, overwriting log files created after taking the snapshot. So, changes (log files) made after the snapshot are lost and you have no point-in-time recovery options.

For example, with the database and log files on a single LUN, suppose you create a full backup on Saturday 6:00. Then, disaster strikes on Monday. By definition, you can now only restore the database and log files as they were on Saturday 6:00; log files which were created after Saturday 6:00 are lost.

With the database and log files on separate LUNs, you can restore the database LUN, which leaves the LUN with the log files intact. Then, after restoring the database, you can start replaying log files.

So, keep this in mind when planning your Exchange LUNs in conjunction with the backup solution to be used. Note that the Mailbox Role Calculator supports this decision by letting you specify Hardware or Software VSS Backup/Restore as the Backup Methodology to be used.

If you’re interested in more background information on how VSS works, I suggest you check out this TechNet article: Volume Shadow Copy Service