LUN Design and Hardware VSS

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

Configure Domain Controller in Exchange 2010

10 years ago it was a best practice to use an ’empty root’ Active Directory model. Lately I see this model quite often in Exchange 2003 environment that need to be upgraded to Exchange 2010.

A customer has an empty root AD with 2 domain controllers in this empty root. Outlook’s autodiscover sometimes returns one of these domain controllers, but in this specific scenario these domain controllers are behind a firewall. Therefore they cannot be used for authentication purposes by (desktop) clients.

Exchange has a service (MSExchange ADAccess) that uses the topology discover to retrieve a list of available domain controllers. You can check the properties of the Exchange Server in the Exchange Management Console or you can check the eventlog for Event ID 2080.

Log Name: Application

Source: MSExchange ADAccess

Date: 15-11-2010 12:46:57

Event ID: 2080

Task Category: Topology

Level: Information

Keywords: Classic

User: N/A

Computer: cashub01.infra.root.local

Description:

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1576). Exchange Active Directory Provider has discovered the following servers with the following characteristics:

(Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)

In-site:

AD001.root.local CD- 1 6 6 0 0 1 1 6 1

AD005.infra.root.local CD- 1 6 6 0 0 1 1 6 1

AD013.infra.root.local CDG 1 7 7 1 0 1 1 7 1

AD014.infra.root.local CDG 1 7 7 1 0 1 1 7 1

AD002.root.local CDG 1 7 7 1 0 1 1 7 1

AD004.infra.root.local CDG 1 7 7 1 0 1 1 7 1

AD006.infra.root.local CDG 1 7 7 1 0 1 1 7 1

AD003.infra.root.local CD- 1 6 6 0 0 1 1 6 1

Out-of-site:

To exclude a particular domain controller the Set-ExchangeServer cmdlet can be used in the Exchange Management Shell. In this example the AD001 domain controller is excluded for Exchange Server CASHUB01:

Set-ExchangeServer Identity “CASHUB01” –StaticExcludedDomainControllers AD001.root.local

Is is also possible to create a list of domain controllers and global catalog servers that are allowed by the Exchange Server:

Set-ExchangeServer Identity “CASHUB01” –StaticDomainControllers AD005.infra.root.local,AD003.infra.root.local

Set-ExchangeServer Identity “CASHUB01” –StaticGlobalCatalogs AD013.infra.root.local,AD014.infra.root.local

After configuring the Exchange Server you’ll see the results in the event log:

Log Name: Application

Source: MSExchange ADAccess

Date: 15-11-2010 22:05:18

Event ID: 2080

Task Category: Topology

Level: Information

Keywords: Classic

User: N/A

Computer: cashub01.infra.root.local

Description:

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1576). Exchange Active Directory Provider has discovered the following servers with the following characteristics:

(Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)

In-site:

AD001.root.local CD- 0 0 0 0 0 0 0 0 0

AD005.infra.root.local CD- 1 6 6 0 0 1 1 6 1

AD013.infra.root.local CDG 1 7 7 1 0 1 1 7 1

AD014.infra.root.local CDG 1 7 7 1 0 1 1 7 1

AD002.root.local CDG 0 0 0 1 0 0 0 0 0

AD004.infra.root.local CDG 1 7 7 1 0 1 1 7 1

AD006.infra.root.local CDG 1 7 7 1 0 1 1 7 1

AD003.infra.root.local CD- 1 6 6 0 0 1 1 6 1

Out-of-site:

The certificate is invalid for Exchange Server usage

When you have an Internet facing Exchange 2010 Client Access Server you most likely will have a 3rd party certificate installed on this CAS Server. Every time the certificate is requested it is checked for validity, and this is checked against a webserver of the Certificate Authority.

When you have Threat Management Gateway (TMG) 2010 Server in front of the CAS Server all HTTP(S) traffic is routed via the TMG Server. The TMG Server is the default gateway on the network interface and in Internet Explorer you have to configure the TMG server as the HTTP proxy.

Continue reading The certificate is invalid for Exchange Server usage

Exchange 2010 Hoster Edition

I already blogged about the Exchange 2010 Hoster Edition… it is generally speaking not a good idea to try this in an enterprise environment… The Exchange 2010 Hoster Edition: http://sysadmin-talk.org/2010/09/address-list-segregation-or-hoster-edition-exchange-2010-sp1/

But currently I’m working for a hosting company, and I have to prepare a migration from Hosted Messaging and Collaboration (HMC4.5) to Exchange 2010 Hoster Edition. So, I have plenty of time to play with it… (And Greg, I have the SPLA licenses, don’t worry 😉

Continue reading Exchange 2010 Hoster Edition

The name on the security certificate is invalid or does not match the name of the site

So you installed Exchange 2007 (or Exchange 2010), you have your Outlook 2007/2010 clients, Unified Communciations certificate, configured the Exchange Webservices, Autodiscover, really anything:

Set-OWAVirtualDirectory –Identity X2007SRV\OWA (default web site) -ExternalURL https://webmail.inframan.nl/OWA -InternalURL https://webmail.inframan.nl/OWA
Set-OABVirtualDirectory –Identity X2007SRV\OAB (default web site) -ExternalURL https://webmail.inframan.nl/OAB -InternalURL https://webmail.inframan.nl/OAB
Set-WebServicesVirtualDirectory –Identity X2007SRV\EWS (default web site) -ExternalURL https://webmail.inframan.nl/ews/exchange.asmx -InternalURL https://webmail.inframan.nl/ews/exchange.asmx
Set-ActiveSyncVirtualDirectory –Identity X2007SRV\Microsoft-Server-ActiveSync (default web site) -ExternalURL https://webmail.inframan.nl/Microsoft-Server-ActiveSync -InternalURL https://webmail.inframan.nl/Microsoft-Server-ActiveSync
Set-ECPVirtualDirectory –Identity 2010CAS\ECP (default web ) -ExternalURL https://webmail.inframan.nl/ECP -InternalURL https://webmail.inframan.nl/ECP

But still users get this annoying certificate warning while on the internal network :“The name on the security certificate is invalid or does not match the name of the site

image

Troubleshooting with Outlook (right mouse click on the Outlook icon in the task bar) but all information that Outlook reveales look good:

image

Using the Remote Connectivity Analyzer (www.testexchangeconnectivity.com) doesn’t show any errors whatsoever. The error message comes from IIS, do the next step is to check the IIS Log File:

image

When using the Get-AutodiscoverVirtualDirectory cmdlet you can check the –InternalURL and –ExternalURL properties, and these turn out to be empty, so we have to set these properties:

Get-AutodiscoverVirtualDirectory | Set-Autodiscover –InternalURL https://webmail.inframan.nl/autodiscover/autodiscover.xml -ExternalURL https://webmail.inframan.nl/autodiscover/autodiscover.xml

doesn’t give the results we want. Even worse, the –InternalURL and –ExternalURL aren’t used at all in the Client Access Server (although they are enforced by the Schema). The Client Access Server object has a property called –AutodiscoverServiceInternalUri, and this property needs the complete URL to the autodiscover XML file:

Set-ClientAccessServer –Identity X2007SRV –AutodiscoverServiceInternalUri https://autodiscover.inframan.nl/autodiscover/autodiscover.xml

Now the error message “The name on the security certificate is invalid or does not match the name of the site” won’t show up anymore on the Outlook clients.