Ru-Board.club
← Вернуться в раздел «Программы»

» Adventnet ManageEngine ServiceDesk Plus

Автор: SVRRR
Дата сообщения: 21.01.2011 13:06
Настраиваю с нуля SDP 8.0.0
Столкнулся со следующей проблемой.
При переписке "Обсуждения с инициатором заявки" между специалистами не отображается кнопка "Ответить", есть только "Переслать".

Все настройки по умолчанию. Подскажите пожалуйста в чем может быть причина?
Автор: kmtrx
Дата сообщения: 21.01.2011 17:49
это отправленные письма от системы или от техника - отвечать вы себе будете?
Автор: SVRRR
Дата сообщения: 21.01.2011 18:24

Цитата:
это отправленные письма от системы или от техника - отвечать вы себе будете?


Ситуация следующая. Техник Иванов создал заявку и направил ее в свой отдел.
Техник Петров ему ответил. Техник Иванов открывает переписку "Обсуждения с инициатором заявки" и видит ответ от техника Иванова, где вместо кнопки"Ответить" видна только кнопка "Переслать".

А должно быть и "Ответить" и "Переслать".
Как быть??
Автор: SVRRR
Дата сообщения: 23.01.2011 00:07
Коллеги, кто еще сталкивался с такой проблемой.... и в каком билде SDP8... ее устранили?? Проблема имеет место быть только при переписке техников.

Автор: SVRRR
Дата сообщения: 23.01.2011 09:40
установил SDP8.0.7 все осталось по прежнему. Делаю вывод что это не баг, а фича))
Автор: kmtrx
Дата сообщения: 24.01.2011 08:25
Отвечайте на заявку кнопкой "Ответить" для самого запроса (заявки)
Автор: SVRRR
Дата сообщения: 24.01.2011 14:07

Цитата:
Отвечайте на заявку кнопкой "Ответить" для самого запроса (заявки)

так и делаю
Автор: fluffymail
Дата сообщения: 25.01.2011 07:24
Коллеги, подскажите. Ни Гугл, ни ФАК не помог.

Наша Организационная структура - лес доменов. Основной и подчиненные.
Если использовать AD аутентификацию то пользователи импортируются из одного домена. (Ну или для каждого можно провести эту операцию). Но ведь, в дальнейшем, при синхронизации SDP будет синхронизировать только последний настроенный для импорта домен? Или все с которыми его подружили?

А если же использовать LDAP то не будет уже синхронизации
Есть ли выход? Чтоб SDP синхронизировал AD-ных пользователей в нескольких доменах?
Автор: SVRRR
Дата сообщения: 25.01.2011 11:06
Установил с нуля SDP8, немного поработал и столкнулся со следующей проблемой!

При попытки сделать заявку самим пользователем через вкладку "Новая заявка", заявка не записывается в базу!!!! (до этого, пару дней работало)
Заявка созданная специалистом от пользователя, успешно записывается в базу.

Если пользователь создает заявку через шаблон или "каталог служб" все работает.

В журнале осталась запись:


Коллеги, что может быть? Думаю что проблема связана с разделением доступа...
Автор: dencomua
Дата сообщения: 31.01.2011 14:48
Коллеги, при попытке отправить какое либо письмо внутри организации - все ок
При попытке отправить это же письмо, скажем на gmail - SDP выдает сообщение "Не удалось отправить уведомление."
в логах "Exception while trying to send notification for Request ID : 57178 Mail sending failed."

кто знает в чем проблема?
Автор: shamsa
Дата сообщения: 01.02.2011 09:52
SVRRR
Открою тебе еще более страшную тайну, ты путаешь Каталог услуг с категорией инцидентов )))))
И я работаю на 8 версии уже третий месяц, вот там и начались проблемы со сквозной авторизацией она не хрена не работает, и галочка "запомнить меня тож не хрена не работаетю и там есть нормальный готовый КАТАЛОГ УСЛУГ. Наконец то, на базе него и можно создавать заявки на облуживание, а то что сделал ты используется для ИНЦИДЕНТОВ созданных или по запросам пользователей или автоматическими системами. Это РАЗНЫЕ ВЕЩИ! правда чтобы это понимать нужно хотя бы один СЕРВИСДЕСК поднять в своей жизни, не программный в смысле, а реальную службу. так что ставь 8 версию и наслаждайся ))))
Автор: vrednyi
Дата сообщения: 01.02.2011 10:45
dencomua
Скорее всего у тебя нет внешней почты на адресе с которого SDP собирает и отправляет почту. ТОбишь адрес выглядит так SDP@домен.lan. Надо добавить внешку для отправки

Добавлено:
Ребята! Кто пользуется сайтами? Помогите настроить! Я никак не могу их победить. У меня есть несколько филиалов со своими специалистами. Мне надо, чтобы они видели только заявки своих филиалов (что достигается посредством сайтов) - вроде бы все логично и понятно. Так вот если спец видит только заявки своего сайта - то при назначении заявки своего сайта на спеца, который видит все сайты, - у него пропадает доступ к этой заявке. why???)
Автор: SVRRR
Дата сообщения: 01.02.2011 14:42
2 shamsa


Цитата:
Открою тебе еще более страшную тайну, ты путаешь Каталог услуг с категорией инцидентов )))))

1. для тугослышащих повторяю еще раз:

Цитата:
"лично я, каталог услуг организовал в разделе - Категории/подкатегория/позиция
версия SDP 7.6.0"



Цитата:
И я работаю на 8 версии уже третий месяц, вот там и начались проблемы со сквозной авторизацией она не хрена не работает,

печально


Цитата:
и галочка "запомнить меня тож не хрена не работаетю

а у меня работает


Цитата:
и там есть нормальный готовый КАТАЛОГ УСЛУГ.

Его все равно надо переделавать под специфику своей организации


Цитата:
Наконец то, на базе него и можно создавать заявки на облуживание,

конечно


Цитата:
а то что сделал ты используется для ИНЦИДЕНТОВ созданных или по запросам пользователей или автоматическими системами. Это РАЗНЫЕ ВЕЩИ! правда чтобы это понимать нужно хотя бы один СЕРВИСДЕСК поднять в своей жизни, не программный в смысле, а реальную службу.

см. п.1
На данный момент перевел все подразделения предприятия, организовав единую точку контакта.


Цитата:
так что ставь 8 версию и наслаждайся ))))

уже перешел на нее))



Автор: shamsa
Дата сообщения: 02.02.2011 08:45
[b]vrednyi[
Гы, там должна быть включена херня, типа видеть только свой сайт и заявки не для одного сайта. Вот и все
Автор: k0lin
Дата сообщения: 02.02.2011 15:23
Коллеги, бьюсь с SSO - версия 8.0.0.7 - не сохраняет настройки в базу jespaconfiguration; - дошел до того. что руками вбил туда через mysql данные, но всё равно на контроллере домена не авторизуется (говорит jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad password). на контроллер домена передаётсмя след инфа - потом в логе безовасности видно
An account failed to log on.

Subject:
    Security ID:        NULL SID
    Account Name:        -
    Account Domain:        -
    Logon ID:        0x0
Logon Type:            3

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:        SDPCOMP$
    Account Domain:        domain.RU

Failure Information:
    Failure Reason:        Unknown user name or bad password.
    Status:            0xc000006d
    Sub Status:        0xc000006a

Process Information:
    Caller Process ID:    0x0
    Caller Process Name:    -

Network Information:
    Workstation Name:    JCIFSX_X_8F
    Source Network Address:    x.x.x.x
    Source Port:        57436

Detailed Authentication Information:
    Logon Process:        NtLmSsp
    Authentication Package:    NTLM
    Transited Services:    -
    Package Name (NTLM only):    -
    Key Length:        0


Может кто-нть показать с рабоатющей системы, какие поля заполнены в таблице?
в ком строке
C:\ManageEngine\ServiceDesk\mysql\bin>mysql -u root -P 33366 servicedesk
и уже скуль-строчку
select * from jespaconfiguration;

Буду очень благодарен, бьюсь уже два дня, пробовал и на 2003, и на 2008R2 - не хочет работать
Автор: kmtrx
Дата сообщения: 02.02.2011 17:28
+---------------+-----------------------------+
| JESPACONFIGID | JESPACONFIG_KEY |
+---------------+-----------------------------+
| 301 | jespa.bindstr |
| 302 | jespa.service.acctname |
| 303 | jespa.service.password |
| 304 | jespa.dns.servers |
| 305 | jespa.account.canonicalForm |
| 306 | jespa.log.level |
| 307 | jespa.domainname |
| 308 | jespa.fallback.location |
+---------------+-----------------------------+
Автор: k0lin
Дата сообщения: 02.02.2011 17:41
kmtrx
Спасибо! а вас третий столбик JESPACONFIG_VALUE - присутствует - вы скрыли его т.к. там приватные данные - или его нету??
у меня три столбика

+---------------+-----------------------------+-------------------------------+
| JESPACONFIGID | JESPACONFIG_KEY | JESPACONFIG_VALUE |
+---------------+-----------------------------+-------------------------------+
| 3301 | jespa.bindstr | azimut.ent |
и т.п.

если всё-таки у вас три столбца, интересует в каком виде и регистре заданы значения для
jespa.service.acctname - к примеру так - TESTCOMP$@AZIMUT.ENT |

значение jespa.account.canonicalForm - у меня 3 и 4 пробовал, не работают
Автор: shamsa
Дата сообщения: 03.02.2011 04:49
НУ так что, никто не может разобраться почему не проходит сквозная авторизация?

Добавлено:
SVRRR

Я уже писал выше. Не надо путать инцидент с запросом на обслуживание
Новая заявка в SDP подразумевает новый инцидент. новое нарушение в работе сервисом. Проблема просто в том, что перевод неправильный. вот вы все и путаетесь, потому что нужно учить теорию. Я уже про это писал
Автор: kmtrx
Дата сообщения: 03.02.2011 08:38
jespa.account.canonicalForm | 3
jespa.log.level | 3


Цитата:
jespa.service.acctname
- похоже имя$@домен

jespa.fallback.location | HomePage.do
Автор: SVRRR
Дата сообщения: 03.02.2011 09:42
2 shamsa


Цитата:
Я уже писал выше. Не надо путать инцидент с запросом на обслуживание
Новая заявка в SDP подразумевает новый инцидент. новое нарушение в работе сервисом. Проблема просто в том, что перевод неправильный. вот вы все и путаетесь, потому что нужно учить теорию. Я уже про это писал

Shamsa, сейчас пользователю по мимо стандартного шаблона "Новая заявка" к которому он уже привык, предлагается пользоваться еще одним шаблоном "Каталогом служб". Объясните мне, зачем ему два девайса?? У него возникла -ПРОБЛЕМА. "Инцидент" это, или "запрос на обслуживание", ему это фиолетово, да и слов он таких заморских не знает)))
Вы попытайтесь взглянуть на эту проблему глазами пользователя. Для него должна быть Единая форма заявки c перечнем всех ИТ-сервисов. И все. А если нет единых понятий, то возникают разночтения...СТП не понимает пользователя, и наоборот. Двадцать лет назад никто про ITIL не знал, но ведь работали...Были обыкновенные диспетчера, которые принимали заявки и эскалировали их дальше... А сегодня это называется 1-ая линия. Ничего по сути не изменилось..

ALL

Добавлено:
Коллеги, повторю свой очередной вопрос.
В сведениях о заявке, есть параметр "Срок ответа":

Для чего он нужен?


Автор: k0lin
Дата сообщения: 03.02.2011 11:42
заработала SSO, пароль не правлиьно заполнял, всёж-таки пришлось таблицу jespaconfiguration заполнять руками - вот сижу и думаю, в чём это может в дальнейшем вылезти
Автор: SVRRR
Дата сообщения: 03.02.2011 15:28
Коллеги, по закрытию заявки в SDP 8 есть вопрос. Тестирую сейчас версию 8.0.0.7, в версии 8.0.0.0 такое также наблюдается.

Когда мы закрываем заявку, нам предлагают- "закрыть принятые":

Если мы отвечаем "ДА", заявка закрывается, статус переводится в "closed".
Если мы отвечаем "Нет", заявка также закрывается c переводом статуса на "closed".

Вопрос: в чем принципиальное отличие закрытия заявки? (и в том и другом случаи заявка закрывается с переводом статуса в "closed").
Автор: kogor222
Дата сообщения: 04.02.2011 07:40

Цитата:
Если мы отвечаем "ДА", заявка закрывается, статус переводится в "closed".
Если мы отвечаем "Нет", заявка также закрывается c переводом статуса на "closed".


Если нажимаем"ДА" - заявка закрывается якобы с подтверждением пользователя.
Если "Нет" - то без подтверждения пользователя.
Вот и вся разница... Кстати когда заявку открываешь в сведениях о заявки видно следующие:
"Сведения о закрытии заявки
    Закрыто после подтверждения от запросчика
Комментарии
выполнено" - это в случае с "Да".
В противном случае: текст меняется на: "... закрыто без подтверждения"..

Вот и весь "тайный" смысл этих "да" и "нет"...

Добавлено:

to SVRRR

по поводу параметра "Срок ответа"....
Этот параметр есть в настройках SLA. Помимо времени решения, есть время первого ответа.
Применяется допустим в случае, если новая заявка зарегистрирована со статусом "открыто", но при начале решения заявки специалистом меняется статус или другие поля До окончания данного срока ответа.
Если специалист должен принять во внимание заявку (допустим в течении 15 минут), отреагировать на нее (в соответствии в вашими процессами), а не сделал этого, то считается уже нарушением соглашения (если есть) о первой реакции, первого ответа по данной заявке.. полезная "фишка" на самом деле... и пользователь может быть уведомлен о том что его заявка принята к рассмотрению специалистом и находится "в работе"...
Автор: SVRRR
Дата сообщения: 04.02.2011 09:30
2 kogor222

Большое Спасибо! за оперативный и полный ответ!

не совсем понятно... по поводу "Срока ответа"

Цитата:
по поводу параметра "Срок ответа"....
Этот параметр есть в настройках SLA. Помимо времени решения, есть время первого ответа.

Параметр "Время первого ответа" (в сведениях о заявке) является - "Дата ответа". И с ним все ясно. Получил специалист заявку от пользователя, ответил первый раз, и это время зафиксировалось как "время первого ответа"- "Дата ответа" . Если время первого ответа нарушается, то у специалиста рядом с параметром "статус" появляется оранжевый кружок- нарушение первого ответа:


А вот "срок ответа" если я правильно понял, указан в SLA и привязан к строке: "Ответ на любой запрос, который соответствует вышеупомянутым правилам, должен быть дан не позднее чем".

Получается что этот параметр ("срок ответа") автоматически проставляется системой при задержке ответа, или в ручную корректируется специалистом. Вот только в чем выражается его полезность?? (не путать со "временем первого ответа" - "Дата ответа")


Цитата:
.. полезная "фишка" на самом деле... и пользователь может быть уведомлен о том что его заявка принята к рассмотрению специалистом и находится "в работе"...

а где настраивается этот шаблон уведомления, и как он точно называется?
В разделе Уведомления для инициатора заявки, есть только эти:

Автор: kogor222
Дата сообщения: 04.02.2011 11:26

Цитата:
А вот "срок ответа" если я правильно понял, указан в SLA и привязан к строке: "Ответ на любой запрос, который соответствует вышеупомянутым правилам, должен быть дан не позднее чем".


"полезность" простая... Контроль за решением заявок к примеру..
существуют разные реализации сервисдэска на предприятиях и в организациях.
если пользователь Звонит в службу (к примеру) и диспетчер заводит заявку назначая на специалиста (с другого подразделения), то тут можно отследить взяли на обслуживание заявку или она до сих пор висит под первоначальным статусом (к примеру).. а если заключены OLA между подразделениями (к примеру департаментом СервисМенеджмента (ДСМ)и ДИТ), то тут можно сказать "норма поведения"... ДСМ отвечает перед бизнеспользователями за предоставление качества услуг Айти.. а OLA по сервисам заключено между этими департаментами АйТи.. Т.к. в данном случае SLA может быть заключен (в данном примере) между ДСМ и Бизнесом.. Но не между Бизнесом и ДИТ напрямую... Вообщем смотря какая организация, какая структура и пр...
Эти параметры применять к различным целям и задачам.. Все зависит от полета "фантазии" ..



Добавлено:

Цитата:
а где настраивается этот шаблон уведомления, и как он точно называется?
В разделе Уведомления есть только эти:


в SLA есть эскалация 1,2,3... и т.д. .. там есть и шаблоны.. там есть и кому.. это как минимум.. )
Автор: SVRRR
Дата сообщения: 04.02.2011 12:14

Цитата:
в SLA есть эскалация 1,2,3... и т.д. .. там есть и шаблоны.. там есть и кому.. это как минимум.. )

В SLA шаблонов нет. А потом, задача стоит посылать уведомления не специалистам а пользователям. ) Поэтому я и привел подробную таблицу с уведомлениями пользователя.
Автор: kogor222
Дата сообщения: 07.02.2011 09:37

Цитата:
В SLA шаблонов нет. А потом, задача стоит посылать уведомления не специалистам а пользователям. ) Поэтому я и привел подробную таблицу с уведомлениями пользователя.


согласен в самом SLA нет.. есть шаблоны уведомлений.. и электронных сообщений..
а чем сложность допустим поставить "галочку" насчет уведомлений инициатора об Обновлении его заявки?!... ведь внутренние задачи и переписка не "светится" пользователю (если конечно у пользователя нет прав или не направлены специалистами).. к примеру .. при регистрации заявки пользователь может получать уведомление о регистрации его заявки.. далее.. при изменении статуса, например (если меняется статус при приеме специалистом на расследование или исполнение заявки) высылается уведомление пользователю.. в данном случае он в курсе что его заявка принята специалистом для решения.. или когда заявка будет выполнена.. тут можно манипулировать уведомлением пользователя.. но конечно многие моменты зависят от организации самого процесса... и Не все, к сожалению, можно реализовать в данном ПО.. пока "WorkFlow" не на высоте.. не тот уровень ПО для реализации сложных Процессов.. может все-таки доработают со временем..
Автор: SVRRR
Дата сообщения: 07.02.2011 10:32
2 kogor222


Цитата:
а чем сложность допустим поставить "галочку" насчет уведомлений инициатора об Обновлении его заявки?!...

В этом случае при каждом изменении заявки специалистом пользователь будет постоянно получать уведомления. Это его будет напрягать.
Автор: kogor222
Дата сообщения: 07.02.2011 10:57

Цитата:
В этом случае при каждом изменении заявки специалистом пользователь будет постоянно получать уведомления. Это его будет напрягать.


на каком именно этапе изменений?..
как-то тестировал:
назначение категорий, подкатегорий и т.д. - получает
назначение, переназначение специалистов - получает
все практически изменения в "шапке" заявки - да, получает..
решение - получает..
а вот назначение задач, сообщения специалистам, внутренние обсуждания - не получает..
Но... если автоматизирована система срочности, приоритетов, назначение специалистов или групп по категориям заявки, и прочее прочее... - то минимизировано получение пользователем дополнительных уведомлений.. это понятно почему.. если "грамотно" сделана первоначальная классификация инцидента или типового запроса на обслуживание, то пользователь получает минимум 4 сообщения.. 1. регистрация 2. классфикация и взятие на обслуживание инцидента или решение.. 3. о решении и 4. закрытие.. И то... последнее можно получать, можно не получать.. Так же как и первое... Но опять же.. насколько оптимизирован, расписан сам процесс.. столько конечно и уведомлений получит пользователь, если стоит "галка" уведомления о обновлении заявки..
конечно так пользователей сам не "мучил" раньше.. у меня своя служба сервисдеска была. которая снимала эти вопросы.. и сам процесс управления инцидентов не стремился усложнять.. надобности в лишних оповещениях не было.. а вот что касалось хорошего описания сервисов и реализации в системе - тут вот пришлось "по потеть"..
Автор: SVRRR
Дата сообщения: 07.02.2011 13:35
2 kogor222


Цитата:
на каком именно этапе изменений?..

на этапе внесения изменений в заявку специалистом, причем при каждом изменении..


Цитата:
если "грамотно" сделана первоначальная классификация инцидента или типового запроса на обслуживание, то пользователь получает минимум 4 сообщения.. 1. регистрация 2. классфикация и взятие на обслуживание инцидента или решение.. 3. о решении и 4. закрытие..

у меня всего три уведомления для пользователя.
1. регистрация
2. классификация и взятие на обслуживание инцидента
3. закрытие

Цитата:
а вот что касалось хорошего описания сервисов и реализации в системе - тут вот пришлось "по потеть"..

это самое главное)

Добавлено:
еще вопрос
Если применяется схема работы дежурных специалистов по графику, например 2Х2.
Как в таком случаи настроить автоматическое переназначение заявки на каждого специалиста с интервалом работы два дня.
Есть специалист - Иванов и Петров. В смену Иванова заявки должны назначаться Иванову, а в смену Петрова соответсвенно Петрову.

Пробовал через "Планировщик" и через "Автоматическое назначение специалиста" не получается.
И возможно ли вообще такое сделать?


Добавлено:
а также, как настроить SMS уведомления специалистам? И с каким оператором сотовой связи работает этот сервис?

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107

Предыдущая тема: Клиент для чтения форумов :)


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.