Exchange Server Pro

Commvault iDataAgent and Remote Public Folders

Paul Cunningham — Tue, 31 Aug 2010 12:02:04 +0000

There is a change in behaviour between Commvault version 7 and version 8 in the way that the Public Folder iData Agent handles public folders.

In Commvault version 7 the Public Folder iDataAgent will only back up content for local public folders. Any public folders for which there is no local replica on the Exchange server being backed up will not be included in the backup.

In Commvault version 8 the Public Folder iDataAgent will back up both local and remote public folders. This means that if the local public folder database has replicas for say 5Gb of the total 20Gb of data in that public folder hierarchy, it will back up the remaining 15Gb from a remote public folder database.

If the remote public folder database that it connects to is over a slow WAN connection then you run the risk of two undesirable outcomes:

WAN link saturation during the backup window
Very long running public folder backup jobs

There are three approaches that you could take to resolve this:

Replicate all public folder data to any server that is running Public Folder iDataAgent backup jobs. This may increase local storage requirements and WAN utilization caused by public folder replication (though you can optimize this in the public folder replication settings to suit your network).
Only run the Public Folder iDataAgent backup job at a central site that holds replicas for all public folders in the hierarchy. This is probably the least administrative effort. However it requires that any data restores also be run at that site and then replicated to the remote site that needs it, which potentially lengthens the total restoration timeframe.
Narrow the scope of the Public Folder iDataAgent backup job to only those folders in the hierarchy for which there are local replicas. This solves the problem now but could lead to new folders created later not being included in the backup scope.

Get more Exchange Server tips at ExchangeServerPro.com

SSL Certificate Trust Errors for New Thawte Certificates

Paul Cunningham — Fri, 27 Aug 2010 09:00:46 +0000

If you renew a Thawte SSL certificate or purchase a new one since 26th July 2010 you may encounter SSL certificate trust errors when clients connect to published websites such as Outlook Web Access.

Web browsers will return an error such as:

The security certificate issued by this website was not issued by a trusted certificate authority

On inspection of the certificate being issued by the website you may see this error:

The issuer of this certificate could not be found

This can be confusing for people who assume that any certificate issued by a commercial CA such as Thawte will be trusted by devices and web browsers that people are connecting from, especially when it occurs after renewing an existing Thawte SSL certificate.

Thawte has published the reason for this:

On June 27 2010, in the interest of better security, thawte signed all certificates with a primary and secondary intermediate that need to be installed along with the SSL certificate. Any certificate issued on or after this date requires the primary and secondary intermediate to be installed.

The new certificates are issued by an intermediate CA known as “Thawte SSL CA”. This CA is not automatically trusted by most web browsers. Thawte provides instructions for installing the correct certificates on the web server or ISA Server that is publishing the website.

Take note of the final steps, the change may not take effect until IIS or ISA Server are restarted.

If your site still have the chaining error, restart the IIS service. If the problem continues, the whole server needs a reboot to use the new roots.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2010 and the Benefits of Commercial SSL Certificates

Paul Cunningham — Thu, 26 Aug 2010 09:00:26 +0000

Petri IT Knowledgebase has published my article on the merits of choosing commercial SSL certificates over self-signed or privately issued ones for Exchange Server 2010.

The business case is clear for purchasing SSL SAN certificates from a genuine commercial certificate authority to use with Exchange Server 2007 and 2010. For an outlay of as little as a few hundred dollars the business receives the benefits of:

Far less administrative effort to implement and maintain SSL for Exchange services

Compatibility with devices and applications that require connection to Exchange services over SSL

Access to Exchange services such as Outlook Web App for remote workers without undermining the security of the network or encouraging insecure behavior by users

Read the full article here.

I frequently encounter customers who request to (in some cases demand to) or have already deployed Exchange Server 2010 with a self-signed or a privately issued certificate. In 2007 it was possible though cumbersome and frustrating. In Exchange 2010 it is possible in some scenarios, equally frustrating, and in a few cases seems to be impossible to achieve 100% seamless integration and trust even for domain members (notably Exchange 2010 with Outlook 2010).

Any perceived cost savings by avoiding commercial certificates are a false economy. You spend far more on consultant and administrator effort to implement and maintain the environment with non-commercial certificates.

I generally recommend Digicert’s Unified Communications certificate for Exchange Server 2010 deployments, as I find them easy to deal with and good value.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange 2010 Hub Transport Server Backup and Recovery

Paul Cunningham — Wed, 25 Aug 2010 09:00:23 +0000

The Exchange Server 2010 Hub Transport Server role is responsible for all email flow within the organization. Every email between two recipients, whether they are both internal mailboxes or one is an external mailbox, will traverse at least one Hub Transport server. This even includes emails between two mailboxes stored on the same database.

In addition to the delivery of email the Hub Transport server also applies transport rules, performs journaling, and can optionally provide message hygiene services as well.

What Needs to be Backed Up on Hub Transport Servers?

To plan for backup and recovery of the Hub Transport server you first need to understand where the server stores its configuration and data.

Active Directory – most of the Hub Transport server configuration information is stored in Active Directory. However there are a few exceptions to that.

System State – the system state contains information such as SSL certificates installed on the server, and service startup and dependency settings in the registry, which will be important if they have been modified from the defaults. The system state will also include information about any other applications or agents installed on the Hub Transport server, such as antivirus and anti-spam products.

File System – the file system contains the transport queues and some of their ESE settings, log files such as message tracking logs and protocol logs, and customizations made to the local transport configuration. The file system will also include the program files for any additional applications or agents installed on the server.

Planning the Hub Transport Server Backup

When you are planning the Hub Transport server backup strategy there are different approaches you can take depending on your requirements.

Backing up Everything

A full system backup of the server, along with a working Active Directory, encompasses all of the required information for a recovery. However this backup takes the longest and will consume the most backup storage.

If a server failed and needed to be recovered from a full backup any undelivered messages still in the transport queue would be lost. But it is impractical to backup the entire server multiple times a day just to protect the transport queue databases from data loss.

Depending on the Exchange environment and the backup infrastructure in place a full server recovery may take longer than simply rebuilding the server from scratch.

Backing up the Minimum

To save on backup storage and minimize the backup time frame the minimum data on the Hub Transport server can be backed up. For most environments this would mean only backing up the transport queue databases and the log files on the file system.

Because these would be relatively fast to back up this type of backup could be performed multiple times per day to minimize the risk of losing undelivered messages. This concern would mostly apply to high volume email environments where the transport queues are regularly backlogged. Of course in those cases some attention should be paid to whatever performance bottleneck is causing the backlog, if it is something within the control of that organization to fix.

Backing up Nothing

A perfectly feasible backup strategy for the Hub Transport server is to back up nothing at all. This would be practical if:

there are multiple, redundant Hub Transport servers deployed
the transport queues are not frequently backlogged
the organization does not wish to retain any log files from the Hub Transport servers

If all those conditions are true then it may not be necessary to back up the Hub Transport servers at all.

Backing Up and Restoring Hub Transport Servers

For the purposes of this demonstration I’ve configured a Hub Transport server with an additional Receive Connector.

Message tracking logs are also enabled.

Recovering a Hub Transport Server

As mentioned earlier most of the critical Hub Transport server configuration is stored in Active Directory. When a Hub Transport server has failed you can recover the server using the following process.

Install a new server to host the Hub Transport server role
Configure the server with the same name and IP address as the failed server, and join it to the domain
Install the Exchange Server 2010 pre-requisites
Perform an installation of Exchange Server 2010 using Recovery Mode

To run setup in Recovery Mode use the following command to launch Exchange Server 2010 set from an elevated command prompt.

C:\Admin\Exchange 2010>setup /m:recoverserver

Setup performs a server recovery instead of a normal installation.

Welcome to Microsoft Exchange Server 2010 Unattended Setup

By continuing the installation process, you agree to the license terms of
Microsoft Exchange Server 2010. If you don't accept these license terms,
please cancel the installation. To review these license terms, please go to

http://go.microsoft.com/fwlink/?LinkId=150127&clcid=0x409/

...............
No key presses were detected.  Setup will continue.
Preparing Exchange Setup

    Copying Setup Files              ......................... COMPLETED

The following server roles will be recovered
    Hub Transport Role
    Management Tools

Performing Microsoft Exchange Server Prerequisite Check

    Hub Transport Role Checks        ......................... COMPLETED
 This computer requires the 2007 Office System Converter: Microsoft Filter Pack.
 Please install the software from http://go.microsoft.com/fwlink/?LinkId=123380.

Configuring Microsoft Exchange Server

    Preparing Setup                  ......................... COMPLETED
    Stopping Services                ......................... COMPLETED
    Copying Exchange Files           ......................... COMPLETED
    Restoring Services               ......................... COMPLETED
    Hub Transport Server Role        ......................... COMPLETED
    Exchange Management Tools        ......................... COMPLETED
    Finalizing Setup.                ......................... COMPLETED

The Microsoft Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to tak
e effect. Please reboot this server prior to placing it into production.

Restart the server as prompted. When the server has finished restarting you can verify that configurations such as the additional Receive Connector and the message tracking log configuration have been recovered with the server.

However the log files themselves are not restored during a Recovery Mode install of Exchange Server 2010.

Neither are additional applications or agents that were previously installed ont he server. For the Hub Transport server one notable item would the Microsoft Office Filter Pack.

Therefore the server is not fully recovered until all of those items, along with any further customizations to the server, have been manually applied.

Full System Backup/Restore for Hub Transport Servers

For this demonstration I used Windows Server Backup to take a full system backup of the Hub Transport server to use for bare metal restore.

This backup can take a while depending on your backup infrastructure and the amount of data involved. However it simplifies the restore process because it restores the full system including log files, customizations, and additional applications.

The full restore brings the server back to an operational state ready for production, however it is a point in time recovery and will not include log file entries or mail items that were still in the transport queue since that point in time.

Recovering Hub Transport Servers with Minimal Backups

When the minimal backup strategy is used in conjunction with server recovery it allows you to make use of an effective hybrid approach to Hub Transport server recovery.

In this approach you combine the two techniques:

fast, frequent backups of the transport queues and message tracking log files at regular intervals throughout the day
restoration using Recovery Mode with and the latest backup files

To do this you run Exchange Server 2010 setup in Recovery Mode as demonstrated earlier but with an additional command line switch.

C:\Admin\Exchange 2010>setup /m:RecoverServer /DoNotStartTransport

The /DoNotStartTransport switch stops setup from starting the Microsoft Exchange Transport service when it finishes installation.

This allows you the opportunity to restore the most recent transport queue database and message tracking log files onto the server before it is put back into production use.

With this recovery model you will still need to reinstall additional applications or agents as with the previous Recovery Mode technique.

Summary

As you can see there are pros and cons to each backup strategy for the Hub Transport server role in Exchange Server 2010. For many organizations the full system backup/restore will be the simplest choice, though it will consume the most backup storage and takes longer to back up. For high volume environments or those with strict auditing and retention requirements the frequent backups of the transport queue database and log files may be the preferred approach instead.

Get more Exchange Server tips at ExchangeServerPro.com

Improved Database Integrity Checking in Exchange Server 2010 SP1

Paul Cunningham — Tue, 24 Aug 2010 09:00:25 +0000

Exchange administrators will be familiar with the ISInteg tool (Information Store Integrity Checker) as a way to check and repair Exchange database integrity.

A pain point with the tool in the past has been that it can only be run on a database that is offline. This means that an otherwise operational database needs to be dismounted to run ISInteg to fix any suspected integrity problem. For Exchange administrators this usually means a long night running the tool outside of business hours to minimize interruption to end users.

Which is why this announcement from the Microsoft Exchange Team blog is great news.

In Exchange 2010 SP1, ISInteg is no longer a standalone program.

With the release of Service Pack 1 for Exchange Server 2010 two new Exchange Management Shell cmdlets will be available:

New-MailboxRepairRequest
New-PublicFolderDatabaseRepairRequest

Each one performs validation and fixing of integrity issues for the respective database type.

The best improvement is that the tools no longer need to run on dismounted databases. In fact they are required to run on mounted databases.

These new ISInteg cmdlets come with some cool new functionality!

The cmdlets work with the database mounted. It’s no longer required to unmount the database to perform an integrity check or fix database errors.

You can repair logical corruption at the mailbox level.

You can fix corrupt search folders.

You can fix Aggregate Counts.

You can fix the Provisional Fid.

Because the tools run against mounted databases, and can perform their operations at the mailbox level, mailbox repairs will only affect the owner of that mailbox instead of every mailbox user connected to that database.

Another useful new feature is that the tools now output their progress to the Event Log instead of to text files, making monitoring of repair requests much easier to manage.

Overall a big improvement and one that will benefit Exchange administrators when they are dealing with database corruption scenarios.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2010 DAGs and VMware High Availability

Paul Cunningham — Mon, 23 Aug 2010 09:00:13 +0000

If you are planning to deploy Exchange Server 2010 Database Availability Groups, and you virtualize your Exchange environment, then it is important to understand the supported scenarios.

Microsoft makes it very clear in their system requirements for Exchange Server 2010:

Microsoft doesn’t support combining Exchange high availability solutions (database availability groups (DAGs)) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers. DAGs are supported in hardware virtualization environments provided that the virtualization environment doesn’t employ clustered root servers, or the clustered root servers have been configured to never failover or automatically move mailbox servers that are members of a DAG to another root server.

In short, DAG members should have any virtualization high availability options disabled.

This is in slight contrast to the advice from VMware themselves:

While the use of database availability groups on top of hypervisor based clustering is not a formerly (sic) supported configuration, internal VMware tests have shown that the two technologies can co-exist and can be a viable solution to ensure maximum recoverability in the case of a host failure.

To paraphrase, it isn’t supported but we think you’ll be fine.

You might get some push back from customers or managers who have been sold on the idea of VMware HA for everything, or who take the line from VMware as implied support for the configuration. But in the real world I prefer to go with what is supported over what is possible.

Get more Exchange Server tips at ExchangeServerPro.com

An Encrypted Connection to Your Mail Server is Not Available

Paul Cunningham — Fri, 20 Aug 2010 09:00:11 +0000

When Exchange Server 2010 has been introduced to an existing Exchange 2003 organization some Outlook 2010 clients may report the following error when setting up a new mail profile.

An encrypted connection to your mail server is not available. Click Next to attempt using an unencrypted connection.

After trying an unencrypted connection Outlook fails to connect to the user’s mailbox.

This will occur for Outlook 2010 users who still have mailboxes on an Exchange 2003 server, however it should only occur when a new profile is being created, not every time they launch Outlook.

You can create the profile by choosing the “Manually configure server settings” option instead.

Get more Exchange Server tips at ExchangeServerPro.com

How to Configure a Relay Connector for Exchange Server 2010

Paul Cunningham — Thu, 19 Aug 2010 09:00:59 +0000

In most Exchange Server 2010 environments there will be the need to allow relaying for certain hosts, devices or applications to send email via the Exchange server. This is common with multi-function devices such as network attached printer/scanners, or applications such as backup software that send email reports.

SMTP communication is handled by the Hub Transport server in an Exchange organization. The transport service listens for SMTP connections on it’s default Receive Connector. However, this connector is secured by default to not allow anonymous connections (ie, the type of connection most non-Exchange systems will be making).

You can see this in effect if you telnet to the server on port 25 and try to initiate unauthenticated SMTP communications.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 19:42:27 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.9]
mail from: somebody@hotmail.com
530 5.7.1 Client was not authenticated

For some Hub Transport servers that are internet-facing, anonymous connections may already be enabled. In those cases relay would still be denied but will behave differently than the first example.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 20:01:44 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.9]
mail from: somebody@hotmail.com
250 2.1.0 Sender OK
rcpt to: somebody@gmail.com
550 5.7.1 Unable to relay

You’ll note that relay is denied if I try to send from an @hotmail.com address to an @gmail.com address, because neither is a valid domain for the Exchange organization. But with Anonymous Users enabled on the Receive Connector I can send from an @hotmail.com address to a valid local address.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 20:05:54 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.9]
mail from: somebody@hotmail.com
250 2.1.0 Sender OK
rcpt to: alan.reid@exchangeserverpro.local
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
test
.
250 2.6.0  [In
ternalId=2] Queued mail for delivery

However if I try to relay out to an external recipient, the Exchange server does not allow it.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 20:11:27 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.9]
mail from: backups@exchangeserverpro.net
250 2.1.0 Sender OK
rcpt to: alerts@managedserviceprovider.com
550 5.7.1 Unable to relay

To permit a non-Exchange server to relay mail we can create a new Receive Connector on the Hub Transport server. Launch the Exchange Management Console and navigate to Server Management, and then Hub Transport. Select the Hub Transport server you wish to create the new Receive Connector on, and from the Actions pane of the console choose New Receive Connector.

Give the new connector a name such as “Relay ” and click Next to continue.

You can leave the local network settings as is, or optionally you can use a dedicated IP address for this connector if one has already been allocated to the server. Using dedicated IP addresses for each connector is sometimes required if you need to create connectors with different authentication settings, but for a general relay connector it is not necessary to change it.

Highlight the default IP range in the remote network settings and click the red X to delete it.

Now click the Add button and enter the IP address of the server you want to allow to relay through the Exchange server. Click OK to add it and then Next to continue.

Click the New button to complete the wizard.

The Receive Connector has now been created but is not yet ready to allow the server to relay through it. Go back to the Exchange Management Console, right-click the newly created Receive Connector and choose properties.

Select the Permission Groups tab and tick the Exchange Servers box.

Select the Authentication Tab and tick the Externally Secured box.

Apply the changes and the Receive Connector is now ready for the server to relay through.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 20:31:00 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.9]
mail from: backups@exchangeserverpro.net
250 2.1.0 Sender OK
rcpt to: alerts@managedserviceprovider.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
test
.
250 2.6.0 <924bab1e-0f07-4054-8700-d121577993b4@EX3.exchangeserverpro.local> [In
ternalId=3] Queued mail for delivery

Because the remote IP range has been secured to that single IP address, any other servers on different IP addresses still won’t be able to relay through the Exchange Server. From any other IP address not included in the remote IP range on the Receive Connector relay will be denied.

220 EX3.exchangeserverpro.local Microsoft ESMTP MAIL Service ready at Wed, 18 Au
g 2010 20:46:06 +1000
helo
250 EX3.exchangeserverpro.local Hello [192.168.0.2]
mail from: backups@exchangeserverpro.net
250 2.1.0 Sender OK
rcpt to: alerts@managedserviceprovider.com
550 5.7.1 Unable to relay

You can later add more IP addresses, IP ranges, subnets, or even add multiple IP addresses to the Receive Connector using a script if necessary.

Get more Exchange Server tips at ExchangeServerPro.com

How to Issue a SAN Certificate to Exchange Server 2010 from a Private Certificate Authority

Paul Cunningham — Wed, 18 Aug 2010 09:00:13 +0000

Exchange Server 2010 makes use of SSL certificates for securing network communications between servers and clients. An example of this is Outlook Web App (OWA) which uses the HTTPS protocol for users connecting via their web browser (eg https://webmail.company.com/owa).

Traditionally SSL certificates were issued for a single name (such as the webmail name above), however this is very limiting because once an SSL certificate is bound to an IP address that IP address is not able to accept connections addressed to different names over SSL, or at least not without the name mismatch causing a warning message to the connecting client.

This became an issue for Exchange Server 2007 and 2010 because, depending on the server roles installed, the server may need to accept SSL connections to several different names such as:

the server’s FQDN (eg ex3.exchangeserverpro.net)
webmail and other published names (eg webmail.exchangeserverpro.net, mail.exchangeserverpro.net, mobile.exchangeserverpro.net)
multiple DNS namespaces (eg autodiscover.exchangeserverpro.net, autodiscover.xyzimports.com)

Configuring multiple IP addresses, DNS records, IIS instances, and SSL certificates for all of the possible names in an Exchange organization would be tedious and expensive.

The X.509 certificate standard has catered for this for a long time now with a feature known as Subject Alternative Names. Basically this allows a single SSL certificate to be configured with a primary name and then multiple alternative names, making it valid for all of the required names that clients and other servers will be connecting to.

SAN certificates are available from most commercial providers however some organizations choose to issue them from their own private certificate authority. Windows Server 2008 Certificate Services supports SAN certificates by default, however Windows Server 2003 requires the option to be manually enabled first.

Enabled SAN Certificate Support for Windows Server 2003 Certificate Services

You can check an existing Windows Server 2003 CA for SAN support by using the certutil utility from a command prompt.

C:\>certutil -getreg policy\EditFlags
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\ca\Po
licyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags:

  EditFlags REG_DWORD = 15014e (1376590)
    EDITF_REQUESTEXTENSIONLIST -- 2
    EDITF_DISABLEEXTENSIONLIST -- 4
    EDITF_ADDOLDKEYUSAGE -- 8
    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
    EDITF_ENABLEAKIKEYID -- 100 (256)
    EDITF_ENABLEDEFAULTSMIME -- 10000 (65536)
    EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)
CertUtil: -getreg command completed successfully.

If there is no EDITF_ATTRIBUTESUBJECTALTNAME2 flag then you can enable it by running the following command.

C:\>certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\ca\PolicyModules\Certifi
cateAuthority_MicrosoftDefault.Policy\EditFlags:

Old Value:
  EditFlags REG_DWORD = 11014e (1114446)
    EDITF_REQUESTEXTENSIONLIST -- 2
    EDITF_DISABLEEXTENSIONLIST -- 4
    EDITF_ADDOLDKEYUSAGE -- 8
    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
    EDITF_ENABLEAKIKEYID -- 100 (256)
    EDITF_ENABLEDEFAULTSMIME -- 10000 (65536)
    EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)

New Value:
  EditFlags REG_DWORD = 15014e (1376590)
    EDITF_REQUESTEXTENSIONLIST -- 2
    EDITF_DISABLEEXTENSIONLIST -- 4
    EDITF_ADDOLDKEYUSAGE -- 8
    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
    EDITF_ENABLEAKIKEYID -- 100 (256)
    EDITF_ENABLEDEFAULTSMIME -- 10000 (65536)
    EDITF_ATTRIBUTESUBJECTALTNAME2 -- 40000 (262144)
    EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

Next you must restart Certificate Services for the change to take effect.

C:\>net stop certsvc
The Certificate Services service is stopping.
The Certificate Services service was stopped successfully.

C:\>net start certsvc
The Certificate Services service is starting.
The Certificate Services service was started successfully.

The server is now ready to issue SAN certificates.

How to Request a SAN Certificate for Exchange 2010

The next step is to create a certificate request from the Exchange server. You can perform this task from the Exchange Management Shell, or from the console. For an example of the console steps see the previous article here.

From the Exchange Management Shell use the New-ExchangeCertificate cmdlet to generate a certificate request. In this example I am requesting a certificate with the following attributes:

A friendly name of “Exchange 2010 Certificate”
The server’s FQDN
The alternative names of mail.exchangeserverpro.net, autodiscover.exchangeserverpro.net, and webmail.exchangeserverpro.net

I’m also using -GenerateRequest to create a certificate request rather than simply creating a self-signed certificate.

[PS] C:\>New-ExchangeCertificate -FriendlyName "Exchange 2010 Certificate" -IncludeServerFQDN -DomainName mail.exchangeserverpro.net,autodiscover.exchangeserverpro.net,webmail.exchangeserverpro.net -GenerateRequest -PrivateKeyExportable $true

The command will output a certificate request that looks similar to this.

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEPDCCAyQCAQAwJTEjMCEGA1UEAwwabWFpbC5leGNoYW5nZXNlcnZlcnByby5u
ZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnbhSAM0y26udUo/+8
yvufXrv0AcuzcLYc/9wxNjgOZjmkQUqXEvrxXXrIzCciWL1KDTYjJyVXNkjqCsB3
8tdLWS7tLR/OLj0Px7bsUkTuJKl95DeYGJwxginMjvVKrdxMkPJloWY6i+5ZzHfs
jhK0+bboyaoQMopwnya7AK0H5AfSDUd+hFzbgpX8hdj7hkMVwCS257/fsNkoJbxA
xC7C9Yk06onHypefiz+uTubNULjKBKdtJiyesj6hakyG1tFddsvv6yqwjtAefyVZ
vYWbkSJiXTwALuOrePlt3wGa12ZxqYwl2Mf98gdb2fTq2M6TosPE0PIxoDZvBzV2
IHZxAgMBAAGgggHQMBoGCisGAQQBgjcNAgMxDBYKNi4xLjc2MDAuMjBlBgkrBgEE
AYI3FRQxWDBWAgEFDBtFWDMuZXhjaGFuZ2VzZXJ2ZXJwcm8ubG9jYWwMEEVYQ0hT
RVJWUFJPXEVYMyQMIk1pY3Jvc29mdC5FeGNoYW5nZS5TZXJ2aWNlSG9zdC5leGUw
cgYKKwYBBAGCNw0CAjFkMGICAQEeWgBNAGkAYwByAG8AcwBvAGYAdAAgAFIAUwBB
ACAAUwBDAGgAYQBuAG4AZQBsACAAQwByAHkAcAB0AG8AZwByAGEAcABoAGkAYwAg
/wQEAwIFoDCBhQYDVR0RBH4wfIIabWFpbC5leGNoYW5nZXNlcnZlcnByby5uZXSC
ImF1dG9kaXNjb3Zlci5leGNoYW5nZXNlcnZlcnByby5uZXSCHXdlYm1haWwuZXhj
aGFuZ2VzZXJ2ZXJwcm8ubmV0ghtFWDMuZXhjaGFuZ2VzZXJ2ZXJwcm8ubG9jYWww
DAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUbaUvsgyyRXS0lEHebbnvEqpd7VwwDQYJ
KoZIhvcNAQEFBQADggEBAEQ5GtxZGMf3rw+gGuIj+A8exB7bM2aSg9Z9X6RyNtHX
3iuCHPEOUdkZFSTR3CWoMal1FcH/r1yzCPXKTWDtyMIzi4tiHA/+V2nXALhH6Fbv
c8G0l47iIGlbvuBkBDTxhmLubXgXGAp1dRfwRXd1Vqy0eDe/0LxlUAwq+Kb/RRLw
UaUf3eVrbQUpWNqEmLcorp3mpwnoqAB+GhP+j0ERCquP629xdlHS2yz3fNfn4xGU
Sv/i5FLUf6WmVJu+kjQ50wlh5nE+XiwQmsta0MNUnqIXu9dDXnOpx+VdmuKdEXlh
/zAHMofanelZ/UUBv7mdwMG3E5U17nJ/VoiIAZAygg0=

-----END NEW CERTIFICATE REQUEST-----

Copy the output to your clipboard for the next steps.

Open your web browser and navigate to the web enrollment URL of your Certificate Services server (eg http://ca-server/certsrv). Click on Request a Certificate. Note if you are running a Windows Server 2003 CA you may need an update to the web enrollment pages before you can proceed any further.

Choose Advanced Certificate Request.

Choose to Submit a Certificate request…, because we’ve already generated the request on the Exchange server earlier.

Paste the generated certificate request data into the form, and choose Web Server as the certificate template. Click Submit to continue.

When the certificate has been issued download the certificate file to your Exchange server.

Completing the Pending Certificate Request

The certificate has been issued and downloaded, and now the pending certificate request needs to be completed for Exchange Server 2010.

Launch the Exchange Management Console, navigate to Server Management, and choose the server that you imported the certificate to. Right-click the new certificate and choose Complete Pending Request.

Browse and select the certificate file that was downloaded, and the continue to complete the wizard.

The certificate has now been installed and is ready to be assigned to Exchange services.

If you encounter an error message stating that “The certificate is invalid for exchange server usage” then see this article for the solution.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2010 “The Certificate is Invalid for Exchange Server Usage” Error

Paul Cunningham — Tue, 17 Aug 2010 09:00:41 +0000

A certificate installed on an Exchange Server 2010 server may display the following error message.

The certificate is invalid for exchange server usage

This can occur when the certificate cannot be verified to a trusted certificate authority. This may occur when the certificate has been issued by a private certificate authority.

To correct the problem you must install the root certificate for the certificate authority. For a private certificate authority this can be obtained from the web enrollment page (eg http://ca-server/certsrv).

Browse to the web page and click on Download a CA Certificate, Certificate Chain, or CRL.

Click to download either the CA Certificate (if the certificate was issued by a root CA) or the Certificate Chain (if the certificate was issued by an intermediary CA).

Launch a new Microsoft Management Console (Start -> Run, mmc.exe) and add the Certificates snap-in to it, connecting to the Computer Account for the Local Computer.

Navigate to Trusted Root Certification Authorities. Right-click on Certificates and choose All Tasks and then Import.

Browse and choose the CA Certificate or Certificate Chain that you downloaded earlier.

Place the certificate in the Trusted Root Certification Authorities store.

Complete the import wizard and then refresh the Exchange Management Console, and the certificate should now be valid.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server Pro

Commvault iDataAgent and Remote Public Folders

Related posts:

SSL Certificate Trust Errors for New Thawte Certificates

Related posts:

Exchange Server 2010 and the Benefits of Commercial SSL Certificates

Related posts:

Exchange 2010 Hub Transport Server Backup and Recovery

What Needs to be Backed Up on Hub Transport Servers?

Planning the Hub Transport Server Backup

Backing up Everything

Backing up the Minimum

Backing up Nothing

Backing Up and Restoring Hub Transport Servers

Recovering a Hub Transport Server

Full System Backup/Restore for Hub Transport Servers

Recovering Hub Transport Servers with Minimal Backups

Summary

Related posts:

Improved Database Integrity Checking in Exchange Server 2010 SP1

Related posts:

Exchange Server 2010 DAGs and VMware High Availability

Related posts:

An Encrypted Connection to Your Mail Server is Not Available

Related posts:

How to Configure a Relay Connector for Exchange Server 2010

Related posts:

How to Issue a SAN Certificate to Exchange Server 2010 from a Private Certificate Authority

Enabled SAN Certificate Support for Windows Server 2003 Certificate Services

How to Request a SAN Certificate for Exchange 2010

Completing the Pending Certificate Request

Related posts:

Exchange Server 2010 “The Certificate is Invalid for Exchange Server Usage” Error

Related posts: