outlook web access

All posts tagged outlook web access

Make OCS client available in OWA

Since Exchange 2007 it’s possible to use your OCS and Exchange together. First you had only the option to use your OCS environment with the Exchange UM server which let you use the voicemail, subscriber access and auto attendant features from Exchange in OCS

The latest addition to this is a limited OCS client integrated in OWA. This gives you the ability to send IM messages via OWA and gives you the option to see precense information.

In this tutorial I will explain how you can install this new feature.


Make OCS client available in OWA

Microsoft has released OCS 2007 R2 Web Service provider a while ago, with this piece of software you will make a limited OCS client available via OWA. In this tutorial I will explain how you can get the OCS client working together with the OWA from Exchange 2010. You can download the software using the link below:

Before installing the software make sure you have a certificate installed which is trusted by the OCS server. When you’ve downloaded the requested files you can start installing them. The file CWAOWASSPMain contains four seperate files and the patch file consists of one MSP file, the files need to be installed in the following order:

  • vcredist_x64
  • UcmaRedist.msi
  • UcmaRedist.msp

When the files are installed it’s time to build the configuration. First we need to gather some information about the certificate being used by the IIS service, you can do this by running the following command in Powershell get-exchangecertificate |fl. You will get an overview of all installed certificates on the CAS server search for the one that is used for IIS, this one can be recognized by checking the entries after the services label. From this certificate we need the values of two fields:

  • Issuer
  • SerialNumber

Now we copied the values it’s time to make the modifications to the OWA configurationfile, you can find it in the following directory c:\Program Files\Microsoft\Exchange\v14\ClientAccess\Owa. Here you will find web.config , which contains the configuration for Outlook Web Access. Before modifying it create a backup of the file, this will let you quickly restore to the original configuration in case OWA doesn’t work anymore after the modifications. Then open the web.config using a text editor such as Notepad and search for the line containing the following word IMPoolName this is the firstline of the section which needs to be changed. Once found change the following lines:

  • IMPoolName: fill in the name of the OCS pool
  • IMCertificateIssues: use the value just copied from issuer, example: CN=company-DC01-CA, DC=Company, DC=Local
  • IMCertificateSerialNumber: use the value justr copied from serialnumber, example: 61580B7D00000000000E

Once done save the file. Next step is to add the OCS client to the OWA, this can be done by using the Set-OwaVirtualDirectory –InstantMessagingType. On the internet you will find several stories about the value that needs to be entered after the InstantMessagingType parameter. The Technet documentation will tell you to use the OCS parameter but in some cases this won’t work according to several forum posts i found. If this is the case try 1 as the value for the parameter and check if it works. Although I don’t think the parameter is the issue since I’ve tried it in a working environment and Exchange gave the message that nothing had changed. To activate OCS in OWA you will need to run the command below to set the InstanteMessagingType parameter:

set-owavirtualdirectory -InstantMessagingType 1


get-owavirtualdirectory -server servernaam |set-owavirtualdirectory -InstantMessagingType 1

The Exchange side is completed, now it’s time for the OCS side. For this you will need to open the OCS administration tool and get the Front End properties of the pool. Here you will find the authorized hosts tab. Here you will need to add the following items:

  • FQDN of OWA

When the fqdn has been added restart the Front End service to make the modifications active. Once the service is started again you will see the OCS client once logged in using OWA.

As you can see you can set your own status and see the status of other users. Besides this the left menu has been extended with a contactlist which corresponds with your contactlist in the MOC client.

It’s time for the 3rd article about Exchange 2010 Beta, in this article we will have a closer look Outlook Web Access Mailbox Policies. In Exchange 2007 configuring which features you want to activate in OWA could only be done per user or global on the OWA itself, in Exchange 2010 Beta there’s a new features called: Outlook Web Access Mailbox Policies. With this policies you can deactivate items for users. When selecting the CAS server under the Organization Configuration you will see two tabs instead of one tab, just as in Exchange 2007.

Outlook Web Access Mailbox Policies

Default there is only one policy called default, in this policy all features are enabled. If you would like to change this you can create a new policy or change the default policy. When creating a new policy you will see the following screen:

Create new Outlook Web Access Mailbox Policy

The only thing you will need to define is a name for the policy and which features you would like to deactivate, default all options are enabled.
When finished configuring the policy just push the new policy and the policy is created.

New Outlook Web Access Mailbox policy created

When the policy is created the only thing you will need to do is assign the polocy to users. This can be done by selecting a user below the recipient configuration option, get the properties of the user and select the tab  mailbox features:

Mailbox features

Here you will see all connection possibilities that a user has to access his/her mailbox, select Outlook Web Access and select properties

Outlook Web Access Properties

In the new opened window you can assign Outlook Web Access mailbox policy to the user. For this you will need to do two things place a checkmark before Outlook Web Access mailbox policy and choose the policy which you like to assign to the user by selecting the browse button.

Many people will use the Outlook Web Access (OWA) functionality. The default language is set to 0 this will ensure that users will be prompted the first time they login to define the default language. Users can change this later by going to the regional settings in OWA.

Administrators can prevent this by defining a default language on the CAS server. This can be done by executing the following command:

Set-OWAVirtualDirectory -Identity “Company\owa (default web site)” -DefaultClientLanguage 1043

The command above will set the language to Dutch, this is done by the code 1043. A full overview of all codes can be found on the page at the end of this post.

Besides this setting the language of the loginpage and error messages can be changed. Default the value is 0, in this case the language configured in Internet Explorer will be used. When the language isn’t supported on the CAS server the default language from the CAS server will be used.

If you would like to change the default language to for example Dutch you will need to execute the following command on the CAS server:

 Set-OwaVirtualDirectory -identity “Owa (Default Web Site)” -LogonAndErrorLanguage 1043


Outlook Web Access

It’s time for a new tutorial, this one goes about Outlook Web Access. In this tutorial I will discuss allthe possibilities that you can configure including some certificate things. I’ve seen there where some typo’s in some English tutorials sorry for that, I think I wanted to translate them to fast 😉 I will soon fix all the errors on it, sorry for the inconvenience.


When you have played with Exchange 2007 and Outlook Web Access earlier you may have seen a lot of differences between Outlook Web Access 2007 and 2003. There have been added nice features to the new version of OWA such as: you can access a file-server/sharepoint-server, you can restrict what files can be opened via OWA and how they are opened then.

Users can only use these functionalities if their mailbox is hosted on an Exchange 2007 mailbox server. The users who have their mailbox on an Exchange 2003 server will use the old version of OWA.

The OWA functionalities are delivered by the Client Access Server (CAS) if you had an Exchange 2003 environment running with OWA this functionality was provided by the Frontednd Server. When we zoom in to the Exchange Management Console en then have a close look ath the server configuration of  the CAS server you will discover that it hosts mutiple websites:

The three that are important for Outlook Web Access are:

  • owa, this is the 2007 version of OWA
  • exchange, this is the 2003 version of OWA
  • exchweb, this site contains most functionalities of OWA

Now you may ask yourself, what are those other directories used for:

  • exadmin, this folder willl be used when you manage Public Folders from the Management Console
  • public, this folder will be use when opening a Public Folder via OWA

We will restrict this tutorial to OWA 2007 only, so we will get the properties of the site named owa.

The first tab we see is general:

You can’t change much on this tab, it contains some information you may find interesting:

  • which server is hosting the OWA
  • under which website the OWA is placed
  • for which Exchange version this OWA is responsible
  • when has the website changed

There are two fields which you can fill in:

  • internal url, here you need to define the url which users on the internal network use to access the OWA
  • external url, here you need to define the url which users on the internet use to access the OWA

You need to pay attention to the url’s when you are going to buy certificates that you buy one for the correct url.

The next tab is authentication on this tab we can setup the way the user has to login to OWA. The default setting is Use form-based authentication below this option you can choose three methods to fill in the username:

  • Domain\username, the user logs in like this test.local\johan
  • User Principale Name, the user logs in like this johan@test.local
  • User Name Only, the user fills in his username, in this case the field logon domain contains the domain where the user needs to login.

The next tab is segmentation on this tab we can control what options end-users will get when they use OWA. You can for example block the ActivSync integration or prevent the password changing in OWA.


On the tab Public Computer File Access you can decide how OWA will react if a user tries to open an attachment while logged into OWA from a public computer:

  • OWA needs to convert the file via the Web ready functionality
  • OWA needs to prevent the opening/downloading of the file
  • OWA allows to open/download the file


As you can see it has been changed a lot compared to OWA 2003. The first option enable direct file access let you configure which files the end-user may open without using the Web ready functionality. When you click on the customise button you can change the files allowed or blocked:

  • allow, which files with the extension/mime-code may be opened
  • block, which files with the extension/mime-code may not be opened
  • force save, which files with the extension/mime-code first need to be saved before opening.
  • unknown files, what does OWA need to do with  “unknown” files

You see there are a lot of possibilities and you can really make changes to allow or block a file. The default settings are quite good, if you won’t allow mp3’s being opened via OWA then you need to delete it from the allow list. The option unknown files will be used when an extension/mime-code is not defined in the other 3 lists. The  default option for unknown files is Force Save which tells OWA to first let the user download the file before opening it.

Another new feature in OWA is WebReady Document Viewing, this function will convert a file to a webpage with the build-in convertors. Normally this shouldn’t be the case because the option Force WebReady Document viewing when a converter is available is disabled. OWA contains converters for the following filetypes:

  • Excel files
  • Word files
  • Powerpoint files
  • PDF files

I think this are the most used files which you want to open using this new function.  You don’t need to have the application installed locally on your pc/laptop.

The last two options on this tab make it possible to open files on remote file servers. With remote file servers you are able to open files on:

  • Windows File Shares
  • Windows SharePoint Services

The remote file servers need to defined on another tab called remote servers this will come later on in this tutorial.

The next tab is Private Computer Access with this tab you can configure the same things as on the tab Public Computer Access only then for trusted computers/laptops. Default there are a few settings that are not the same as on the tab Public Computer Access for example the options to access Windows File Shares and Windows SharePoint Services is enabled.

On the last tab remote file servers you can setup which servers are accessable via OWA. You can easily set this up by adding a server to one of the two lists. It would be a lot of work to add all the file-servers that you want to block and for example allow only one. For this case you can use the option unknown servers the action defined there will be used for every server who isn’t listed on the allow or block list. Default the action is block.


As you can see there is only one button left that we didn’t spoke about. The button configuration on the bottom of the tab. With this button we need to specify which domains need to be seen as internal domains. When a server is added from a domain that is not listed OWA will not see it as an internal server and will block access to it.

We now have spoken about all the tabs of OWA. The other things such as certificates will be handeled via the Powershell and IIS admin MMC.

When OWA is published on the internet it may be necessary to use a 3rd party certificate for the OWA, you can buy a certificate with for example VeriSign. OWA 2007 uses https and form-based authentication by default. Here a self-signed certificate is used, which can result in warnings from webbrowsers.

You will have to add a copy of the self signed certificate to the trusted root authority to prevent this error. You can get a copy of this certificate in two ways:

  • via the website itself and then import it into the right store
  • by exporting it via Powershell and import it in the right store

First via the website itself:

  • go to the website
  • click on continue when the warning is displayed.
  • click on the certificate error button in the addressbar
  • click on display certificate
  • click on install certificate
  • choose the option to save all certificates in the archive below
  • select the trusted root authority via the browse function
  • click on next en finish
  • a warning will be displayed that you are importing a certificate, accept it
  • a message will be displayed that the certificate is installed

All the steps above can be done on a client. All the steps below need to be executed from the CAS server:

  • execute the following domain: Get-ExchangeCertificate -DomainName mail.test.local
  • an overview will be displayed with all certificates that are used by mail.test.local
  • then we need to export the certificate: Export-ExchangeCertificate -Thumbprint 5113ae0233a72fccb75b1d0198628675333d010e -BinaryEncoded:$true -Path c:\certificates\export.pfx -Password:(Get-Credential).password
  • when this command is executed it will prompt you for a username and password. The password is the only thing that is necessary to export and import the certificate.
  • the last step is importing the certificate in the trusted root authorities on the client, optionally this can be done via a Group Policy.

Both warnings will result in not displaying the message anymore. When a 3rd party certificate will be installed the steps above are not needed. The only thing you should arrange is that you trust the root certificate from the 3rd party.

When you choose to get a certificate from a 3rd party we first need to create a CSR and after that when receiving the file from the 3rd party install it.:

  • start Powershell
  • run the following command: New-ExchangeCertificate -DomainName test.ocal -Force -FriendlyName OWA -GenerateRequest:$True -Keysize 2048 -Path c:\owa.req -privatekeyExportable:$true -SubjectName “C=NL, O=Test, L=Utrecht, S=Utrecht, CN=owa.test.local”
  • this command will generate a CSR to get a certificate
  • when we receive the certificate from the 3rd Party we need to install it
  • importing is done by the following command: Import-ExchangeCertificate -Path c:\certificaat.crt | Enable-ExchangeCertificate -Services “IIS”
  • with the parameter-Services we can tell Exchange that this certificate may only be use for IIS in this case. Other options are SMTP, IMAP and POP3.

If everything is configured we can check if OWA is working OK, this can be done in two ways:

I use OWA 2007 for a few months now and I must say it’s working really good. I hope you have learned something from this tutorial.

A new feature within Exchange 2007 is message classification. With this you can assign a classification to an e-mail and for example create a transport rule which blocks e-mails of certain classifications.

This functionality can only be used in combination with Outlook 2007 client and Outlook Web Access. Default Exchange 2007 contains 5 message classifications:

  • A/C Privileged
  • Attachment Removed
  • Company Confidential
  • Company Internal
  • Partner Mail

You can get the current message classifications by executing the following Powershell command:


This will give the following result:

You can make new message classifications with the following command new-messageclassification and a few parameters.

new-messageclassification -name Marketing  -DisplayName “Marketing Confidential” -SenderDescription “This classification must be used by the marketing department”

In the example above we will create a new message classification named Marketing.  After that we assign the name that will be displayed in the client as Marketing Confidential  and with the last parameter senderdescription we can give a short description of the classification which will be displayed to the user when selected.

This classification will be used for all languages including Dutch. You can type the senderdescription in Dutch, but you can also add multiple languages. The client will then decide which language it needs, looks if it is available and if it it will display the correct language.

new-messageclassification -Identity Marketing -Locale nl-NL -DisplayName “Marketing NL” -SenderDescription “Deze classificatie mag alleen gebruikt worden door de marketing afdeling”

With the parameters above we will create a Dutch message classification for the earlier created message classification Marketing. That this one is only for dutch is because we specified the parameter -Locale  followed by the language. With the parameter identity  we select the original message classification Marketing. De other parameters displayname and senderdescription have both the same function as when creating a new message classification.

Default all users can use a message classification, you can prevent this:

get-messageclassification Marketing -IncludeLocales |Remove-AdPermission -User AU -AccessRights GenericRead -InheritanceType None

With the command above we remove the right the authenticated users have on the Marketing message classification.

get-messageclassification Marketing  -IncludeLocales | Add-AdPermission -User “domainname\Marketing” -AccessRights GenericRead -InheritanceType None

Next step will be to assign read rights to the members of the group Marketing to the Marketing message classification.

There are a few thinks you should keep in mind when you are gone use message classifications. In OWA it will work but in Outlook 2007 you can’t totally prevent users from using a message classification. This is because users can modify the file Classifications.xml which will allow them to add the message classification to their client.

But it is a way to make it more difficult for a user to use it.

In the previous part we spoke about message classification in Outlook 2007. In OWA you don’t have to configure anything for message classification but for Outlook 2007 you need.

Configuring Outlook 2007 takes two steps:

  • create registry keys
  • create classifications.xml

Before you using the classifications.xml you need to create the registrykeys as displayed below:


“AdminClassificactionPath”=”c:\\Program Files\\Office\\Classifications.xml”



All the parameters are logical, except the last one. The parameter TrustClassifications only needs the value  00000001 when the mailbox of a user is placed on an Exchange 2007 server.

The last step is creating the classifications.xml file. This step needs to be performed on the Exchange 2007 server. Microsoft has developed a standard script for it and placed it in the script directory of Exchange 2007, it called Export-OutlookClassification.ps1

./Export-OutlookClassifications.ps1 > c:\export\classifications.xml

Make sure the folder to which you want to export exists, else you will get an error message The command above will create a xml file called classifications.xml in the export directory.

You can also choose to only export the Dutch language message classifications:

./Export-OutlookClassifications.ps1 -Locale “nl” >Classifications.xml

As you can see only nl is used instead of nl-NL both are the same, for a full overview have a look at this  page.

Message classifications can be used in transport rules. You could do a check if a message is marked with a specific message classification and block the e-mail.

Besides that option you can also let a transport rule assign a classification to a mail according to the conditions you specify.