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:

HKLM\System\CurrentControlSet\Services\MS Exchange OWA\InstantMessaging.

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:

(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 Files\Microsoft\Exchange Server\V14\ClientAccess\OWA 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.

Found this useful link on a blog by the good people at communicationsserverteam.com and thought it was worth a mention.

Article: http://communicationsserverteam.com/archive/2010/01/25/726.aspx

Basically free high-level overview for following features:

• Instant Messaging
• Presence
• Contact Management
• Audio and Video
• Desktop Sharing
• Office Application Integration
• Add a Live Meeting
• Communicator Web Access

You can register for these sessions on the following link:

https://events.livemeeting.com/967/15027/reg.aspx?pc=05

Neil Cruickshanks

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:\Support\UM,Language,Packs\fr-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

Server 2008 AD schema onwards has a very cool feature called fine-grained password policies, these can be a bit arduous to setup, the easiest way that I’ve found to set them up is to create an ldifde answer file and import them using that.  In this example I’m creating a password policy called ServiceAccounts and applying it to the group called ServiceAccounts. 

dn: CN=ServiceAccounts, CN=Password Settings Container,CN=System,DC=robsdesk,DC=com
changetype: add
objectClass: msDS-PasswordSettings
msDS-MaximumPasswordAge:-1728000000000
msDS-MinimumPasswordAge:-864000000000
msDS-MinimumPasswordLength:8
msDS-PasswordHistoryLength:0
msDS-PasswordComplexityEnabled:TRUE
msDS-PasswordReversibleEncryptionEnabled:FALSE
msDS-LockoutObservationWindow:-18000000000
msDS-LockoutDuration:-18000000000
msDS-LockoutThreshold:5
msDS-PasswordSettingsPrecedence:20
msDS-PSOAppliesTo:CN=ServiceAccounts,OU=DomainManagement,DC=robsdesk,DC=com

Execute this command:

Ldifde -i -f pso.ldf

This will create a policy with the following attributes:

• Maximum password age of 2 days
• Minimum password age of 1 day
• Minimum password length of 8 characters
• Password history
• Require complexity
• Store with reversible encryption
• 30 minute lockout observation window
• 30 minute lockout
• Lockout after 5 failures
• Precedence of 20 – like MX records the lowest ‘cost’ comes first.

Make accounts you want to apply the policy to a member of the group.  You can edit the settings in the policy using ADSIEdit by navigating to the Password Settings Container within the System container. 

More detail can be found here: http://technet.microsoft.com/en-us/library/cc770394(WS.10).aspx

Cheers,

Rob

Quick post and run but worth bearing in mind, if you’re doing FBA on TMG & are offloading SSL before the TMG box there’s a reasonable chance that you may not have any certificates installed on your TMG server.  If this is the case users will not be able to change their passwords & those with password must be changed at next login will not be able to log in. 

This is because the TMG server needs to be able to open an LDAPS connection to a DC to do the password change, the S in LDAPS stands for secure, no certificate = not secure.  Install certs, reboot & all is well in the world again.