Простая реализация сервера может использовать для индикации состояния значение CSN контекста перед началом процесса поиска. Подобная реализация будет встраивать это значение во все возвращаемые SyncCookie. Мы будем называть это CSN куки. При запросе обновления сервер будет просто генерировать сообщения об изменении для всех записей в содержимом каталога, чьи CSN больше чем предоставленный CSN куки, а также генерировать сообщения о наличии для всех остальных записей в содержимом каталога. Однако, если текущий CSN контекста совпадает с CSN куки, серверу следует вместо этого генерировать ноль сообщений об изменении и ноль сообщений об удалении, а также установить индикатор refreshDeletes в TRUE, поскольку каталог не был изменён.
В реализации должно также учитываться влияние изменения мета-информации, способной воздействовать на то, как будет определяться содержимое каталога, например, контроля доступа. Один из методов состоит в том, чтобы сервер поддерживал CSN мета-информации, распространяющей влияние на контекст в целом, или CSN мета-информации. Этот CSN мета-информации будет обновляться тогда, когда изменяется мета-информация, воздействующая на то, каким образом будет определяться содержимое каталога. Если значение такого CSN мета-информации больше чем CSN куки, серверу следует проигнорировать куки и рассматривать запрос как запрос первоначального содержимого каталога.
Кроме того, серверы могут рассмотреть вопрос поддержания некоторой информации об истории изменений отдельно для каждой сессии, чтобы уменьшить количество сообщений, которые требуется передать в ходе инкрементных обновлений. В частности, сервер может сохранять информацию о записях, по той или иной причине не попадающих более в область рассмотрения не подключенной в настоящий момент сессии синхронизации, и в дальнейшем использовать эту информацию для генерации сообщений об удалении вместо сообщений о наличии записей.
При усечении информации об истории изменений, CSN последней записи, удалённой из информации об истории изменений, может быть сохранён как CSN усечения информации об истории изменений. Такой CSN усечения может быть использован для определения возможности синхронизации клиентской копии из содержимого информации об истории изменений путём его сравнения с состоянием синхронизации, содержащимся в предоставляемом клиентом куки.
При большом количестве сессий, возможно, имеет смысл вести подобную информацию об истории изменений только для избранных клиентов. Кроме того, использующим такой подход серверам необходимо следить за потреблением ресурсов для обеспечения разумной работы сервера и защиты от злоупотреблений. Может быть целесообразно ограничить использование такого режима работы какой-либо политикой.