Those familiar with Office Communications Server 2007 probably noticed after the first few deployments of Lync Server 2010 that the old Invalid_AD_Phone_Numbers.txt file created by the Address Book Service appeared to be missing-in-action in Lync Server.  This is a very handy file that helped quickly identify all the accounts in Active Directory with poorly formatted (or just plain wrong) telephone field information.  A solid Enterprise Voice deployment of Lync Server really hinges on a clean and concise numbering plan across the board.

I myself spent a fair amount of time hunting around the new file structure to see if it was simply relocated.  As documented in this previous article the location of the server address book files moved in Lync Server, as did the proper location of the Company_Phone_Number_Normalization_Rules.txt file.  But the search proved fruitless.

Recently it was discovered that the missing invalid numbers file is not the victim of a dropped feature but an apparent bug which prevents the creation of the file under normal circumstances.  In order to bring back that helpful file a quick workaround must be applied.  Microsoft is aware of the root issue and a hotfix will be in the works, but until then the following process can be used to restore this missing feature.


The supported workaround is to manually define a secondary msRTCSIP-GroupingID on a Lync enabled user account.  This problem appears when only the default Grouping ID is defined in the Lync environment.  As Lync Server was designed to be compatible with multitenant hosted deployments the Address Book file storage directory was reorganized to support multiple tiers for unique, segregated address books.  When looking at the ABFiles directory there is now a child folder for each Tenant ID with separate folders under those for each unique Grouping ID.

The default path for Address Book file storage utilizing the default TenantID (00000000-0000-0000-0000-000000000000)and GroupingID (00000000-0000-0000-0000-000000000000) values looks like this:



In order to trigger the creation of the invalid numbers file a secondary Grouping ID must be defined on at least one object in AD.  This must be a Lync-enabled user account, but it should not be any existing account which is in use.  If a non-default ID is configured on a normal Lync user account then although the invalid number file will be created, that user will be placed into a completely different Address Book group and will effectively be cut off from the rest of the Lync users and placed into their own separate address book .  Use of the SIP URI will still allow communications, but all address book searches would be segregated.

For this reason it is recommended to create a new Lync user account to serve one purpose: to define a second Grouping ID.  This account should be enabled for Lync but not actually used by anyone.  If this account is later SIP-disabled, deleted or the custom setting is removed then the workaround will no longer function.

Configure New Lync Account

  • Add a new Active Directory user account and enable it in the Lync server Control Panel.


  • Enable Advanced Features in Active Directory Users and Computers and then open the Attribute Editor tab on the user account (or use ADSIedit).  Locate the msRTCSIP-GroupingID attribute and edit the properties.


  • Enter any value within the supported data range (maximum of 32 digits). In this example a string of 32 ones were used to mimic the same pattern used by the default 32-bit zero value. The actual value of the data is not important as long as it is unique to the Lync server environment and within the accepted range. (An out-of-range value will be prevented by the attribute editor.)


  • Save the changes to the user account.




Update Address Book

  • Issue an Update-CsAddressBook cmdlet using the Lync Server Management Shell to force a new address book file update process.  Within 5 minutes the following events should appear in the Lync Server event log.


What should immediately stand out is the new warning entry of Event ID 21034. This event log message reports the creation of the failed number normalization output file, including a link directly to it.


At this point the file should now be stored in the default location and contain details on all of the failed normalization attempts from Active Directory users and contacts.


If this file does not appear then it is possible that there are no invalid fields in the Active Directory environment so to test the process simply put some sort of bad data in the Telephone Number field on a Lync user account and re-run the previous synchronization step.

Additional Information

As the msRTCSIP-GroupingID functionality is new to Lync Server there are a few additional changes that the above work-around has created in the Lync Server environment.

  • Browse to the ABFiles directory on the Lync Server to see that now a second GroupingID folder (11111111-1111-1111-1111-111111111111) has been created under the original default TenantID folder.


  • Open the new folder to reveal just two address book files, one windows client file and one device client file.  This is the new address book for all users assigned to the second Grouping ID, which currently is just the single dummy account.


By comparison the original directory still contains all of the address book client and devices file for the remainder of the Lync population, which is still assigned to the default Grouping ID.


October 2011 Update:  Microsoft has released a hotfix for this issue: this fix is planned to be included in the upcoming Cumulative Update 4 release for Lync Server 2010.

By Jeff Schertz

Site Administrator

5 thoughts on “Resurrecting the Invalid Numbers File in Lync”
  1. Respectfully, the Lync Doc Team is a small team of hard-working, caring individuals who write THOUSANDS of pages of quality documentation for each product release. If we're missing something, just let us know. We value your feedback: You can also engage with us on DrRez on Twitter and Facebook.

Leave a Reply

Your email address will not be published. Required fields are marked *