Sunday, 29 August 2010

RunAs Radio Show

A few weeks ago Richard Campbell from RunAs Radio, asked if I would participate in an interview for the Talk Show.

This was initially to be on Exchange UM but ended up been around Office Communications Server.

Recording this was a new experience, and an interesting one at that, the interactive nature and not knowing what questions would be asked made it a challenge.

The recording can be found here, and I encourage people to subscribe to the podcast.

If you have suggestions for other topics you would like covered, you can contact Richard Campbell and Greg Hughes, at

Tuesday, 20 July 2010

Communications Server 14, Authentication and Certificates

In order to support new features in Communications Server 14 (CS14) such as IP Phones and Branch Office Survivability an additional authentication method has been added along with the introduction of User Certificates.

This additional Authentication method is in the form of an Extension and Pin combination allowing for users to login to the new IP Phones, this allows a user to easily login to a phone rather than needing to use their domain username and password.

The authentication method is limited to CS, in that CS authenticates the login within it’s own database, if the login is successful a User Certificate is issued to the IP Phone, this is then used to provide access to the CS Web Services and used for  authentication with the CS Servers.

Due to this being a CS authentication method, a Kerberos Token is not issued to the IP Phone, meaning that an IP Phone can not authenticate to Exchange Web Service causing some functionality loss (More details in a future post).

The Extension and Pin used for this processes is the same for Dial In Conferencing removing the “yet another Pin issue” although Exchange still uses it’s own Extension and Pin combination.

Moving forward it would be useful if Exchange could use the CS Pin Authentication Web Service rather than use it’s own when operating as part of an OCS environment. With Exchange 2010 Service Pack 1 moving to use UCMA for Unified Messaging hopefully having an option to use CS Pin Authentication is a logical next step.

The Pin is managed via a Web Interface in a similar way to the Dial In Conferencing Pin in OCS 2007 R2, the management of this has been moved from Communicator Web Access (CWA) to be part of the Web Components Role which is co-located with the CS Front Ends.

Taking a look at the User Certificates, these are issued by CS acting as the Issuing Authority, rather than proxying these requests to an Enterprise CA (Server Certificates issued by an Enterprise or Public CA are still required for TLS\MTLS).

Certificates are issued to the Client Endpoints (IP Phones, Office Communicator etc) allowing authentication to CS14, rather than using the Kerberos token each time. When using Office Communicator Kerberos is used for the initial logon (to get the Certificate) and for non-CS Web Services such as Exchange.

Certificates are also an integral part of the new Resiliency options in CS, allowing a client to authenticate and register to CS if connectivity to Active Directory Serves are lost; this is of particular importance in the branch office scenario when using the Survivable Branch Appliance (SBA).

When using Office Communicator these are issued to a user SIP URI and stored within the User’s Certificate store, meaning that if the same Domain User logs in as a different SIP URI,  a new authentication process will be initiated rather than using an existing certificate.

On IP Phones certificates are deleted when the “Switch User” process occurs, or a hot desking users session expires. Allowing for a new user to login using their Extension and Pin.

User Certificates by have a life span of several months helping to ensure that if a user logs into Communicator during a WAN outage they are still able to authenticate with CS. While it is currently unclear if this life span can be shortened the ability to deactivate certificates when necessary should suffice for most organizations.

Hopefully these additions will not add additional complexity and will simply become a backend process within CS14.

Tuesday, 8 June 2010

Communications Server “14” – TechEd Day 1

Since VoiceCon Orlando 2010, news about the Wave 14 release of Communications Server has been trickling out. At TechEd New Orleans this changed with a number of sessions focused around the Communications Server “14” release.

This also coincided with information being released on the Microsoft Product Pages.

This post will detail the information discussed in the Day 1 sessions, at a high level. My aim is to build on this as more information becomes available.

No dates were given for CS14, only that it would be this Calendar Year, also it is not clear if all the functionality mentioned would be available at RTM or if some would come at a later date.


  • Photos Displayed within Communicator, can be from Active Directory, SharePoint or User Specified URL. Can be restricted by Administrator. Along with the user being able to choose not to show their picture and hide pictures in their contact list.
  • Photos downloaded from AD using a new Web Service Address Book Service Web Query (ABS-WQ) and Cached locally.
  • ABS-WQ used for Distribution List Information and Hierarchy along with an alternative to downloading the Address Book everyday.
  • Option to use Address Book (same as R2) or Web Service, set on per User or Pool Level.
  • Exchange Web Services used over MAPI, functionality such as Conversation History will be via EWS.
  • New Contact Group – Frequent Contacts. Dynamically managed includes 10 most frequent contacts along with Team members and Pinned contacts.
  • New Presence State “Off Work”.
  • Time zone and Location published in Contact Card, Location Publishing can be disabled.
  • Enhanced Privacy, enabled at Pool Level. Only show presence to people on the users contact list. Users can opt out and display presence to all.
  • Ability to place a test call within Communicator.
  • In Call feedback of call Quality.


  • Will use ABS-WQ for searches.


  • Enabled via Inband Provisioning.
  • Client connected directly to SharePoint.
  • SharePoint 2007 or later supported.
  • Provides Expert Search, both specified on a user’s MySite but also inferred based on documents users post etc (Unclear if this is SharePoint 2010 only).
  • Phonetic Search for Users and Skills when using SharePoint (Unclear if this is SharePoint 2010 only).


  • Support for redundancy across Datacenters.


  • LiveMeeting client is no more, the functionality is built in to Communicator “14”.
  • Attendee Console to provide full fidelity access to conferences by external participants.
  • There will be a Silverlight client to provide access to conferences where participants can not install the Attendee Console. It was inferred that this would not have all of the features of the Attendee Console.
  • Conferences can be recorded, these recordings record everything that happens within the conference, IM, Voice, Video, Sharing.
  • Recording are played back using the Recording Manager and including Handouts.
  • Recordings can be “published”to a WMA file, with the ability to publish all or parts of the recording such as only the Voice and Active Speaker Video for example as well as been able to specify a time window.
  • When creating meetings, options are available to specify who is allowed in automatically and who should be granted access by a Leader. Also settings on who should automatically be granted Leader Status.


  • E911 support, this is provided by routing calls via a SIP Trunk to a PSAP who in turn will route the call to the correct Emergency Call Center based on location of the caller.
  • Branch Office Survivability, if the connection to the OCS Server is lost, calls can be routed via local PSTN Connections.
  • Support for Call Access Control, allows administrators to specify if WAN links can be used for Voice and Video along with limiting the number of concurrent calls.
  • Media Bypass for PSTN calls, allows calls to bypass the Mediation Server if the client can route the RTP traffic direct to the Gateway. It is unclear if this is G711 only or if the Gateways will support RTAudio.

Cloud Support:

  • Communications Server “14” is designed to work in the cloud.
  • Support for some users on site and some in the cloud with shared namespace.
  • Support for Exchange in the Cloud and OCS on site, along with the same support for SharePoint.
  • No dates were provided as to when this will be available only that they are working on it. I also assume it will be staged.
  • Voice in the Cloud will be via Partner Solutions.


  • Ability to build Silverlight applications in to the “Conversation” Pane. Allowing developers to provide context based information such as Contact Center Functionality to users.


  • Supported, but within specified boundaries.
  • Will include support for Voice and Video.

Mobile Client:

  • Improved functionality.
  • Support for more devices.


  • Support for Voice and HD Video Federation with Windows Live Messenger.

At a high level, I think I have covered off most of the “New” items, hopefully more information to come.

Tuesday, 1 June 2010

NET’s 21st Century Gateway

Network Equipment Technologies (NET) are due to launch a brand new gateway branded as the UX. This gateway will be designed with the 21st Century in mind breaking away from the TDM world gateways are usually found in.

Gateways were originally designed for bridging the TDM world with the IP world for purposes such as:

  • Connecting TDM PBXs together over an IP Network,
  • Providing connections to Software Products such as:
    • Microsoft Exchange
    • Microsoft Office Communications Server (OCS).
    • Software Fax Solutions
  • Providing TDM connectivity for  Softswitches.

Today the Telephony landscape has changed, organisations find their Telephony Estates are made up of a mix of PBXs which could be IP or TDM, and usually from a number of different vendors.

This is usually due to acquisitions or different regions doing their own thing. In order to link these together to provide functionality such as PSTN Bypass and Centralised Voicemail third party gateways are often required.

This is due to PBXs supporting different protocols such as H323 or SIP, and some may be pure TDM. Others require more complex number transformation and translation than is possible on the PBX.

The problem with the vast majority of gateways available today is that they were designed for a TDM world and while many have been updated to provide IP to IP Routing, there are still limitations around functionality such as Transcoding.

This is where the UX changes the playing field as it being designed with the new Telephony Landscape in mind.

While the UX will take the best parts from the NET VX and Quintum DX Gateways, it is being built from the ground up and for all intense purposes will be unrecognisable from its predecessors.

The UX is not going to replace the VX or DX which are still excellent gateways; the VX is more scalable and designed for the more complex and usually larger deployments, with the DX being for smaller deployments.

The fit for the UX appears to be branch offices or medium sized deployments.

Looking into the telephony side of the UX it will support two interface modules allowing for a combination of E1\T1 Ports along with FXS ports.

It will provide full support for features such as Any to Any routing, LDAP based routing logic and Transcoding.

The UX will be capable of providing Transcoding capabilities when used as a SIP Demarcation Device due to it not requiring E1\T1 Line Cards to provide this capability.

The UX will also provides the following:

  • Session Border Controller
  • SIP Registrar
  • IP Router and Switch
  • Application Solution Model (ASM)

The ASM will be a module within the gateway and for all intense purposes will be a standalone server based on the latest Intel i7 architecture. This will be an optional module and will not be required for the gateway to function.

The purpose of the ASM will be to provide a platform for Telephony Applications which would usually run on a separate server, this could include:

  • emFast Fax Solutions
  • FMC Solutions from Tango
  • Microsoft Communications Server Survivable Branch Appliance, announced at Voicecon Orlando 2010

Hopefully this gives an insight into what NET are going to provide at a relatively high level. My aim is to provide a more detailed and technical post as and when more information becomes available.

Sunday, 23 May 2010

Remote Call Control Lives On

At the start of December 2009 I wrote a blog post on how Remote Call Control (RCC) was going to be depreciated in the Wave 14 release of OCS.

This was based on Microsoft and Cisco: Joint Interoperability Support Statement, which was released at the time. This document has now been updated and can be found here.

Within this document is the following statement:

“Remote Call Control is supported by Microsoft in Office Communications Server 2007 and Office Communications Server 2007 R2 and will continue to be supported for both new customers and customers upgrading their Remote Call Control deployments to the next release of Office Communications Server. “

This new statement indicates that RCC will continue to be supported for both new and existing customers compared to the pervious statement which announced the deprecation and support for upgrades only.

This change will certainly have a knock on effect in terms of how people look to deploy Wave 14, how partners have positioned RCC and Wave 14 with existing and potential customers.

When RCC was not going to be supported for new deployments, customers had to make a decision:

  • Deploy OCS 2007 R2 with RCC today and upgrade to Wave 14
  • Not deploy RCC and for all intense purposes keep their PBX and OCS separate
  • Move to Wave 14 as their PBX and move away from the PBX they have today

Customers now have the same options as they did with OCS 2007 R2, which is to continue with their PBX and deploy OCS with RCC, assuming the PBX supports this.

For customers who see the value of using Wave 14 as their PBX this will not stop them moving but for those who want to use the OCS functionality but retain their PBX the decision is now a lot easier.

One thing is for certain, interesting times are ahead.

Sunday, 11 April 2010

Monitor Active Directory LDAP Queries

I recently had a requirement to view the LDAP Queries that Exchange 2010 was running against a 2008 Active Directory Server when a Service Starts.

When the LDAP queries are sent to the Active Directory Server they are encrypted meaning that tools like Wireshark and Network Monitor can’t be used.

In researching into how I could monitor these queries on Server 2008 I came across this blog post. Which describes how to use the Reliability and Performance Monitor (RPM) to monitor Active Directory which includes the LDAP queries.

The results are captured in a file called “Active Directory.etl” and stored in subfolders under “c:\perflogs\ADDS”. When the Capture is stopped, RPM generates a report which contains an analysis of the captured data, including the top 25 LDAP queries.

The top 25 LDAP queries appear to be the most CPU intensive queries, this may be useful for some people but of  little use if you are wanting to view all of the LDAP queries.

Luckily all is not lost all of the queries are stored within the Active Directory.etl filet. Looking into how I could extract information from this file, I found this post. The only slight difference is that I needed to use the –lr flag in order to extract the LDAP queries.  The full command is:

tracerpt -lr "Active Directory.etl""

This produces an XML file called dumpfile.xml and contains all of the captured LDAP queries, unfortunately it does not store the results of the queries.

Saturday, 10 April 2010

Benelux Techdays – Communications Server “14” Sessions Review

On the 1st April Fran├žois Doremieux presented at the Benelux Techdays Event.

He presented two sessions the first was an introduction to Microsoft Communications Server “W14” and the Second was New Voice capabilities and infrastructure in Microsoft Communications Server "W14".

On the 9th April the recordings of these sessions were published on the TechNet Edge site and can be found here and here.

These recording provide some additional detail around what is coming in Communications Server (CS) 14 and also some clarity of items mentioned in the Voice Con RFP response my review of which can be found here.

The reminder of this post will build on my review of the RFP and focus on items which I believe are new or where there is further clarity.

In addition due to the topics of the session delivered this will focus purely on the Voice aspects of Cs 14 with the exception of some architectural comments.

Starting with the new client functionality.

There will be the ability to easily place a test call from the Communicator Client, this appears to be similar in functionality to the Deployment Validation Tool for OCS 2007 R1 and R2 but built into the OCS Servers rather than a separate component.

The Music on Hold (MoH) functionality is local to the client rather than a server based function it is unclear however if the user will be able to select their own hold music or if the option is to simply enable or disable MoH.

There was also the mention of the ability to choose different ring tones, although this was not discussed in any further detail. In OCS 2007 R1 and R2 it is possible to change the ring tone via the Windows Sound Settings but this would imply the ability is built into the client, possibly with a list of different ring tones to choose from. What would be useful is the ability to choose different ring tones based on the person calling. Such as one ringtone for corporate contacts, another for external and another for certain Caller Line IDs etc.

There will also be the ability to record calls on the local client, although this can be disabled by the administrator if required.

Moving on to look at Call Admission Control (CAC), it was mentioned that this should not be a replacement for right sizing the network. If there is not enough bandwidth for Video at a site this functionality should be disabled for users at that site rather than risk them having a bad experience.

CAC should be used for when the usage of Voice or Video exceeds the planned usage for a site or if a user travels from a site were they are allowed to use Video to a site which is not designed for Video, CAC could either block the Video completely or if there is sufficient bandwidth allow it.

There was also mention of ability to prioritise Emergency Calls, I assume this means that even if the resources are allocated for other calls and there is no alternate route the Emergency Call will still be placed and risk bad quality rather than rejected.

Looking at the configuration options for CAC it was mentioned that it is fully configurable in terms of Locations, Topology, Network Links with limits for Voice and Video being separate and on a link by link basis.

What is not clear is if the limits are the number of concurrent calls or based on bandwidth limits. Due to the elastic nature of the RTAudio and RTVideo codecs it will be interesting to see how these are configured.

It was also mentioned that the full path of the call is assessed before if takes place, meaning that in a star topology where traffic goes via a hub site it will ensure that there is capacity on all the required links before it can take place and then re-route or reject if there is not enough capacity.

Rerouting can either be via different WAN links, via the Internet assuming local internet connections are available or via the PSTN for Voice Calls. What is not clear is how it will handle multiple links between sites such as primary MPLS links and then backup links which offer a high latency for example but suitable for some calls.

It was also mentioned that there will be the ability to down-rate video, so if the client\user wants to utilise HD but only enough bandwidth for VGA or CIF is possible then the video will be down-rated.

Looking at interoperability with other PBXs there will be support for getting and setting presence via SIP, this is often referred to as SIP Verb support. This will provide the ability retrieve presence from a PBX and update the users presence status if they are in a call. It is unclear if PBX will be able to retrieve presence information from OCS using the same method.

The new IP Phones were also covered but the only item I believe which has not been mentioned before is the ability to view the users calendar on the phone.

Moving on to Conference Calls, when the user is in a conference call in Communicator they can easily access the conference access details which include Dial In Number, Conference ID and URL so these can easily be shared with participants.

There is also improvements for users using a traditional PBX rather than Enterprise Voice but where they want to utilise the conference functionality in OCS. They are able to configure Communicator to automatically call their PBX extension, placing them immediately in the call when they answer. Along with an option to override this on a per call basis for situations when they are away from their PBX phone.

This would also require a connection between OCS and the PBX either via a Gateway or Direct SIP.

For the Location Information required for E.911 Support, this is provided via the Integrated Location Information Server Role (LIS), which I assume is part of the Front Ends.

Moving on to the Mediation Server, this will pretty much disappear in Wave 14 in terms of being a Standalone Server, it will become a Role within the Front End Servers for the majority of deployments.

Looking at why there was a requirement for a Mediation Server in the first place it was as a demarcation device and to perform trans-coding from RTAudio to G.711.

In order to not move this entire load to the Front Ends additional logic has been added as to when G.711 can be utilised instead of RTAudio, with the media being sent directly to the Gateways rather than the Mediation Server. I am hoping this also applies for Direct SIP capable PBXs. While OCS 2007 R2 was capable of using G.711 for some calls if the network conditions were correct it still relayed this via the Mediation Server.

A standalone Mediation Server will still be required when using a SIP Trunk from a Telephony ISP (TISP).

Looking at the Survivable Branch Appliance (SBA) this will either be a Server Blade in a Gateway or a Gateway Blade in a Server. If the WAN links fail the clients in the Branch will utilise the PSTN connectivity supplied by the Gateway or possibly a local Internet connection.

The Clients will register with the SBAs in the branch, if this fails the clients will re-register to the Front Ends. In order to do this the clients are aware of the additional locations at which it can register. It is unclear if this will always be the OCS Front End Servers or if it can be another SBA. Failover and Failback will be automatic.

It appears that although the client registers with the SBA they will use all the functionality of the Front Ends as long as they are accessible. The reasoning appears to be that the SBAs will be more stable and reliable than the WAN connections and as such while losing the WAN will result in restricted functionality the client will not need to re-register.

In order to provide the ability for client to register, the SBA will act as a SIP Registrar and provide Authentication, Client Configuration Details, Telephony Routes and Policies.

When in failover mode (Access to Frontends Lost) it was mentioned that Presence Information may be lost due to the Front Ends providing Presence Aggregation.

In addition the SBAs are designed to require minimal effort and knowledge to deploy in the branch and administered centrally. Allowing non IT staff or local 1st line support staff to deploy them.

It also appears that users outside of the Enterprise accessing via the Edge, I assume via VPNs as well will be able to register with another registrar if the Front Ends go offline. I assume this means to an SBA or secondary pool. I assume this will require Directors in place and that they are still online since these would be the “Next Hop” for the Edge Servers.

Moving on to look at the Architectural Changes, it was mentioned that all server roles can be co-located with the exception of the Monitoring Server. I am assuming they mean the Edge Server as well.

As mentioned in the RFP the Datacenter Redundancy will be improved, the ability to split a Pool across two Datacenters will still be possible assuming a low latency WAN link, less than 15 milliseconds, which is the SQL replication limit. Under this scenario there would be no loss of functionality and be fairly transparent to the end user.

The new Datacenter Redundancy scenario is designed for Datacenters were there is no option for a low latency WAN link such as one in the US and one in Europe. For this there is the concept of a secondary pool which clients can failover to. With this set-up there would be a loss of functionality such as Presence and Contact Lists, since these are held in the Pool Database. I also believe that scheduled conferences and “MeetMe” style conference will not be available due to these details being held within the Pool Database as well.

Functionality such as Call Routing, CDR, External User Access and Ad-hoc Conferencing will still be available.

If the Datacenter was completely lost then there is the ability to move the users to the secondary pool, meaning that full functionality will be restored. Although I am unsure if this means the Contact Lists will be lost along with other items stored in the Pool Database or if there will be a mechanism to retrieve this data from things like SQL backups.

The final item is the monitoring and alerting capabilities, this appears to be the reminder of the OCS 2007 R1 and R2 Deployment Validation Tool built into CS 14. This will provide the proactive monitoring and alerting of issues to System Center Operations Manager (SCOM). Agents can be deployed to machines and perform checks such as trying to register with CS and placing test calls to monitor network characteristics. These were referred to as Synthetic Transactions.

Again this is my interpretation of what was mentioned in the recordings of the sessions and these may or may not appear in the finial release; or the functionality may work in a different way.

And on a closing note it was mentioned in both sessions that at TechEd US, Everything that there is to know about CS14 will be revealed.

Sunday, 28 March 2010

Communication Server “14” – Voicecon RFP Response Review

During Voicecon Orlando each of the PBX Vendors submitted a response to a hypothetical RFP for an IP Telephony Solution. The RFP was written by Allan Sulkin, along with being reviewed, analyzed and then a “wining” vendor chosen during VoiceCon.

This year Microsoft was the wining vendor due to them being the most cost effective solution along with fulfilling the requirements of the RFP.

The Microsoft response to the RFP has been published for review and can be found here, the response provides information on the new Wave 14 release and the reminder of this post will focus on this information.

Since Wave 14 has not been released the information within the response is subject to change, so items mentioned may not make the final cut or may work in a different way than detailed. Therefore the information is based on my interpretation of the RFP response contents along with assumptions of how things may work.

It appears that Wave 14 will support Windows Server 2008 R2 which is expected along with using the same hardware specifications as OCS 2007 R2, this will should enable organisations to migrate their OCS estate to Wave 14 with a minimal investment in new hardware.

In addition there will be PowerShell support for administrative functions, there is also reference to Role Based Access Console (RBAC) although it is unclear if this is for Wave 14 or in reference to Exchange 2010.

The architecture of Wave 14 appears to have changed, the first thing is the disappearance of the Mediation Server, it is not shown on the architecture diagrams or included in the architecture description. The description of the Front End mentions that it provides all Signalling and Media Functions therefore it looks like the Mediation Server is now a function or role of the Front End Server.

There also appears to be a new redundancy offering for redundancy across physical sites. A whitepaper was released for OCS 2007 R2 with regards to Site Resiliency which can be found here. This is the basis of the redundancy within the RFP response. The response also lists a another option which appears to be a concept of a backup Site, allowing endpoints to re-register to the backup site automatically.

In order to provide this there must be some form of replication of the databases to ensure that users to do not lose their Contact Lists along with other items such as conference details.

There is also an indication that this can be performed in both direction, implying that both sites can host users. Therefore it appears that the concept of Pools is being superseded by Sites with each Site hosting users and resources but also being a hot standby for another site.

For organisations that do not need a secondary site to host users this could be an expensive way of provide resiliency but it removes the network requirements detailed within the OCS 2007 R2 Site Resiliency whitepaper.

Also how resiliency around the Edge Servers across sites is also not detailed.

There is also an indication that the XMPP Gateway will be part of the Edge Server.

Moving on to look at the new telephony features within Wave 14 the following are detailed within the response:

  • E911 Support
  • Call Park
  • Malicious Call Trace
  • Private Lines
  • Music on Hold
  • Survivable Branch Appliance (SBA)
  • Call Admission Control (CAC)
  • Support for additional IP Phones

In order for E911 to be supported OCS needs to know the location of every logged in endpoint either through the system knowing their location through a pre-defined Location Database within OCS or by being entered by the user.

Within an Office Environment there appears to be two ways to identify were a user is. The first is through the mapping of IP Subnets to locations within an office building this relies on the network design issuing different subnets to different floors or specific areas on each floor. While many business will have their subnets set-up in this way some will not and would therefore needs to redesign the way their network works.

The second option is to go by the switch port the device is connected to and for each switch port on each switch to be specified with a location in the Location Database. It is unclear how the switch port details will be queried although it is assumed that this will be using technologies such as CDP for Cisco and other technologies for other switch vendors.

For wireless devices the MAC Address of the Access Point they are connected to is used to retrieve the location information.

If for any of these scenarios there is no location information available or when the user is working remotely the user will be prompted to enter their location. I am not sure how this will work for the IP Endpoints as entering an address on something like the CX500 (Non-touch screen) will be time-consuming using the 12 digit dial pad.

In addition when a 911 call is made an alert IM can be sent to places like the Security Office to alert them.

Malicious Call Trace allows for a user to flag as call as inappropriate, this flag is stored within the CDR data for the call. There is no mention of if a Malicious Call can be recorded, although there are areas of the response which indicate that calls can be recorded by the client. Such as the support for Group Listening which has the following comment “Users may take advantage of built-in recording to enable post-call group listening”

There also appears to be support for Private Lines, which are usually used to provide Managers with two numbers one which is their publish business number and the other which is private. It is unclear how this is implemented, whether is means each user can have two Line URIs of if it is implemented some other way.

In addition there is also an indication that Music on Hold will be supported on the endpoints, currently this in only available in the Attendant Console in OCS 2007 R2.

Looking at how conferencing has changed in Wave 14 there is an indication that Voice Conferences can be recorded this is something which was not available natively within OCS 2007 R2, even through there was a warning when entering a conference that it may be recorded; there was also an SDK sample application that could record conferences on an ad-hoc basis.

The following statement also indicates that conferences can be reserved “Users have the ability to schedule and reserve audio/video conferencing sessions through Microsoft Outlook calendaring”. This is a change from what OCS 2007 R2 offers in that in R2 conference can be scheduled but no resources are reserved within the MCUs. This statement would seem to indicate that the MCU resources can be reserved to ensure that their is capacity for the conference to take place.

In terms of the new IP endpoints it appears that to login to the CX600 an extension and pin is used whereas the CX700 continue to use the domain username and password, hopefully this PIN is the same as the Conferencing PIN and not another one to maintain and remember. There is an indication that users can login to the CX500 but no mention as to how, I am assuming it is also via an Extension and Pin combination.

This does start to provide support for a Virtual Office style system allowing the IP Phones to be used in hot desk style scenarios. USB tethering is also supported on the CX600. Hopefully this will also be mirrored on the Astra equivalent devices.

The CX500 designed for Common Areas are not associated with specific users but can have calling restrictions applied to them; I am assuming something like a Contact Object will be used to represent them in Active Directory and authentication hopefully via MAC Address. It is also mentioned that users can login to them if needed.

Analogue devices will also be supported and represented in Active Directory as Contact Objects allowing for calling restrictions to be applied. The route that these devices connect into OCS appears to be via Analogue Terminal Adapters (ATAs) or Survivable Branch Appliances with FXS ports. It is unclear how these will work together but I assume people like AudioCodes will release new firmware for their MediaPacks and hopefully other vendors like NET\Quintum will as well.

The final two elements to cover are Call Admission Control (CAC) and the Survivable Brach Appliances (SBA).

Call Admission Control allows for calls to either be rejected or alternatively routed depending on the number of calls currently taking place over a WAN connection. The settings are controlled via the Administrator and can be applied to WAN and Constricted LAN connections. It allows for example Voice Calls to be re-routed via PSTN connections if a WAN connection is saturated or for Video to be routed via the Internet and Voice via the WAN connection.

If all possible routes are unavailable then the call will be rejected.

What is not clear is how dynamic this functionality is and also if it relies on an SBA to be deployed in the branch to provide re-routing via the PSTN and\or Internet Connections.

For Example if a Video Call is going via a WAN connection and a Voice call needs to take place would a Video Call be re-routed via the Internet while in progress. Or if a Video Call will be downgraded from HD to VGA to provide capacity for another call. Or if the calculation are based purely on available Bandwidth or if other network characteristics such as Jitter and Packet Loss are also taken into account.

The final item is the Survivable Branch Appliance (SBA), this provides functionality to a branch office in the case of a WAN failure. The device appears to operate in two modes a standard mode and a Local Survivability Mode. Irrelevant of the mode the SBA is operating in clients within the branch will always register to the SBA, if the SBA fails the clients will re-register with the Front End Servers in the main office.

When the SBA comes back online clients will re-register with the SBA although it can be defined as to when this happens. Hopefully this means either out of business hours or next login.

What is not clear is how information will flow when the SBA is operating in the standard mode.

  • Will all SIP messaging go via the Front Ends?
  • Will it go via the SBA then be relayed to the Front Ends?
  • If for example it is an IM conversation between two users in the branch office will the traffic stay local to the SBA?
  • Are there MCU resources on the SBA?

Until the 3rd Parties start to release the products and until Microsoft release further information it is difficult to know how it will function.

The response does indicate that during Local Survivability Mode all functionality will be available with the exception of Call Forwarding Settings and Response Group Settings. Although this is contradicted in the following paragraph indicating that only Call Forwarding Settings are unavailable. This is while referring to two different sizes of Branch, so it does pose the question of if there are two types of SBA.

In order to still maintain functionality like Instant Messaging to other sites, the SBA must be able to route IMs etc via a Local Internet connection but again this is not clear. It does indicate that PSTN calls will route out via the local PSTN connections.

Voicemail will continue to work and allow deposit and retrieval via the PSTN (hopefully via an Internet Connection as well).

It is also unclear what will happen with things like CDR Data and IM Archiving, hopefully these will be cached and then relayed when the WAN connection returns.

I think that is about everything, although I might have missed one or two things. I am aware the ordering of this post is a little strange in terms of content but hopefully it all makes sense.

Saturday, 13 March 2010

Exchange 2010 UM – Behind the Scenes MWI

With the release of Exchange 2010 the uptake of using Exchange as a Voicemail platform appears to be increasing. I am unsure if this is due to the Message Waiting Indicator (MWI) functionality now been included, or if the time is now right for customers to start adopting it.

While researching into the UM features of Exchange 2010, information around the features available and how to configure them is plentiful but there appears to be very little information about how MWI operates behind the scenes.

Therefore this post is based on the limited information that appears to be available and from looking into the MWI functionality.

The initial information at a high level comes from a slide deck produced by Ankur Kothari a Sr. Technical Product Manager at Microsoft. This has been published in PDF format and can be found here. Due to it being a PDF there are a number of slides which are hard to read and understand these are due to them been animation based slides and the PDF shows all the animations on a single page.

A high level view of the UM processes for leaving a message and for MWI can be seen in the diagram below (borrowed from Ankur’s slide deck)

High Level Diag

As can be seen from the diagram above the process of leaving a message has not changed; one thing to note, step 3 shows the Voice message being delivered to the Mailbox server since this is an SMTP message from the UM Server to the recipient it goes via the Hub Server.

The new to Exchange 2010 part of the diagram above is the MWI part. This works in two parts the first is the notification from the Mailbox Role to the UM Role that MWI needs to either be turned on or off. The second is the SIP NOTIFY message between the UM Role and the IP-PBX or Gateway.

Before looking into this in more detail it is worth covering off some of the higher level details. MWI is enabled at both a UM Mailbox Policy and Gateway Level, for MWI to be set correctly it needs to be enabled on the UM Mailbox Policy and at least one Gateway associated with the Policy and Dial Plan. These are enabled by default but in some scenarios it may be necessary to disable MWI for some gateways.

Also MWI does not function if the Dial Plan has a URI type of SIP URI, even though the MWI settings are available. I am unsure why this is the case but I assume it is by design and probably due to the fact that a SIP URI dial plan is most commonly used for OCS.

Moving on to look at how MWI works, the process starts with the Mailbox Role which hosts the UM Mailbox Assistant this Assistant actively monitors the user’s mailbox for the number of read and unread messages. When this count changes it sends an RPC  message to a Unified Messaging Server which hosts the UM Dialplan the user is associated with. There can be a small delay in this task being performed, this is usually due to the time it takes for Outlook to update Exchange when a message’s read\unread flag gets changed.

The following message can be seen in the Event Log of the Mailbox Role Server when diagnostic logging is turned on:

MBX MWI Event Log

The UM Mailbox Assistant is housed within the Microsoft Exchange Mailbox Assistants Service; this Service needs to be running in order for MWI to function (along with a number of other Exchange functions) .

Once the message has been received by the UM Server, a SIP message is sent to the IP-PBX or Gateway, if the first gateway is unavailable or responds with a SIP error message it will attempt each remaining IP-PBX or Gateway associated with the Dial Plan and enabled for MWI.

The SIP message sent to the IP-PBX or Gateway is a NOTIFY message and contains the following information:

  • MWI On or Off
  • Account to modify MWI on
  • Number of Read and Unread messages

The Message Body of the SIP Message looks like:

Sample MWI SIP

The reasons why the number of read and unread messages are sent is some PBXs and Phones display the number of read and unread messages. This is as specified in the RFC3842, unfortunately Exchange does not implement an optional part of the RFC which is to provide the message count for urgent messages; this would have rounded the implementation off nicely since Exchange provides the ability to mark Voicemails as High Importance.

The RFC also provides scope for the number of read and unread fax messages to be passed to the IP-PBX or Gateway, this is not implemented within Exchange MWI and is not include as part of the Voicemail message count.

The following message can be seen in the Event Log of the UM Role Server  when diagnostic logging is turned on if the SIP Notify has been successful:

UM MWI Event Log Sucess

If an MWI notification fails messages similar to the following can be see, these are written to the Event Log on the UM Role Server irrelevant of the Diagnostic Logging Setting:

UM MWI Event Log Fail 1

UM MWI Event Log Fail 2

During the MWI process both on the Mailbox Role and the UM Role a number of LDAP queries are run against Active Directory these are to look up information such as if the UM Mailbox Policies are enabled for MWI and the associated Gateways, this information is not cached and is queried for each time.

Once the IP-PBX or Gateway has been acknowledged the MWI Notify message it is left to the IP-PBX or Gateway to locate the phone or phones associated with the specified extension and either turn on or off the Message Waiting Indicator.

Any IP-PBX or Gateway that supports RFC3842 should work with Exchange 2010 MWI although specific settings my be required on the PBX.

In summary MWI is something which was missing from Exchange 2007 and although there were third party applications to fill the gap, it was still seen as a major deployment blocker. Hopefully with Exchange 2010 supporting MWI it will increase the number of Exchange UM deployments.

Tuesday, 16 February 2010

Ferrari and Exchange UM

On February 2nd 2010 Ferrari electronic passed the Exchange 2010 Unified Messaging Fax testing without any restrictions.

While this in itself may not seem unusual the way in which the solution works is.

With Exchange 2010 Microsoft removed the ability for Exchange to receive a fax instead they now redirect the message to a Partner fax solution, in the SIP world known as a REFER. These solutions are based on T.38 which is the protocol used to send and receive faxes over IP.

T.38 has been in use for a number of years and for the majority of faxes it works without issue but it also fails when some older fax machines are sending the fax or when IP network conditions are not ideal.

For organisations that are looking to move from Exchange 2007 to 2010 and use the fax capabilities within Exchange their only option is to deploy a Partner Fax Solution, this can be a costly exercise and is something else to maintain and support.

This is where the Ferrari Gateway differs, it incorporates the Partner Fax solution within the gateway allowing it to process the fax within the gateway and submit it to the Exchange 2010 Hub Transport Server.

This removes the overhead of deploying a Fax Solution within an organisation and also removes potential issues associated with T.38, fax reception on the gateway is performed using the T.30 protocol which is the standard for fax transmission over the PSTN.

This solution is supported within the Firmware of the unit and on gateways running Firmware 3.x or greater. It is also free on all those units.

Looking at the background of Ferrari it is no surprise that they have developed this imitative solution since their background is fax solutions dating back over 20 years.

Also on offer are outbound faxing solution for Exchange (and other vendors), the Exchange solution is tightly integrated and managed through the Exchange Management Console providing a common interface for administrators.

In addition Ferrari Gateways are supported on OCS 2007 R2 to provide Enterprise Voice Functionality. It would seem that Ferrari are progressing within the Microsoft UC space and mainly seen within Germany, Austria and Switzerland with partners appearing in Asia Pacific and the Americas.

If I get the opportunity to get my hands on one of the units I will provide further feedback\insight.

Tuesday, 12 January 2010

Communicator Automatic Updates Fail for 64 Bit Machines

In January Microsoft released the .83 release of Communicator 2007 R2. Installing this update either by running the MSP file or using tools like System Center Configuration Manager all is fine for 32 and 64 Bit machines.

Issues started occurred when trying to install the update using the Communicator Update feature within OCS R2. For 32 Bit users all was fine and for 64 Bit users running releases prior to .56. The issue was that all users running Communicator 2007 R2 .56 Release on a 64 Bit platform the update just fails.

After looking at the IIS log files I came across the following entry:

POST /AutoUpdate/Ext/Handler/OCUpgrade.aspx folder=OC&lang=1033&mode=non-ui&arch=x64&flavor=pm&build=fre 443 Domain\User Microsoft+Office+Communicator/3.0 200 0 0 530

While this looks fine the key is the arch=x64, this was from a client running .56 with a 64 Bit Operating System. If I look at the log entry for a 64 Bit Operating System running a release prior to .56 the line looks like

POST /AutoUpdate/Ext/Handler/OCUpgrade.aspx folder=OC&lang=1033&mode=non-ui&arch=x32&flavor=pm&build=fre 443 Domain\User Microsoft+Office+Communicator/3.0 200 0 0 530

At a quick glance this may look ok but the architecture is listed at 32 Bit.

From looking at this, it appears that the .56 release has been changed to get the architecture type from the Operating System rather than either a hardcoded x32 value or it was extracted from the Communicator Build type, as currently Communicator is a 32 Bit build only.

In doing this we now get a 64 Bit Operating System correctly identifying as 64 Bit but in turn it breaks the download. There is an easy fix to this and that is to copy the x32 directory and rename the copy to x64.

So along with having


I now also have


My clients can now download the update and all is fine.

So while my clients can now update this does open up a few questions.

The first is does this mean there will be a 64 Bit version of Communicator. While I do not know what Microsoft is planning an educated assumption can be made.

There is going to be an Office 2010 64 Bit which means there will need to be a Communicator 64 Bit as well for the integration to work correctly and due to the timing of Office 2010 we will hopefully not have to wait until Wave 14.

The bigger question\issue I have is that even if I am running a 64 Bit Operating System I want to, rather need to download a patch\update that works with the client I am running which could be either a 32 or 64 Bit Build.

So as it stands at the moment if a 64 Bit version of communicator is released and I put a 64 Bit update in the 64 Bit folder tree, my 32 Bit Build of Communicator running on a 64 Bit OS will download a 64 Bit update which will not work.

Hopefully this will be fixed before a 64 Bit version is released, as fixing it afterwards will be a nightmare.