Exchange 2010 Outlook Web Access now offers integration with OCS R2 in much the same way as Office 2010 (for those of you that have used it), in that you can now see your OCS buddy list. Whilst this can be really useful in Outlook Web Access some of the steps to get this working can be a little tricky and need to be done in a particular order.

Quick note, each of the following steps will need to be completed on all Exchange 2010 CAS Servers in your organisation.

Firstly, download the Microsoft Office Communications Server 2007 R2 Web Service Provider:

http://www.microsoft.com/downloads/details.aspx?familyid=CA107AB1-63C8-4C6A-816D-17961393D2B8&displaylang=en

Secondly, if you are running your CAS Servers on Windows 2008 R2 you will need the ‘UcmaRedist.msp’ patch:

http://www.microsoft.com/downloads/details.aspx?FamilyID=B3B02475-150C-41FA-844A-C10A517040F4&displaylang=en

Run the CWAOWASSPMain.msi and install it (default location is C:Web Services Provider Installer).

Copy UcmaRedist.msp to the C:Web Services Provider Installer folder.

You will now need to install the files in that folder in the following order:

vcredist_x64.exe

UcmaRedist.msi

(run an elevated Command prompt (run as Admin))

Browse to C:Web Services Provider Installer folder and install the following:

CWAOWASSP.msi

UcmaRedist.msp

You can now confirm that the installation has completed correctly by browsing to and checking for the following registry key:

HKLMSystemCurrentControlSetServicesMS Exchange OWAInstantMessaging.

If the InstantMessaging key does not exist under MS Exchange OWA then ensure you ran the CWAOWASSP.msi from an elevated command prompt.

Hopefully by this point you will have installed a FQDN Certificate off your internal CA for your CAS Server(s), if not, you will need to. OCS works entirely on Certs and checks the FQDN of the Server(s) you add against the cert that it is operating with – basically, the self-signed certificated that Exchange installs with will not with OCS.

Once you have a cert from your internal CA that matches the FQDN of your Server you will need to launch Exchange Powershell and run the following command:

Get-ExchangeCertificate | fl

Details you will require:

Issuer	CN=Server Root CA, O=Company Limited etc.
SerialNumber	00FF4A82B8779966333CB2A177046F44C3
Services	IIS (only needs IIS but can have others)

(Keep this screen open as you will need the information from the certificate registered for IIS in the next step.)

Now browse to C:Program FilesMicrosoftExchange ServerV14ClientAccessOWA and edit the ‘web.config’ file with notepad.

You will need to complete the following sections:

IMPoolName

IMCertificateIssuer

IMCertificateSerialNumber (this needs to in two octet sets as per below)

example:

Now you need to enable the CAS Server to use OCS for IM, to do this run the following from the Exchange Powershell:

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory –InstantMessagingType OCS

Once the command has completed you will need to perform an ‘IISReset’

 

Now, connect to your OCS R2 Server and bring up the Front-End properties of the pool and select the Host Authorisation tab. Click Add.

Add the host name as the FQDN of the CAS Server(s) that are being configured for IM (this will be need to be the same as the FQDN certificate registered on the CAS servers for IIS). Tick the boxes for ‘Throttle as Server’ and ‘Treat as Authenticated’.

Once you have restart the OCS R2 Front-End Service it should all be working.

After downloading and attempting to install the French language pack for Exchange 2010 UM I was less than pleased to the receive an error:

It took me a few moments to digest what was occurring but after reading the error (always a good start) and looking through the Exchange setup logs ([ERROR] Could not find a part of the path ‘C:SupportUM,Language,Packsfr-FR’), it would appear that if the Language Pack is in a folder that contains spaces it will not install.

If you look at the error above you will note that the spaces in my folder name have been replaced by comma’s ‘,’.

Resolution

Remove the spaces in the folder containing the Language Pack

 

Neil Cruickshanks

Two of the many significant changes coming with Exchange 2010 are the change to DAG’s and to terminate MAPI connections at the Client Access Layer. 

Under Exchange 2007 an Outlook user has the server name configured to that of the mailbox (server / cluster) name, under Exchange 2010 with the concept of DAG’s you no longer connect to the exchange mailbox server directly, your server name is one of your Client Access Servers.  In its out of the box configuration its not very fault tolerant, if the client access server is unavailable the client wont be able to connect.  Client Access Arrays along with load balancing (can be NLB, Forefront TMG or another solution) are the way to tackle this issue.

In this example I have a Forefront TMG (beta 3 – I’ve not upgraded to the RC yet…) server exposed to the internet, behind this I have two Exchange 2010 servers both running Hub, Client Access and Mailbox roles.  There is also a supporting AD, DNS, Certificate infrastructure etc… however I’ve not shown it in the interests of keeping this simple, thanks to Visio it looks like this:

I am publishing the following external names:

autodiscover.contoso.com – Exchange autodiscover

mail.contoso.com – OWA, OA, EWS, ECP, EAS

As we want to load balance / provide fault tolerance for our Exchange 2010 services we have a web farm created with Exch2010.contoso.com & Exch2010-2.contoso.com using HTTP / HTTPS GET requests to verify connectivity. 

Three publishing rules have been configured as follows:

Name	Services
OA – Farm	OA, OAB, EWS, Autodiscover
OWA – Farm	OWA, ECP
EAS – Farm	EAS

All publish to the web farm containing the two Exchange servers.  Again in the interests of keeping this simple I’ve not gone into SSL offload & authentication delegation – best practice would have multiple listeners – FBA for OWA, NTLM for OA etc… but I’ve got one public IP so one listener it is!

To configure a client access array the following steps need completing (I’ve not documented the usual steps you would go through to configure your internal and external URL’s – you set these up as usual):

• Create a client access array

Creating the client access array is simple, all that is needed is to specify an FQDN (an internal name which doesn’t resolve on the internet is fine – the name doesn’t get registered in DNS) and name, in this case I used cas.contoso.com (original eh!) and the AD site the array will serve:

New-ClientAccessArray cas.contoso.com -FQDN cas.contoso.com -Site Default-First-Name-Site

This will create your new array & place all Exchange servers with the client access role in the site specified into your array.

• Configure mailbox databases to use the client access array – this information is then passed back to the client via autodiscover.

When the mailbox database has the RPCClientAccessServer field completed this specifies either a client access server or client access server array to be returned to the client through autodiscover. 

Simple enough to do, this is the command I used:

Set-MailboxDatabase testdb -RpcClientAccessServer cas.contoso.com

Once this has been set, allow a few minutes for replication & client connections will start to be directed to cas.contoso.com from autodiscover & existing clients will begin to update their configuration – the Exchange Server field in outlook will become cas.contoso.com.

So should one of your client access servers go offline TMG will send the connection to another server in the farm and the client will continue to work as it has as CAS array name specified rather than an individual server.

There is documentation on technet about this, however it’s still quite vague – as you would expect at this stage, more will come in due course.

Exchange… awesome product! 

Just found this gem of information on Anderson Patricio’s blog, something which stumped me when setting up some 2010 HA demo’s. 

Exchange 2010 allows you to create a highly available implementation with just two servers (excluding edge), you can combine mailbox, hub and client access on one box, do this twice & use a DAG to replicate the databases & you have highly available Exchange (you can use Forefront TMG to load balance). 

The Exchange 2010 DAG functionality replaces the CCR / SCR technology in Exchange 2007, like CCR DAG requires a file share witness to prevent split brain syndrome.  Typically in Exchange 2007 you would place this on a Hub transport server (having manually created the share & permissions), Exchange 2010 has a wizard to create the FSW on a remote server for you which is handy, however as I found out when I tried to use it against a non Exchange server it didn’t work, I manually created the FSW – putting it down to a Beta / RC bug, however it would appear that you need to add the Exchange Trusted Subsystem group to the local administrators group on the target server to allow the FSW wizard to work.

Rob

Recently I was tasked with performing a mass update on a large HMC / multi tenant style Exchange 2007 implementation.  The update itself was a reasonably simple one – prevent Outlook clients who were not running in cached mode from connecting to their mailboxes (as an aside the reasoning for this was the need to prevent clients with desktop search applications from having a negative performance impact on mailbox servers), the PowerShell cmdlet to do this is ‘Set-CasMailbox’.

In our test environment I executed the following in an Exchange PowerShell session:

Get-CasMailbox -OrganizationalUnit ‘PlatformUsers’ -resultsize unlimited | Set-CasMailbox -MAPIBlockOutlookNonCachedMode:$true

This had the desired effect however took quite some time to run, so looking for a way of speeding this up I stumbled upon the UseRusServer option.  Including this the above command now looks like this:

Get-CasMailbox -OrganizationalUnit ‘PlatformUsers’ -resultsize unlimited | Set-CasMailbox -MAPIBlockOutlookNonCachedMode:$true -UseRusServer <servername>

By using this command Exchange doesn’t have to look for a server running the Recipient Update Service, this makes the process a lot faster (by some rough timings in this environment somewhere between 7-10 times faster) it also meant I had control over which server was used to perform the update against, I chose a server responsible for OAB generation, Exchange could have chosen a mailbox server holding user mailboxes, there likely wouldn’t have been a performance impact but why take the risk.

In the live environment this change affected around 400,000 accounts, so the performance improvement was worth having!

Rob