Archive for April, 2009

New features of Communicator Web Access 2007 R2 include:

  • Collaborate with external organizations. Communicator Web Access 2007 R2 offers the ability for customers and business partners outside of your organization to join conferencing and collaboration sessions easily and inexpensively. Invite anyone with a Web browser to join a conversation that you are hosting, share your desktop with a vendor to discuss a project, or start a conference call with a stakeholder and route the call to your handheld device.

  • Desktop sharing. Users can see everything happening on someone else’s computer, and can even be given the right to control that computer. People running Microsoft Windows and a supported Web browser can share their desktops with others; anyone running a supported Web browser (including people using Macintosh or Linux computers) can view and control a shared desktop.

  • "Dial-out” Conference Audio. Audio conferencing (using standard telephones, including cell phones) can be added to any existing instant messaging or desktop sharing session. You supply the names of each person to take part in the audio conference, and Communicator Web Access will take care of calling each person and with setting up and managing the conference call.

  • Support for distribution groups. Users can add distribution groups to their contact list and exchange instant messages with all (or some) of the members of those groups.

  • Customize the login screen and links. Your IT department has the ability to customize login screen and links.

For the Full Text Click Here –>


The Microsoft Unified Communications “How-To” training tool is a Microsoft Silverlight™ 2 application that provides step-by-step instructions for common UC tasks. You can customize the How-To application to your company’s needs based on the UC features you’ve installed. For example, if you have installed all UC features except Communicator Mobile and Communicator Group Chat, you can modify the XML file so that those features and topics do not appear in the interface.

Download it here!

Microsoft Office Communications Server 2007 R2

Communicator Mobile for Java

Microsoft Office Communicator Mobile for Java is a new enterprise messaging client built on the Java Platform Micro Edition. When it is deployed together with Office Communications Server 2007 R2, Communicator Mobile for Java enables mobile phones that can run Java applications to function as unified communications endpoints, providing instant messaging (IM) and presence to create a familiar experience for users of Microsoft Office Communicator. Mobile devices enable users to extend the reach of Office Communications Server 2007 R2. This topic describes the prerequisites, the required server components, and the deployment process for Communicator Mobile for Java.

Mobile Device Software Requirements

The following are prerequisites for installing the Communicator Mobile for Java client.

  • Nokia S60
  • Nokia S40
  • Motorola RAZR V3xx

Each of the mobile phones must also meet the following prerequisites:

  • Capable of running Java applications greater than 512 KB, and with a heap size of 2 MB.
  • Mobile Information Device Profile 2.0 (MIDP 2.0).
  • Connected Limited Device Configuration 1.1 (CLDC 1.1).
  • Screen resolution:
    240×320 for Nokia S40 and Motorola RAZR V3xx phones.
    240X 320 or 320×240 for Nokia S60 phones.
  • Data-connection-enabled (GPRS, Edge, or 3G connection) mobile device. Subscription to an unlimited data plan on the mobile device is recommended, because the client and server will be exchanging messages even when they are in an idle state.

For details about the specific mobile phones supported for Communicator Mobile for Java, see Supported Clients.

Required Server Components

The following list describes the Office Communications Server components that are required to implement Office Communicator Mobile for Java:

  • Office Communications Server 2007 R2. Communicator Mobile for Java requires a deployment of Office Communications Server 2007 R2.
  • Communicator Web Access server. The Communicator Web Access server is a critical server deployment requirement for Communicator Mobile for Java. Communicator Mobile for Java uses the Communicator Web Access server to connect client devices to the Office Communications Server 2007 R2 environment, and the Communicator Web Access server acts as a gateway to the various Office Communications Server functions.
  • Voice mail configuration. The Communicator Mobile for Java user account must be configured with an Exchange mailbox, and it must be enabled for Enterprise Voice.
  • Reverse proxy deployment. A reverse proxy is typically used in front of Web servers, and it presents a single interface to clients. It is also used to balance the load on a Web server farm. Communicator Mobile for Java connects to Communicator Web Access server through the reverse proxy.
  • Exchange Client Access server. The Client Access server role supports the Microsoft Outlook Web Access and Microsoft Exchange ActiveSync client applications and the Post Office Protocol version 3 (POP3) and Internet Message Access Protocol version 4rev1 (IMAP4) protocols. The Client Access server role accepts connections to your Exchange 2007 server from a variety of different clients, including mobile devices. The Client Access server role is required in every Exchange Server 2007 organization.


this one is definitely one to get… and with the sneaky upgrade path from beta to rc which you could not do in previous version means this is going to have huge adoption in my eyes! 🙂

IP-PBX Vendor

Tested Product

Supported Configuration

Software Versions Tested

OCS 2007 R2

OCS 2007


Cisco Unified Communications Manager

Direct SIP


























Check out the UC Open Interoperability Program for more information.

Known Limitations:

  • The PRACK message sent by CUCM 4.2(3) is malformed by missing the MAXFORWARDS header.  As a result, this configuration requires PRACK to be disabled.  By default, PRACK is disabled in CUCM 4.2(3)
  • For Office Communications Server 2007, this support requires update package for Communications Server 2007 Mediation Server: August 2008 .
  • OCS 2007 may not appropriately normalize the PAI in the 200 OK or UPDATE, resulting in OC displaying a non RFC3966 formatted global number and in failed RNL on OC. When calling from OC 2007 to a Cisco phone number, after the caller gets connected, the name of the person on the Cisco phone may not be shown on Communicator, and instead OC may display the E.164 number (without a "+") for the person on the Cisco phone. This is resolved in OCS 2007 R2
  • When calling from OC 2007 to a Cisco phone number, where the Cisco extension is disconnected or out of service, the Cisco IP-PBX may not notify OC 2007 in a timely manner. This has been remediated in OCS 2007 R2.

Check out this link on Microsoft Technet about the new features in exchange 14

Microsoft OEM partner Polycom will now distribute, sell and support RoundTable and it will be renamed the Polycom CX5000 Unified Conferencing Station.
The deal will make RoundTable available through Polycom’s global channel to more people in more countries with stronger support from Polycom.


I went away for the weekend and while i was driving home i realised how easily the weekend passed … you might ask what the hell is this guy on about but i want to explain that without proper planning for the whole weekend i would have had a much stressful time!

Anyway this got me thinking about the importance in planning a Unified Communications Roll-Out…

I have lost count how many times i have heard the phrase “it will do” and still it makes my skin crawl a little!

What i am referring to is clients/customers etc… not taking the time to plan the system and roll-out properly or when you discuss pilots etc.. they try to reverse engineer your proposal in to something that will do…

Unified Communications is a beast in its own right and should not be attempted without full commitment from the teams and management. So here is some points i think should be followed which i hope others find useful!

1. Assess the companies intent – some companies want the technology and all its features but you have to be realistic from day one and if it is beyond their reach in terms of implementation cost you would be safer to walk away.  Never compromise on the quality of your design this design and implementation becomes your reputation.

2. Define the requirements of the solution – this is for 2 reasons, one is the ensure you fully understand what the company wants out of the unified communications solution and to ensure it is obtainable. The second is so the company understands what they want if only at this point from an IT or Management perspective.

3. Arrange Meetings with the departments which will have to adopt the technology… this again is for a couple of reasons, the first being that user education is paramount in a unified communications roll-out as if you do not at least inform the departments of the plans and how the technology can benefit then you will run into stumbling blocks very very quickly. the second being that the other departments might come up with useful solutions and questions about how to make there life easier with the technology being rolled out.. the importance of this comes from the following example a customers management team recently request a full UC solution with Microsoft Exchange and OCS and when we started the consultation process we took it upon ourselves to talk to the staff as the management were not keen on getting everyone involved, we ended up coming up with really clever ways of bringing the technology to them and made it easier for them to adopt the technology and change there daily process to become more efficient around it!

4. Define pre-requisites and stick to them! and more so VERIFY EVERYTHING is in place before you start – common sense i know but you would be surprised the amount of people who take the customers word… and yes i know it sounds terrible you should trust your customer but i always safe better safe than sorry!

5. Define pilot users – here you want to ensure you have a definitive list of people who the technology is being rolled out to, i find this important so your roll-out does not spiral out of control and you do more than what your department or company is getting paid to do. Also it gives you the chance to hand pick a mix of technology users so you can ensure you get a good variety of a user base for the pilot

6. Deploy the system in steps – again common sense but there is no point in rushing and building an entire system and only getting to the end and realising half it was not done properly it will save hours of troubleshooting. So in relation to the MS environment, Deploy the active directory updates first… then verify.. then prepare the server …. verify… then roll-out the front end server and you got it verify.. Microsoft have excellent validation tools for there products and Best practice analyzers for when you deploy each roll.. so ensure you validate, verify as you go rather than getting to the end and trying to do it then…

7. After you roll-out to the first 10 or 15 users STOP for a couple of days and measure performance metrics on the servers and network and review the end user experience and modify the process and/or training for rolling out to the client for the next batch… this way you get you process documented and reviewed as you go. Plus you will be on top of any problems before they occur usually and you do not risk upsetting a lot of people.

8. A Pilot is a Pilot – ensure every end user, management and any team involved in the roll-out understand the meaning of a pilot and that they know this is a pilot… A Pilot being a test system which is being tweaked and modified as it is being rolled out, this has the possibility for downtime. Make sure this notification is sent out regularly to everyone so there is no mistake that the system is still in pilot until the day you upgrade its status to Production!

9. Training – ensure the teams are appropriately trained and that you supply documentation for the relevant procedures they might require! again i know this is common sense but it is often overlooked.

10. Review – once the pilot is deployed allow for at least one month testing, check in on a weekly basis to ensure everything is going to plan. Ensure the management and teams are happy and that their understanding of what is deployed matches the definition of the solution.


Well i hope this helps…….

Please comment if you have anything to add as i am always interested in improving my methods ….