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

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

Опубликовано (изменено)

Покупал давно первый раз KIS11(не продление), вскоре вышел KIS12, удалил KIS11 и поставил 12, ключ подошел, лицензия продолжилась и вот уже заканчивается(20 дней осталось). Уже вышел KIS13, я старый удалил, сохранив лицензию, установил 13 и после ввода ключа от KIS12 мне пишет, что лицензия истекла... Мне теперь что делать? Покупать KIS13 карту продления за 1100 руб или KIS13 обычный за 1600 руб? И чем это все отличается?

 

Проблема решена! Ввел в личном кабинете свой ключ от KIS12, теперь у KIS13 осталось как и надо дней до окончания лицензии. Вопрос только остался таков:"Что нужно купить для продления лицензии? KIS12 продление или KIS13 продление? И в чем отличие продления от обычной версии, которая дороже стоит?"

Изменено пользователем kennydzzze
Опубликовано (изменено)
"Что нужно купить для продления лицензии? KIS12 продление или KIS13 продление? И в чем отличие продления от обычной версии, которая дороже стоит?"
Покупайте продление KIS13. Отличие в цене, что-то вроде скидки постоянным пользователям. Обязательно сохраните предыдущий код, может пригодиться при активации продления. Изменено пользователем Drru
Опубликовано
:D Разве на продлении есть отметки для КИС-12 или для КИС-13. Я что-то не заметил ни одной коробки в магазинах М Видео с этими пометками. Продавцы сообщают, что продление применимо и для той и для другой версии. Может я что-то не понял? :(
Опубликовано

MODEST, продление 2013 версии подходит и к 2012. С 2013 версии на коробке перестали писать номер версии антивируса.

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

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



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

    • Din
      Автор Din
      Есть приватный ключ, подскажите как и чем расшифровать?
       
      Сообщение от модератора Mark D. Pearlstone Перемещено из темы.
    • KL FC Bot
      Автор KL FC Bot
      Даже компании со зрелой ИБ и достаточными инвестициями в это направление не застрахованы от киберинцидентов. Атакующие могут использовать уязвимости нулевого дня или скомпрометировать цепочку поставок, сотрудники могут стать жертвой сложной мошеннической схемы по проникновению в компанию, сама команда ИБ может допустить ошибку в настройках защитных инструментов или процедуре реагирования. Но каждый такой случай — повод улучшать процессы и системы, делать защиту еще эффективнее. И это не просто мотивационный афоризм, а практический подход, который вполне успешно работает в других сферах, например в авиационной безопасности.
      В авиации требования по обмену информацией для предотвращения инцидентов предъявляются ко всем участникам — от производителей самолетов до стюардесс. И речь идет не обязательно об авариях или сбоях, в этой отрасли принято сообщать и о потенциальных проблемах. Сообщения постоянно анализируются и на их основе корректируются меры безопасности. Постоянное внедрение новых мер и технологий привело к снижению числа фатальных инцидентов с 40 на миллион вылетов в 1959 году до 0,1 — в 2015-м.
      Но главное — в авиации давно поняли, что такая схема не будет работать, если ее участники боятся сообщать о нарушениях процедур, проблемах качества и других причинах инцидентов. Поэтому авиационные стандарты включают требования non-punitive reporting и just culture — то есть сообщения о проблемах и нарушениях не должны приводить к наказанию. Есть подобный принцип и у инженеров DevOps, они обычно называют это blameless culture и используют при разборе масштабных сбоев. Незаменим такой подход и в кибербезопасности.
      У каждой ошибки есть фамилия?
      Противоположностью blameless culture является принцип «у каждой ошибки есть фамилия», то есть конкретный виновник, который ее совершил. В рамках этой концепции за каждую ошибку применяют дисциплинарные взыскания вплоть до увольнения. Однако в реальности использование этого принципа вредно и не ведет к повышению защищенности.
      Сотрудники боятся ответственности и искажают факты при расследовании случившихся инцидентов, а то и уничтожают информацию, пытаясь скрыть улики. Искаженная или частично уничтоженная информация об инциденте усложняет реагирование и ухудшает общий исход, потому что ИБ не может правильно и быстро оценить масштаб инцидента. При разборе инцидентов фокус на конкретном виновнике не позволяет сосредоточиться на том, как надо изменить систему, чтобы подобные инциденты не повторялись впредь. Сотрудники боятся сообщать о нарушениях политик и практик ИТ и ИБ, поэтому компания упускает шанс устранить дефекты защиты ДО ТОГО, как они стали причиной критического инцидента. Сотрудники не мотивированы обсуждать вопросы кибербезопасности, обучать друг друга, корректировать ошибки коллег. Чтобы все в компании могли внести вклад в ее защиту, надо действовать иначе.
       
      View the full article
    • infobez_bez
      Автор infobez_bez
      Здравствуйте! 
      Вопрос по Kaspersky Endpoint Security для Linux 12.1
      Машины управляются сервером администрирования, есть как на Windows так и на Linux, управляются разными политиками, но на машинах с Linux (Основа, Астра, Роса) - в логе событий устройств каждые 5-10 секунд появляются события "Ключ успешно добавлен" -> "Ключ успешно удален", это продолжается все время пока компьютер включен 
      Задач по распространению ключа нет
      На машинах с Windows такого нет
      Подскажите, куда копать? 

    • andrei96
      Автор andrei96
      Здравствуйте люди добрые. 
       
      проблема такая: на сервере администрирования ksc10.2.434( не гневитесь почему не обновленный) 
      При добавлении ключа вылетает ошибка : «не удалось добавить ключ»
      при том при всем, и для рабочих станций такая же ошибка. Есть мнение, что лаборатория Касперского специально сделала ключ недоступным для старых версий. Подскажите , есть ли у кого либо точное понимание так это или нет? 
       
      в журналах kaspersky event viewer и просмотр последних событий ksc ничего связанного с ключом и лицензией - нет. 
    • tav
      Автор tav
      Всех приветствую !
       
      Поднял пока что тестовый KSC последний на Alt Linux.
      Версия KSC Linux PF 15.1.0.12199 и версия KESL PF 12.1.0.1543.
      В настройках политики установил распространять ключ через KSC и на самой лицензии галка стоит.
      Клиент работает не в режиме легкого агента.
       
      В итоге клиент виндовый подхватывает ключ с сервера KSC, клиент линуксовый при установке автоматом ставит тестовую/пробную лицензию и ни как не хочет цеплять автоматом лицензию.
      Если я создаю задачу для линуксовой группы/клиента сменить ключ, то все ок клиенты по задаче меняют ключ тестовый на корпоративный.
      Не понимаю почему именно линуксовые клиенты автоматом не тащат ключ. Настройки как я понимаю правильные.


×
×
  • Создать...