I already blogged earlier about the multi-tenant hosting possibilities in Exchange 2010 SP1 when using the /hosting switch during installation. This provides a true multi-tenant Exchange 2010 environment but lacks quite an amount of functionality, like Public Folders, the Unified Messaging Role, Lync Server 2010 multi-tenant integration (although an update on this is expected later this year) and provisioning difficulties. You can read my two earliers blog post on Exchange 2010 hoster edition and Exchange 2010 SP1 hosting & Control Panel. Although it is doable, it is difficult at the same time.

With the upcoming Service Pack 2 for Exchange 2010 there’s nothing new with respect to the Hoster Edition, but for a normal installation (also referred to as on-premises installation) a new feature called Address Book Policies (ABP) will be presented. The new ABP feature is the successor of the Exchange 2007 Address List Segregation (which is not supported in Exchange 2010 since it might horribly break Exchange 2010). This makes it easier for non hosting customers to implement multiple address lists without using the /hosting switch (please remember you need to be a registered hoster to officially use the hoster edition of Exchange 2010 SP1).

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.

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.

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.

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

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.

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:

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

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:

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.

Recently I ran into an issue with a customer where one mailbox server in a DAG was accidentally deleted. According to Microsoft it is more or less easy to recover an Exchange server since all configuration data is stored in Active Directory. While this is true it was not that easy as I expected since the DAG (and therefore the cluster service) come into play….

Suppose we have a 2 node DAG, both nodes have three server roles (Hub, CAS and Mailbox) and the File Share Witness is on another Hub Transport Server. Node 2 is called EXCH02 is ‘accidentally’ deleted and won’t come back ever. EXCH01 will now hold the active copy of the Mailbox Database and EXCH02 needs to be recovered. The following steps can be used to recover this server:

EXCH02 needs to be removed from the DAG, but before doing this the passive copy of the Mailbox Database should be removed from EXCH02. Open the Exchange Management Shell on EXCH01 and enter the following command: Remove-MailboxDatabaseCopy –Identity “Mailbox Database1027716905\EXCH02” This references the passive copy of the database and will remove it. Since EXCH02 is no longer available the command will throw several warning messages, but the passive copy will be delete (actually the info will be deleted from Active Directory):

Remove EXCH02 from the DAG. Again, use the Exchange Management Shell on EXCH01 to achieve this and use the following command:

The –ConfigurationOnly switch is needed to actually remove the info from Active Directory. If this switch is omitted the command will try to contact EXCH02 to remove the cluster service, but since the server is not available anymore this won’t work. The server EXCH02 should now be fully removed from the DAG, you can check this in the Management Console;

It can happen that the DAG is not fully cleaned up, you can see this in the Management Console:

Also when opening the Failover Cluster Management snap-in you’ll see that there are some leftovers from the old DAG member.

Right click the old DAG member (i.e. EXCH02) and select “Evict”. The server is now really completely removed from the cluster (=DAG). Now, if you don’t check the actual DAG status and there are some leftover you’ll notice later on that it’s not possible to add the newly created server to the DAG;

Reset the Computer Account in Active Directory;

Build a new server and configure it exactly like the server (EXCH02) that was lost. Use the same Windows Service Packs and hotfixes and use the same disk configuration etc. After installing, give it the same name as the original name (EXCH02) and join it to the domain. Since the computer account was reset this should give no issues at all;

Install all prerequisite software for the Exchange server;

Install Exchange 2010 from the command prompt (using setup.com, the graphical setup application setup.exe is not capable of doing this) using the /mode:RecoverServer option. This will start the setup of Exchange 2010, but instead of using input from the administrator all input is taken from Active Directory. The setup application will automatically pickup the right configuration:

After installation reboot the server and bring it up to date with the latest Exchange Update Rollup fixes (when needed);

After rebooting the new server can be added to the DAG. Open an Exchange Management Shell and enter the following command:

When the DAG is complete a new copy of the mailbox database can be created, a copy of the active mailbox database (running on EXCH01) will be created on the new server and log replication will be initiated between the DAG nodes. Use the following Management Shell to achieve this:

In a previous blog post with an introduction of Lync Server 2010 I already showed the setup flow. The most important part is the central SQL server, the Central Management Server or CMS. In this blogpost I’ll continue with the installation of Lync Server 2010.

Lync Server preparations

I’ll start with a simple setup (just like most customers tend to do). I’ll install Lync Server 2010 for instant messaging, presence information and (simple) video conferencing. Initially I’ll setup this up for interal use only, but in a future blog post I’ll connect the Lync environment to the internet so users at home can connect. Or parters (federation) can connect to our Lync environment of course.

For testing purposes I wanted to Lync Enable the (default) administrator account in Active Directory using the Lync Control Panel. This failed with the following error:

Active Directory operation failed on “wes-dc02.wesselius.local”. You cannot retry this operation: “Insufficient access rights to perform the operation 00002098: SecErr: DSID-03150BB9, problem 4005 (INSUFF_ACCESS_RIGHTS), data 0”. You do not have the appropriate permissions to perform this operation in Active Directory.