Перейти к содержанию

Проблемы при обновление KSC 14.0 до 14.2


Рекомендуемые сообщения

При обновлении KSC 14.0 до 14.2 не запускается сервер администрирования KSC. в событиях ОС пишет вот такие ошибки. 

Служба 'kladminserver' остановлена из-за ошибки. #1950 (1062) Generic db error: "1062, 'Duplicate entry '2954-4' for key 'PRIMARY'' , LastStatement='CALL AK_UPGRADE_DB_BATCH_15()'" 
   18043D0444043E0440043C043004460438044F0420003E04310420003E044804380431043A0435043A00200031003900350030002F00310030003600320020002800470065006E00650072006900630020006400620020006500720072006F0072003A002000220031003000360032002C00200027004400750070006C0069006300610074006500200065006E007400720079002000270032003900350034002D0034002700200066006F00720020006B0065007900200027005000520049004D004100520059002700270020002C0020004C00610073007400530074006100740065006D0065006E0074003D002700430041004C004C00200041004B005F0055005000470052004100440045005F00440042005F00420041005400430048005F0031003500280029002700220029002C00200063003A005C0061005C0063005C0067005F006100390065007A00300077007A0076005C0073005C00700072006F0064007500630074005C006F0073006D0070005C006B00730063005C006400650076005C007300650072007600650072005C00640062005C006D007900730071006C005C00640062006D007900730071006C005F0069006E006E006500720063006F006E006E0065006300740069006F006E0069006D0070006C002E006300700070002C0020003300370033002E000A003B0020005B004B004C005300540044005300560043005D00200063003A005C0061005C0063005C0067005F006100390065007A00300077007A0076005C0073005C00700072006F0064007500630074005C006F0073006D0070005C006B00730063005C006400650076005C007300740064005C0073006500720076006900630065005C0073006500720076006900630065006100750074006F00730074006F00700069006D0070006C002E0068004000320034003100 

Остановка из-за ошибки. #1950 (1062) Generic db error: "1062, 'Duplicate entry '2954-4' for key 'PRIMARY'' , LastStatement='CALL AK_UPGRADE_DB_BATCH_15()'" 
   18043D0444043E0440043C043004460438044F0420003E04310420003E044804380431043A0435043A00200031003900350030002F00310030003600320020002800470065006E00650072006900630020006400620020006500720072006F0072003A002000220031003000360032002C00200027004400750070006C0069006300610074006500200065006E007400720079002000270032003900350034002D0034002700200066006F00720020006B0065007900200027005000520049004D004100520059002700270020002C0020004C00610073007400530074006100740065006D0065006E0074003D002700430041004C004C00200041004B005F0055005000470052004100440045005F00440042005F00420041005400430048005F0031003500280029002700220029002C00200063003A005C0061005C0063005C0067005F006100390065007A00300077007A0076005C0073005C00700072006F0064007500630074005C006F0073006D0070005C006B00730063005C006400650076005C007300650072007600650072005C00640062005C006D007900730071006C005C00640062006D007900730071006C005F0069006E006E006500720063006F006E006E0065006300740069006F006E0069006D0070006C002E006300700070002C0020003300370033002E000A003B0020005B004B004C005300520056005D00200063003A005C0061005C0063005C0067005F006100390065007A00300077007A0076005C0073005C00700072006F0064007500630074005C006F0073006D0070005C006B00730063005C006400650076005C007300650072007600650072005C007300650072007600650072005C007300650072007600650072002E006300700070004000370030003200 

...обновление Сервера администрирования завершилось с ошибкой. Ошибка: #1950 (1062) Generic db error: "1062, 'Duplicate entry '2954-4' for key 'PRIMARY'' , LastStatement='CALL AK_UPGRADE_DB_BATCH_15()'"

 

База данных - MariaDB 10.11.1

Операционная система где установлен сервер Касперского - Windows Server 2016

 

ок.JPG

Снdк.JPG

  • Печаль 1
Ссылка на комментарий
Поделиться на другие сайты

Добрый день. Запрос сделал, жду ответ. Заодно решил сдесь спросить. Забыл дописать в начале, что  насчёт MariaDB, сама СУБД развёрнута на Ubuntu 22.04

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

  • 1 month later...
20.03.2023 в 17:37, Mihail_ сказал:

Добрый день. Запрос сделал, жду ответ. Заодно решил сдесь спросить. Забыл дописать в начале, что  насчёт MariaDB, сама СУБД развёрнута на Ubuntu 22.04

 

Нашли ли вы ответ?

Ссылка на комментарий
Поделиться на другие сайты

20.03.2023 в 19:40, Mihail_ сказал:

База данных - MariaDB 10.11.1

Вероятно ответ будет что данная БД не поддерживается официально - https://support.kaspersky.com/KSC/14.2/ru-RU/96255.htm

Ссылка на комментарий
Поделиться на другие сайты

  • 3 weeks later...

Вопрос решился, проблема была в нехватке переменных. И насчёт версии базы данных. На их сайте указано, что можно использовать MariaDB 10.5 (сборка 10.5.17 и выше) 

Вот я и обновил свой сервер БД до последней версии. 

Данню проблему обещали исправить в новых версиях

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

  • 4 weeks later...
26.05.2023 в 23:34, Mihail_ сказал:

Вопрос решился, проблема была в нехватке переменных. И насчёт версии базы данных. На их сайте указано, что можно использовать MariaDB 10.5 (сборка 10.5.17 и выше) 

Вот я и обновил свой сервер БД до последней версии. 

Данню проблему обещали исправить в новых версиях

Можете поподробнее описать что было сделано для исправления ошибки?

Ссылка на комментарий
Поделиться на другие сайты

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

Мои действия при выполнении :
1. Остановить службу Сервера администрирования.
2. Запустил установщик KSC 14.2 режим обновления.
3. Запустил скрипт fix_non_unique_unicode_strings\start.cmd от пользователя с правами Администратора.
4. Запустил скрипт klsql2\start.cmd от пользователя с правами Администратора.
5. Запустил службу Сервера администрирования.

Если служба Сервера администрирования KSC 14,2 не запустится. То необходимо перезагрузить сервер KSC и сервер БД и заново запустить обновление сервера. 

update KSC 14.0 do 14.2.rar

Ссылка на комментарий
Поделиться на другие сайты

19.06.2023 в 08:07, PeterN сказал:

Можете поподробнее описать что было сделано для исправления ошибки?

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

Мои действия при выполнении :
1. Остановить службу Сервера администрирования.
2. Запустил установщик KSC 14.2 режим обновления.
3. Запустил скрипт fix_non_unique_unicode_strings\start.cmd от пользователя с правами Администратора.
4. Запустил скрипт klsql2\start.cmd от пользователя с правами Администратора.
5. Запустил службу Сервера администрирования.

Если служба Сервера администрирования KSC 14,2 не запустится. То необходимо перезагрузить сервер KSC и сервер БД и заново запустить обновление сервера. 

update KSC 14.0 do 14.2.rar

  • Согласен 1
Ссылка на комментарий
Поделиться на другие сайты

  • 7 months later...

Проблема вызвана некорректно написанной процедурой "AK_UPGRADE_DB_BATCH_15", вызываемой при обновлении схемы базы данных до 14 версии. При обновлении в таблицу "nl_storage_host_hash" по идее должен быть добавлен первичный ключ по столбцам "nHostId" и "nListProdId", видимо ради оптимизации, т.к. изначально никаких индексов в данной таблице нет. В процедуре это делается SQL-вызовом:

ALTER TABLE `nl_storage_host_hash` ADD CONSTRAINT `PK_nl_storage_host_hash2` PRIMARY KEY (`nHostId`, `nListProdId`);

Естественно, при этом в таблице не должно быть дубликатов пар значений в этих столбцах. Но вашем случае (и моём тоже) они есть. Конкретно, где-то в таблице, есть как минимум две строки с одинаковыми полями "nHostId" со значением "2954" и "nListProdId" с "4". Решение простое: нужно подцепиться к базе данных и удалить такие строки с дубликатами, я цеплялся через phpMyAdmin (база MySQL 5), строк было с десяток при общем размере таблицы в 300 строк. Так что просто вручную, примерно так:

DELETE FROM `nl_storage_host_hash` WHERE `nHostId` = "2954" AND `nListProdId` = "4" LIMIT 1;

Если использовать скрипты от техподдержки, то за это отвечает скрипт номер 2 в приложенном архиве выше, но там просто вся таблица стирается.

Ссылка на комментарий
Поделиться на другие сайты

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
  • Похожий контент

    • Илья Н.
      От Илья Н.
      Добрый день!
      Планирую произвести обновление KSC с версии 12.2.0.4376 до версии 14.2, используется KES версии 11.10.0. База данных расположена на отдельном сервере, используется Microsoft SQL Server 2008 R2. 
      До этого KSC не обновлял, прочитал оф руководство по обновлению, вроде бы всё понятно. Есть ли какие нибудь нюансы при выполнении обновления? 
    • tav
      От tav
      Всех приветствую !
       
      Поднял пока что тестовый KSC последний на Alt Linux.
      Версия KSC Linux PF 15.1.0.12199 и версия KESL PF 12.1.0.1543.
      В настройках политики установил распространять ключ через KSC и на самой лицензии галка стоит.
      Клиент работает не в режиме легкого агента.
       
      В итоге клиент виндовый подхватывает ключ с сервера KSC, клиент линуксовый при установке автоматом ставит тестовую/пробную лицензию и ни как не хочет цеплять автоматом лицензию.
      Если я создаю задачу для линуксовой группы/клиента сменить ключ, то все ок клиенты по задаче меняют ключ тестовый на корпоративный.
      Не понимаю почему именно линуксовые клиенты автоматом не тащат ключ. Настройки как я понимаю правильные.


    • MicroSkittles
      От MicroSkittles
      Добрый день. В предприятии имеется сервер KSC 14. Данный сервер в домене, мне все доступы выданы на мою доменную учетку. Я могу делать всё на сервере, кроме редактирования политик, при открытии все компоненты серые. Что еще можно посмотреть, может сталкивался кто? так же мне выдана группа KLAdmins на мою доменную учетку.
       
       





    • ГГеоргий
      От ГГеоргий
      Добрый день!
      Подскажите пожалуйста есть ли возможность откатить обновления в самом хранилище обновлений KSC? То есть не для конечных точек KICS for nodes или KES с помощью их задач, а именно внутри хранилища? 
      сценарий следующий:
      Выходит новое обновление, мы его загружаем в хранилище сервера администрирования. Затем проливаем его например на тестовую группу из 10 пк (к примеру). Переводим защиту на пк полностью в режим информирование и наблюдаем. Если понимаем, что обновление как то негативно влияет на работу, то мы откатываем обновление на самих тестовых хостах и также внутри самого хранилища. Откат внутри хранилища необходим например в случае когда подключится новый ПК и ему нужно будет загрузить старое обновление, а не то которое негативно влияет. 
      как вот сделать именно централизованный откат в самом хранилище чтобы дальше сервер снова смог старые "рабочие" обновы раздавать? 
      и в дополнении вопрос - есть ли возможность в политиках на конечных устройствах их переводить в режим информирования лишь одним чекбоксом или переключателем каким то? или вот в нашем сценарии придется каждый раз руками пробегаться по каждому протектору и в "информирование" переводить?
    • website9527633
      От website9527633
      Добрый день! Возник вопрос при обращении агентов удаленно посредством запуска скрипта на рабочих станциях, вопрос: как в Агенте администрирования 15 на рабочих станциях, в скрипте указать пароль от удаления Агента администрирования?
      К примеру у меня скрипт отрабатывал таким образом, но в случае версии Агента администрирования 15, он запрашивает дополнительно пароль от удаления
      @echo off
      start "" "C:\Program Files (x86)\Kaspersky Lab\NetworkAgent\klmover.exe" -address 192.168.1.1 -silent
×
×
  • Создать...