Search This Blog

Friday, 4 October 2013

Updating the Lync 2010 Address Book

Artical Taken from Jeff Shertz's Blogs

The overall process is basically the same as what Office Communications Server does (covered in this past article), but with added flexibility of easily customizing some of the timing of the different events.  The entire process happens over time based on a number of intervals, and by default looks like this:
  1. Changes performed on Active Directory objects are automatically synchronized by the LS User Replicator once every 60 seconds.  These changes are written into the back-end SQL database for the pool as well as the rtcab database which is used by Address Book Web Query service for the Lync 2010 Mobile client.
  2. Once every 24 hours (1:30AM local server time) the LS Address Book Server will execute a synchronization pass which pulls the most recent information stored in the SQL rtc database and writes those changes into the address book files.
  3. On a randomized schedule the Lync client and Lync Phone Edition clients download any updated .lsabs and .dabs files from the Lync Server’s share to update the client’s local GalContacs.db cache file.
    Just as with OCS there are many scenarios when waiting a ‘day or so’ to see changes appear in the contact list are less than ideal, so the manual steps have been outlined in detail in this article.

Understanding the Process

The first two items on the list above are both server-side processes are are controlled individually by separate Set and Update cmdlets.  Since PowerShell cmdlets are now used for any and all configuration this means that separate command-line tools like lcscmd.exe or abserver.exe are no longer used in Lync Server.  The ‘abserver.exe –RegenUR’ command has been replaced by Update-CsUserDatabase and the ‘abserver.exe –SyncNow’ command has been replaced by Update-CsAddressBook.
    Let us first look at the User Replicator configuration, which is the process which synchronizes data between Active Directory and the Lync SQL databases.
  • Execute the Get-CsUserReplicatorConfiguration cmdlet.
PS C:\> Get-CsUserReplicatorConfiguration
Identity                  : Global
ADDomainNamingContextList : {}
ReplicationCycleInterval  : 00:01:00
The ReplicationCycleInterval value indicates the default behavior of Lync Server to search Active Directory for any changes every minute. This interval is 1 minute by default and can be customized to any value between 1 second and 24 hours.
The second half of the server-side process is controlled by the Address Book Service which pulls information from the SQL database and writes the changes to the address book files.
  • Execute the Get-CsAddressBookConfiguration cmdlet.
PS C:\> Get-CsAddressBookConfiguration

Identity                   : Global
RunTimeOfDay               : 1:30 AM KeepDuration               : 30
SynchronizePollingInterval : 00:05:00 MaxDeltaFileSizePercentage : 20
UseNormalizationRules      : True
IgnoreGenericRules         : False
EnableFileGeneration       : True
Noteworthy here are the SynchronizePollingInterval and RunTimeofDay settings.  The default RunTimeofDay value of 1:30 AM is the same setting that OCS used and is still indicative of the one time per day that Lync Server automatically updates the address book files automatically.
The SynchronizePollingInterval is how often the abserver.exe process checks for a pending synchronization event.  Basically when the Update-CsAddressBook cmdlet is run then a ‘synchronize now‘ event is marked and the update is not actually run immediately.  The event itself happens the next time abserver looks to see if a sync event has been triggered.  This polling interval is 5 minutes by default and can be customized to any value between 5 seconds and 3 hours.

Update Servers

Because Step #1 in the process happens by default every minute then any recent changes in AD should already be imported into the SQL database.  If this is not the case or for some reason normal replication is failing then a manual process can be used to toss out the entire copy of AD information in the SQL database’s address book store and regenerate a completely new copy.  To rebuild Lync’s copy of the AD data simply use the Update-CsUserDatabase cmdlet.  Be aware that is stuff is more process intensive than the automatic delta synchronization.  This step should not be necessary under normal circumstances.
In the time it took to read the previous paragraph Lync Server should have synchronized and outstanding changes in Active Directory and Step #2 can be manually processed.
  • Execute Update-CsAddressBook to trigger the Lync Server to synchronize current Active Directory information in the SQL database into the downloadable client and device address book files. (The -verbose switch was used in the example below to display the informational text; it is not required when running the cmdlet.)
  • After 5 minutes check the Lync Server event log on the server for a group of LS Address Book Server event reporting the results of the update command.
  • The contents of the four LS Address Book Server informational events show the triggered update and the results. The number of OC delta files written” shows that 40 new contacts were created, reflecting the new user accounts previously added into Active Directory and enabled for Lync Server.
Event ID:      21005
Synchronization pass started.
Event ID:      21010
Synchronization pass completed successfully. Address Book web service backend data partition = RtcAb1
Event ID:      21056
Synchronization Pass Summary.
Sync pass completed with 11 contacts processed
Number of separate AD partitions: 1
Number of valid contacts: 11
Number of empty contacts: 0
Number of invalid contacts: 0
Number of cached photos deleted: 0
Number of stale OC files deleted: 0
Number of OC full files written: 1 with 11 total contacts
Number of OC delta files written: 8 with a total of 40 new/updated contacts and 0 deleted contacts. Number of OC bytes written: 10,072 compressed to 7,134 bytes on disk.
Number of stale device files deleted: 0
Number of device full files written: 1 with 0 total contacts
Number of device delta files written: 11 with a total of 0 new/updated contacts and 0 deleted contacts.
Number of device bytes written: 1,657 compressed to 1,248 bytes on disk.

Event ID:      21004
Next synchronization pass will start at:
9/24/2010 1:30:00 AM

Update Clients

Just as Office Communicator has done since a later R2 hotfix, Lync also will not immediately download changes to the Address Book files when first launched, but instead wait for a random interval of time between 1 and 60 minutes.  To trigger an immediate download two steps must be taken on the client workstation.  The first step only needs to be performed once per workstation, while the second would be done each time a forced update is desired.
  • First, execute the following command from the Windows Command Prompt run as an administrator (or manually add the GalDownloadInitialDelay registry key).  Setting this value to 0 will force Lync to immediately download the address book instead of randomly selecting a time to check the server.
reg add HKLM\Software\Policies\Microsoft\Communicator /v GalDownloadInitialDelay /t REG_DWORD /d 0 /f
Take note that the there is another difference here between the Lync and Communicator clients.  For standard 32-bit operating systems the registry path below is the same regardless of the client versions (OC 2007 R2 with July 2009 update or Lync 2010 RC) but previously 64-bit operating systems running the 32-bit only OC 2007 R2 client had to have the setting created under the Wow6432Node policies key.
  • Second, exit the Lync client and manually delete the GalContacts.db and GalContacts.db.idx files from the user’s profile directory. If the .db file still exists during startup of the client then Lync may still wait for that random interval between 0 and 60 minutes before checking for changes on the server’s address book files.  By deleting the file the Lync client must download an entire new copy, forcing it to pick up any changes.
On Windows XP workstations:
%userprofile%\Local Settings\Application Data\Microsoft\Communicator\sip_<username@domain>\
On Windows Vista or Windows 7 workstations:
  • Restart the Lync client and search for any of the recently changed information, for example the Telephone Number added to this AD user account now appears for the Lync contact.
image     image

Sunday, 18 August 2013

HA Proxy on FreeBSD

To achieve high availability load balancing with HAProxy on FreeBSD you can use Common Address Redundancy Protocol (CARP) to setup backup node and using that configuration avoid single point of failure (SPOF). Basic idea about CARP is that CARP allows multiple hosts to share the same IP address. It is a free, non patent-encumbered alternative to Cisco’s HSRP. It is mostly implemented in BSD operating systems. This is pretty useful for load balancing. I tested it with almost the same configuration that will be described here with JMeter running and it performed really well without failed requests when I shutdown master node. CARP can be added to FreeBSD system rebuilding the kernel or just loading the if_carp.ko module at boot time which I will use here. At the end you will get something like this:

HAProxy load balancing on FreeBSD using CARP

All traffic will be automatically forwarded to backup node only if master is unavailable and again forwarded to master once it’s available. So with this setup you will get high availability. First I will show how to install HAProxy on both servers. As we are using FreeBSD that will be done through ports, so first step is to update port collection. If you are new with FreeBSD that can be done like this:
cd ~
cp /usr/share/examples/cvsup/ports-supfile .
sed -i -e "s@CHANGE_THIS@cvsup8@g" ports-supfile
csup -L 2 ports-supfile
When port collection is updated you can go forward and install HAProxy:
cd /usr/ports/net/haproxy
make install clean
echo 'haproxy_enable="YES"' >> /etc/rc.conf
pw useradd haproxy
Next step is HAProxy configuration. Configuration file can be found here: /usr/local/etc/haproxy.conf. In this example I will use basic HTTP load balancing with two web servers:
        maxconn 2048
        user haproxy
        group haproxy
        mode http
        timeout connect 5000ms
        timeout client 50000ms
        timeout server 50000ms
    listen http-in
        bind *:80
        balance roundrobin
        server web0 maxconn 1024 check
        server web1 maxconn 1024 check
To check if it works you can start it and try to browse your HAProxy IP address:
/usr/local/etc/rc.d/haproxy start
Above configuration and all steps are the same on both load balancing nodes, so just repeat all of this on backup node. When all is prepared it’s time to enable CARP kernel module (both nodes):
echo 'if_carp_load="YES"' >> /boot/loader.conf
Next on the master node bellow configuration options needs to be added to: /etc/rc.conf file:
ifconfig_carp0="vhid 1 advskew 100 pass techbar"
IP address used here will be shared between both HAProxy nodes and that will be access point to HTTP requests. Also by manipulating “advskew”, the master CARP host can be chosen. The higher the number, the less preferred the host will be when choosing a master. The default is 0. Acceptable values are from 0 to 254. It is very important that the passwords, specified by the pass option are identical.

Also here is configuration for backup node:
ifconfig_carp0="vhid 1 advskew 200 pass techbar"
As you see configuration is basically the same, just advskew is different. Now you just need to reboot the system and check if everything works as expected. For testing you can shutdown master and try to access to the shared IP address.

This example shows how CARP can be used for load balancing, but it can be used for anything else, like firewalls or something. Basically whenever you need high availability. If you have any questions or problems during setup just post a comment.

Monday, 1 July 2013

Disable a user on Lync 2010

Disable-CsUser -Identity "Ken Myer"
This removes the user from Lync  

Friday, 28 June 2013

Exchange 2010 Commanlets for viewing queues

Viewing Queues

View queue on server;

Messages on queue;
Get-Queue | Get-Message

view queue on specified server
Get-Queue -Server serverad─▒

view queue on all transport servers
Get-TransportServer | Get-Queue

Message on the all transport servers queue
Get-TransportServer | Get-Queue | Get-Message

Suspending all the messages on queue
Get-Queue | Get-Message | Suspend-Message

Deleting messages on queue
Get-Queue | Get-Message | Remove-Message

Thursday, 28 February 2013

Commandlet for Identifying iOS 6.1 Devices

Identifying iOS 6.1 Devices

Get-ActiveSyncDevice | where {$_.deviceos -match "iOS 6.1"} | select devicetype,deviceos,deviceuseragent

Wednesday, 13 February 2013

Startup key combinations for Intel-based Macs

Blocking USB Devices and Removable Media

Create a GPO
The first step is to open Group Policy Management and create a new GPO.

I typically like to create 2 GPO's One for blocking read access and one for blocking write access.

By Creating 2 separate policies I can apply each individually so I can allow read access for certain groups of users while blocking write access and I can apply both policies to other groups so I can block all access.

The policy we are about to create is user based This means that it will apply to the users and not the computer. This means we can block access as need for normal users on a computer while still allowing access for other users like say IT (ourselves) so we can still do our thing without any issues.

These policies apply to all forms of removable media not just USB based media. therefor you can use them to block other media access such as CD and DVD access as well.

Set the Desired Policy Items
In your GPO browse to the following location.

User Configuration >> Policies >> Administrative Templates >> System >> Removable Storage Access

If you look through the list of options you will see 2 choices for each media type. One choice when enabled blocks write access and the other choice blocks read access.

In my attached image i show an example of blocking all read access.

Therefor to block read access to each of these media types simply enable the deny read access item for each. 
If you want to block write access enable the block write access options. 
If you want to block both the enable both options.

Its really that simple.


For some reason Digital cameras require both read and write access. So if you have users that need access to a digital camera directly through the camera's USB connection they will need read and write access. Even if all they want to do is read files from the camera. However if you remove the memory card from the camera and read it with a memory card reader it only needs read access as expected.

Apply the GPO
Now that you have created your GPO Policy (or policies if you want more granular control like I did) all that you need to do is apply the GPO to the Users you wish to restrict removable media for by assigning it the correct OU's.

Once applied simply wait for the policy to update on the users computer or run "gpupdate /force" to speed things up and test it out.

This is a simple and reliable way to control user access to removable media for users with the bonus of still being able to allow yourself or other special users of your choice the ability to use that same removable media ... able-media

Using Powershell to delete email in Exchange 2010

This can be used to find/delete one email or thousands of emails. A few weeks after the above happened, an automated alerting system went nuts and sent out about 80,000 emails to 10 or so mailboxes. Again, the below came in handy to zap away the offending emails.

Introducing… the Search-Mailbox cmdlet. This can search for specified criteria and will copy the results to a destination mailbox.  First off though, we have to tell Search-Mailbox which mailbox(es) to search – do this using the Get-Mailbox cmdlet.

For example:

Get-Mailbox -Identity “UserMailbox To Search” | Search-Mailbox -SearchQuery subject:”This email is SPAM!”,from:”” -TargetMailbox “Mailbox to put search results into” -TargetFolder “A folder in that mailbox”

This will search “UserMailbox to search” for any emails with a subject that contains “This email is SPAM!” and from “”. If it finds any emails that fit the criteria, then it will copy them all to “Mailbox to put search results into” in the folder “A folder in that mailbox”. Simple huh!

Note – if you leave the -Identity off the Get-Mailbox cmdlet, then it will search EVERY mail box in Exchange. Could be handy, but also be quite slow.

Now, if you want to delete emails, it’s pretty much the same command, just put a -DeleteContent onto the Search-Mailbox cmdlet and remove the TargetMailbox/TargetFolder options.

For example:

Get-Mailbox -Identity “UserMailbox To Search” | Search-Mailbox -SearchQuery subject:”This email is SPAM!”,from:”” -DeleteContent

There are a bunch of options you can use with the -SearchQuery option:

Source -

Monday, 28 January 2013

How to Rebuild the Full-Text Index Catalog

How to Rebuild the Full-Text Index Catalog

Exchange 2007
12 out of 17 rated this helpful Rate this topic
Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2011-01-12
This topic describes two ways to rebuild the full-text index catalog, programmatically via an Exchange Management Shell script, and by manually deleting the full-text index catalog directory.
To programmatically rebuild the full-text index catalog, run the ResetSearchIndex.ps1 script provided at <drive>:\Program Files\Microsoft\Exchange Server\Scripts\.
To manually rebuild the full-text index catalog, stop the Microsoft Exchange Search Service, delete the old catalog, and then restart the service. This procedure forces the server to re-create the full-text index catalog.
To perform the following procedures, the account you use must be delegated membership in the local Administrators group.
For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.
  1. Start the Exchange Management Shell.
  2. Remove the index directories that are associated with specified mailbox databases:
    ResetSearchIndex.ps1 [-force]  <dbname> [<dbname>]
  3. Remove the index directories that are associated with all mailbox databases:
    ResetSearchIndex.ps1 [-force] -all
  1. Stop the Microsoft Exchange Search Service by running the following command:
    Net Stop MsExchangeSearch
  2. Delete the full-text index catalog directory.
    There are scripts located in the \Exchange Server\Scripts directory that can help you to administer and manage Exchange Search. Using the Exchange Management Shell, you can run the following scripts:
    • GetDatabaseForSearchIndex.ps1   When the index directory files are provided, this script returns the associated mailbox database names. Example script:
      GetDatabaseForSearchIndex IndexDirectoryName1 IndexDirectoryName2
    • GetSearchIndexForDatabase.ps1   This script returns index directories for the specified mailbox database names. Example script:
      GetSearchIndexForDatabase MailboxdatabaseName1 MailboxdatabaseName2 -All
      The directory name follows the convention CatalogData-<guid>-<guid> where the first <guid> is the GUID of the database, and the second <guid> represents the Instance GUID, which is used on a clustered mailbox server to distinguish between the nodes. The following is an example folder name: \CatalogData-b56624f3-bf19-4463-926f-d4705ac3dd08-cc64dd2d-2428-4f12-bba2-79d6d34c4d27
      The typical path for the .edb files and the catalog data directory is: C:\program files\microsoft\exchange server\mailbox\first storage group\
    You can use the following example to verify that you are targeting the appropriate catalog directory:
    GetSearchIndexForDatabase -All
  3. Start the Microsoft Exchange Search Service by running the following command:
    Net Start MsExchangeSearch

Exchange 2007/2010 Get Out Of Jail Quick Card - No Disk Space

Exchange 2007/2010 Get Out Of Jail Quick Card - No Disk Space


Your Exchange 2007/2010 has run out of disk space on the partition holding the mailbox database and the database has dismounted, there is no quick way to increase the size of the partition, and it looks like the only solution is to move the database to another drive, which will mean downtime whilst the database is dismounted during the move.


(A temporary fix to get the database up and running.)

In the folder where the EDB file for the affected Mailbox Database resides, there is a folder with name beginning catalogdata which can be quite large (for example - 15GB for a 250GB database):

If the Microsft Exchange Search Service is stopped by running the command

net stop MsExchangeSearch

or stopping the Microsoft Exchange Search Indexer from services.msc

then the entire catalogdata folder can be shift deleted

After this is done, DO NOT restart the Microsoft Exchange Search Service for two reasons:

1: Restarting MsExchangeSearch will cause the Full-Text Index Catalog to get rebuilt which may fill to the same size as before
2: Rebuilding the Full-Text Index Catalog can cause high CPU utilization, and is best rebuilt out of business hours

Remember this is only a temporary fix to give some breathing space whilst downtime for the mailbox database to be moved to a larger drive - or whatever - can be arranged. Free space on server disk partitions should always be monitored.


Further reading - How to Rebuild the Full-Text Index Catalog

Tuesday, 15 January 2013

Entrust 2048 Certificate issue

Now this issue has been causing me major issues with communication between Lync and Hotmail right from the start, and im please to say it is now resolved with a few months of head scratching and a lot of help from Microsoft Support.

Issues included intermittent communications between Lync / Hotmail - so some times it worked, sometimes it didn't, some users were fine some were not, which also made it a night mare to diagnose.

Thanks to Scott Oseychlk for this solution & Many thanks to Jimmy Levesque and Mark Giannotti in ECS Technical Support at Entrust Certificate Services for this information!



You may find that OCS 2007 / OCS 2007 R2's Federation and/or PIC fails against partners who do not support Entrust root certificates signed using a 2048-bit public key.

For example, the "broken" certificate chain may resemble the following:

Edge server's certificate -> Entrust L1B chain -> Entrust 2048 Root


For Federated partners who do not support the 2048-bit Root, you can introduce an additional chain certificate which points back to the Entrust 1024-bit root. The chain of authority would then be as follows:

Edge server's certificate -> Entrust L1B chain -> Entrust 2048 chain -> Entrust 1024 Root

To accomplish this, you will be replacing the Entrust 2048 Root certificate with the attached Entrust 2048 chain certificate.

Here are the steps to follow:

1. Start up your MMC console and add the Certificates snap-in for your server's Computer Account.

2. Under "Trusted Root Certification Authorities/Certificates," remove the Certification Authorities (2048) certificate.

3. Ensure you have the Secure Server Certification Authority certificate under the same Trusted Roots folder.

4. Under "Intermediate Certification Authorities/Certificates," import the attached Certification Authorities (2048) chain certificate as follows:

i. Save the attached "2048-to-1024-Cross-Cert.txt" 2048 chain certificate as a *.crt file.

ii. In MMC, expand the Intermediate Certification Authorities folder.

iii. Right-click on Certificates and select All Tasks -> Import

iv. Follow the resulting Certificate Import Wizard to import the 2048 chain certificate into the Intermediate Certification Authorities store.

5. Check to make sure you have two Entrust Certificates under Intermediate Certification Authorities/Certificates: The Entrust Certification Authority - L1B and the Certificate Authority (2048).


Many thanks to Jimmy Levesque and Mark Giannotti in ECS Technical Support at Entrust Certificate Services for this information!

Update (December 10, 2009):

We have successfully tested & validated that communicating with AOL via PIC (using a certificate rooted against a CA that is signed with 2048 bits) works properly.


You can download the file from here: