Adam's UC Blog

Microsoft Lync Mobile and WiFi

2011-12-16T00:05:00.001Z

In the last week Microsoft have released their Lync Mobile Clients, which support IM, Presence and Call via Work. Competitors have made a lot of noise around the seemingly limited functionality such as not providing Voice over WiFi, Video or Desktop sharing. Like any competitors they will openly pick holes in a product rather than look at why Microsoft may have done this.

Taking a look at the Voice and Video over WiFi aspect of this (and to some extent desktop sharing). Current Wireless Technology is somewhat limited when it comes to Real Time Media and the average Wireless deployment is usually not designed with Real Time Media in mind.

While users can use their Laptop and use real time media within application such as having a Lync call over a wireless connection issues start to occur the moment someone starts to walk around with the laptop. This is because WiFi was never really designed to be used while people are moving, yes it is designed for mobile workers but for them to be stationary while using it.

This changes the moment you start to use a mobile device over WiFi as a user will often walk around with the device, potentially getting further away from an Access Point reducing the signal strength and available bandwidth, moving between access points or even worse outside of coverage completely.

The last two points, moving between access points and leaving the coverage are the ones which really cause issues with real time media over WiFi. Access points do not have the ability to seamlessly handover connections between them; due to this there can be instances where you lose the network connection for a few seconds when moving between them. For real time media this causes major issues and you will lose part of a call for example. This is why technologies such as DECT are still widely used (and seen as the industry standard for wireless telephony devices) as they do offer this functionality and are specifically designed for users moving about while on a call.

Looking at the issue that occurs when leaving the wireless coverage completely, users will be in a position where their call terminates since there is no capability to provide a seamless handover between the WiFi and GSM (this isn't a Lync issue, it is industry wide). Due to this if a user moves out of coverage of the Wireless network then the call will drop and they will have to re-dial causing user frustration along with a bad experience.

This is why Lync Mobile sticks to Voice over GSM as it is the only way to guarantee good quality call and a good experience. This is the “Call via Work” functionality where Lync will place an outbound call to the Mobile Device and then an outbound call to the number dialled, this could be to another Lync user in which case it could be a SIP call or it could be out to the PSTN.

While there is generally a cost to placing these calls it is often the trade-off between having a good call and an alright call which could drop halfway through, personally I know which one I would prefer. There are also ways to mitigate these costs such as using a dedicated “Mobex” connection to your GSM provider or through Mobile Gateways which utilize SIM cards to place calls.

I have worked with several customers who use Mobile Gateways and associated SIM cards they are very easy to set-up and are usually connected to a Lync Certified Gateway, such as NET. On these gateways a static route could route all mobile calls to them or functionality such as LDAP lookups can be used to dynamically route calls for mobile devices owned by the organization to the Mobile Gateway.

Depending on the contracts negotiated with mobile providers it is sometimes possible to provide free calls between the Mobile Gateway (which are effectively mobile phones) and the mobile phones.

Lastly some vendors have stated that they are developing new Wireless Access Points to better support real time media over WiFi, if they do this it should benefit all users who want to run real time media over WiFi, but the very requirement that they need to do this demonstrates that today there are issues.

RunAs Radio Show

2010-08-29T15:36:00.001+01:00

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 info@runasradio.com.

Communications Server 14, Authentication and Certificates

2010-07-20T19:32:00.001+01:00

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.

Communications Server “14” – TechEd Day 1

2010-06-08T02:13:00.001+01:00

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.

Communicator:

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.

Devices:

Will use ABS-WQ for searches.

SharePoint:

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).

Architecture:

Support for redundancy across Datacenters.

Conferencing:

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.

Telephony:

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.

Development:

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

Virtualisation:

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

Mobile Client:

Improved functionality.
Support for more devices.

Federation:

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.

NET’s 21st Century Gateway

2010-06-01T00:03:00.001+01:00

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.

Remote Call Control Lives On

2010-05-23T12:15:00.001+01:00

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.

Monitor Active Directory LDAP Queries

2010-04-11T00:39:00.001+01:00

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.

Benelux Techdays – Communications Server “14” Sessions Review

2010-04-10T00:27:00.003+01:00

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.

Communication Server “14” – Voicecon RFP Response Review

2010-03-28T20:28:00.001+01:00

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.

Exchange 2010 UM – Behind the Scenes MWI

2010-03-13T00:03:00.001Z

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)

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:

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:

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:

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:

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.

Ferrari and Exchange UM

2010-02-16T15:03:00.001Z

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.

Communicator Automatic Updates Fail for 64 Bit Machines

2010-01-12T21:29:00.001Z

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 10.0.0.1 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 10.0.0.1 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

\\localhost\ClientUpdateData\oc\x32

I now also have

\\localhost\ClientUpdateData\oc\x64

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.

The End of Remote Call Control

2009-12-05T22:44:00.001Z

BJ Haberkorn recently wrote an article entitled Cisco: Just Like Any Other Office Communications Server ISV?, while this article provides some interesting information and insight; BJ provides a link to the joint support statement which can be found here.

Within the support 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 customers upgrading their Remote Call Control deployments to the next release of Office Communications Server. Microsoft has announced the deprecation of Remote Call Control in Office Communications Server. As a result, in the next release of Office Communications Server, new deployments of Remote Call Control will not be supported by Microsoft. “

This is the first time I have seen in writing that Remote Call Control will be depreciated in the Wave 14 Release of OCS.

So what does this mean for Remote Call Control (RCC) for customers looking to deploy OCS R2 with RCC today.

One of the main reasons why customers deploy RCC is that their users still require some of the PBX functionality that OCS cannot provide or customers have gone through a recent IP Telephony (IPT) upgrade but want to utilise some of the OCS Features such as Busy Lamp, Missed Call Notification and Caller Line ID (CLID) lookup.

For these customers as the statement indicates they will still be able to utilise this functionality with the Wave 14 Release, what we do not know at the moment is the lifecycle for Wave 14. While customers are not forced to upgrade to each release as it comes out customers often try to keep up with the release cycles. I think it is a safe assumption that for Wave 15 RCC will not be supported under any scenario. So the question is when will Wave 15 be released will it be in 2011 following the yearly releases we have seen with 2007, 2007 R2 and then Wave 14 or will the release cycle be extended, at this stage this is a complete unknown.

For customers who are utilising RCC due to a lack of telephony features in OCS some of these will hopefully be addressed in Wave 14 allowing some customers to migrate from RCC to Enterprise Voice (EV). Wave 15 will hopefully further extend the telephony features removing the reason for using RCC from being used due to a lack of features to being utilised by customers who do not want to move away from their IP-PBX.

So while we know that RCC is being depreciated what I have not yet seen a comment on is Dual Forking, this functionality is often used by companies who want to allow a user to use both a traditional PBX Phone and use OCS as a Softphone. While this functionality is not dependent on RCC the two go together and are usually deployed together. Until further information is released it will be an unknown.

The final thing to look at is the term “Supported”. The statement indicates that for customers upgrading from a previous version to Wave 14 it will be supported for them to use RCC but for new customers it will not be supported.

This indicates that the functionality will remain available and I am unsure how this will be “locked” out for new installs. What is more likely is that the term “Supported” to Microsoft usually means if it will be Supported by Microsoft Product Support Services (PSS). So while RCC may work for new installs it will not be supported by PSS.

While a lot of this is speculative it will hopefully give an indication of how the support for RCC is changing and hopefully the picture will become clearer as the Product Group release further details about the Wave 14 Release.

Office 2010 Beta (OCS Integration)

2009-11-18T11:55:00.001Z

At PDC they announced the release of the Office 2010 Beta, MSDN and TechNet first followed by General Download a day later; a lot of people were expecting this is be announced at TechEd EMEA but we had to be content with the Exchange 2010 Launch.

After using the CTP of Office 2010 since it became available I couldn’t wait to move to the Beta; but feared the process of having to uninstall and install all of the 2010 application suite. I could see hours being spent configuring it how I wanted and syncing all of my SharePoint Workspace (Groove), Spaces.

To my amazement I had none of this pain, everything was configured, SharePoint Workspaces had all of my Spaces configured and up to date along with Outlook being fully configured.

So after the joy of not been able to deal with emails for 30 minutes, I went to work through the backlog and noticed a few things have changed for the worse and some changes are just interesting.

The light grey on the folder list is now dark grey making it hard to read some of the greyed out text, I will have to work out how to fix (change) that one.

In the CTP the office icon was used for the File Menu this has now changed to the word File and looks a bit lost in the box; I have shown the CTP and Beta one below, personally I prefer the CTP one:

CTP:

Beta:

Moving on the surprising part is the change to the OCS Integration, the Presence Icons have changed from being Circular to a Square along with the changes to the Contact Card.

This is a change between CTP and the Beta and completely different to OCS and Exchange OWA. The new Contact Card is shown below; this was in the CTP and has been commented on by several people.

The differences I want to look at is the presence bar on the left hand side of the photo and the smaller presence icons that appear next to a persons name in Email, the Quick Contacts Pane etc; incidentally the photo is retrieved from SharePoint .

The new presence icons are shown below:

State	Contact Card	Presence Icon
Unknown
Offline
Available
Away
Busy
Do Not Disturb

I do find it hard to tell the difference between the Unknown and Offline for the Presence Icon, but apart from that the Icons look functional and do seem to flow a bit better than the current ones.

So the question is, is this the future of the OCS Presence Icons or is it just the Office Product Group doing what they want.

If we take a look at another of the Wave 14 Products, Exchange 2010, the presence icons shown in OWA are the same as OCS 2007 R2. This is to be expected since they utilise the UCMA API, which is released by the OCS Product Group.

I would have assumed that Office would use the Communicator APIs, if they are, they either have a better relationship with the OCS Product Group than the Exchange Product Group or they use their own Icons.

So is this the product groups doing their own thing or just that Office is further ahead in their Wave 14 development, I guess we will only find out when OCS Wave 14 is released be it Beta or RTM.

OCS 2007 R2 Updates

2009-11-15T17:59:00.000Z

As part of the October update to OCS R2, Microsoft released the Server Update Installer. This application allows an administrator to install all of the updates applicable to a specific machine rather than needing to locate and install each one separately.

The application provides a useful middle ground between the updates being released for manual installation and them being released via Windows Update (If they are at all).

The Update Installer is simple to run and details of how to run it are provided within this Microsoft Knowledge Base Article.

Personally I would like to see the Server Update Installer progress into something more, something that is integrated in with OCS in a similar way to the way client updates can be pushed out via the Front Ends.

When Client Updates fist came out I was critical of them and even more so when one of the QFEs broke the update mechanism. The Client Update require the logged in user to be a local administrator which in the majority of organisations they are not. There are also numerous tools to deploy the updates such as WSUS and SCCM.

The same is true for Server Updates they can be deployed using standard tools such as SCCM; the area where tools such as SCCM are lacking is that they are not aware of what OCS is doing. At a set time they will push out and install the updates and then reboot the machine; this is done irrelevant of if an MCU on a Front End is hosting a conference or if a Mediation Server currently has a call in progress.

The only way for an administrator to overcome these issues is to remove servers in rotation from Load Balancers, modify Voice Routes to take Mediation Servers out of service; all of this is very time consuming for something as simple as installing an update that takes 5 minutes to install.

Therefore I would like something built into OCS that takes all of this hassle out of my hands. I give OCS a Server Update Package to install and it goes away and does it all for me, identifies which servers need to be updated, and one by one takes the servers out of service, waits for resources to no longer be used (or migrate sessions to another server), install the updates, reboot and brought back into service.

This may sound like overkill but it means that the expensive HA solution that I have installed continues to operate and my users do not notice; all they see is new functionality coming online.

Maybe something like this will appear in future releases as the management tools improve, methods such as Remote PowerShell would make processes like this easier to implement, at least from my very simplistic view.

Number Normalization – Server Side

2009-10-20T11:07:00.002+01:00

In OCS Number Normalization is performed in two places either on the Server if it is a Server activity or on the client if it is a client activity .

During my testing for my previous post around PSTN Conferencing I came across some difference in the way client side and server side normalization works.

These differences mean that translations which would succeed on the client will fail when performed server side.

My intial investigation have focused around a single Normalziation rule, in order to keep things simple.

So first the background, in the UK it is common for PBXs to require a 9 to be prefixed to numbers for outbound dialling so to cater for this I often use the following normalization rule, this allows users to continue to enter numbers as they would have done using a PBX phone:

This rule should allow for either:

01134960121
901134960121

To be entered and be translated into:

+441134960121

This works as expected in the communicator client as shown in the following two screenshots:

Route Helper and Test Translation within the Admin Tool both perform the translation as expected as well.

In this test there is only 1 Normalization Profile, which is assigned to the Pool and Mediation Server; there is no User Specific Profile assigned.

With regards to the logging shown during this post we will be focusing on the TranslationApplication log; as this contains the required information; in order to make the logs readable I have removed all but the explanation text; and each line is shown as a bullet point.

Before moving to the Server Side aspect, shown below is the output for when the Communicator Client logs in and downloads the Normalization Profile.

OnLocationProfileRequest: SERVICE, reqUri=sip:adam.gent@contoso.com;gruu;opaque=app:locationprofile:get;default
Phone context is user-default, using Location Profile assigned to caller URI
Using user-default profile: name=UK.contoso.com
Found default parameter, need default profile
Using default profile: UK.contoso.com
Sending 200 response to SERVICE request profile details. xml=<LocationProfileDescription xmlns="http://schemas.microsoft.com/2007/03/locationProfileDescription"><Name>UK.contoso.com</Name><Rule><Pattern>^9?0(\d{9,10})$</Pattern><Translation>+44$1</Translation><InternalEnterpriseExtension>false</InternalEnterpriseExtension><ApplicableForDeviceDialing>true</ApplicableForDeviceDialing></Rule><OptimizeDeviceDialing>false</OptimizeDeviceDialing></LocationProfileDescription>

I have removed all normalization rules from the last log line above apart for the one we are interested in.

Moving onto the Server Side, OCS uses the Translation Application to perform all Server Side Normalization requirements on the Server. For testing I have tested against the PSTN Conferencing (Conferencing Attendant Service (CAS)) and incoming calls into the Mediation Server.

Starting with Conferencing, I have called into the CAS twice from a Mobile (Cell) Phone, the first test is using 01134960121 as the phone number to identify with and the second is using 901134960121 both of these should be translated to +441134960121 as shown earlier with the Communicator Screenshots

The first test failed and the second test worked correctly as can be seen in the log outputs below:

Input: 01134960121 Expected Output: +441134960121 Actual Output: No Match

OnRequest: INVITE, reqUri=sip:+441134960100@contoso.com;user=phone newHostPart=
Processing From URI: sip:+447700900621@contoso.com;user=phone
Global number, no further From URI processing. FromUri=tel:+447700900621
Global number, no further processing. RequestUri=sip:+441134960100@contoso.com;user=phone
calledNumber='01134960121'
No matching rule found

Input: 901134960121 Expected Output: +441134960121 Actual Output: +441134960121

OnRequest: INVITE, reqUri=sip:+441134960100@contoso.com;user=phone newHostPart=
Processing From URI: sip:+447700900621@contoso.com;user=phone
Global number, no further From URI processing. FromUri=tel:+447700900621
Global number, no further processing. RequestUri=sip:+441134960100@contoso.com;user=phone
calledNumber='901134960121'
ruleName='PSTN Access UK - 0, 90' matched Num='901134960121', txNum='+441134960121'
MATCH: New request Uri='sip:+441134960121@contoso.com'

This shows that the Translation Application does not understand the optional part of the Regular Expression.

In order to see if this just occurs with the CAS, I did the same tests by providing 01134960121 and 901134960121 as the Called Number in an incoming call to the Mediation Server. Again the first test failed and the second test worked correctly as can be seen in the log outputs below:

Input: 01134960121 Expected Output: +441134960121 Actual Output: No Match

OnRequest: INVITE, reqUri=sip:01134960100;phone-context=UK.contoso.com@contoso.com;user=phone newHostPart=
Processing From URI: sip:+447700900621@contoso.com;user=phone
Global number, no further From URI processing. FromUri=tel:+447700900621
calledNumber='01134960100'
No matching rule found

Input: 901134960121 Expected Output: +441134960121 Actual Output: +441134960121

OnRequest: INVITE, reqUri=sip:901134960100;phone-context=UK.contoso.com@contoso.com;user=phone newHostPart=
Processing From URI: sip:+447700900621@contoso.com;user=phone
Global number, no further From URI processing. FromUri=tel:+447700900621
calledNumber='901134960100'
ruleName='PSTN Access UK - 0, 90' matched Num='901134960100', txNum='+441134960100'
MATCH: New request Uri='sip:+441134960100@contoso.com;user=phone'

Having established the same issue occurs for both the CAS and Mediation Server, I wanted to see what happened if I entered simple Normalization Rule to match 01134960100

In order to do this the following Normalization Rule was added and it was placed in the order after the existing rule.

The screenshot below shows the new rule:

And the screenshot below shows the rule order:

Running the two tests that failed again, 01134960100 for both the CAS and the Mediation Server both worked as expected although against the new Normalization Rule.

These are shown below:

Conferencing, Input: 01134960121 Expected Output: +441134960121 Actual Output: +441134960121

OnRequest: INVITE, reqUri=sip:+441134960100@contoso.com;user=phone newHostPart=
Processing From URI: sip:+447700900621@contoso.com;user=phone
Global number, no further From URI processing. FromUri=tel:+447700900621
Global number, no further processing. RequestUri=sip:+441134960100@contoso.com;user=phone
calledNumber='01134960121'
ruleName='PSTN Access UK - 0' matched Num='01134960121', txNum='+441134960121'
MATCH: New request Uri='sip:+441134960121@contoso.com'

Mediation Server, Input: 01134960121 Expected Output: +441134960121 Actual Output: +441134960121

OnRequest: INVITE, reqUri=sip:01134960100;phone-context=UK.contoso.com@contoso.com;user=phone newHostPart=
Processing From URI: sip:+447700900621@contoso.com;user=phone
Global number, no further From URI processing. FromUri=tel:+447700900621
calledNumber='01134960100'
ruleName='PSTN Access UK - 0' matched Num='01134960100', txNum='+441134960100'
MATCH: New request Uri='sip:+441134960100@contoso.com;user=phone'

While breaking down the Normalization rules into simple rules is one option, it is far from ideal as it create more rules and potentially more confusion; considering the rules work as expected client side.

Since I have only looked at a single Regular Expression which focuses around an optional character either there is an issue with the optional character within the Translation Application or there are issues with other regular expressions.

In summary just because every OCS test tool says that the normalization rule works and it works in Communicator do not assume that it works server side. Hopefully this will be fixed so that the same rule produces the same output no matter if it is run client or server side.

It would also be useful for another test tool that allows for testing against the Translation Application.

The test platform was OCS 2007 R2 Enterprise Edition running QFE2.

Follow-up July Updates Dial In Conferencing

2009-10-13T23:34:00.001+01:00

A few months ago I posted about the changes in Dial In Conferencing following the July Updates also knows as QFE 2; which can be found here.

Since this posting Brian Ricks pointed out that if the Tel URI has the extension specified in a users OCS Account Settings this will be used to match against when authenticating in Dial In Conferencing; it also populates in Communicator Web Access. An example of the Line URI setting can be seen below:

Someone then asked the question of what happens if someone has the same extension such as:

tel:+12223334444;EXT=4444
tel:+12225554444;EXT=4444

While OCS will prevents duplicate phone numbers it will allow duplicate extensions.

This intrigued me, so I started to look in more detail of how the conferencing login works and the associated activities such as setting a PIN.

The first step was to configure two users with the different E.164 numbers but with the same extension and one user with just an E.164 number, these were:

User A: tel:+12223334444;ext=4444
User B: tel:+12225554444;ext=4444
User C: tel:+12226664444

The next step was to set a password on each this is done via CWA; the system I am testing this on is set to allow passwords with a minimum length of 4 and to keep things simple I opted to set a password of 9898 for each account.

This worked for the first account, for the second account I received the error shown below.

Knowing that the password does comply with the policy and trying for a second time, I tried a different PIN (7878) and this worked correctly.

Therefore it appears the answer to the question of if multiple people can have the same Extension assigned, they can not have the same PIN resulting in OCS being able to match an Extension and a PIN uniquely to a user account.

The problem I see with this is that with an error message of:

“The PIN you provided does not meet your company’s policy requirements. Please create a new PIN.”

Users are likely to try the same PIN a couple of times and then call the IT Support team; if the error message indicates that they had to choice a different PIN users a more likely to do so.

So now that we know how OCS keeps users unique, lets take a look under the hood.

During this we will be focusing on the UserPinService log; as this contains the required information; in order to make the logs readable I have removed all but the explanation text; and each line is shown as a bullet point.

In addition each call to the PSTN Conferencing is done using a standard phone, rather than using an OCS Endpoint. This ensures that Communicator or Phone Edition does not automatically authenticate.

First lets look at how the User PIN Service locates the user to do the PIN matching against; the logs below show me logging in with an extension of 4444.

Error Translating Number: No matching rule has been found in the dial plan for the called number.
ResolveUser Sproc - Phone Number = 4444, NPH1 = +4444 NPH2 = 4444 Phone Ext = 4444 MaxResults = 200

From the first line it is possible to see that there is no normalization rule in the location profile assigned to the Pool that matches 4444.

The User PIN Service then goes to look for a Tel URI that matches 4444, +4444 or an extension that machines 4444; this is shown in the second log line above.

If a user(s) is found the logs will show something similar to the below:

Found [1] pools to search across.
initialized with [1] branches and [2] users.

In this case two users were found and the User PIN Service continues to try and match the entered PIN against one of these two users.

Expanding on this I added a new Normalization Rule to the Profile assigned to the Pool, this contained the following:

Phone pattern regular expression: 4444

Translation pattern regular expression: +12226664444

This resulted in three users being located by the User PIN Service, which is shown below:

ResolveUser Sproc - Phone Number = 4444, NPH1 = +4444 NPH2 = +12226664444 Phone Ext = 4444 MaxResults = 200
Found [1] pools to search across.
initialized with [1] branches and [3] users.

In addition by configuring two additional users with a Tel URI of 4444 and +4444, the search result increased to 5; these were then removed to avoid further confusion.

It is also worth pointing out that the exact same routine would happen if a person entered their full phone number:

Error Translating Number: No matching rule has been found in the dial plan for the called number.
ResolveUser Sproc - Phone Number = 1222333444, NPH1 = +1222333444 NPH2 = 1222333444 Phone Ext = 1222333444 MaxResults = 200

Looking at what happens when the PIN entered is invalid, log entries similar to the below will appear:

VerifyUserPinBatchLocal - Succeeded, calling back with [3] results.
VerifyUserPinBatch succeeded for Pool [OCSR2.contoso.com]
BranchTransaction for Pool [OCSR2.contoso.com] is now complete.
branches pending [0]. Results so far [3]
no users matched the supplied pin.

If the PIN entered matches a user, log entries similar to the below will appear:

VerifyUserPinBatchLocal - Succeeded, calling back with [3] results.
VerifyUserPinBatch succeeded for Pool [OCSR2.contoso.com]
BranchTransaction for Pool [OCSR2.contoso.com] is now complete.
branches pending [0]. Results so far [3]
found one user [usera@contoso.com] with valid account/pin from pool [OCSR2.contoso.com].

The next aspect to look at is the PIN Change process. If the user tries to enter a PIN which is already assigned to a user, log entries similar to the below will appear:

Succeeded, calling back with [3] results.
VerifyUserPinBatch succeeded for Pool [OCSR2.contoso.com]
BranchTransaction for Pool [OCSR2.contoso.com] is now complete.
branches pending [0]. Results so far [3]
found two matches. User1 [usera@contoso.com] User2 [userb@contoso.com]. Failing request with pinNotUnique.
ResolveUserWithPin call failed with [PinNotUnique] verification code [OtherFailure]

If the PIN Change is successful, log entries similar to the below will appear:

Succeeded, calling back with [3] results.
VerifyUserPinBatch succeeded for Pool [OCSR2.contoso.com]
BranchTransaction for Pool [OCSR2.contoso.com] is now complete.
branches pending [0]. Results so far [3]
no users matched the supplied pin.
ResolveUserWithPin call failed with [OtherFailure] verification code [OtherFailure]
Need to increment auth failure for all users
Processing RecordFailureBatch sproc.
Deserializing request: Microsoft.Rtc.Server.UserPin.Private.updateuserpintype
Processing SetPin sproc.

The last line shown above shows that the PIN is being Set, the failure notices can be safely ignored these are the User PIN Service checking to see if another user with the same Extension is already using the PIN.

Now that we have gone through the main processes; it is worth looking at the issues that occur with multiple users having the same Extensions; either directly specified or through the normalization process.

As we have seen the User PIN Service searches Active Directory based on 4 criteria and pulls back records matching 1 of those 4 criteria; in addition it limits the maximum number of returned rows to 200. While this for the majority of installation will not be an issue for large installations looking to move from 100’s of PBXs to OCS issues could occur.

The other issue being the more common will be users receiving an error while changing their PIN; while a 4 digit PIN allows for 6561 combinations, not taking into account the PINs blocked by OCS for being too simple, users are still creatures of habit and try to keep things as simple as possible. Therefore it is likely users will try PINs like 1212 or 9090.

The final thing to consider is what happens if two people end up with the same PIN and the same extension. In order to get two users with the same PIN, required a bit of trickery but it is something that can happen within a live environment.

I removed the 4444 normalization rule and then configured User B and User C with an PIN of 1819. OCS allows me to do this due to 4444 no longer translates to +12226664444. I then added the 4444 normalization rule back in.

This results in two users which will be matched with an Extension of 4444 is entered and PIN of 1819. Although two users are matched OCS handles this by refusing access to the conference since it does not know which user is trying to access the conference. This is shown in the logs as:

found two matches. User1 [userb@contoso.com] User2 [userc@contoso.com]. Failing request with pinNotUnique.
ResolveUserWithPin call failed with [PinNotUnique] verification code [OtherFailure]

It is likely that this scenario will only happen is you are utilising the extension setting in the Line URI and you modify the the Pool Normalization Profile after users start setting their PINs. This could happen if additional PBXs are brought online which were not catered for the initial Voice Plan design. The only solution would be to remove the Normalization rule or get all users to reset their passwords.

The other important part of Dial In Conferencing is the Conference Attendant (CAA) and Conference Announcement Service I stayed away from pulling logs from the Conference Attendant in an aim to keep this as simple as possible. For those of you wondering why a user is prompted for a PIN if the Extension is invalid this is due to the CAA capturing both the Extension and the PIN before passing it into the User PIN Service.

I will aim to review the Conference Attendant (CAA) and Conference Announcement Service in a later post.

One thing to point out that this has all been tested on a system with only a Single Pool; how the scenarios alter with Multiple Pools I am unsure.

And the final point is that during the testing for this post I found some strange behaviour in the Number Normalization, I will follow this up in a separate post.

Outlook Anywhere fails after Exchange 2007 SP2 Install

2009-09-13T22:07:00.001+01:00

I recently upgraded an Exchange 2007 install from SP1 to SP2, and hit a couple of issues during the install. In order to perform the install I followed the steps listed here; along with uninstalling every UM Language Pack except for en-US. Everything was going fine until running the SP2 installer.

The installer reached the “Removing Files” step which I believe is either step two or three (At this stage I had not decided to blog about it so didn’t take any notes). At this stage the installer failed and prompted to restart the machine and run the installer again at this stage it started to go down hill.

After restarting and attempting to run the SP2 install I hit an error saying the install could not continue with this error:

“The Exchange binary files are not installed, but the backup settings registry key is present. Only build-to-build upgrade mode is available”

On taking a look through the Exchange Program Files location the binary files were missing, needless to say this did cause a few moments of worry. Since I had not come across this issue before, I turned to the Internet and found this Microsoft Article, it refers to SP1, but was able to fix my current issue. After copying Exchhelp.chm to the correct location and starting the 3 IIS Services I was able to continue with the install.

The TechNet Article instructs you to extract the files from the Exchange Service Pack exe, you should have already performed this step to run the installer; also since the Exchange Binaries have been deleted you can not start the Services, but they do need to be set to Automatic.

After this I was able to run the upgrade, I did hit issues though I had to keep setting the services to Automatic from Disabled, this was due to each Role disabling them as the Service Pack was applied and then failed if they were not set to Automatic (Manual would probably have worked as well) by the time that role had been updated, this was annoying and not all services needed to be changed back to Automatic but without an exact list to work from, changing them all seemed the easiest option.

By this stage the Service Pack installed and everything appeared to work, email came and went, users were able to receive email using Outlook and OWA. Well via Outlook if they had a connection to the Corporate Network, Outlook Anywhere had stopped working; and my Event Log had started getting very full. The Event Log filled up with two errors

The first error had an Error ID of 2214 and a description of:

“Could not load all ISAPI filters for site 'DEFAULT WEB SITE'. Therefore site startup aborted.”

The second error had an Error ID of 2268 and a description of:

“The HTTP Filter DLL C:\Program Files\Microsoft\Exchange Server\ClientAccess\owa\auth\owaauth.dll failed to load. The data is the error.”

Again I had never come across this issue before and found a posting on the Microsoft Exchange Discussion Forums, which can be found here; the thread lists two solutions the one highlighted in the link worked for me.

The post indicates that extrace.dll needs to be copied to a location where the system was looking for it, after running Process Monitor the extrace.dll was being looked for in each folder in the system path; this did include “C:\Program Files\Microsoft\Exchange Server\Bin”, this path actually had the extrace.dll file in it but for some reason was not being found. After copying extrace.dll to c:\windows\system32 Outlook Anywhere started to work.

After everything started to work I wanted to replicate the issue, so I removed the extrace.dll file from c:\windows\system32 and Outlook Anywhere still worked, restarted IIS and it still worked, rebooted and it still worked.

Running Process Monitor again it appears that the extrace.dll file in “C:\Program Files\Microsoft\Exchange Server\Bin” is being found and used. I am not sure why it failed in the first place but now it appears to be finding the file correctly, letting it find and use the file in “C:\Program Files\Microsoft\Exchange Server\Bin” means the file will be updated by future updates.

I am unsure if a reboot after the Service Pack installed would have fixed the issue with Outlook Anywhere, until I find another system with the same issue, all I can do is wonder.

Hopefully this post will fix someone’s issue and if I find a reboot fixes the issue I will update this post.

On a final note I highly encourage people to use Process Monitor and all the Sysinternals Tools, they can often save a great deal of time.

Cisco CUCIMOC Features

2009-08-27T09:15:00.001+01:00

In my last post I said I would go into detail on the features offered by CUCIMOC. I do not intend to compare these to the features offered by Remote Call Control (RCC)\Dual Forking as these features are documented in a number of places and are a standard within OCS.

CUCIMOC offers a number of features which are identical to that of RCC\Dual Forking, it appears that Cisco did not want to take away any of the Voice functionality, it looks like only one Voice Feature has been added which is Call Park a feature often used within businesses but is missing not only from RCC\Dual Forking but also from the Enterprise Voice side of OCS as well.

Before going into further detail on the Client Features, I just want to comment on the CUCM aspect.

When running in RCC mode CUCIMOC is controlling a Cisco IP Phone, this phone retains all of the functionality it would have through being used manually.

When running as a Softphone, CUCIMOC is registered as a Cisco Unified Client Services Framework (CSF) device; this is a Phone created on the CUCM in the same manor as an IP Phone would be.

I have not tested what features are available such as Call Recording, Boss Secretary Working, Busy Lamp etc but I would assume that most of this functionality would work.

So lets look at what the Client has to offer.

The client offers some of the features that you have come to expect from a Cisco Client, such as Server Status and Create Problem Report; these aid in the troubleshooting and when escalating faults to Cisco support. These are added to the tools menu within Communicator and can be seen below.

The one of greatest interest is the “Select Device for Communication Pane” this allows the user to select which device they wish to use. This is useful if a user has multiple phones assigned to their user profile. Users are able to select any phone which is assigned to their CUCM User Account, the Directory Numbers can differ.

One slight bug appears to be that the number is only shown if you select the device.

It should be noted that if using CUCIMOC as a Softphone, it will only register the device it is using, other devices will show as unregistered. Due to this, there is a delay when switching between Desk Phone mode and Softphone mode and vice-versa this is due to the device being registered/unregistered.

Taking a look at the CUCIMOC Communications Pane, there are a number of options:

Contacts and Number, are “Dragged and Dropped” here to dial a number
Used to call Voicemail, when there are no Voicemails this is option is greyed out
Displayed the Conversation (Call) History
Switches between Softphone and Desk Phone Mode
Options
Dial Pad

I will come back to dialling and the in call features later. Clicking on the Voicemail icon simply calls through to Voicemail.

The Conversation History brings up the window shown below.

Users are able to double click a previous call to redial or they can right click to display other numbers to call, they also have the option to send an Instant Message or view the Contact Card.

I have shown the contact card below, since it looks different to the Communicator one, unfortunately there is no way to dial from the contact card.

Switch between devices is self explanatory, click and switch.

Moving on to the options, I have chosen to show these below as they are self explanatory.

When forwarding calls, the “Another of my phone numbers” provides a drop down box on selection to choose a number, and “Another contact or number” displays a Cisco version of the Contact List to either choose a contact or enter a phone number.

The final item in the Communications Pane is the dial pad, this allows user to place call by entering a number on the dial pad and selecting call, it can also be used for DTMF during a call, it is a nice addition and something that users often comment on as a missing feature from Communicator.

Moving on to look at placing a call and the features offered once the call has started, there are three ways to call a person, one is by right clicking a contact and clicking “Place a Call”, if the contact has multiple numbers it will always call the work number. The “Place a Call” option is added in by CUCIMOC.

Another method of placing a call is to drag the contact on to the Dial icon in the Communication Pane.

One thing to note is that the numbers for contacts are direct from an LDAP source, which each user is configured for, in my case this is Active Directory. This means that it does not use the contact numbers provided via Office Communicator. Due to this if a Federated Contact provides their contact numbers (Access Level Company and Higher) you will not be able to dial these contacts without manually entering their details.

Although users are able to call outlook contacts, by searching for a contact and either right clicking or by using drag and drop.

The final way of making a call is by escalating an Instant Message conversation to a Voice Call, this can either be a 2 Person Conversation or an IM Conference. This is performed through selecting the users at the top of the Instant Message window (multiple select via Ctrl) and then selecting “Place a Call”. Conferencing is handled as detailed later in this post.

Before looking at the in call features, lets take a look at how an inbound call in handled. When a call is received a Toast is displayed providing the option to either answer the call or send it to voicemail. If the number is within the LDAP source it will resolve the Caller ID to a Name (I think this may also be for Outlook Contacts but not 100% sure).

One thing to note is that there is no way to choose were to answer the call like there is with RCC\Dual Forking. It is answered using the currently selected device. Initially I viewed this as a problem, until talking to someone who pointed out that you choose the device you want to use when you start working, only changing it when you change location.

When a call in answered a new window opens showing the in call options, this is shown below.

End Call, Further in Call Options
Start an IM with the Caller
Place Call on\off Hold
Mute Call (Softphone mode only)
Adjust Speaker Volume (Softphone mode only)
Dial Pad for DTMF etc.

Each of the above is self explanatory so we will move on to the other In Call Options, these are shown below:

Conference and Transfer function in away you would expect from Cisco telephony, starting with Conference.

The user has the option to add people to the call creating a conference, this is done by calling the additional participant, talking to them then adding them to the existing call. This differs from the OCS route of just dumping people into a conference. This sequence is shown below:

Choose Person to Call

Add Additional Person

Join Person to Existing Call

Three way call

People can also be added to the conference through drag and drop, but this will call the default number, as detailed above.

Transferring is handled in a similar way, the user selects who to transfer to, talks to the person they have called and then has the option to transfer the call, this is commonly known as an announced transfer. This is a useful addition as OCS only has announced transfer for RCC and when using the Attendant Console.

The main transfer dialog is shown below, the dialog for choosing who to transfer to is the same as the conference one shown above.

There is the option to not transfer, by selecting the End Call button or to complete the transfer by clicking Complete Transfer.

One thing I have noticed is that you can switch between calls, by clicking the Hold button, the problem is though that on switching back you lose the Complete Transfer option. I have only tested this in Desk Phone mode, I am unsure if this is the same in Softphone mode.

The final item to look at is Call Park, this functions as you would expect on a CUCM, the call is parked on a Pilot Number, and presented to the user to pass on.

As you can see from above, it is parked on 5990.

That brings to an end the review of the CUCM features, it has gone on longer that I thought but hopefully it all makes sense and is of use. I may have missed out a feature or two, but hopefully I have covered all the important ones.

OCS R2 Web Scheduler

2009-08-16T17:19:00.001+01:00

On Friday (August 14th ‘09) Microsoft released the OCS R2 version of the Meeting Web Scheduler.

This allows users who can not use the Outlook Plugin, to be able to schedule meetings, it does have some limitations such as not being able to schedule recurring meetings and it is also limited to the English language.

This can be downloaded from here, once installed an Installation Document can be found in the installation location, I am not sure if this is available as an independent download or if it has been added to the Documentation Libraries.

The Web Scheduler is installed on the Front End Servers for a Consolidated Enterprise Edition, on the Web Components Server for Expanded Enterprise Edition and on the Standard Edition Server.

Once the Web Scheduler has been installed it needs to be activated, this is done using the LCSCMD command.

For a Standard Edition Server this is:

LcsCmd.exe /web /action:Activate /role:Meeting /poolname:<pool_name> /User:<user_name> /Password:<password>

For an Enterprise Edition Server this is:

LcsCmd.exe /web /action:Activate /role:Meeting /poolname:<pool_name> /User:<user_name> /Password:<password> /guest:<guestuser> /guestpassword:<guestpassword>

This Username and Password should be the same account used to activate the OCS Web Components, by default this is “RTCComponentService”. For the Enterprise Edition Servers you also require the Guest Username and Password, by default this is “RTCGuestAccessUser”

The LCSCMD command can be found at cd "%commonprogramfiles%\microsoft office communications server 2007 r2" (The installation document missed out the Microsoft part of the path).

One things to note is that during our installation the FrontEnd Service did not restart after it was shutdown by the installer.

Once installed and activated the SMTP Server needs to be set, this is done using a VBS file to modify the web.config file; the web.config file can be edited directly as well.

There are two web.config files one for the Internal users and one for the External users, you need to modify both files.

These are located at:

"%ProgramFiles%\Microsoft Office Communications Server 2007 R2\Web Components\conf\int"

"%ProgramFiles%\Microsoft Office Communications Server 2007 R2\Web Components\conf\ext"

To set the SMTP Server address, using the VBS script the syntax is:

cscript WebSchedulerConfig.vbs /Action:SetSmtpServer /SMTPServer:SERVER_FQDN

Only a single SMTP Server can be specified, so this should be taken into consideration for High Availability deployments.

The Web Scheduler will send the email as the user that is creating the conference and uses the RTCComponentService account to do this or the account name you choose to use. Therefore you will need to ensure this account has the relevant permission to do this. In Exchange this is done by granting the “Send As” right to the RTCComponentService Account.

The last thing to do is to ensure that conf/ext is available from the outside world, if using ISA this should be the addition of a Path on the Web Components publishing rule.

Most of the information above is available in the Web Scheduler Installation document.

I have come across the following during installing and testing.

Having the same user in the Presenter and Attendee list will result in a “Server Error has Occurred” message.
The installation document mentions that users can join meeting be navigating to “https://ocsfqdn/conf/int/join.aspx”, this web page does not exist.
It will use different PSTN Conference IDs for Conference Calls unlike the Outlook Plugin.
The attendees get sent a meeting request which they can accept, decline etc. For the person setting up the meeting, the request appears to be incorrect as no meeting enters the calendar, so any responses from participants result in an error of “The meeting is not in the Calendar, it may have been moved or deleted” . I am not sure if this is due to running the CTP of Office 2010 or due to our SIP Addresses not matching our Primary Email Addresses, or if it is a general issue.

One of the useful items in Web Scheduler is that it lists all conferences a user has scheduled, either via the Outlook Plugin or by using the Web Scheduler, this allows users to easily see what is scheduled; it also lists the expiration date of the conference which users are unable to see any other way.

OCS R2 Caller Line ID\Name

2009-08-03T12:48:00.001+01:00

In the July Server Updates a change was made to allow the Callers Name to be passed from the PBX\Gateway to the Mediation Server and in turn passed in to OCS; the change also flows the other way as well.

This change goes back on previous comments made by Microsoft in that they would not trust any information from the PBX with the exception of the Callers Phone Number.

In an mixed telephony environment were users are split between Enterprise Voice and Traditional Telephony passing the Callers Name is an important feature, as there are often phone numbers which are not listed in Active Directory. For example Shop Floor Phones, Hall Phones etc.

The change is equally if not more important the other way as well, as traditional PBXs only store Name to Extension mappings for Extensions that exist on the PBX.

This functionality has existed for years with trunking methods such as QSIG which allows for Display Names to be passed between PBXs.

So lets look at how this is handled by OCS.

Below is a screenshot of the Toast for an incoming call into OCS, in this case the Callers extension is not in Active Directory.

The name is shown in Italics to show that the Callers Name has come from the PBX in this case a Cisco Call Manager rather than from Active Directory.

One thing to note is that this does not work on Tanja Phones, all that is shown in the Callers Phone Number; this is tested on 3.5.6907.35.

This information can also be seen in the SIP Trace as shown below:

The Callers Information is also shown in the Invite out to another Phone if you are using Simultaneous Ring; although this is only useful if you are calling a phone that can understand this:

The final part is an OCS User calling a PBX Phone, this functionality is not enabled by default and requires a changed on the Mediation Servers.

The screenshot below is a Toast on the Cisco IP Communicator, the Phone Number is not known to the PBX and as such would result in just the Callers Phone Number being displayed prior to the July Update.

This information can also be seen in the Invite shown below:

The change required to enabled the Callers Name for Outbound OCS calls is detailed in the KB972721, but is covered below for completeness.

A file called MediationServerSvc.exe.config should be created in the Mediation Installation Directory which be default is at %programfiles%\Microsoft Office Communications Server 2007\Mediation Server

This file should contain.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
                 <appSettings>
                                <add key="forwardDisplayName" value="True" />
                 </appSettings>
</configuration>

Once this file has been created the Mediation Server should be re-started. I am somewhat surprised this is not a WMI setting, since a number of Mediation Server settings were moved to WMI in R2 rather than creating\modifying this file.

Just to add if you are not seeing the Callers Name being passed between the PBX\Gateway and OCS or vice versa you should ensure that the Gateway\PBX is configured to allow the Callers Name to be passed.

OCS R2 Dial In Conferencing (July Update)

2009-08-02T20:55:00.001+01:00

Dial In Conferencing was a feature added in OCS R2 and has been modified since the initial release by the Patches released in April and July.

The purpose of this post is to cover off the changes in the July Patch.

The first change is to the Announcements made during the login phase. “Authenticated User” has been replaced for “Leader” and a Leader is now required to login to conferences protected by a PIN.

Previously if a conference was protected by a PIN the Leader or any Authenticate users did not need to login, this has now changed.

It should be noted that while the prompt says Leader, anyone who has an Extension and PIN on the OCS System can login. Microsoft have purely just changed Authenticated to Leader.

The main thing I wanted to comment on though is that a user can now enter their Extension rather than their full DDI to login as an authenticated user.

So if my Extension is 1234 and my DDI is +44201231234. I can now enter 1234 or 44201231234, being able to enter the Extension does make life a bit easier.

So now that I can save a second or two when logging into conference calls I became interested in how OCS or more specifically the Conference Attendant translates 1234 to +44201231234 in order to look up my User in Active Directory and check that my PIN is valid.

In order to translate the Extension number into the E.164 number it uses the Location Profile assigned to the Pool. For many organisation this would not be an issue but for Organisation who assign different Location Profiles to each user, using an Extension would result in failures.

Using multiple Location Profiles are common in situations were Companies are using OCS to replace multiple independent PBXs with overlapping Dial Plans. Something which is made easier in R2 (R1 required Group Policy Settings).

So while for the majority of OCS Users using the Extension may be possible for some organisations it will cause issues. Personally I would prefer to have an option to turn this off and for Voice Prompts to just say enter your Full Phone Number.

I am also unsure how this will work in OCS Deployments that have multiple Pools as I am assuming OCS will use the Location Profile in the Pool that the Conference is Hosted on, which again will create issues were extensions overlap.

The last area of confusion for me is Communicator Web Access (CWA). The July CWA update adds in an Extension field as shown below:

I am unsure how the Phone Extension is worked out, since it does not appear to come from active directory as for all instances it appears to be calculated as detailed above and Normalisation Rules are one way.

I might get a surprise tomorrow when I login, some overnight process might run and populate the field and get rid of the error.

Or I am missing something in Active Directory, if I do find out there is an AD field I will update the post.

July OCS Updates

2009-07-28T20:50:00.001+01:00

There has been a new round of updates for OCS; I have seen links for the various updates, but not for all of them together so they are listed below.

Communicator

http://www.microsoft.com/downloads/details.aspx?FamilyID=515d6dba-4c6a-48bb-a06a-d99c5742676d&displaylang=en

Attendant Console

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=36beb56d-072e-4a92-b781-a1e8a548a5ac

Servers

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=b3b02475-150c-41fa-844a-c10a517040f4

Tanja

http://www.microsoft.com/downloads/details.aspx?familyid=565595be-6cf3-4a61-a1e4-12555749ca64&displaylang=en

It looks like the release notes have not been fully updated, so not 100% sure what the fixes are except so far I have heard they fix a call transfer issue were the transferring user (the one in the middle of the three parties) was receiving a failure message even though the transfer worked.

Last but not least there is an update to the documentation, I really wish they would tell us which of the many documents were updated!

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e9f86f96-aa09-4dca-9088-f64b4f01c703

Three of these links came from Joachim Farla’s Blog

http://unified-communications.blogspot.com/2009/07/update-on-microsoft-downloads.html

Cisco CUCIMOC

2009-07-28T09:21:00.002+01:00

CUCIMOC was officially released to the public on the 15th July as part of the Cisco Unified Communications Manager (CUCM) 7.1 launch; but has been in private Beta for several months and was first shown to the public at VoiceCon Orlando ‘09.

CUCIMOC stands for Cisco UC Integration for Microsoft Office Communicator and is part of the Cisco Strategy to allow customers to embrace Microsoft OCS for Instant Messaging and Presence while allowing Cisco to continue to own the End to End Voice Estate.

So the question that has been asked over and over again is why did Cisco release CUCIMOC when they already have a method of integrating with OCS. The following is my view on this which is hopefully not biased in either direction (Cisco or Microsoft).

Prior to the release of CUCIMOC the only way to integrate between OCS and the CUCM was to utilise the Dual Forking and Remote Call Control (RCC) functionality within OCS; with Remote Call Control requiring the addition of the Cisco Unified Presence Server (CUPS).

For Cisco there are a number of issues here, firstly it requires the addition of the CUPS Server for RCC, for most customers the requirement to add an additional Server purely for integrating with OCS causes many issues, such as:

Cost to deploy the additional server
Administration overhead and cost
Licensing Costs

CUPS becomes even more expensive if you start to look at High Availability which requires the addition of a second CUPS Server and a pair of Load Balancers. For the Dual Forking side additional configuration is required on the CUCM to support this along with the OCS Mediation Server.

The other element for Cisco is that for Dual Forking, Microsoft own the Voice Path once the call hits the Mediation Server. Microsoft Voice is an engineering change to Cisco and makes the deployment more complex; in addition there is the requirement to configure all of the Voice aspects in OCS.

Finally for the Cisco aspect we need to consider what they lost to Microsoft and what they are trying to take back. With the Dual Forking and RCC route they lose both the Presence and Voice aspects. By moving to CUCIMOC they take back the Voice which for Cisco should be the preferred over presence.

For Microsoft there are also a number of issues, firstly they have made it no secret that they are not going to continue to develop the RCC aspects of OCS; so there is always a chance that either RCC will be removed or there will be a point were it will no long be viable for either Cisco or Microsoft to maintain the interoperability. Then there is the Dual Forking aspect while I do not envisage Microsoft removing this functionality it does not tie in with their plans for OCS to be a fully functional PBX replacement.

Getting the focus back to CUCIMOC the answer to the question of why did Cisco release this appears to be that Cisco did not want to be reliant on the Microsoft offered integration methods or be caught out if they were removed or deemphasized. It also allows Cisco to continue to own the End to End Telephony of a company.

Before focusing on what CUCIMOC offers in terms of functionality I just want to review the why they choose to offer CUCIMOC instead of pushing CUPS\CUPC (Cisco Unified Presence Client).

It would appear that the Cisco party line tends to be if the customer has OCS or wants to go OCS then it is better to support this decision and offer integration than offer nothing at all; this has been seen with Exchange Unified Messaging verse Cisco Unity.

If someone has not made a decision as to using OCS or another platform then Cisco will offer CUPS\CUPC as a possible solution.

So rather than as some say CUCIMOC it Cisco’s way to show the end of CUPS\CUPC it is more Cisco ensuring that no matter what route a customer takes Cisco has a solution for them.

So lets start to look at what CUCIMOC has to offer. CUCIMOC integrates with OCS through using the Tab functionality within Communicator; this functionality has been around since LCS (and incidentally was how Avaya “bolted” their Softphone into Communicator) and allows for a Web Page to be displayed and interacted with. This can be seen below (CUCIMOC is shown within the Red Box):

So what does CUCIMOC have to offer; well the functionality is similar to that of if the RCC and Dual Forking route was taken.

The functionality includes:

Control of a Cisco IP Phone
Using the PC\Laptop as a Softphone (Cisco IP Communicator is not required)
Notification of incoming calls via a Toast Popup
Dialling from applications such as Internet Explorer
Dial Pad for Dialling
Call History
Calling Buddy List Contacts (Slightly different than the RCC and Dual Forking route)

In another post I will go into this in more detail (This post can be found here).

I should also point out what CUCIMOC takes away or at least what Cisco suggests you take away.

The Installation Guide asks the implementer to configure OCS for Instant Messaging and Presence Only; disabling all Voice and Video functionality within OCS. Cisco list 3 reasons for doing this:

Single User Experience
Inconsistent Voice Traffic
Mixed Configuration is harder to manage and monitor

While all of these are valid reasons the one thing that always springs to the top of my mind is if OCS is only used for IM and Presence then only the Standard OCS CAL is required.

The one thing they do not mention disabling is Web Conferencing AKA On Premise LiveMeeting to comply with the Standard CAL requirements you would also have to disable this.

The problem with disabling this functionality is that CUCIMOC only replaces the Voice Aspect there is no support for Video or Web Conferencing.

This functionality is available within the Cisco Portfolio using products such as WebEx for Web Conferencing and Cisco Unified Video Advantage for Video.

So the question is will we see these being tied into a future CUCIMOC release; for the Video aspect I would hope so as it is a natural progression. WebEx I am not sure as it is a hosted subscription based service.

The last thing to touch on is the Remote Access and Federation abilities of OCS. Firstly Federation from a Voice (and Video) point of view allows federated OCS systems to easily communicate. By disabling all but IM and Presence this functionality is removed; users in other organisations receive messages informing them that the functionality is disabled if they attempt a Voice or Video call.

For some this loss of this functionality is a major issue for others it is more an annoyance depending on the usage of this functionality within their organisation. Currently I do not see how Cisco can work around this and provide the functionality within CUCIMOC.

For Remote Access users OCS has the ability to use Voice (and Video) remotely through the Edge Servers; this is something that CUCIMOC does not currently offer.

Within the Cisco Telephony Portfolio it is possible to use Cisco IP Phones without a VPN through using the Cisco ASA Phone Proxy. It will be natural extension for CUCIMOC to utilise this functionality to provide Voice without needing a VPN.

So in conclusion CUCIMOC is a good start towards Cisco building Voice into the Communicator Client without relying on Microsoft to continue to provide functionality such as Remote Call Control and Dual Forking. Like any new software release; the first release is usually a public statement of intent with further releases building on this to provide the functionality that customers require.

Hopefully within the next few releases things like Video Support and Voice (and Video) without a VPN will be added allowing customer to not lose functionality if they choose to use CUCMOC.

Document Libraries, Inbound Email and Workflows in SharePoint

2009-07-16T15:29:00.001+01:00

So up until a week ago I had never installed SharePoint and never really used it. But needless to say that didn’t stop me installing it and trying to get it working.

Well everything worked fine, inbound emails in to SharePoint were working and being stored in document libraries correctly and then I tried to be clever and use a custom workflow (although I believe this problem is with standard workflows as well). I wanted the workflow to run when an email was received by the Document Library.

It turns out that since SP1, there was a “Security” Enhancement that stops the System Account from running the Workflows and since incoming emails are processed and then items created as the System Account the workflows do not run.

There is a patch for SP1 to fix this and the patch is rolled into SP2, but you have to run a command to get it all working. The fix sets the workflow to run as the user that linked the workflow to the Document Library.

This information is provided in various KB articles which are linked to from several forums but since I have spent far too long searching for it I thought I would post about it here, so if nothing else I know were to look next time.

You need to run the following command, the stsadm tool can be found in %COMMONPROGRAMFILES%\microsoft shared\web server extensions\12\bin

stsadm -o setproperty -pn declarativeworkflowautostartonemailenabled -pv true

KB article 953289 provides details of this along with a link to the hotfix for SP1 users.