The concept is to integrate outlook web App with office communications Server 2007 R2 for presence and instant messaging, which means that users using Outlook web App will have The ability to provision their presence and use a built-in instant messaging system to chat with other OCS users, in addition to the basic Outlook Web App features. Isn't cool!

Let's get started and see how this can be accomplished.

There are four main steps to get this work

A - Configuring the Exchange Client Access Server
B - Configuring the Office Communication Server
C - User Configuration
D - High availability considerations

A - Configuring the Exchange Access Server

In order to properly configure your Exchange Client Access Server you should follow the following steps:

1. Download and install the "Microsoft Office Communications Server 2007 R2 Web Service Provider" on your Exchange 2010 CAS server (this adds special DLLs and configuration files needed to link OWA 2010 to your OCS 2007 R2 environment)
2. Gather Information about the certificate used by the Client Access Server.
3. Edit the OWA Web Config file.
4. Enable OCS Integration.
5. Restart Internet Information Services.

Step 1:- Downloading/Installing the OCS 2007 R2 Web Service Provider Files
Follow this link CWAOWASSPMain.msi to Download and install on your Exchange Client Access Server the "Microsoft Office Communications Server 2007 R2 Web Service Provider”

Step 2: Gather Certificate Information

In order to establish a secure communication between the Office communications Server and the Exchange Server both Servers should trust each other's, thus the certificate that used on the exchange server and assigned to Internet Information Services should be trusted by the OCS Server, thus the Exchange Certificate and OCS server Certificate would either be issued from the same issuer, for example: Enterprise/Subordinate CA. or issued by third party public Certificate Services example "VeriSign, star field ... etc...".

Note that in some cases where exchange is using a public Certificate for IIS and a private certificate for SMTP services you should always use the public certificate information used by IIS in the web.config file that we will see in the next step

In order to examine the Exchange Certificate Used by IIS uses the following command from the exchange PowerShell:

Get-ExchangeCertificate |fl

You should have a similar output portion in case of a private Certificate

IsSelfSigned : False
Issuer : CN=RootCA, DC=mydomain, DC=com
SerialNumber : 71652G3R00000000001A
Services : IMAP, POP, IIS, SMTP
Status : Valid
Subject : CN=Exch2k10.mydomain.com
----------------------------------------------------------------------------------------------------------------------------
In case of a public Certificate used for IIS

IsSelfSigned : False
Issuer : SERIALNUMBER=10688435, CN=Starfield Secure Certification Authority, OU=http://certificates.starfieldtech.com/repository, O="Starfield Technologies, Inc.", L=Scottsdale, S=Arizona, C=US
SerialNumber : 03F7FA1DFB783B
Services : IIS
Status : Valid
Subject : CN=Exch2k10.mydomain.com
---------------------------------------------------------------------------------------------------------------------------

Step 3: Edit the OWA Web Config File
On the Client Access Server, navigate to the following directory:
C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\OWA

Open the web.config file using Notepad and perform the following steps:

1. Search for OCS (IMPoolname). You see the following three entries:

2. Populate the pool/server name:
In the <add key="IMPOOlName" section, insert the FQDN of the OCS server between the final two quotes. For our example, the line will look like this:

3. Populate the Certificate Issuer:
In the <add key="IMCertificateIssuer" section, insert the issuer of the certificate (gathered earlier) between the final two quotes. For our example, the line will look like this:

Important: in case you have double quotes included within your Certificate issuer name you should enclose the certificate issuer name with a single quote. for our example the line will look like this:

4. Populate the Certificate SerialNumber:
In the <add key="IMCertificateSerialNumber" section, insert the certificate serial number between the final two quotes. For our example, the line would look like this:

or

Important: You must manually add spaces in the Serial Number string to separate each octet or the system cannot locate the certificate.

5. Save and close the Web.config file.

Step 4: Edit the OCS Integration
To enable the OWA Virtual Directory to use OCS IM integration, from Exchange PowerShell, type the following command:

Get-OwaVirtualDirectory -server SERVERNAMEHERE Set-OwaVirtualDirectory -InstantMessagingType 1

Step 5: Restart Internet Information Services
Although the preceding changes should be detected automatically, administrators might need to restart IIS on the Client Access Server. However, doing so can cause any current OWA sessions to be logged off, so care should be taken.
From the command prompt on the Client Access server, issue the IISRESET command to restart the services.

B- Configuring the Office communications Server
Prerequisites: hotfix for UcmaRedist.msi; UcmaRedist.msp from the Microsoft Office Communications Server 2007 R2 Hotfix KB 968802 in case you have installed OCS 2007 R2 on windows 2008 R2

The Exchange Server 2010 Outlook Web App IM integration component is implemented as an OCS 2007 end-point. Thus For the integration component to sign in to OCS 2007 R2, the OCS server must be configured to trust the Client Access Server.

This is accomplished by adding the Exchange Client Access Server as a trusted server on the OCS 2007 R2 front end. To do so, perform the following steps:
1. While logged in as an OCS administrator, start the OCS Management Console by selecting the following:
Start\All Programs\Administrative Tools\Office Communicator Server 2007 R2
2. Navigate to the OCS 2007 R2 Pool. Right-click the OCS Pool name and select Properties; then select Front End Properties
3. Click on the Host Authorization tab; then click the Add button.
4. In the Add Authorized host window
Select the FQDN radio button.
Type the name of the Client Access Server, basically what you type in to run OWA, such as owa.mydomain.com
(Note: you could use the IP address button instead of the FQDN button but this is less secure as it does not rely on certificate authentication, so use the name you use to access OWA externally as that'll likely use https SSL security and will work)
Select (checkbox) the following options: Treat as Authenticated and Throttle as Server.
5. Click OK to save the configuration changes.
6. To allow changes to take effect immediately, stop and restart the OCS front-end services; note that doing so will disconnect any active users.

C- User configuration
Users should be enabled for OCS with enhanced presence enabled prior of using the IM integration

D- High availability considerations
in order to configure OCS outlook web app integration in an highly available environment where multiple Exchange CAS configured for load balancing exists, you should take the following into consideration :

1- Create the web.conf entries on all load balanced CAS servers
2- Enable IM integration on all load balanced CAS servers
3 - Add all CAS servers FQDNs along with the OWA load balanced FQDN as authorized hosted to the OCS server pool properties.

UPDATE FOR Exchange 2010 SP1

if you install Exchange 2010 SP1 the previous configuration will be broken, this Microsoft has introduced some changes on exchange to the instant messaging settings. actually what micorosoft has done is that they have moved the instant messaging settings from web.config to Active Directory where it should be.

But this is will not require you to redo all the integration steps what you will need is to simply discard the web.config part and run the following commands on all Exchange CAS servers deployed in your organization.

Get-ExchangeCertificate | Where-Object {$_.Services -match "IIS"} | Get-ExchangeCertificate | fl thumbprint,subject

Copy paste the Certificate thumbprint in the following command

Get-OwaVirtualDirectory -Server "CasServer" | Set-OwaVirtualDirectory -InstantMessagingCertificateThumbprint 4DC1EE3506E06E971FF82AC8DD60015EAC11B21E -InstantMessagingServerName ocspoolname.domain.local -InstantMessagingType OCS -InstantMessagingEnabled $true

Enjoy!

The Forefront TMG Managed Control service failed to initialize. Error information: Command failed with error: The term 'Get-AntiSpamUpdates' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again

At first sight it looks like the Get-AntiSpamUpdates cmdlet was removed in Exchange 2010 SP1 and that the TMG Managed Control service is not aware of that change yet! I have no confirmation about this bug yet but it looks like, for now, it is better to refrain from installing Exchange 2010 SP1 on your Edge server if the latter is running of Forefront TMG.

On the other hand, I have installed Exchange 2010 SP1 on several Mailbox/CAS/HUB servers without issues.

Updates:
This has been confirmed by Microsoft Exchange team and the TMG Product team

As you might know Microsoft didn't release migration tools from Lotus to Exchange 2010 directly so the path was Domino -> Exchange 2007 and then Exchange 2007 -> Exchange 2010.

Since Exchange 2007 SP3 has been released a couple of days ago I've installed it on, what I was planning to be, a temporary server.

I was surprised today that I was not able to install Exchange 2010 and setup.com /PrepareSchema failed with the following error.

Setup encountered a problem while validating the state of Active Directory. The Active Directory schema version (14625) is higher than the Setup’s version (14622). Therefore, PrepareSchema can’t be executed.

I have searched but didn't find anything about this error online, however my best guess is that Exchange 2007 SP3 raised the schema version to 14625 which is higher than the Exchange 2010 RTM schema version 14622. Looks like I'm stuck with Exchange 2007 SP3 untill Exchange 2010 SP1 is out of beta !

Edit July 30, 2010
Looks like this is becoming more popular and has been blogged about here and here

We have seen in part 1 of this tutorial the classical approach to single mailbox recovery from backups using Exchange 2010 and how this method can only restore the mailbox content to a new structure and this could be annoying for some.

Analyzing the findings of our first approach we can deduce that the problem lies behind the fact that the new mailbox of user2 has a different GUID than the one in the backup. So, logically, changing the GUID of the new mailbox and setting it to the same as the one in backup should solve the issue right ?

Let's see how we can accomplish this to make the magic happens.

Disclaimer:This article contains steps that tell you how to use ADSIEdit.msc. However, serious problems might occur if you use it incorrectly. Therefore, make sure that you follow these steps carefully and I cannot be held responsible for any damage you might bring do to your system.

Retrieving the GUID of the backed up mailbox

The plan sounds very simple but putting into action is just a bit more complex. We need first to get the GUID of the mailbox that was backed up and is currently mounted in the "Recovery Database". This can be done using Exchange Management Shell by running

Get-MailboxStatistics -Database RecoveryDatabase | fl DisplayName,MailboxGuid

Finding the GUID of the new mailbox

We should now find the GUID of the new mailbox of user2. To do so we will use the ADSIedit.msc

1. Run ADSIEdit.msc
2. Connect to the "Default Naming Context"



3. Browse to where is located the user you are trying to recover



4. Right-click -> Properties
5. Find the MSExchMailboxGuid attribute

Analyzing the MSExchMailboxGuid attribute

If you click on the edit box and compare both MSExchMailboxGuid values, the one showing outside and the one in hexadecimal format, you will notice they do not match one to one.

Here is how to convert from one value to the other.
The "dashed-value" of user2 mailbox is 22ecdf44-d001-4486-bb73-538a3d86d8d5
Take each portion before the 3rd dash and write down the bytes backward for example
22ecdf44 will become 44 DF EC 22
d001 will become 01 D0
4486 will become 86 44
then take the last two portions as they are: BB 73 53 8A 3D 86 D8 D5

So the Hexadecimal value of
22ecdf44-d001-4486-bb73-538a3d86d8d5 is 44 DF EC 22 01 D0 86 44 BB 73 53 8A 3D 86 D8 D5

Let's apply the same logic on the GUID retrieved from the backup

9d9c537a-9c00-4949-a7c8-9c62b5a2d48e to get its hex value:
7A 53 9C 9D 00 9C 49 49 A7 C8 9C 62 B5 A2 D4 8E

Insert the calculated hexadecimal value to replace the current user2 mailbox GUID.

Recovering the mailbox

It is now time to test and see if what we did was fruitful, so let's go to Exchange Management Shell and run again

Restore-Mailbox user2 -RecoveryDatabase recdb

As you can notice the command will finish without any errors, and logging to user2 mailbox will show the mailbox fully recovered with all items back in their original place.

Conclusion

In this 2 parts tutorial I have went through all steps required to recover a single mailbox from backup when running Microsoft Exchange 2010. In part 1 I have covered the "traditional" way to do it and showed how the items will be recovered in a side folder structure, in part 2 I have showed you have you can use ADSIEdit to change the GUID of the user's mailbox to be able to recover items to their original location.

Hope you enjoyed the article.

Part 1 - Backup Exchange 2010 for free (at simple-talk.com)
Part 2 - Restore Exchange 2010 (at simple-talk.com)
Part 3 - Single Mailbox Recovery in Exchange 2010 - Classical approach
Part 4 - Single Mailbox Recovery in Exchange 2010 - Magic

I have written a 2 part tutorial at simple-talk.com about Microsoft Exchange 2010 Backup and Restore in which I have covered all steps needed to successfully backup your database as well as different recovery scenarios. This article can be looked at as an extension of the recovery process, part 2, and will cover the case when a single mailbox needs to be recovered from the backup.

I would like to stress first that it is not usually needed to recover a single mailbox from a backup when running Microsoft Exchange 2010 because deleted mailbox can be found in the "Disconnected Mailboxes" under "Recipient Configuration" and can simply be reconnected. However if you are just curious to learn or you are in need to recover a single mailbox for whatever reason keep on reading.

I will assume in this article that you are already familiar with the backup and restore process and that a successful full backup of the database already exists.

Scenario Preparation

Let's first take a look at the the mailbox of user2, you will notice a couple of emails and one of them dating after the last successful backup.

Great! I will now delete the mailbox of user2 and make sure it is not recoverable by purging it from the disconnected mailboxes.

To do so I started by getting the deleting the mailbox of user2 Exchange Management Shell

Disable-mailbox user2

As expected the mailbox is now found in the disconnected mailboxes

To purge it we will need first to get the mailboxGuid of all disconnected mailboxes and then force delete it. This can only be done using Exchange Management shell with the below commands

 Get-MailboxStatistics -Database "MBsrv2" | ?{$_.DisconnectDate -ne $null} | fl DisplayName, MailboxGuid
 Remove-Mailbox -Database "MBSrv2" -StoreMailboxIdentity "MailboxGuid" -Confirm:$False

Searching again for disconnected mailboxes will return empty results proving the mailbox is really purged and only recoverable by restore.

Mailbox Recovery

Now that we have messed things up it is time to restore, for this scenario follow the same steps as highlighted in "Emails recovery" section of my restore article. I will pick it up here from the point where the recovery database was successfully mounted.

The first thing I was tempted to try was to simply issue

Restore-Mailbox user2 –RecoveryDatabase recdb

This failed without a doubt since user2 now has no mailbox

Creating a new mailbox for user2 and trying again also failed, obviously because the mailbox GUID has changed.

My next step was simply "going by the book" and using the following Exchange Management Shell command

Restore-Mailbox user2 -RecoveryDatabase recdb -RecoveryMailbox user2 -TargetFolder "recover"

This worked OK, as you can see all items, but the email that was sent after the backup was taken, were recovered however not in their original location rather in a new tree under the specified "Recover" folder.

Conclusion

Even though we were able to recovered all backed items of a mailbox using method highlighted in this article I was still not satisfied with the results. The fact that restored items showed up in a different tree would, of course, be beneficial in most cases but won't be an acceptable solution for the majority of my clients. I needed a "real" mailbox recovery to convince them.

I will show you, in part 2 of this article, how to accomplish a mailbox recovery as if the mailbox was never deleted so stay posted.

Part 1 - Backup Exchange 2010 for free (at simple-talk.com)
Part 2 - Restore Exchange 2010 (at simple-talk.com)
Part 3 - Single Mailbox Recovery in Exchange 2010 - Classical approach
Part 4 - Single Mailbox Recovery in Exchange 2010 - Magic

To add a entry

$SafeSenders = (Get-ContentFilterConfig).bypassedSenders
$SafeSenders.Add("user@safedomain.com")
Set-ContentFilterConfig -BypassedSenders $SafeSenders

To remove an entry

$SafeSenders = (Get-ContentFilterConfig).bypassedSenders
$SafeSenders.Remove("user@domain.com")
Set-ContentFilterConfig -BypassedSenders $SafeSenders

To backup the list

Of course you can use the ExportEdgeConfig.ps1 script to do it, however you might want to backup just the sender safe list in that case use the following script

(Get-ContentFilterConfig).bypassedSenders | export-csv c:\SafeList.csv

To restore the list

Set-ContentFilterConfig -BypassedSenders:$null
$SafeList = (Get-ContentFilterConfig).bypassedSenders
import-csv C:\SafeList.csv | foreach{ $email = $_.local += "@"; $email += $_.domain; $SafeList.add($email)}
Set-ContentFilterConfig -BypassedSenders:$SafeList

Don’t wait for the weekend to get the hottest links. You can get them fresh by following us on twitter

However I have faced a strange issue with Exchange Web Services and coexistence of Exchange 2007 and 2010. Since it is clearly stated on technet that

Clients that use Exchange ActiveSync, Exchange Web Services, POP3, and IMAP4 can't use redirection.

I thought it is safe to assume that EWS traffic will be proxied just like it is the case of ActiveSync, POP3 and IMAP4. My thoughts were further confirmed by the same technet article stating that Proxying supported between Client Access servers in the same Active Directory Site for the Exchange Web Services protocol (check section "Client Access protocols for redirection and proxying"), but obviously my thoughts were wrong!

Doing some tests with requests hitting the Exchange 2010 CAS server & using the famous test exchange connectivity website showed failures for users who's mailboxes are still on Exchange 2007 with the following error, while the test passed for users who's mailboxes are now on Exchange 2010.

The Client Access server version doesn't match the Mailbox server version of the resource that was being accessed. To determine the correct URL to use to access the resource, use Autodiscover with the address of the resource.

So it seems that the only way for EWS to work in a mixed Exchange 2007-2010 environment is that the application itself should support Autodiscover.

This is bad news, it means that my client will need to edit manually the settings for all its Blackberry Internet Service (BIS) users!

At this point I am still unsure if it is a bug but it looks like one, so if someone has more insight about it I would really appreciate the feedback.

Cluster IP address resource 'Cluster IP Address' cannot be brought online because the cluster network 'Cluster Network 2' is not configured to allow client access. Please use the Failover Cluster Manager snap-in to check the configured properties of the cluster network.

Open the Failover Cluster Manager go to Networks and select the faulty network reported in the above error. You will notice that "Allow clients to connect through this network" is enabled.

This seems to be a bug and the solution is pretty easy, you just need to deselect "Allow clients to connect through this network", click on Apply, select it again and apply once more the new configuration, this should take care of the error right away.