In most environments that plan to implement Exchange 2010, there will probably be an older (legacy) version of Exchange Server running. This document provides information on how Exchange 2003, Exchange 2007, and Exchange 2010 will work together in regards to OWA. If implemented correctly this will provide a single namespace for user access to the Outlook Web App (OWA), regardless of where their mailbox is located.

Because the variations are numerous in customer environments, the steps in this bulletin may not work for every implementation. The steps are tailored for several typical environments and actual steps for configuring this solution may vary.

Planning for Coexistence

Some general planning guidelines for coexistence are as follows:

• Make sure that the Exchange Server 2003 servers are running Service Pack 2 or higher.
• Make sure that the Exchange Server 2007 servers are running Service Pack 2 or higher.
• An Exchange Server 2010 server running the Client Access Server, Hub Transport and Mailbox roles (CAS/HUB/MBX) is present in the Internet-facing site
• Update the main OWA URL to point to the Exchange Server 2010 CAS servers. Consider changing your public DNS records so that the public OWA URL (i.e. mail.contoso.com) points to the new IP address of your Exchange 2010 CAS server, or the virtual IP address of your load-balanced CAS Array.
• Create a legacy URL to point to the Exchange Server 2007 CAS or Exchange Server 2003 FE servers if they exist and make a DNS entry externally to point to the legacy server.
• Create a certificate for the Exchange Server 2010 CAS servers to include the OWA URL, the Legacy URL, and Autodiscover URLs – Other names may be needed for protocols such as IMAP and SMTP.
• Change the External URL setting on the Exchange Server 2007 CAS Server to the legacy URL if applicable
• Update the rules on the firewall/ISA Server to point to the correct locations for Exchange Web traffic.

Single AD Site with Exchange 2007 and Exchange 2010

This scenario is a typical scenario for most of our small to mid-sized customers. Typically, they will have one Active Directory site and the addition of Exchange 2010 into their environment will not change that. If the steps below are followed, users can continue to use their existing URL for OWA. They can also expect to have single sign-on for their OWA users, even if they are on Legacy versions of Exchange.

This is a very clean experience for the users and should help make the migration painless as a user’s learning curve will not be required.

The following list contains the basic instructions for the setup of the single sign-on and a brief explanation of what will happen when a user accesses OWA:

• Change the current owa.company.com address to point to the 2010 internet facing CAS server. The reason for this is that Exchange 2010 CAS server is designed to properly handle requests for legacy mailbox requests. Exchange 2007 can handle requests for 2007 and 2003 but not 2010 so if you want a uniform URL you need to have the 2010 CAS server as the internet facing CAS server.
• Create a legacy.company.com Host record to point to the 2007 CAS server. The reason for this is to be able to have a Host record that can be used by the 2010 CAS server to know the location of the 2007 CAS server that can handle the legacy requests.
• Ensure that the ExternalURL value is populated and the InternalURL value is set to $NULL for the OWA virtual directory on the Exchange Server 2007 CAS that is the target of the redirect. If necessary, use the following command to set this: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL https://legacy.company.com/owa -InternalURL $NULL.
• Create a SAN certificate that will either have the wildcard entry (i.e. *.contoso.com) or contain subject name entries for owa.contoso.com, legacy.contoso.com and autodiscover.contoso.com (other names may be needed for protocols such as IMAP and SMTP).
• Assign that certificate to the CAS servers. This certificate should be assigned to the 2007 and 2010 CAS servers to prevent any name mismatch certificate warnings. The reason the 2007 CAS servers would need the certificate is because the name that the 2010 CAS servers will be using to access the 2007 CAS servers will be the new legacy name and unless a wildcard certificate was previously used then that name will not be on the certificate.
• On the 2007 CAS server type the following. The following command will turn on FBA, Turn on Basic Authentication, and set the External URL. The reason we are doing this is to ensure the 2007 and 2010 CAS servers have the same Authentication settings and that we add the new External URL so that the 2010 knows where to go with the legacy requests: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL https://legacy.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.
• On the 2010 CAS server type the following. The following command will turn on FBA, Turn on Basic Authentication, and set the External URL to match what was being currently used by the users: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL https://owa.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.
• We are also setting the ECP to match OWA because then the single sign-on will continue to work when a 2010 user clicks on the options within OWA: Set-ECPVirtualDirectory -Identity "CAS_Server_Name\ECP (Default Web Site)" -ExternalURL https://owa.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.

What happens when a user logs in?

• A user browses to https://owa.contoso.com/owa then authenticates in the FBA page presented by 2010 External facing CAS server.
• The 2010 CAS server will verify the users AD site/Mailbox Version/External URL set on the 2007 CAS servers in that site in our case https://legacy.cotoso.com/owa.
• CAS2010 will then silently redirect the user’s browser session to https://legacy.contoso.com/owa using a hidden FBA form with the fields populated.  OWA will return a small web page containing a hidden form with the same information as what the user had originally submitted to CAS2010 FBA page (username, password, public/private selector, URL to redirect to after logon) and a submit URL synthesized from URL obtained in step 2, and target Exchange -specific path and query string. The web page will also contain script to automatically submit the form as soon as it is loaded.  This is the last part of the logon process that E2010 CAS will have a role in.
• CAS2007 will consume that hidden form’s data, authenticate the user and:

• Retrieve and render the user’s mailbox data from the Exchange 2007 mailbox server and provide the data view back to the user.  The response will contain an FBA cookie for the legacy namespace, and from that point on all user activity within the session will go to legacy CAS only.
• Or proxy the request to the Exchange 2003 mailbox server and provide the data view back to the user.  The response will contain an FBA cookie for the legacy namespace, and from that point on all user activity within the session will go to legacy CAS only.

Multiple AD Sites with Exchange 2007 and Exchange 2010 (redirect)

In most cases in a 2 internet facing site Environment the users in the internet facing sites would type the name that correlates to the site they are located in but for this example we will assume they did not.

This scenario is typically found in a medium- to large-size company that has multiple Active Directory sites that are not well connected. In this case, you would not want the traffic from a CAS server to return mailbox data from a server in an Active Directory site where the connection is not optimized.
In this case if a user goes to a site where the mailbox is not located and authenticates, the Exchange Server 2010 CAS server would provide a page informing the user to click on a link to take them to the CAS server for the site where the mailbox is located. When the link is clicked, the user will be prompted for authentication again, this time from their local (to the Mailbox server) CAS server. This will not be a single sign-on scenario unless the user accesses the proper link for the site where there mailbox is located.

An explanation of what the user will see follows the instructions to configure the solution:

• As stated above change the current owa.company.com address to point to the 2010 internet facing CAS server. The reason for this is that Exchange 2010 CAS server is designed to properly handle requests for legacy mailbox requests. Exchange 2007 can handle requests for 2007 and 2003 but not 2010 so if you want a uniform URL you need to have the 2010 CAS server as the internet facing CAS server.
• The opposing regional site should already have a unique URL such as regional.company.com. If this is an existing setup the naming should still be in place and there would be no need to Change this.
• Create a SAN certificate that will either have the wildcard entry (i.e. *.contoso.com) or the cert should contain subject name entries for owa.contoso.com, legacy.contoso.com and autodiscover.contoso.com (other names may be needed for protocols such as IMAP and SMTP).
• Make sure that the OWA in the regional site is set for basic Authentication with FBA for OWA and that the external URL value is set correctly similar to the following: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL https://regional.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.
• On the 2010 CAS server type the following. The following command will turn on FBA, Turn on Basic Authentication, and set the External URL: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL https://owa.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.
• We are also setting the ECP to match OWA because then the single sign-on will continue to work when a 2010 user clicks on the options within OWA: Set-ECPVirtualDirectory -Identity "CAS_Server_Name\ECP (Default Web Site)" -ExternalURL https://owa.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.

What happens when a user logs in?

• Browse to https://mail.contoso.com/owa. Authenticate in the FBA page presented by 2010.
• The 2010 CAS server will verify the users AD site/Mailbox Version/External URL set on the 2007 CAS servers in that site in our example https://regional.coontoso.com/owa.
• CAS2010 will then provide a redirection page for the user to click a link for https://regional.contoso.com/owa and let them know this is the link they should use. The reason this will occur is because the users are located in a different AD site and they have External Facing CAS servers in that site. This process will be the same whether the other site has 2007 or 2010 CAS servers in the internet facing site.
• After clicking the link the user will get another authentication prompt at the CAS server in the site where the mailbox is located and all of the traffic will then go through the users Local CAS servers.

Multiple AD Sites with Exchange 2007 and Exchange 2010 (proxy)

This scenario could apply in a medium- to large-size company that has multiple Active Directory sites that are well connected. This provides a single namespace for the users to connect to for OWA access and minimizes user confusion.

In this case if a user goes to the published OWA URL and authenticates, the Exchange 2010 CAS server silently proxies to the Client Access Server that is local to their Mailbox server. The user would not be prompted again or redirected to another site for action.

This will generate more network traffic, as the rendered mailbox data will be passed to and from the CAS server in the site where the mailbox is located back to the External facing CAS server. The configuration steps and the user experience explanation follow:

• As stated above change the current owa.company.com address to point to the 2010 internet facing CAS server. The reason for this is that Exchange 2010 CAS server is designed to properly handle requests for legacy mailbox requests. Exchange 2007 can handle requests for 2007 and 2003 but not 2010 so if you want a uniform URL you need to have the 2010 CAS server as the internet facing CAS server.
• The opposing regional site CAS Servers should not have an External URL value set for the OWA virtual directory they should have just an internal URL value the default values for this are typically fine.
• Create a SAN certificate that will either have the wildcard entry (i.e. *.contoso.com) or the cert should contain subject name entries for owa.contoso.com, legacy.contoso.com and autodiscover.contoso.com (other names may be needed for protocols such as IMAP and SMTP).
• Assign that certificate to the 2010 CAS servers.
• Make sure that the OWA in the regional site is set for integrated Authentication for OWA using a command similar to the following on the 2007 non internet facing CAS server. The reason for this is because we will be using integrated authentication for requests that are proxied to this server from the Exchange 2010 CAS server. This is the same process as in Exchange 2007: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" –ExternalURL $Null –formsAuthentication $False –WindowsAuthentication $true.
• On the 2010 CAS server type the following. The following command will turn on FBA, Turn on Basic Authentication, and set the External URL: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL Https://owa.company.com/OWA -FormsAuthentication $True -BasicAuthentication $True.
• We are also setting the ECP to match OWA because then the single sign-on will continue to work when a 2010 user clicks on the options within OWA: Set-ECPVirtualDirectory -Identity "CAS_Server_Name\ECP (Default Web Site)" -ExternalURL Https://owa.company.com/OWA -FormsAuthentication $True -BasicAuthentication $True.
• 7. From the External facing 2010 CAS server go to the 2007 server and copy the latest set of binary files to the 2010 server (every time a rollup is placed on the 2007 CAS servers this process will need to be redone). The reason for this is when you are being proxied the External facing 2010 server has to present the rendered data to the users. Since they are legacy users we need to have a comparable copy of the binary files based on the Exchange Rollup they are on:

• From the 2010 CAS server go to START then RUN then type something similar to \\2007cas\c$\program files\microsoft\Exchange Server\Client Access\OWA.
• Copy the Highest version of the build files from that location and paste them on the internet facing 2010 CAS server in the location similar to the following c:\program files\Microsoft\Exchange Server\V14\ClientAccess\OWA.
• Then restart IIS on the 2010 CAS server and this should allow proxying to work. If the wrong files are copied or this step is not completed you will see an error on the 2010 external facing CAS servers in the application log telling you to copy the files.

What happens when a user logs in?

• Browse to https://owa.contoso.com/owa. Authenticate in the FBA page presented by 2010.
• The 2010 CAS server will verify the users AD site/Mailbox Version/External URL set on the site where the user is located.
• There will not be an External URL Value set on the site where the user is located, so the user will be authenticated via Proxy using integrated authentication over the internal URL.
• The 2007 non internet facing server will render the data and pass that along to the 2010 server to pass along to the user. The 2010 internet facing CAS server will NOT be out of the loop in this case.

Exchange 2010 and Exchange 2003 within a Single Site or Cross Site

The scenario below is for a company that does not have Exchange Server 2007 installed and is migrating or coexisting with Exchange Server 2010 and Exchange Server 2003, only.

The Exchange2003URL value can be found in Active Directory in the following location using ADSIEdit.MSC:

This will allow the Exchange 2010 server to know where to direct the Legacy users so that they can access OWA using the 2010 CAS servers URL. This parameter was added as there is no longer a /exchange virtual directory in Exchange Server 2010, as there was in Exchange Server 2007. 

It is important to understand that Exchange Server 2010 cannot proxy to Exchange Server 2003 Mailbox role servers. Exchange Server 2010 must redirect this traffic.

In this situation you would use the new Exchange2003URL parameter that is configurable via the Exchange Management Shell with the set-OWAVirtualDirectory commandlet explained below:

• Change the current owa.company.com address to point to the 2010 internet facing CAS server. The reason for this is that Exchange 2010 CAS server is designed to properly handle requests for legacy mailbox requests. Exchange 2003 can handle requests for 2003 only. If you want a uniform URL you need to have the 2010 CAS server as the internet facing CAS server.
• Create a legacy URL such as legacy.company.com to point to the 2003 FE server. We need this in place so that we have a URL that we can provide the Exchange 2010 CAS server the proper configuration to find the 2003 FE server.
• On the 2010 CAS server type the following. The following command will turn on FBA, Turn on Basic Authentication, and set the External URL: Set-OwaVirtualDirectory -Identity "CAS_Server_Name\OWA (Default Web Site)" -ExternalURL https://owa.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.
• We are also setting the ECP to match OWA because then the single sign-on will continue to work when a 2010 user clicks on the options within OWA: Set-ECPVirtualDirectory -Identity "CAS_Server_Name\ECP (Default Web Site)" -ExternalURL https://owa.company.com/owa -FormsAuthentication $True -BasicAuthentication $True.
• Configure the Exchange2003URL property on the 2010 CAS server to point to the new Legacy URL. Then new Exchange2003URL value was added to Exchange 2010 as a configurable attribute for the OWA virtual directory to provide a way for Exchange 2010 to know the location to send the 2003 users. In previous versions we used DAVEX for this but since DAVEX was removed we now rely on this property…. The following is an example of how to set this property: set-owavirtualdirectory “2010 CAS server name\owa (default web site)” -exchange2003url https://legacy.company.com/exchange.
• FBA will need to be enabled on the 2003 FE server. The reason for this is because we are passing the credentials from the 2010 CAS server to the 2003 FE server via a hidden form. This is designed to prevent the user from having to authenticate again.

What happens when a user logs in?

• Browse to https://owa.contoso.com/owa. Authenticate in the FBA page presented by 2010.
• The 2010 CAS server will verify the users AD site/Mailbox Version/External URL/ and in this case Exchange2003URL value.
• The 2010 CAS server will then silently redirect the user to the legacy URL and auto-populate the Credentials provided in step one using a hidden FBA Page.
• The 2003 server will then Authenticate the user silently and will provide the data to the user. This process will allow for a single sign on for the legacy users. At this point the 2010 server would be out of the loop.

Thanks to Timothy Heeney, Chris Lineback and Sam Kamau putting together all of this awesome piece of information which will help so many customers in migration processes.

One corrupted mailbox can have the potential to disrupt service by taking down the entire information store, thereby affecting all users on that server. Mailbox quarantine has been introduced in Exchange Server 2010 to help prevent this situation.

What is Mailbox Quarantine?

Mailbox quarantine is a feature in the Exchange Server 2010 information store. Based on values in the registry, the store detects a mailbox or mailboxes that have the potential to or have caused the store to crash and quarantines them for specific period. The mailboxes that have the potential to crash the store are called Poisoned mailboxes.

When does quarantining happen?

Quarantining of mailboxes can occur in two situations:

• A thread that is doing work for a mailbox has crashed.
• More than 5 threads allocated to process a mailbox, have not progressed for long time.

How does it work?

The store will tag a mailbox that has the potential to crash the store. The tag includes the number of times that mailbox has caused the store to crash and a time stamp. If the store is crashed by a mailbox, a registry key is created. The path to the registry key is:

HKLM\SYSTEM\CCS\Services\MSexchangeIS\Servername\Private-dbguid\Quarantined Mailboxes\ {Mailbox GUID}

It will have the following two values:

• CrashCount – The number of times the mailbox has crashed the store.
• LastCrashTime – The last time the mailbox crashed the store.

The key is not created until the store has been crashed at least one time by a mailbox.

Each time a database is mounted, the store checks the registry to see if any mailboxes hosted on this particular database is tagged. If the registry indicates that a mailbox has caused the store to crash the mailbox will be quarantined.

By default, if a mailbox has been identified as a threat 3 times in 2 hours then that mailbox will be quarantined for 6 hours.

These default settings can be modified by creating the following key:

HKLM\SYSTEM\CCS\Services\MSexchangeIS\ParameterSystem\Servername\Private-dbguid\Quarantined Mailboxes

Using the following values:

• MailboxQuarantineCrashThreshold – The number of times a mailbox can be identified before the store quarantines it.
• MailboxQuarantineDurationInseconds – The number of seconds a mailbox remains in quarantine before the store releases it.

These two values do not exist by default. They should be created only if there is a need to change the default behaviour.

A background process in the store runs every 2 hours (this default can’t be changed) to check the registry values for each mounted database. The store checks the CrashCount and LastCrashTime values and performs any of the following four actions:

• If all tagged mailboxes have a CrashCount value less than the MailboxQuarantineThreshhold (default value of 3) in the last 2 hours, then the dbguid registry value for the mailbox located at HKLM\SYSTEM\CCS\Services\MSexchangeIS\Servername\Private-dbguid\Quarantined Mailboxes is deleted.
• If a tagged mailbox has a CrashCount is greater than the value MailboxQuarantineThreshhold (default value of 3) and a mailbox is not quarantined then the mailbox will be quarantined immediately.
• If a mailbox has been quarantined longer than the default 6 hours or the time specified in the value MailboxQuarantineDurationInSeconds then it will be released immediately.
• If a mailbox is quarantined for less than the default six hours or time specified in the value MailboxQuarantineDurationInSeconds then it will remain quarantined.

What happens when clients try to access a quarantined mailbox?

When a client attempts to access a mailbox the following occurs:

1. The store will return an error code ecMailboxQuarantined and based on this, XSO throws the transient exception MapiExceptionMailboxQuarantined to signal transport and other XSO clients

2. Every 5 minutes transport tries to deliver message sent to a quarantined mailbox

3. Outlook clients see the following pop up when they try to access a quarantined mailbox

4. OWA displays the following pop up error message when trying to access a quarantined mailbox

Only clients such as MFCMAPI that can pass Open-As-Admin flag can access a mailbox while it is in quarantined state. Even Exchange processes such as content indexing and mailbox assistants cannot access the mailbox.

For example, a move mailbox request will fail with the following pop up error:

Resetting a quarantined mailbox

It is possible to reset a quarantined mailbox by deleting the quarantine registry key for that mailbox located at:

HKLM\SYSTEM\CCS\Services\MSexchangeIS\Servername\Private-dbguid\Quarantined Mailboxes\ {Mailbox guid}.

The database then has to be dismounted and remounted or the IS service restarted for the reset to take effect immediately. Unless the underlying issue is not resolved, the mailbox could crash the store and become quarantined again.

Troubleshooting

Application log

The following event will be logged when a mailbox is automatically quarantined:

Log Name: Application

Source: MSExchangeIS

Event ID: 10018

Task Category: General

Level: Error

Description: The mailbox for user /o=AMERICAS/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=test1 has been quarantined. Access to this mailbox will be restricted to administrative logons for the next 6 hours.

The following event will be logged when a mailbox is automatically removed from the quarantine:

Log Name: Application

Source: MSExchangeIS

Event ID: 10019

Task Category: General

Level: Error

Description: The quarantine of the mailbox for user /o=AMERICAS/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=test1 has expired. Access to the mailbox has been restored.

Shell Command

We can also use the Get- MailboxStatistics cmdlet to see if a mailbox has been quarantined.

Get-MailboxStatistics –identity test1 | FL Isquarantined

Isquarantined : True

Performance Monitor

The store also provides the performance monitor counter: MSExchangeIS Mailbox\Quarantined Mailbox Count. This counter shows the number of quarantined mailboxes on a specific server.

EXTRA

Finally we can used EXTRA to trace data. Select Function from Trace Types and use the tag tagQuarantineMailbox under component Store.

Thanks to Hamza Hassen and Jonathan Runyon for putting all this information together which will help so many of us certainly…

SSL certificates are issued for periods of spanning a number of years (typically in multiples for example one, two or more years, however eventually they do expire and need to be renewed).

The renewal process involves generating a fresh CSR (Certificate Signing Request) on one of your Exchange Client Access servers. This is then sent to a root certification authority (e.g. VeriSign) for processing into a valid SSL certificate (essentially they sign the request).

Creating a Certificate

In order to generate a CSR file on the Client Access Server and Windows Server 2008 open the Exchange Management Shell and type the following command:

New-ExchangeCertificate -GenerateRequest -Path c:\myReq.csr -KeySize 1024 -SubjectName “c=GB, s=Middx, i=MyCompany, ou=IT, cn=mail.mydomain.com” -PrivateKeyExportable $True

The string that you provide after the -SubjectName switch is very important and it is made up of the following values:

• c – This is the country of origin.
• s – This is the state we are in.
• i – This is the company that you work for, or indeed the SSL certificate will be assigned to. You should note that if you have purchased SSL certificates before it is worth ensuring that the company naming convention is consistent throughout all certificates that you have purchased.
• ou – This is the organisation unit that the section of the company which will take charge of the certificate.
• cn – This should be set to the DNS FQDN of the Client Access Server which will be using the certificate.

This will produce a file in the root of C drive on the CAS server called myReq.csr. This should be sent to our root certification authority.

When the CSR has been generated you will be provided with a CRF (Certificate Response File) which looks like the following (this will be returned to you via email):

-----BEGIN CERTIFICATE-----JJkbbssCCAuucgAwIBAgIQcyE6jZgwnFgAq0d7onjMFzANBgkqhkiG9w0BAQUFADCBzj

EEWNNNEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du

MR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv

biBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhhd3RlIFByZW1pdW0gU2VydmVyIENB

MSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNlcnZlckB0aGF3dGUuY29tMB4XDTA4MDcxMTE2M

DU0OFoXDTEwMDcyNjE1NTcxN1owgYYxCzAJBgNVBAYTADDDDDDjujjjjjw87666cvNxMJkeDE

PMA0GA1UEBxMGTG9uZG9uMSswKQYDVQQKEyJMb25kb24gQm9yb3VnaCBvZiBIb3Vuc2xvdyBD

b3VuY2lsMQswCQYDVQQLEwJJVDEcMBoGA1UEAxMTb3dhLmhvdW5zbG93Lmdvdi51azCBnzANB

gkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAolvn0lT1W+cdRFjqOn56tPwHNULjq7LDA/G4ZAIVf9

cl7y4jLKR/6/3x2O/1st8OEcFDFKElmn8dzoA3pG14JL8ZmBTh0RLxtGRw9fHB2ARuYplagoD

LqgA5mzEPo3a3wCKboTaEwKwoeQ9dAp2bGcvs4lMPptI48eoSDhFs/u0CAwEAAaOBpjCBozAd

BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwQAYDVR0fBDkwNzA1oDOgMYYvaHR0cDovL

2NybC50aGF3dGUuY29tL1RoYXd0ZVByZW1pdW1TZXJ2ZXJDQS5jcmwwMgYIKwYBBQUHAQEE

JjAkMCIGCCsGAQUFBzABhhZodHRwOi8vpgthennn/ss88877a222129tMAwGA1UdEwE

B/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAuYSyeOUx53TkjCfol2psVY3E9uzMb6P6nrgs2U

uG8BBQlshPkv+te8G2JpaaaaCmcrCV8J0WQN8mRm5443vbdasafJTBxB2PAZfl3GSWEgDIH

q/lg3IOxG43YK4qDWYTu3j/Ngymq8g/d+0VrqkF/AmXWnGMGIQmE3GUnUDXeZKOR8SM=

-----END CERTIFICATE-----

You should copy the CRF (including the Begin Certificate and End Certificate) into a text file called owa.txt and then rename the file owa.cer. You should then copy this file up to a drive on the CAS server where you are working.

Installing a Certificate (CAS)

Firstly you need to remove the existing (expired) SSL certificate from your Client Access Server. In order to accomplish this you need to open the Exchange Management Shell and then type in the following command:

Get-ExchangeCertificate | fl | out-file –filePath c:\certs.txt

This will create a text file in the root of C drive called certs.txt which contains the details of every certificate install on the server. The output should look like the following:

The key property that will identify the certificate that you wish to replace is the Not After field. As this is essentially the expiry date and should have already expired or indeed be very close to expiring. Make a note of the thumbprint (the long number at the bottom after the Thumbprint field) and then type in the following command:

Remove-ExchangeCertificate –thumbprint <thumbprint that you noted down>

As a tip here is to copy the thumbprint from the text file above and then paste it into the PowerShell Window. When you have typed the command and pressed enter you will be presented with the confirmation message:

Are you sure you want to perform this action?

Remove certificate with thumbprint 138B6EC5AAE868F495ECCBDA05C1F011B08A7CD3?

[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help(default is “Y”):

Confirm the action by entering A and then press ENTER. You are now ready to import the new certificate onto the Client Access Server. In order to do this type in the following command within the PowerShell window (ensure that the path you specify to the certificate file matches the location where you placed the new certificate in the earlier steps):

Import-ExchangeCertificate -path e:\certificates\owa.cer –FriendlyName “owa.mydomain.com”

You should then be presented with the following output (again here you will need to make a note of the thumbprint):

Thumbprint Services Subject

———- ——– ——-

B52842F7408772B7151FF74FDAE914EA7B59B53A ….. CN=owa.mydomain.com,…

Now that the certificate has been imported into the certificates repository you need to enable it for OWA. In order to do this run the following command in the PowerShell window:

Enable-ExchangeCertificate -Thumbprint B52842F7408772B7151FF74FDAE914EA7B59B53A -Services IIS

The new certificate should now be installed you can confirm this by running the following command:

Get-ExchangeCertificate

The output of which should be:

Thumbprint Services Subject

———- ——– ——-

B52842F7408772B7151FF74FDAE914EA7B59B53A …W. CN=owa.mydomain.com,…

The key thing here to note is the W under services (this signifies that the cert has been enabled for OWA) and that the thumbprint matched what you have typed in previously.

Imagine the scenario where you want to to set an execution policy for a specific user on a machine. The per-user setting is nothing more than a key in the registry, something like:

[HKEY_USERS\S-1-5-21-REST-OF-SID\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell]

"ExecutionPolicy"="RemoteSigned"

So all you have to do is grab your users’ SIDs (easy enough with AD cmdlets or ADSI I suppose) and modify the registry directly (as long as you have admin rights).

The proper way of doing this, of course, would be using Group Policy, see Set-ExecutionPolicy for details on that.

You can alter who is affected by the statement by using the –scope option.  The setting will be persistent though. You shouldn’t need to run it each time PS is started up.

First of all a HUGE THANKS to Yuval Sinay for putting this information together.

The following article will provide a summary on common issues in Exchange 2010 deployment in the Enterprise. The information in this article consists of my own experience and official Microsoft knowledgebase articles. Due to the fact that your Exchange environment may vary, please read the information carefully and test the suggestions from this article - in a lab that can demonstrate the current Exchange infrastructure.

The article is divided to the following chapters:

1. General issues in Exchange 2010 deployment.

2. Best practices in Exchange 2010 deployment.

3. Common issues in Exchange 2007 migration to Exchange 2010.

4. Common issues in Exchange 2003 migration to Exchange 2010.

General issues in Exchange 2010 deployment

• When you are using account with administrative privilege to export mailboxes, you may get error on permission issue. The same symptoms may occur if you are using Backup software from third party.
  • Give the account that use for export/backup purpose, the required permissions to access to the user mailbox: Get-MailboxDatabase | Add-ADPermission -user "domainname\backupaccountserviceaccountname" -AccessRights GenericAll
  • Administrative Accounts (e.g. Domain Admins have deny access permission to users mailboxes by default).
• When you are trying to relay from Exchange 2010 server, you may block by default.
  • Setup the required relay permissions: Allow Anonymous Relay on a Receive Connector
  • In high secure environment you can add security features like Authentications, SSL, etc.
• Microsoft posts a nice guide on known issue while trying to move mailboxes from old Exchange system to the Exchange 2010 system.
  • Troubleshooting Mailbox Moves
• Outlook 2003 customers may report on slow performance during send and receive.
  • Upgrade to Outlook 2007 or higher, otherwise: Outlook 2003 email messages take a long time to send and receive when you use an Exchange 2010 mailbox
• After installing Exchange 2010 on computer that own Global Server role, Exchange services may not started after reboot.
  • Services for Exchange Server 2007 or Exchange Server 2010 cannot start automatically after you install Exchange Server 2007 and Exchange Server 2010 on a global catalog server
• During Apple iPhone synchronization, the following error message may appear:"Exchange ActiveSync doesn’t have sufficient permissions to create the “CN=Yuval Sinay,OU=Users,OU=Lab Demo,OU=Pilot Exchange 2010,DC=shadowall,DC=local” container under Active Directory user “Active Directory operation failed on mail.shadowall.local. This error is not retriable. Additional information: Access is denied. Active directory response: 00000005: SecErr: DSID-03151E04, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0“.
  • If the account is a member of Protect Group you may need to verify that the user Mailbox permission set to apply inheritance has the following setting on: “Include inheritable permissions from this object’s parent".
  • The "Send As" right is removed from a user object after you configure the "Send As" right in the Active Directory Users and Computers snap-in in Exchange Server
• Users with mobile phones that using third party operating system may report on “Certificate Error” during the synchronization stage.
  • This issue isn’t related to Microsoft, and it’s a common issue that the mobile phone operating system didn’t setup with the correct “Root CA” certificate or the mobile phone operating system don’t support certificate with SAN extensions *”Unified Communications Certificate”).
  • Microsoft recommends using only specific certificate type in Exchange 2010 system. If you are like to obtain a public certificate, please note that Microsoft released a list of official supported vendors: Unified Communications Certificate Partners for Exchange Server and for Communications Server
• Outlook 2003 users may report on failure in connection to the Exchange 2010.
  • Upgrade to Outlook 2007 or higher, otherwise enable the option on the outlook 2003 (Manually or by using GPO): “Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server".
  • Alternatively we can disable the requirement to use RPC with encryption support, by using the power shell command on the relevant Exchange 2010 server: “Set-RpcClientAccess -Server savdalex10 -EncryptionRequired $false". This one isn’t recommended, due the security risk it imposes.
• During use Exchange 2010 Best Practice Analyzer, the following error may appear: "Unrecognized Exchange signature Active Directory domain 'domainname' has an unrecognized Exchange signature. Current DomainPrep version: 12639."
  • As I know, this issue should be resolved in Exchange 2010 Service Pack 1. Exchange 2010 Best Practice Analyzer doesn’t support earlier Exchange versions.
• Using Symantec BackupExec 2010 to restore users emails accomplished successful. However, after checking the user mailbox you may found that no user data is restored.
  • Restore of individual emails/mailbox from a Granular Recovery Technology (GRT) backup set of Exchange database, completes successfully but no messages are restored
• During the Exchange 2010 organization upgrade, the following error may appear: "The execution of: "$error.Clear(); if ($RolePrepareAllDomains) { initialize-DomainPermissions -AllDomains:$true -CreateTenantRoot:$RoleIsDatacenter; } elseif ($RoleDomain -ne $null) { initialize-DomainPermissions -Domain $RoleDomain -CreateTenantRoot:$RoleIsDatacenter; } else { initialize-DomainPermissions -CreateTenantRoot:$RoleIsDatacenter; }", generated the following error: "Length of the access control list exceed the allowed maximum."
  • On a Windows Server 2008-based computer, Exchange Server 2010 installation cannot be successful at the organization preparation process
• During Exchange 2010 installation, “error code 3221685941” may appear.
  • You receive an error message that contains error code 3221685941 when you install Exchange Server 2010
• Users may report that they can’t open DOC, PDF, and XLS files by using Exchange 2010 OWA.
  • Install Exchange 2010 Rollup Pack 3 or higher: Description of Update Rollup 3 for Microsoft Exchange Server 2010 Release to Manufacturing
• Outlook 2003 users can’t publish their FB data on Exchange Server 2007 or 2010:
  • Users who use Outlook 2003 cannot publish their free/busy data in Exchange Server 2010 or in Exchange Server 2007
• Some users cannot connect Exchange Server 2010 using Outlook Anywhere.
  • You cannot connect to an Exchange Server 2010 server by using Outlook Anywhere
• Self signed certificates warnings.
  • Outlook displays the Security Alert dialog box when Exchange is using a self-signed certificate
• A few customers that are using Symantec Enterprise Vault 8.x reported on mailbox data restore issues. The following error may appear: “Error 3310: There was a problem accessing a network service or resource. The dispenser will re-queue the current item and sleep for 5 minute(s). Task: Mailbox Archiving Task for EXCHANGESERVERNAME (Retrieval). For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp.”
  • Upgrade to Symantec Enterprise Vault 9.x contact Symantec Support for further assistant.
• Exchange Server 2010 Management Tools start up issues.
  • Microsoft Exchange Team released a nice document that can help: Troubleshooting Exchange 2010 Management Tools start up issues
• Due miss configuration of third party backup software, the following error may appear: “Exact Error Message 0xe0000380 - Backup Exec attempted to back up an Exchange database according to the job settings. The database was not found in the Database Availability Group”
  • Please contact the third party support staff to resolve this issue. Symantec released a nice article how to resolve this issue: Exchange Information Store for Exchange 2010 is not visible in the Backup Selections or the Exchange 2010 backup fails with either the error "0xe0000380 - Backup Exec attempted to back up an Exchange database according to the job settings. The database was not found in the Database Availability Group
• In most scenarios, the backup server should use Windows 2008 x64 / Windows 2008 R2 operating system with the latest edition of the Exchange 2010 Management Tools.
• An issue with cluster upgrade was reported by a customer from Israel. Upgrading from Exchange Server 2003 cluster to Exchange Server 2007/2010 cluster may lead to communication issue, if we are hosting the routing group connector on that cluster.
• It’s recommended to move the routing group connector to an alternative Exchange Server, before starting the cluster upgrade.
• During Exchange Server 2010 installation, the following error may appear: “The execution of: “$error.Clear(); if ($RoleStartTransportService) { start-SetupService -ServiceName MSExchangeTransport }”, generated the following error: “Service ‘MSExchangeTransport’ failed to reach status ‘Running’ on this server.”
• Enable IPV 6 on the network adapter(s).
• When you try to install the Exchange Server 2010 mailbox role, the installation process fails