Используем Windows Messenger в корпоративной среде::Журнал СА 9.2007
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 5466
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 6643
Комментарии: 1
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 7926
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 8216
Комментарии: 2
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 7210
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Используем Windows Messenger в корпоративной среде

Архив номеров / 2007 / Выпуск №9 (58) / Используем Windows Messenger в корпоративной среде

Рубрика: Администрирование /  Администрирование

Иван Коробко

Используем Windows Messenger в корпоративной среде

Хотите повысить эффективность работы службы поддержки в вашей фирме? Используйте Windows Messenger для достижения этой цели. Это не потребует больших трудозатрат и принесет хорошие дивиденды.

В крупных организациях для удобства общения прибегают к помощи Windows Messenger. В качестве сервера сообщений обычно используется Live Communication Server, для работы которого необходим SQL-сервер. В качестве клиента используется Windows Messenger или Microsoft Office Communicator (MOC) 2005.

Live Communication Server 2005

Впервые система обмена мгновенными сообщениями была встроена в Microsoft Exchange 2000. Обмен информацией происходил исключительно открытым текстом, шифрование даже не предлагалось. Исправить имеющиеся недостатки и обеспечить больший функционал предполагалось в Real-Time Communications (RTC) Server. Окончательный продукт получил название Live Communications Server (LCS) 2003. Главные идеи, заложенные в LCS, – обеспечение шифрования передаваемых данных, сокращение интернет-трафика, интеграция с Active Directory, поддержка всех видов связи в реальном времени (мгновенных сообщений, телефонии, видеоконференций, совместного использования приложений), обеспечение мощного API для интеграции со сторонними решениями.

В 2005 году Microsoft выпустила новую версию LCS. Существует два варианта поставки – Standard и Enterprise. В дистрибутив первого включен MSDE, второй предполагает наличие SQL Server. Единственным принципиальным отличием LCS 2005 Enterprise является возможность масштабирования и распределения нагрузки между пулом серверов. LCS 2005 Standard можно использовать в крупных организациях – он способен обслуживать до 15 тыс. пользователей и позволяет устанавливать «федеративные» отношения – связь сервер-сервер между отделами, филиалами или разными компаниями.

Windows Messenger

Сегодня для LCS 2005 штатным клиентом является Windows Messenger 5.х. Последняя вышедшая версия – 5.1.0701, которую можно загрузить с сайта Microsoft: http://www.microsoft.com/downloads/details.aspx?FamilyID=a8d9eb73-5f8c-4b9a-940f-9157a3b3d774&displaylang=en.

Windows Messenger использует протокол Session Initiation Protocol (SIP), специально созданный для обеспечения связи между пользователями, различными способами, начиная от мгновенных сообщений, заканчивая видеоконференциями.

Протокол SIP разработан организацией по стандартизации Internet Engineering Task Force. Windows Messenger также обеспечивает подключение к службам Microsoft .NET Messenger и Exchange 2000 и выше Server Instant Messaging Service.

Microsoft Office Communicator (MOC) 2005

Крупным организациям вместо Windows Messenger Microsoft предложила альтернативу – пакет Microsoft Office Communicator (MOC) 2005, известный также под рабочим названием Istanbul. Фактически это клиент для LCS 2005 без возможности прямого подключения к публичным сетям – из современных протоколов в нем поддерживается исключительно SIP. МОС имеет расширенную поддержку голосовой связи: позволяет выполнять операции удержания или переадресации вызова автоматически на основе информации о доступности абонента. При этом все коммуникации максимально интегрированы между собой – в рамках одного сеанса можно оперативно переключаться между любыми их видами, поддерживать голосовую связь во время совместного использования приложений и т. д.

Другая особенность MOC – усовершенствованный механизм индикации присутствия. Современные IM-клиенты предлагают традиционный набор возможностей вроде слежения за активностью пользователя. MOC автоматически устанавливает статус «Do not disturb» не только при срабатывании экранной заставки, но и любого полноэкранного приложения и даже при инсталляции/удалении программного обеспечения. Он предоставляет информацию на основе календарной информации из Microsoft Outlook – таким образом становится известно не только предполагаемое местонахождение человека, но и примерное время, когда он планирует освободиться. Естественно, этот механизм включается только по желанию пользователя. Он функционирует только при наличии Exchange 2003.

Расширенные возможности Windows Messenger

Служба поддержки крупных предприятий заинтересована в высокой скорости обработки поступивших заявок от сотрудников, оперативном оповещении о предстоящих регламентных работах и т. д.

Этот круг актуальных задач стоит во всех крупных организациях. Чем крупнее организация, тем сложнее справиться с этими задачами. Обычно для работы с заявками сотрудников используют электронную почту, в редких случаях систему HelpDesk, однако скорость работы с помощью этих решений бывает не столь высокой, как хотелось бы. Использование Windows Messenger позволит пользователям быстро и просто взаимодействовать со службой поддержки.

Идея состоит в том, чтобы создать специальную учетную запись, которая будет фигурировать в списке контактов всех сотрудников. Параллельно на выделенном сервере будет установлен клиент Windows Messenger, который будет настроен на учетную запись службы поддержки. Именно там все сотрудники службы поддержки смогут, подключившись через терминальную сессию, видеть пришедшие сообщения. В качестве альтернативы может быть создан специальный сервис, который будет при получении сообщений перенаправлять их на почтовый адрес службы поддержки. Это отдельная тема, которая выходит за рамки статьи.

Решение задачи состоит из двух частей:

  • создание учетной записи и настройка Windows Messenger;
  • создание приложения, которое с заданной периодичностью добавляет созданную учетную запись в контакт-лист сотрудника в случае ее отсутствия.

Создание учетной записи в Active Directory

Прежде чем создавать учетную запись, определим задаваемое пространство имен. Необходимо указать имя пользователя, его SIP-имя и отображаемое имя (Display Name), выяснить имя LCS-сервера. Войдя в Active Directory c Exchange Server, создадим учетную запись со следующими параметрами (см. рис. 1, 2):

  • Имя пользователя – MSN. В списке контактов сотрудников фигурирует только SIP-имя. Имя пользователя произвольно.
  • Пароль можно задать любой.
  • SIP-имя – help@firm.ru.
  • Отображаемое имя – ** HELP **. Именно это имя фигурирует в списке контактов пользователя.
  • SIP-сервер. Определяется автоматически в домене.

Рисунок 1. Создание учетной записи пользователя HELP

Рисунок 1. Создание учетной записи пользователя HELP

Рисунок 2. Настройка LCS учетной записи пользователя HELP

Рисунок 2. Настройка LCS учетной записи пользователя HELP

Для того чтобы новая учетная запись добавлялась в список контактов Windows Messenger без запроса на подтверждение, во вкладке «Live Communication» нужно сконфигурировать список разрешенных пользователей (allow list), нажав на кнопку «View/Edit» (cм. рис. 2), и добавить в появившемся диалоговом окне все учетные записи домена (см. рис. 3).

Рисунок 3. Настройка LCS. Формирование allow list

Рисунок 3. Настройка LCS. Формирование allow list

После того, как учетная запись успешно создана и конфигурирована, необходимо установить Window Messenger на одном из серверов и войти в него от имени созданного пользователя. Для того чтобы он был все время в сети, нужно не закрывать удаленную терминальную сессию.

Создание JOB на SQL-сервере

Ознакомимся с внутренним устройством LCS-базы, для успешного создания JOB на SQL-сервере. Интерес представляют две таблицы Resource и Contact.

Таблицы Resource и Contact базы SIP

Вся информация, касающаяся MSN, хранится в SQL-базе RTC, которая автоматически создается при установке LCS на сервере и ее интеграции с Active Directory. В базе достаточно много таблиц, из которых будут использованы только две: Resource и Contact. В таблице Resource приводятся соответствия идентификационных номеров адресам почты пользователей (см. рис. 4).

Рисунок 4. Таблица Resource, база RTC

Рисунок 4. Таблица Resource, база RTC

Типы данных и их описание см. в таблице 1.

Таблица 1. Поля таблицы Resource, база RTC

Поле

Тип данных

Длина

Пример

Описание

ResourceId

int

4

1245

Идентификационный номер, фигурирующий во всех остальных таблицах базы RTC

UserAtHost

nvarchar

450

SProkudin@firm.ru

Адрес электронной почты пользователя

В таблице Contact (см. рис. 5) находятся все контакт-листы всех пользователей.

Рисунок 5. Таблица Contact, база RTC

Рисунок 5. Таблица Contact, база RTC

В ней присутствует 5 полей (см. таблицу 2).

Таблица 2. Поля таблицы Contact, база RTC

Поле

Тип данных

Длина

Пример

Описание

OwnerId

int

4

1245

Идентификационный номер учетной записи, контакт-лист которой необходимо считать

BuddyId

int

4

178

Идентификационный номер учетной записи – члена контакт-листа пользователя, которому соответствует идентификационный номер в поле OwnerId

SubscribePresence

bit

1

1

Принимает значение 0 или 1. Если 0 – пользователь ожидает согласия на добавление его учетной записи в контакт-лист адресата

DisplayName

varbinary

256

0x…..

Отображаемое имя пользователя в контакт-листе. Во всей таблице заданы нулевые значения

ExternalUri

varbinary

1024

0x…..

SIP-адрес пользователя, в текстовом виде он выглядит как sip:help@firm.ru. Во всей таблице заданы нулевые значения

ContactExtansion

varbinary

1024

0x…..

Описание контакта. Во всей таблице заданы нулевые значения

Создание процедуры добавления пользователя в базу

Работу сценария можно разбить на несколько частей. Для добавления в таблицу записи необходимо использовать стандартную процедуру Insert Into. Поскольку запись help@firm.ru надо добавить только тем пользователям, у которых ее еще нет в листе контактов, то формируется подзапрос с отрицанием. В нем определяется список пользователей, в котором присутствует такой адрес. Из-за того, что таблица сделана так, что все поля в ней должны быть заполнены, то бинарные данные приходится заполнять пустыми/нулевыми значениями. Ради сокращения листинга в SQL-сценарии используется глобальная переменная, которой присваивается значение идентификационного номера help@firm.ru:

declare @@support int

select @@support=ResourceId

from Resource

where UserAtHost=‘help@firm.ru’

INSERT

INTO

[Contact]

select ResourceId,

@@support,

1,

convert(varbinary,''),

convert(varbinary,''),

convert(varbinary,'')

from Resource

Where ResourceId

Not In

(

select c.OwnerId

from Contact as c, Resource as r

where c.BuddyId=r.ResourceId and r.UserAtHost=‘help@firm.ru’

)

После проверки работоспособности сценария в Query Analyzer необходимо создать для этой базы процедуру в Enterprise Manager. Назовем ее MSNAddSupport. Для этого необходимо войти в «Enterprise Manager -> Enterprise Server Group -> имя сервера -> Databases -> RTC -> Stored Procedures» и выбрать в контекстном меню «New Stored Procedures». В появившемся диалоговом окне есть шаблон: CREATE PROCEDURE [OWNER].[PROCEDURE NAME] AS. Вместо [OWNER].[PROCEDURE NAME] необходимо написать имя процедуры, например MSNAddSupport. Имя процедуры произвольно. После назначения имени процедуры установите курсор на вторую строчку и скопируйте созданный текст SQL-сценария. Нажмите «Ok» и сохраните сделанные изменения.

Процедура создана (см. рис. 6).

Рисунок 6. Процедура MSNAddSupport

Рисунок 6. Процедура MSNAddSupport

Проверить работоспособность созданной процедуры можно с помощью команды exec MSNAddSupport в Query Analyzer.

Создание JOB для регулярного исполнения процедуры

После того как стало достоверно известно, что процедура работает корректно, необходимо добиться ее регулярного выполнения через установленный период времени, например через 20 минут. Для решения задачи необходимо в «Enterprise Manager -> Enterprise Server Group -> имя сервера -> Management -> SQL-server Agent -> Jobs» создать новую задачу, выбрав «New Job» в контекстном меню. В появившемся диалоговом окне 4 вкладки:

  • General. Основная вкладка, в которой указывается имя задачи (MsnAddSupport), задается категория, добавляется описание работы.
  • Steps. В вкладке перечислены шаги, из которых состоит работа. Шаги выполняются последовательно по порядку. В только что созданной задаче необходимо создать хотя бы один шаг, нажав на кнопку «New». Затем появится окно, в котором указывают имя шага, тип, базу данных и команду. В данном случае это команда запуска процедуры: exec MSNAddSupport (см. рис. 7).

Рисунок 7. Создание задачи во вкладке «Steps» в MsnAddSupport

Рисунок 7. Создание задачи во вкладке «Steps» в MsnAddSupport

  • Schedules. Здесь формируется расписание запуска сформированной задачи. Для этого необходимо нажать на кнопку «New Schedules» и в появившемся окне назначить имя и выбрать тип (см. рис. 8). Поскольку необходимо добиться, чтобы задача запускалась каждый час, необходимо выбрать Recuring и скорректировать настройки, нажав на кнопку «Change». В диалоговом окне необходимо задать соответствующие параметры (см. рис. 9.).

Рисунок 8. Создание расписания запуска во вкладке «Scheduled» в MsnAddSupport

Рисунок 8. Создание расписания запуска во вкладке «Scheduled» в MsnAddSupport

Рисунок 9. Настройка периодичности запуска задачи MsnAddSupport

Рисунок 9. Настройка периодичности запуска задачи MsnAddSupport

  • Notification. Настройка уведомлений администратора о работе задачи. По умолчанию сообщение об отработке задачи фиксируется в журнале событий сервера. Возможен вариант отправки электронного письма по указанному адресу электронной почты, использования Net Send-сообщений.

Выполнив все описанные действия последовательно, добиваются ежечасной проверки списка контактов каждого сотрудника.

Если в нем отсутствует контакт help@firm.ru, то выполняется процедура добавления этого контакта в общий список.

Windows Messenger у клиента

Итак, все необходимые операции для тестирования созданного сервиса проделаны.

Созданный контакт появится у пользователя только после перезагрузки его клиента.

Это можно сделать двумя способами: перезагрузить рабочую станцию (клиент стартует автоматически) или перезапустить клиента вручную. После перезапуска в списке контактов появляется долгожданная запись (см. рис. 10).

Рисунок 10. Window Maessenger у клиента

Рисунок 10. Window Maessenger у клиента

Я надеюсь, что созданный сервис позволит значительно ускорить эффективность работы службы поддержки.


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru