Assign below information to new user Carl below and enable Lync features.

Telephone number (Work phone number): 1111222

Home number: 33334444

Mobile number: +8655556666

JobTitle: SE

Department: ECS

After Update-CsUserDatabase and Update-CsAddressBook, you will see the Lync client download address book files successfully,

 Now if Carl check his own phone information, the mobile phone number can be seen in the contact card but no work/home number.

And also let another Client Bob (Who has been prevent to download address book) check Carl’s contact card, he sees the same thing with Carl does .

Why the Work/Home phone can not be displayed? And Why Bob has no local address book, he can still see Carl’s phone numebers?

Here are some explainations:

1. Each phone number must be E.164. If not, we need use Company_Phone_Number_Normalization_Rules.txt to normalized to E.164 format.
2. Testuser should publish its contact information from his local address book back to Lync server (A location called Static Publication in Lync backend-database), and then Lync will retrieve these nubmere again via In-BandProvision.

Some users often ask: why not Lync pick up the phone numbers directly from local address book files like Outlook? My personal thought is that such meachnisam can make sure each Lync user can get other user’s contact card information real time.

Note: Let’s assume the design that Lync pick up the phone numbers directly from local address book. In this case, if Bob want to call Carl, however Bob recently failed to download address book (perhaps wront proxy settings in IE prevent to download address., and Bob haven’t noticed that make him always thought its address book is latested) . So if Carl changed his phone number, Bob will not know and call old wrong number.

Ok, back to the this scenario, let’s continue to make all of them displayed.

Now open Carl’s local GalContacts.db, we will notice the phone numbers. Is it too simple for Work and Home numbers?

Here comes normalization rule part.

Get Sample_Company_Phone_Number_Normalization_Rules.txt in Lync Server 2010\WebComponents\Address Book Files\Files folder, copy it to Lync file store folder then rename it to Company_Phone_Number_Normalization_Rules.txt.

Open it and add a rule as:

Now let’s run Update-CsAddressBook again, then address book file regenreatd and downlowed by Carl. It shows correctly.

Open Carl’s GalContacts.db again, the number are correct.

Now Bob will see the correct result as well. (Though he has no local address book yet)

So now, we have finished configuring the contact card. You may also refer following blogs for more information:

Lync 2010 Address Book Normalization

https://blog.schertz.name/2010/09/lync-2010-address-book-normalization/

Updating the Lync 2010 Address Book

https://blog.schertz.name/2010/09/updating-the-lync-2010-address-book/

603  Decline

ms-diagnostics:  3098;reason="No MCU Factory Available";source="FE.contoso.com"

The resolution is:

Create DWORD registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\

Call it “SendTrustedIssuerList” with value of 0, default value. 

The reason is that since the IM conferencing server using the certificate from third party vendor, the MCU component may not display the third party certificate to itself (loop back) since this certificate is not in trusted certificate authorities list. That’s why we need set the SendTrustedIssuerList key to false. 

When Communicator client access the contact card, it will retrieve the title info from Static Publications, which is aggregated by OCS server. For the details, when a user subscribes to a presentity’s presence, the user can receive multiple instances of the presentity’s contact card. One of these is published by Office Communications Server when the data is from Active Directory. Others are published by Office Communicator when the presentity signs in, and they can be from in-band provisioning, the Address Book Service file, or user input. The data from the different instances can conflict with each other. It is up to the client application to interpret and reconcile the conflicting data. Office Communicator does the reconciliation for some properties, but not all of them. Office Communicator Service does not do any reconciliation, except publishing the Office Communicator Server instance of the contact card if it is missing or accidentally overwritten by client publication.

Please note that if one communicator failed to retrieve the latest values will overwrite the Static Publications with the outdated data available to it. Therefore, we not only need make sure the OCS generated correct address book file and subscriber’s communicator download the correct GalContact.db, but also need make sure the presentity’s communicator (the user in the contact card) also downloaded the correct GalContact.db and published the latest data to Static Publications.

OC Presence: Category Instances
https://msdn.microsoft.com/en-us/library/dd941370(office.13).aspx

Base on above theory, the troubleshooting steps are as follows:

1. Make sure the address book files in sever side generated successfully:

The address book data is retrieved from Active Directory, stored in the RTC database, extracted from the RTC database, and then placed in files and the RTCAb database for use by various clients. The following steps are performed:

• User Replicator (UR) reads the new or modified (that is, added, deleted, changed) user and contact object information from Active Directory and writes it into the RTC database. This process runs every 60 seconds.
• ABServer.exe reads the address book information from the RTC database and generates two sets of full and delta (that is, contains only the changes) address book files for use by Office Communicator (that is, with the file extension *.lsabs) and Office Communicator Phone Edition (that is, with the file extension *.dabs). These files are placed in a NTFS directory.  ABServer.exe also creates a full database (that is, RTCAb) that is used by the Address Book Web Query Service. By default, ABServer runs on a daily basis at 01:30. Also all phone numbers that cannot be normalized are placed into a .txt file in the same NTFS folder.
• Office Communicator, Office Communicator Phone Edition, and other related clients download either the full or delta file on a daily basis. They are access either through a file URL (also called a UNC path) to the NTFS folder or through a HTTPS URL (or HTTP if configured). The address book entries are then stored locally in the GalContacts.db and potentially in GalContactsDelta.db.
• Office Communicator Mobile clients leverage the Address Book Web Query Service, which leverages the latest daily updates in the RTCAb database.

Data Flow in Address Book Server
https://technet.microsoft.com/en-us/library/bb963980(office.12).aspx

1). Deleted files out of the ABS share in OCS server.
2). Ran the abserver –regenUR
3). Ran the abserver –syncnow
4). Both commands returned with the usual “completed successfully. You may need to wait 5 minutes.
5). Go to OCS server side’s address book files folder, run the command below to check each file one by one, such as Abserver /dumpfile F-0e6d.lsabs , check the output file to see if the target contact in these files contain old value or new value.

Managing the Address Book Server from the Command Line
https://technet.microsoft.com/en-us/library/bb936631(office.12).aspx

2. After verifying the server side address book generated succcessfully with correct info, then we can make sure communicator client download the file sucessfully.

1). Delete all the communicator’s address book files under AppData\Local\Microsoft\Communicator\SIPAccount\
2). (Optional) After client side GalContacts.db files regenerated, we can double cofirm if the department, title, phone number etc. in contact card has been updated or not. Use some tool such as UltraEdit, open the GalContacts.db, search the department, title, phone number etc. to see if it is the new value or old value for this user.

Note: We can also let Office Communicator (.37 or later) downloads the GAL immediately after start-up:
 
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator]
"GalDownloadInitialDelay"=dword:00000000

3. Now we can wait for some time. Let communicator user publish its latest contact info from downloaded GalContacts.db to Static Publications via SIP. Then check it again.