What can you do if the Public Certificate you are using on your Edge server(s) is not trusted by Office Communicator 2007 Phone edition? The public certificate is not trusted because its corresponding Root CA certificate is not installed on the device per default. In this post I describe how to make Root CA certificates available on the device.
You can use the certutil mechanism to install the Public Root CA certificate. First you download the certificate from the CA's web site. Then you use the certutil command to publish the certificate to your Active Directory. It will be added as an object under CN=Certification Authorities, CN=Public Key Services, CN=Services, CN=Configuration, DC=<domain>, DC=<tld>. You can add multiple Root CA certificates using this method. The device will download all the certificates found.
After the public Root CA certificate is published you will have to connect the device once to the internal network to get the certificate downloaded. Before you do that you need to reset the device to clear the certificate store, since you need the device to ask for certificates (if you didn't do this the device would use the currently installed certificate when challenged by your internal OCS servers and not search for them in Active Directory). You reset the device by inserting a paper clip in the small hole on the back between the USB and headset connectors. Afterwards you can connect the device to the Internet and it will connect to the Edge server.
PS: The above only works if the device is able to get to your Active Directory domain controller and the way it finds that is through DNS or NetBios. Please make sure this works by following the steps in this document. If you are using UPN style username and the certificate download fails try to use <domain>\<username> style login.
As a user of OCS 2007 you have the ability to receive Missed Call Notifications. How the Missed Call Notification is generated depends on the configuration of the user in question. Let's examine the different options.
Enterprise Voice with Exchange 2007 SP1 Unified Messaging (UM)
As an Enterprise Voice enabled user with voice mail coming from Exchange 2007 SP1 UM you can receive Missed Call Notifications and Voice Mails in your Exchange 2007 mailbox, when someone has tried to call you from either Office Communicator 2007 (OC), Office Communicator 2007 Phone Edition (OCPE) or from the PSTN/PBX. The Missed Call Notifications and Voice Messages are generated by Exchange 2007 SP1 UM.
The Missed Call Notifications can be generated in two ways depending on the state of the call when the caller hangs up. The states, for a user online with OCS 2007 and without call forwarding active, are:
- OCS 2007 rings all registered end-points for the user
- After a user defined time-out the call is forwarded to Exchange 2007 SP1 UM
- Exchange 2007 SP1 UM connects the call and plays the greeting and ask the user to leave a voice mail
- The voice mail is recorded and sent
If the caller hangs up in state 1 or 2 the call is still under control by OCS 2007. OCS 2007 will process the hang up and send a SIP INFO message to Exchange 2007 SP1 UM and instruct it to send a Missed Call Notification message to the called user. The SIP INFO message contains information about who is calling and who is called. Exchange 2007 SP1 UM will do reverse number lookup in AD and the called user's Outlook Contacts and will generate the Missed Call Notification message.
If the caller hangs up in state 3 the call is under control by Exchange 2007 SP1 UM and Exchange 2007 SP1 UM will do reverse number lookup in AD and the called user's Outlook Contacts and will generate the Missed Call Notification message.
If the call is in state 4 the called user will only a receive a Voice Mail message and no Missed Called Notification.
If the user is offline or with call forwarding set directly to Voice Mail the call will be routed directly to Exchange 2007 SP1 UM and go to state 3 in the above list.
Enterprise Voice without Exchange 2007 SP1 UM or Remote Call Control
As an Enterprise Voice enabled user without voice mail or a Remote Call Control user you can receive Missed Call Notifications in your Exchange mailbox. The Missed Call Notification is generated by OC 2007 via MAPI. The Missed Call Notification is only generated when OC 2007 is running. Microsoft Outlook does not need to be running.
Enterprise Voice with PBX Integration
As an Enterprise Voice with PBX Integration enabled user the generation of Missed Called Notification is the responsibility of the PBX system. OCS 2007 and OC 2007 will not generate Missed Call Notifications.
We have released a new update for Office Communicator 2007 Phone Edition powered devices - http://support.microsoft.com/default.aspx?scid=kb;EN-US;949659. The image version is now 1.0.522.71.
Sometimes, when you upload a new .cab file for Microsoft Office Communicator 2007 Phone Edition or Microsoft RoundTable using the OCS 2007 Software Update Service Management Console Upload Software feature, the upload fails with an HttpException and the message Request timed out in the event log. The actual exception might vary, but the real reason is typically lack of resources on the WSS server. The resources lacking might be memory or CPU or a combination of both. You typically get the exception because the upload of the .cab times out. If you run into this try to add resources, i.e. more memory or more CPU capacity. If that is not possible here are a couple of tips you can use to increase the various time-outs.
On the server running the OCS 2007 Software Update Service Management Console you can edit the web.config file found in C:\Program Files\Microsoft Office Communications Server 2007\Web Components\UC Device Updates\Management Console. The web.config file controls the .NET requests the Management Console is using to talk to the WSS server. The web.config is per default read protected, so you have to make it writeable before editing it. In the file is a XML section called httpRuntime. This is the section you can tune. HttpRuntime is described here http://msdn2.microsoft.com/en-us/library/e1f13641(VS.71).aspx. In my test environment I'm using the following settings <httpRuntime maxRequestLength="900000" executionTimeout="300" appRequestQueueLimit="30"/>. This mean that the client will time-out after 300 seconds or 5 minutes.
Now you have changed the client time-out, but you typically also need to change the server side time-out on the WSS server. This is done by tuning the IIS time-out setting. The default is 120 seconds, but you can increase that by using the instructions in http://support.microsoft.com/default.aspx/kb/925083. On my test system I use 300 seconds. After changing the time-out stop and restart the web site hosting WSS.
Update 21-JAN-08: The above tuning is not the complete fix. The code itself is using other timeouts. We are investigating this and will report back.
Update 28-FEB-08: Please install the build released today http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=889c542e-8b09-46c2-bd86-671c21668830. It should fix the issue with .cab upload error.
Exchange 2007 SP1 UM provides voice mail functionality for OCS 2007 users when they are Enterprise Voice enabled. How is it possible to provide Exchange 2007 SP1 UM fault-tolerance for these users?
Exchange 2007 SP UM and OCS 2007 are integrated at the UM dial plan level. A given UM dial plan can be served/hosted by multiple UM servers. Do provide fault-tolerance you implement two or more UM servers and assigns the OCS integrated UM dial plan to all of them.
How can OCS 2007 use these UM servers in a fault-tolerant way?
OCS 2007 discovers UM users, UM servers and UM dial plans from Active Directory. It finds the UM dial plan of a user by looking at the EUM proxy address of the user, ie. the user with the SIP URI tu@contoso.com has as one of his proxy addresses EUM:tu@contoso.com;phone-context=Hellerup.contoso.com. The value of phone-context is the name of the UM dial plan. By looking at the UM dial plan attribute msExchUMServerDialPlanBL OCS 2007 gets the list of the UM servers servicing the dial plan. Let's call that list the "working set".
OCS will randomly contact one of the UM servers in the "working set". If that fails it will try a second one. If that also fails it will give up and the call can't be completed. A failed UM sever will be removed from the "working set". OCS will incrementally throttle traffic to the failed UM server and when it replies positively it will be included in the "working set".
Microsoft Office Communicator 2007 (OC) enables you to drive your presence from information in your Outlook calendar. If the Outlook calendar has a meeting OC will change your presence to be "In a Meeting". If the Outlook calendar has an appointment OC will change your presence to be "Busy". Depending on the access level other OC users are also able to see the Subject and Location of your meeting. The Enhanced Presence Model document contains information about this.
How is it working? Are the OC users looking up Exchange Free/Busy information about each other? Do you need to give other users special permissions on your calendar? These are some of the questions I'm being asked. Let me try to explain how it works.
OC is publishing its calendar information to the OCS server in the so called presence document and the information is stored on the OCS server in the SQL database. It is made available to other OC users who are subscribing to the information or just asks for it for instance by hovering over the user in the To field on an email. On the publisher you can see the data you are sending by hovering over the presence state. See the screen shot 
where Test User Sixtyfour is in a meeting in the location "Hellerup Saratoga" and the subject of the meeting is "test of subject from OC".
The subscriber of the presence information can see the calendar information by open the Contact card of the user and hover over the calendar information on the contact card. See screen shot. 
When OC publish calendar information it associates an expiry time for all the information. For the calendar information the expiry time is set to endpoint. That means it will expire as soon as the endpoint signs out of OC. At that point the OC publisher will be in the offline state and subscribers can't see his Outlook calendar information.
To understand a bit more on how OC is sending the meeting data information I enabled logging in OC and looked in the resulting uccp logs. The publisher will sent out a SERVICE SIP message with embedded XML. The publisher XML looks like this 
. The subscriber will get a BENOTIFY SIP message with embedded XML and it looks likes this 
OC publish calendar information for 128 15min slots (8,5 hours) in advance. It is refreshing the calendar information if needed each 30 minutes (configurable via GPO) or on sign in. To learn more about the exchange of presence information using XML data see Unified Communications Enhanced Presence Schemas for Microsoft Office Communications Server 2007.
In summary to answer my own questions from above: No, OC users are not accessing free/busy information for each other and hence No, you don't need to give special permissions on your calendar.
When implementing Enterprise Voice in OCS 2007 the assumption is that each user homed on OCS will have his/her own dedicated phone number directly reachable from the PSTN, a so called Direct Inward Dialing (DID) or Direct Dial-In (DDI). It is the DID defined for the user in E.164/RFC 3966 format in the msRTCSIP-Line attribute, i.e. tel:+4544890101. Some customers might not have a DID for each user. In stead they have 1 DID for the company, i.e. the main number, and all recipients have a unique extension assigned. An Interactive Voice Response (IVR) system or a switch board operator answers the main number and redirect the calls to the recipient.
So how could you implement Enterprise Voice in such a scenario? In a non-DID scenario you will have to define the msRTCSIP-Line attribute for each user in the format tel:+<main number in E.164>;ext=<extension>, i.e. tel:+4544890101;ext=200.
When implementing this type of solution you need to make sure that your SIP/PSTN gateway can understand this format. Why? It needs to be able to understand the components of the string and work with them. On outgoing calls from OCS to the PBX they need to be able to extract the extension from the Calling Line Id and present only the extension to the PBX (i.e. strip "tel:+<main number in E.164>;ext="). On incoming calls to OCS from the PBX they need to generate the format for Calling Line Id and Called Line Id.
We are looking at alternative solutions for this scenario for future releases of OCS 2007.
In case you haven't seen it the UC OIP web site has been updated with the January 2008 status http://technet.microsoft.com/en-us/office/bb735838.aspx. There is now one IP-PBX vendor qualified for Dual Forking with RCC.
The Office Communicator 2007 Phone Edition device is able to retrieve the users Outlook Contacts, Call logs and Voice Mails and display them on the device. How is it doing it? It is accessing the Exchange 2007 Client Access Server (CAS) and retrieving the information using Exchange 2007 Web Services (EWS). How is it locating the Exchange 2007 CAS and EWS?
It is locating the Exchange 2007 CAS through the use of a well-known A records found in DNS. It is using the SMTP domain of the primary e-mail address of the user to locate the A record. The primary e-mail address is sent to the device during the sign-in process through in-band provisioning. The A records it is looking for are the following in this order https://<SMTP domain>/autodiscover/autodiscover.xml, https://autodiscover.<SMTP domain>/autodiscover/autodiscover.xml and http -> https redirect. Outlook 2007 is able to use Active Directory Service Connections Points (SCP) and DNS SRV records to locate Exchange 2007 CAS, but the device does not support these additional methods.
The Exchange 2007 CAS runs the AutoDiscover service. The AutoDiscover service is responsible for finding and presenting the various URL's used to interact with Exchange 2007 EWS and information about how to connect Outlook 2007 to Exchange 2007. The device is using those URL's to retrieve the Outlook Contacts, Call logs and Voice Mails from Exchange 2007.
So how can you troubleshoot missing Outlook Contacts, Call logs and Voice Mails on the device? You could try some of these things from a PC connected on the same network as the device:
- Use nslookup to test that you can find an A record in DNS for <SMTP domain> or autodiscover.<SMTP domain>
- Try to access the URL's from IE https://<SMTP domain>/autodiscover/autodiscover.xml, https://autodiscover.<SMTP domain>/autodiscover/autodiscover.xml and the http variant and see if you get an XML response back with 600 Invalid request.
- Make special note of the certificates used on the AutoDiscover service and on the CAS? Does the device trust that certificate? Is it the default self-signed certificate used by Exchange 2007? if so the device does not trust it and it will not communicate with the AutoDiscover service
- Try to use Outlook 2007 Test e-mail AutoConfiguration (press and hold control and right click the Outlook icon in system tray). Select only Use AutoDiscover and input your E-mail Address and click Test. Check if that returns a lot of XML in the XML tab.
- Try to access the URL ending in /ews/exchange.asmx shown in the XML tab from the browser. If that returns a lot of XML back it means EWS is working
- If the above have shown that Exchange 2007 AutoDiscover and EWS are working try to check the IIS log on the Exchange 2007 CAS server for signs that the device is trying to communicate with it
If all checks out OK, but you're still not seeing the information on the device, it is time to call Microsoft Support.
On January 16, 2008 Microsoft made localized versions of the Office Communicator 2007 Phone Edition firmware available on Microsoft.com for download. There are Dutch, French, German, Italian, Japanese, Korean and Spanish firmware versions. The firmware version available is 1.0522.41.
In order to run the localized versions on a Office Communicator 2007 Phone Edition device you need to order it from the manufacturers as a localized version. It is not possible to update a device from one locale (i.e. English United States - ENU) to another locale using the Office Communications Server 2007 Update Software Service.
During configuration of the OCS 2007 Software Update Service you need to run the ConfigUpdatesServer.vbs script. However running the script might result in the error "ERROR: OCS Common Files not found in registry".
If you are using a 64-bit version of Windows 2003 the error can be caused by running the command with the 64-bit version of cscript. The 64-bit version of cscript accesses the 64-bit area of the registry (high level picture :-) and since OCS 2007 is not a native 64-bit application it stores its registry information in the 32-bit area of the registry. To overcome the problem use the 32-bit version of cscript found in c:\windows\syswow64.
Phone normalization rules in OCS 2007 are stored in Active Directory and can be manipulated using Enterprise Voice Route Helper and the OCS 2007 Administration MMC snap-in. The rules are not only used on the OCS server, but they are also downloaded to the client. How is the process?
The rules are updated in Active Directory on the domain controller used by tool. The WMI provider on each front-end server in the pool/standard edition server queries the domain controller it is connected to each 5 minutes for updated rules. So if they are not talking to the same domain controller you will have to factor in Active Directory replication latency.
When the client (OC 2007 or OC 2007 Phone Edition) signs in to the pool they will get configuration information downloaded through in-band provisioning. The phone normalization rules are in the <LocationProfileDescription> XML tag. The client will also re-load the rules each 8 hour.
In OCS 2007 we use the Mediation Server role as the routing end-point for voice calls going outside the OCS environment, ie. to the PSTN or to a PBX. For more information about voice in OCS 2007 see here.
When routing to PSTN/PBX you sometimes would like to have fault-tolerant routes, ie. if one Mediation Server goes down another can take over. Let's assume we have the network below.
We have UC end-points and an OCS pool in Paris and we have Mediation Servers in Copenhagen (DK-MS-1 and DK-MS-2) and we have a Mediation Server in Stockholm (SE-MS-1). The network between Paris, Copenhagen and Stockholm is a triangle as shown with Link 1, Link 2 and Link 3. Let's also assume that calls from Paris to numbers in Denmark (+45) should break-out in Copenhagen and you have configured OCS 2007 routing to that effect.
So what happens if the network link (Link 1) between Paris and Copenhagen goes down? Can user in Paris still call numbers in Denmark?
If the network connectivity is such that IP packets from Paris to Copenhagen can flow via Stockholm then calls from Paris will break-out in Copenhagen as normal. The only difference is that the packets travel via Stockholm. The reason is that media will travel directly from the UC end-point to the Mediation Server. So what happens if both Link 1 and Link 3 are down? Now the IP packets can't travel to Copenhagen via Stockholm.
This leads to the wish to configure OCS 2007 routing such that calls to Denmark should break-out in Stockholm in case Link 1 and Link 3 are down. In the normal situation calls to Denmark should still break-out in Copenhagen. How to configure routing to support this requirement?
You start by configuring your normal route to Denmark (+45 calls). This route has the two Mediation Servers (dk-ms-1 and dk-ms-2) in it. Having the two Mediation Servers in the route mean OCS 2007 will round-robin the calls between the two servers, and in case one is not working use the other one. The next thing is you configure a route for +45 calls to go via the Mediation Server in Stockholm (se-ms-1).
The trick is to designate one route as primary and the other as secondary. The way you do that is by creating corresponding phone usage records. You have a phone usage record for primary route (dk primary) and a phone usage record for secondary route (dk secondary). You then make sure that in the policy the primary phone usage record is listed before the secondary phone usage record.
In the screen shot I have used Enterprise Voice Route Helper (part of the OCS 2007 Resource Kit Tools) to show the configuration. You can see I have a policy called mb. The policy contains two phone usage records with dk primary first and dk secondary second. You can also see that I have two routes both with the pattern +45 for calls to Denmark. The first route has phone usage dk primary and the second has dk secondary. The way it will work is this.
A UC user in Paris with the policy mb calls a number in Denmark. Routing will first select dk primary route because both the pattern and phone usage are matching. Routing will try to contact dk-ms-1 and dk-ms-2 and realize that it can't communicate with any of them. It will then continue down the routing table to find a new match. It will find a match on the dk secondary route, since both pattern and phone usage matches. It will then send the call to se-ms-1 and the call will break-out in Stockholm and call the PSTN number in Denmark.
During migration from LCS 2005 SP1 to OCS 2007 you will have to understand which clients can be used under which conditions during the migration. When I talk about clients I'm referring to Office Communicator 2005 (OC 2005), Office Communicator 2007 (OC 2007), Office Communicator Mobile 2005 (CoMo 2005), Office Communicator Mobile 2007 (CoMo 2007), Communicator Web Access 2005 (CWA 2005) and Communicator Web Access 2007 (CWA 2007).
In the following table I have tried to illustrate when a given client can connect to a given server and under which conditions. The sequence of rows is meant to simulate the normal migration sequence from LCS 2005 SP1 to OCS 2007.
| Row | Client connects with | User homed on | Enabled for Enhanced Presence | Enhanced Presence Mode set | Connection works? |
| 1 | OC 2005 | LCS 2005 SP1 | N/A | N/A | Yes |
| 2 | OC 2007 | LCS 2005 SP1 | N/A | N/A | No |
| 3 | OC 2005 | OCS 2007 | No | No | Yes |
| 4 | OC 2007 | OCS 2007 | No | No | No |
| 5 | OC 2005 | OCS 2007 | Yes | No | Yes |
| 6 | OC 2007 | OCS 2007 | Yes | Yes (sets it on first successful connection) | Yes |
| 7 | OC 2005 | OCS 2007 | Yes | Yes | No |
In the following I will use OC 2007 to cover all the new clients OC 2007/CWA 2007/CoMo 2007 and OC 2005 to cover the old clients OC 2005/CWA 2005 and CoMo 2005.
The first 2 rows shows that OC 2005 can connect to LCS 2005 SP1, but OC 2007 can not. Row 3 shows that OC 2005 can connect to OCS 2007 as long as the user has not been enabled for Enhanced Presence and Enhanced Presence Mode has not been set. Enhanced Presence is the new presence architecture implemented in OCS 2007. Row 4 shows that OC 2007 can not connect to OCS 2007, if the user has not been enabled for Enhanced Presence. Row 5 shows that OC 2005 can connect to OCS 2007, even if the user has been enabled for Enhanced Presence, but only as long as Enhanced Presence Mode has not been set.
Enhanced Presence Mode is set the first time OC 2007, CWA 2007 or CoMo 2007 successfully connects to the server. Row 6 shows that OC 2007 can connect and that it sets Enhanced Presence Mode on first successful connection. Row 7 shows that after the user has been Enabled for Enhanced Presence and Enhanced Presence Mode is set only the new clients can connect.
When a user is moved from LCS 2005 SP1 to OCS 2007 he/she is not automatically enabled for Enhanced Presence. When a user is created on OCS 2007 he/she is automatically enabled for Enhanced Presence, but Enhanced Presence Mode is not set. If a user has been enabled for Enhanced Presence he/she can not be disabled for Enhanced Presence.
Enabling a user for Enhanced Presence can be done using the Active Directory Users and Computers MMC snap-in (User Properties -> Communications -> Configure -> Enable enhanced presence), through the OCS 2007 Administration MMC snap-in (Users -> Properties -> Configure -> Enable enhanced presence) or through WMI by setting the EnabledForEnhancedPresence user property on the relevant instance of MSFT_SIPESUserSetting (see the LCSEnabledConfigureUsers.wsf script in the OCS 2007 Resource Kit Tools for a way to do it).
To check if a user has Enhanced Presence Mode set use the OCS 2007 Resource Kit tool dbanalyze. Run a report on the user like this dbanalyze /report:user /user:<SIP URI of the user> and check the output for the RichMode row. If RichMode is True then the user has Enhanced Presence Mode set.
