OCS 2007 R2 - Problems saving normalization rules leads to orphaned rules left in Active Directory

I ran into an interesting problem while performing a Nortel CS1000, NET VX1200 and OCS 2007 R2 integration for a client who are trying to have users slowly migrated to OCS. The problem happened when I started reconfiguring their location profiles because the one currently configured did not have the correct name and had way too many test rules in there that I felt would be more work to sort than to create from scratch. The following describes what I experienced:

After documenting the existing normalization rules that we wanted to keep and creating the new location profile, I went ahead to remove the old location profile and was prompted with the following 2 error messages as I clicked OK to close the windows:

The property sheet could not be refreshed after apply. MMC may not be able to apply any further changes correctly to WMI. Please close property sheet and re-open if you want to make any further changes.

Office Communications Server Snap-in cannot save some or all of the settings.

Since clicking the OK button wouldn’t allow me to close the window, I proceeded to close the last window by clicking the Cancel button.

What’s interesting was that when I open the Voice Properties window again, I noticed that the old location profile was no longer there (despite hitting Cancel).

However, once I proceeded to recreate one of the rules i wanted to name “10 Digit”, I was prompted with the following error message:

The normalization rule name conflicts with another rule in the system. This includes rules created for other location profiles.

Since I knew exactly where the location profiles and normalization rules were stored wtihin Active Directory, I decided to use ADSIedit to have a look.

Navigate down: Configuration –> Services –> RTC Service –> Location Profiles

… I can see that there’s only one Location Profile which means the location profile was deleted properly so I went ahead and expanded the Location Normalization Rules node and saw the following:

… since I only had 7 normalization rules configured and I can see that there’s more than 10 entries in this node, I began to check the msRTCSIP-RuleName of each entry one after another and just as I suspected, I found that some of the rules that existed in the old deleted profiles were still there:

Match DID to Alex shouldn’t be here anymore.

The following shows the properties window for the normalization rule I had problems with:

Since this company has offices that span 7 sites worldwide, I figured I’d try forcing a replication with Replication Monitor even though I didn’t think that was the problem (I’m working at the head office, making changes on the local domain controllers so this shouldn’t be a replication problem).

So even after forcing a replication and ensuring no errors were thrown, the keys were still there.

So what’s the resolution? Well, we’re not in a rush to get this resolved today so I’m going to let it sit in this state for a day and if these orphaned keys are still there, what I will do is:

1. Manually delete these keys within ADSIEdit.
2. Open Replication Monitor and force a replication from the domain controller ADSIEdit was connected to when I deleted the keys.
3. Using ADSIEdit, check the other local domain controller to ensure changes were replicated properly and then continue to do the same for, say, the domain controller in UK (I’m working in the Ontario office).

I was asked by a few people about what might have caused this and while I can’t definitively say I know, my guess with my:

Active Directory hat – would be that there may be something wrong with the domain controller OCS was trying to write to. There are 2 DCs in that site (out of 7) and I was able to replicate this twice so there is a possibility that I was writing to the same domain controller.

OCS hat – I’ve had problems in the past with another environment where the mediation servers would lose connectivity to the domain controllers rendering it unable to establish a secure connection (verified with nltest tool). That environment was more related to network due to different subnets and the network.

Sorry I can’t provide a better explanation. :)

Update

It’s been 3 days and I just had a look at the orphaned normalization rules in Active Directory and they’re still there so I went ahead and manually deleted them.