Category Archives: ABServer

AD Contact Numbers not showing in Lync

05 Tuesday Feb 2013

Posted by in ABS, ABServer, AD Normalization, ADContacts, AddressBook Service, contacts, E.164, Invalid AD Phone Numbers, Normalisation, Normalization, Test

≈ Leave a comment

Its always frustrating how Administrators don’t have any standard format in which they add telephone numbers to user in AD.
Its even more frustrating when Lync WONT collect these numbers and send to the RTCAB database cause they aren’t in E.164 format.

It is possible to add normalization rules for modifying numbers from AD to E.164 so that they are recognised by Lync and sent off to the Database.

If this happens the AddressBook Service will gladly distribute these to Lync user via GAL or WEB.

It will even distribute numbers that aren’t in E.164 as long as they have a normalization rule in the “Company Phone Number Normalization Rules” text file that matches the format in AD (as per the Extension Example below)

So how does this work?
Simply create a txt file and copy to the Lync Share

….LyncShare1-WebServices-1ABFiles

Company_Phone_Number_Normalization_Rules.txt

Now populate the txt file with your rules as per the example below:

#Start
#
# Normalize 4-digit extension numbers from Active Directory into E.164
#
# Legacy extensions
#
(d{4})
+643321$1
#Normalize NZ National Numbers from Active Directory into E.164
#+64$1
0([3-9]d{7})
+64$1
#Normalize NZ Cell numbers from Active Directory into E.164
#+642$1
0(2d+)
+642$1
#Extension Dialing for 8xxx range
(8d{3})
$1
#End


To find further Active Directory Normalization failures navigate to the directory:
C:LyncShare1-WebServices-4ABFiles0000000-0000-0000-0000-0000000000000000000-0000-0000-0000-000000000000Invalid_AD_Phone_Numbers.txt

NB
Just be warned, this isnt validated so if you make any typos you wont find this reported

BUT you can test this by running the ABServer.exe -testphonenorm switch.
Simply run the ABServer .exe from the directory:-
C:Program FilesMicrosoft Lync Server 2010ServerCore

Example


..Program FilesMicrosoft Lync Server 2010ServerCoreABServer.exe” -testphonenorm “021 123 4568”



ABS Updates take too long

05 Tuesday Feb 2013

Posted by in ABS, ABServer, Address Book, AddressBook Service, CsClientPolicy, GAL, WebSearch

≈ Leave a comment

GAL or Server Based Search?

There is always going to be that one person that gets annoyed with how long it takes before the AB is updated with new information from AD…

There are some great blogs on how to speed up the process of Updating the GAL.
Lync will query AD based on the CsUserReplicationConfiguration – ReplicationCycleInterval. By default this is set to 1 minute.


The ABService will then look for updates in the RTC Database based on CsAddressBookConfiguration – SynchronizePollingInterval (default set to 5 minutes)


The Lync Client in turn will Download the updated AD Files triggered at login and initiated by a random time between 1 – 30 minutes. This can be forced to immediate with the RegKey GALInitialDownloadDelay set to 0

The problem is that once the Client is actually running it needs to keep checking for updates. This is done by another random timer between 1 – 60 minutes…Aargghh!!

If you want “Real Time” AddressBook responses you will have to move away from using the GAL and instead query the Lync Server via Web directly.

Chang the CsClientPolicy – AddressBookAvailability to WebSearchOnly (default is WebSearchAndFileDownload)

Set-CsClientPolicy -AddressBookAvailability WebSearchOnly


Rebooted the client to load the new Client Policy, checked in configuration information which now states under Gal or Server based Search: Server Based Search

Once the change has been made you will notice that the Lync User no longer gets the error that the Address Book is updating and search results may be affected as the query is directly to the Lync Web Services.

NOTE
If a user has had a number change BOTH the old and new number shows on the user drop down list for dialing, HOWEVER only the OLD number shows on the Contact Card until the 1:30 AM Sync has run…

Go figure….

AddressBook Error after CU applied

28 Saturday Jul 2012

Posted by in ABS, ABServer, AddressBook Service, GAL, RTCAB, RTCDatabase

≈ Leave a comment


Problem
This one came up a few months ago…

One thing that has been omitted from the automatic update procedure is the PS command to update the SQL database  Don’t get me wrong, I am really happy about the simplicity introduced by running the LyncServerUpdateInstaller.exe that figures out what updates to apply to which servers on its own. 

In my case, after running the updates I launched the PS Command as instructed

Install-CsDatabase -Update -ConfiguredDatabases -SqlServerFqdn -UseDefaultSqlPaths

Only to find that I no longer had full access to the SQL backend (thanks SQL Admin). Once this was corrected I attempted the PS Command once more and to my disappointment was greeted by this error below:-

Running script: C:Windowssystem32cscript.exe //Nologo “C:Program FilesCommon FilesMicrosoft Lync Server 2010DbSetupRtcAbDBSetup.wsf” /sqlserver: /serveracct:EMSCRTCComponentUniversalServices /verbose
—————
Installed SQL Server 2005 Backward Compatibility version is 8.05.2312
Connecting to SQL Server on
SqlMajorVersion : 10
SqlMinorVersion : 50
SqlBuildNo : 1600
SQL version is acceptable: 10.50.1600.1
Default database data file path is F:SQL_Data
Default database log file path is G:SQL_Logs
Opened database rtcab

Db version unknown. Clean install required.
(Major upgrade of database required.)
Due to schema changes this database cannot be re-used. It must be dropped and a new one created.
To preserve data, you must use this product’s backup/export restore/import solution. Examine the product documentation for instructions.
—————
Exit code: ERROR_NEED_MAJOR_UPGRADE_USE_IMP_EXP (-50)
—————
What! The ABSStore database was not getting created, and now the RTCAB and RTCAB1 databases are poked. They were working fine just before.

Effect

I had run out of time and needed to get off the systems so I did a quick check and found that all seemed to work fine. I then noticed that my Lync Event log on the FE was reporting that the ABServer and all things related to AB was stuffed. The ABServer.exe was attempting to start and then failing in a cycle that quickly filled the logs. Shortly after this users started getting the old ! to indicate that the client was unable to download the GAL. Makes sense since the AB wasn’t running.


Interestingly, a Lync Trace of the ABServer reported this:

Connection string “Data Source=;Initial Catalog=RtcAb;Integrated Security=True;Enlist=False;Connection Reset=False;Connect Timeout=10”

Followed by connection errors. Taking a closer look at the myriad of errors in the event log I also saw this:

Process: ‘C:Program FilesMicrosoft Lync Server 2010ServerCoreABServer.exe’ Exit Code: C3E8302D!_HRX! (The worker process failed to initialize itself in the maximum allowable time.!_HRM!).
Cause: This could happen due to low resource conditions or insufficient privileges.
Resolution: Try restarting the server. If the problem persists contact Product Support Services.

Restarting the server, of course…that didn’t work.

I know it isn’t resourcing as I been trying this at different times of the day and the SQL server wasn’t low at all. Ahh privileges ..wasn’t that how this all started? Running the update PS Command with insufficient rights? That has been remedied. Talking to the inhouse DBA I was informed that the RTCAB and RTCAB1 look rather unusual. RTCAB1 had been locked and the Schema was odd. Some rights didn’t look right (all DBA talk, right).

Solution 

First up let me remind you that I get rather anxious simply by using the SQL acronym in speech. After trying a new CU update (which failed with the same error) from advice here and here.. 

I decided to “drop” the RTCAB and RTCAB1 databases (more SQL talk). Had the SQL guy back them up as a precaution (they were broken already but somehow this made me feel a little more comfortable).

Stopped all things Lync from the FE Server (stop-cswindowsservice), dropped the databases and then launched the PS Command (above) that started all this trouble. 

SUCCESS!

What I noticed was that the PS Command Install-CsDatabase -Update simply installed the RTCAB and RTCAB1 databses when it found that they had been dropped…phew..gulp! 

I then ran update-csaddressbook, replicated to other Lync servers. Manually deleted the GAL and fired up the client, GAL was downloaded. Finally!

The SQL DBA tells me that the RTCAB and RTCAB1 now look very different as far as permissions and shema are concerned. 

I’ll ask them to explain this to me once more but don’t hold your breath for a better take on this from me, as I said before touching S-Q-L makes me very uncomfortable, talking about it is almost forbidden so it may simply be a whisper.