Saturday, 5 December 2009

The End of Remote Call Control

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.

Wednesday, 18 November 2009

Office 2010 Beta (OCS Integration)

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:               CTP File Icon

Beta:              Beta File Image

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.

Contact Card

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 Unknown CC New Unknown New
Offline Offline CC New Offline New
Available Available CC New Available New
Away Away CC New Away New
Busy Busy CC New Busy New
Do Not Disturb DND CC New DND New

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.

Sunday, 15 November 2009

OCS 2007 R2 Updates

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.

Tuesday, 20 October 2009

Number Normalization – Server Side

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:

Existing Normalization Rule

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:

Communicator Showing Translation 0Communicator Showing Translation 90

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,;gruu;opaque=app:locationprofile:get;default
  • Phone context is user-default, using Location Profile assigned to caller URI
  • Using user-default profile:
  • Found default parameter, need default profile
  • Using default profile:
  • Sending 200 response to SERVICE request profile details. xml=<LocationProfileDescription xmlns=""><Name></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,;user=phone newHostPart=
  • Processing From URI:;user=phone
  • Global number, no further From URI processing. FromUri=tel:+447700900621
  • Global number, no further processing.;user=phone
  • No matching rule found

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

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

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;;user=phone newHostPart=
  • Processing From URI:;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;;user=phone newHostPart=
  • Processing From URI:;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=';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:

New Normalization Rule

And the screenshot below shows the rule order:

Translation Ordering Location Profile

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,;user=phone newHostPart=
  • Processing From URI:;user=phone
  • Global number, no further From URI processing. FromUri=tel:+447700900621
  • Global number, no further processing.;user=phone
  • calledNumber='01134960121'
  • ruleName='PSTN Access UK - 0' matched Num='01134960121', txNum='+441134960121'
  • MATCH: New request Uri=''

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

  • OnRequest: INVITE, reqUri=sip:01134960100;;user=phone newHostPart=
  • Processing From URI:;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=';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.

Tuesday, 13 October 2009

Follow-up July Updates Dial In Conferencing

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:

Line URI Example

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.

Set PIN - Error

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 []
  • BranchTransaction for Pool [] 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 []
  • BranchTransaction for Pool [] is now complete.
  • branches pending [0]. Results so far [3]
  • found one user [] with valid account/pin from pool [].

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 []
  • BranchTransaction for Pool [] is now complete.
  • branches pending [0]. Results so far [3]
  • found two matches. User1 [] User2 []. 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 []
  • BranchTransaction for Pool [] 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 [] User2 []. 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.

Sunday, 13 September 2009

Outlook Anywhere fails after Exchange 2007 SP2 Install

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.

Thursday, 27 August 2009

Cisco CUCIMOC Features

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.

CUCIMOC Tools Menu

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.

CUCIMOC Device Select

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:

CUCIMOC Feature Bar

  1. Contacts and Number, are “Dragged and Dropped” here to dial a number
  2. Used to call Voicemail, when there are no Voicemails this is option is greyed out
  3. Displayed the Conversation (Call) History
  4. Switches between Softphone and Desk Phone Mode
  5. Options
  6. 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.

CUCIMOC Conv History

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.

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

CUCIMOC Place a Call

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

CUCIMOC Dial Number

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.

IM to Call 

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

CUCIMOC Incoming Call

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.


  1. End Call, Further in Call Options
  2. Start an IM with the Caller
  3. Place Call on\off Hold
  4. Mute Call (Softphone mode only)
  5. Adjust Speaker Volume (Softphone mode only)
  6. 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:

CUCIMOC In a Call Options

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:

CUCIMOC Conference Step 0.5              Choose Person to Call

CUCIMOC Conference Step 1        Add Additional Person

CUCIMOC Conference Step 2       Join Person to Existing Call

CUCIMOC Conference Step 3png     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.

CUCIMOC Transfer

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.

Sunday, 16 August 2009

OCS R2 Web Scheduler

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.

Monday, 3 August 2009

OCS R2 Caller Line ID\Name

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.

Inbound Call from Cisco to OCS with CLID

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:

Inbound call from Cisco to OCS, Wire Trace INVITE

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:

Inbound call from Cisco to OCS, Wire Trace sim-ring

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.

Outbound Call from OCS to Cisco, Toast with CLID

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

Outbound Call from OCS to Cisco, Wire Trace INVITE

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" ?>
                                <add key="forwardDisplayName" value="True" />

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.

Sunday, 2 August 2009

OCS R2 Dial In Conferencing (July Update)

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:

02-08-2009 20-42-47

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.

Tuesday, 28 July 2009

July OCS Updates

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.


Attendant Console



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!

Three of these links came from Joachim Farla’s Blog


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

CUCIMOC Screenshot

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.

Thursday, 16 July 2009

Document Libraries, Inbound Email and Workflows in SharePoint

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.

Wednesday, 10 June 2009

Polycom CX5000 AKA RoundTable

Today we received one of the new CX5000 Devices, this is the first one we have received since the RoundTable moved to Polycom.

So as with any RoundTable, I needed to configure it and assumed that I could just use RTManage as I have with all the other versions; using RTManage resulted in an “Unknown Error”, very useful.

After sometime scratching my head, I decided to look at the administrators guide; this resulted me in finding a CX5000 version of RTManage, now known as CX5000Manage.

Once I was able to get this installed, after having to uninstall the original RTManage application as they can not coexist. I was able to configure everything as required.

Slightly annoying the two application can not coexist but not the end of the world.

Technorati Tags: ,,

Friday, 5 June 2009

OCS R2, Tanjay’s (OCPE) and Updates

I recently had to set-up two new Tanjay’s on an OCS R2 install.

These devices shipped with a version which was not a beta build but also not a build that works with OCS R2.

I knew that the Device Update Service within OCS R2 was working as I had previously upgrade Tanjay’s and also that logging in on a Tanjay was working.

But for some reason these two Tanjay’s would not update, I was prompted to login so did so, the certificate would download, time would sync and then a constant cycle of freezing and rebooting.

The Display showed “"Authentication Completed, Retrieving User Information”, this would stay on the screen for a few minute, then a reboot, a login, display the same, reboot and over and over again.

I checked the logs on the Server, they showed that the Tanjay was connecting to the Device Update Service and was been given a URL to download from, and the download was happening.

The device would upload logs to the Server (Not that I know how to read these), so all looked good.

After spending far too long on what should be a simple operation, and searching around the internet I came across nothing that jumped out at me, although did find a couple of useful posts.

After getting very frustrated I found the solution.

The issue appeared to be that logging into the device was causing the update to fail, so the only option was to do the upgrade without needing to login; I assumed incorrectly the device would update correctly and then login using the new firmware.

In order to update without logging in, the Tanjay looks for the ucupdates.DHCPDomain record for the R1 firmware and ucupdates-r2.DHCPDomain for the R2 firmware. Since this was a green field OCS R2 deployment I had only created the ucupdates-r2 record thinking it would be all that was needed, and only for the Roundtables.

I created the ucupdates A record pointing it to the same IP Address that the ucupdates-r2 A record is pointing to, then I reset the device using the pin hole on the rear of the device; this clears the device and resets it back to factory defaults.

When the device rebooted it was able to download the UC Interim Firmware then, the latest R2 firmware and hay presto 10 minutes later all worked.

It should be noted that the ucupdates A record should be created in the same domain that DHCP gives out this will not necessarily match your SIP Domain.

Monday, 25 May 2009

Exchange 2010 and MWI

For months prior to the Exchange 2010 Beta being released there where rumours going around about what new features would be added.

One of the biggest features that interested me was something as seemingly minor as MWI. It is something that every voicemail system had, something that everyone took for granted, until it was no longer there.

Ever since Exchange 2007 came out, MWI has given me and many other consultants nightmares. The never ending discussions with customers as to if they needed MWI, it going so well until the one group of people (usually the Senior Executives)  that just couldn’t do without it. Everyone else was usually happy when it was pointed out that they lived in outlook so would just see the email.

Then came the painful discussion of, well you could have MWI but it would cost, and usually not a small cost either.

Well now those days are over and once again I can go into a meeting to discuss the advantages of moving to Exchange UM, without spending time talking about MWI (Let’s just hope fax support is not mentioned).

In order to see how good the MWI support is, I decided to set-up a new Exchange 2010 system and connect it to a Cisco CallManager 7. To my amazement MWI just worked, leave a voicemail and MWI lights up.

Who would have thought a small red light could bring so much pleasure (and grief)….

Thursday, 21 May 2009

Communicator Automatic Updates

Today I was looking for the latest Knowledgebase number for Communicator R2 for a document and was expecting to find the article for 3.5.6907.9.

I was rather surprised to find the article for 3.5.6907.22 (kb971083), dated 19th May 2009. There are a number of updates within it but the one that jumped out was to fix a bug that has broken automatic updates.

For those of us who decided to use Automatic Updates and had to work though the numerous issues in getting it to work, this is to say the least rather annoying.

After doing some research I came across a post on Aaron Tiensivu’s Blog (link), on a way to update clients who are running 3.5.6907.9 to 3.5.6907.22. While this method allows clients to be updated without administrators having to visit each PC, it still requires user interaction and is not something that could be done without warning.

Anyone doing this should send out information to their users before hand on how to perform the update.

Another option would be to push out the patch via Group Policy, SCCM or other similar products; but if you wanted to use these methods why would you use the Communicator Update option in OCS?