Программные лицензии представляют собой файл, который в зашифрованном виде содержит параметры лицензии и характеристики компьютера, для которого данная лицензия получена. Доступ к этому файлу определяется правами доступа файловой системы. Если файл лицензии находится в каталоге, к которому нет доступа у пользователя, от имени которого работает экземпляр 1С:Предприятия, пытающегося получить лицензию - значит лицензия не будет получена!
2. Как работает программная лицензия?
Приложение 1С:Предприятия (клиентское или серверное) при необходимости получения лицензии выполняет поиск файлов по всем доступным путям. Далее из файлов получаются параметры самой лицензии и характеристики компьютера, для которого лицензия получена. Если параметры текущего компьютера не совпадают с полученными - файл лицензии отвергается. В противном случае выполняются проверки, связанные с количеством пользователей и типом лицензии (клиентская или серверная).
3. Что есть что в диалоге получения лицензии.
В диалоге получения лицензии есть два момента, которые вызывают наибольшие трудности - такое ощущение складывается по этому форуму.
Это страницы помощника с выбором компьютера, для которого должна быть установлена лицензия и выбор доступности лицензии (текущему пользователю или всем пользователям).
При получении программных лицензий необходимо выбрать, характеристики какого компьютера будут использоваться при привязке лицензии. От вида лицензии и компьютера, на котором запущен Конфигуратор, зависит, какой пункт следует выбирать при получении лицензии.
"На компьютер сервера 1С:Предприятия" имеет смысл выбирать в случае получения любых программных лицензий, если использование полученной лицензии предполагается на компьютере, где расположен сервер "1С:Предприятия" и это не тот компьютер, на котором выполняется получение программной лицензии. В этом случае файл с полученной программной лицензией всегда будет размещаться в каталоге профиля того пользователя, от имени которого работает сервер "1С:Предприятия" (по умолчанию — USR1CV82) на том компьютере, на котором работает сервер "1С:Предприятия".
"На этот компьютер" имеет смысл выбирать во всех остальных случаях. Исключением является многопользовательская программная лицензия, для которой выбирать пункт "На этот компьютер" имеет смысл только при запуске Конфигуратора на терминальном сервере или в терминальной сессии. Также в этом случае можно будет выбирать, куда будет помещен файл с активированной лицензией — в каталог профиля текущего пользователя или в каталог, доступный всем пользователям системы. Это будет каталог того компьютера, на котором выполняется активация программной лицензии.То, какой набор лицензий будет доступен для использования, зависит от того, куда будут размещены файлы с активированными лицензиями. Если они размещены в каталоге профиля пользователя, от имени которого выполняется активация лицензии, то другие пользователи этого же компьютера не получат доступ к этим лицензиям. Например, если на терминальном сервере активирована однопользовательская программная лицензия, и она размещена в каталоге профиля текущего пользователя (например, User1), то другой пользователь (например, User2) не сможет работать в то время, когда пользователь User1 не работает. Для того чтобы активированная лицензия была доступна всем пользователям компьютера, ее надо размещать в каталоге, предназначенном для всех пользователей системы. Тогда однопользовательская лицензия из примера, приведенного выше, будет доступна любому пользователю терминального сервера, при условии, что другие пользователи не используют данную лицензию (т.к. она однопользовательская).
4. Как активировать дополнительную программную лицензию?
Если требуется активировать дополнительную клиентскую программную лицензию на компьютере, на котором уже активирована программная лицензия, то делать это необходимо в точности так, как и при первой активации программной лицензии на выбранном компьютере.
Если выполняется получение серверной и многопользовательской программной лицензии и существует возможность запустить Конфигуратор на компьютере с установленным сервером "1С:Предприятия", то рекомендуется выполнять получение обеих лицензий на компьютере сервера, при этом получать лицензию следует "На этот компьютер" и "Всем пользователям данного компьютера".
ВНИМАНИЕ! Не рекомендуется размещать один файл программной лицензии одновременно в нескольких различных каталогах, доступных приложениям "1С:Предприятия". Это может привести к тому, что файл с лицензией станет непригодным для использования, т. к. является одним из вариантов нарушения лицензионного соглашения.
5. Рекомендации по получению программных лицензий
5.1. Файловый вариант информационной базы
5.1.1. Лицензия получается на клиентском компьютере
Однопользовательскую лицензию рекомендуется получать "На этот компьютер" и "Всем пользователям данного компьютера".Многопользовательскую лицензию активировать не имеет смысла.
5.1.2. Лицензия получается на терминальном сервере
Программную лицензию (любую) рекомендуется получать "На этот компьютер" и "Всем пользователям данного компьютера".
5.2. Файловый вариант информационной базы через веб-сервер
5.2.1. На компьютере, где получается лицензия, возможно запустить Конфигуратор
Рекомендуется установить на компьютер с веб-сервером толстый клиент и с помощью Конфигуратора получить лицензию (любую) "На этот компьютер" и "Всем пользователям данного компьютера". Так можно поступить, если веб-сервер развернут на ОС Windows.
5.2.2. На компьютере, где получается лицензия, невозможно запустить Конфигуратор
Установить на этот компьютер сервер необходимой разрядности и получить лицензию для компьютера сервера с любого компьютера в сети, на котором установлен толстый клиент. Серверное приложение позволит получать программную лицензию даже в том случае, если отсутствует серверная лицензия. Рекомендуется получать лицензию (любую) "На компьютер сервера 1С:Предприятия". С помощью этого способа можно получить, например, многопользовательскую программную лицензию для работы с файловой информационной базой через веб-сервер, развернутый на ОС Linux.
5.3. Клиент-серверный вариант информационной базы
5.3.1. Лицензия получается на клиентском компьютере
Однопользовательскую лицензию рекомендуется получать "На этот компьютер" и "Всем пользователям данного компьютера".
Многопользовательскую лицензию рекомендуется получать "На компьютер сервера 1С:Предприятия".
Получать многопользовательскую лицензию "На этот компьютер" не имеет смысла.
5.3.2. Лицензия получается на терминальном сервере
Программную лицензию (любую) рекомендуется получать "На этот компьютер" и "Всем пользователям данного компьютера".
5.3.3. Лицензия получается на компьютере сервера "1С:Предприятия"
Программную лицензию (любую) рекомендуется получать "На этот компьютер" и "Всем пользователям данного компьютера".
5.4. Серверная лицензия
5.4.1. Лицензия получается на клиентском компьютере
Рекомендуется получать программную лицензию (любую) "На компьютер сервера 1С:Предприятия".
5.4.2. Лицензия получается на компьютере сервера "1С:Предприятия"
Рекомендуется получать программную лицензию (любую) "На этот компьютер" и "Всем пользователям данного компьютера".
Тем, кто не сталкивался с 8.2 и всеми проблемами, особенно ранних версий платформы на системах с большим количеством пользователей меры, описанные в этой статье окажутся избыточными. Но все действия продиктованы только опытом, и проверены практикой.
1) Резервный центральный кластер создавать нужно. Это аксиома. Если у вас более 10 пользователей и в течение дня в 1С ведется хоть какая-то работа - выделите хотя бы обычный компьютер с не серверным "железом" под резервный центральный кластер - это пригодится.
2) Резервный центральный кластер - это не кластер включенный в группу резервирования.
Это полноценный центральный кластер, который является копией существующего. Да, это возможно; более того - это нужно делать. Только нужно отключить фоновые задания на резервном кластере серверов. Я не уверен по поводу лицензионного соглашения с 1С, но если в каждый момент времени будет использоваться только один центральный кластер ничего страшного в этом нет. Но сами понимаете, чтобы "подмена" кластеров была "горячей" кое что придется сделать... как минимум сбегать в серверную и переставить ключик. Кроме того резервный центральный кластер можно запускать с ключем -debug (в реестре: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\1C:Enterprise 8.2 Server Agent параметр "imagePath"). И использовать для отладки серверного кода разработчиками. Резервирование центрального кластера в случае использования штатного механизма 1С - штука наверное хорошая, вот только у меня лично она не сработала. Дело в том, что она не работает в случае "подвисания" процесса центрального кластера "rpmngr" - т.е. процесс есть, определить его отсутствие ещё не удаётся, механизм использования резервного центрального кластера не включается. А пока что с центральным кластером чаще всего случались проблемы "зависания" а не "падения".
3) Про 1cestart.exe забудьте. Моё личное мнение конечно, но по-моему этот блок в 1С отдали писать каким-то студентам (что вполне возможно, т.к. стартер не является частью платформы и не особо критичен). Столько ошибок в его работе находили в релизах, столько "глюков" было обнаружено в это простом инструменте, что пользоваться им решительно не советую, особенно в свете того, что далее будет специальный скрипт запуска 1С.
4) Для запуска 1С разработал специальный скрипт:
В данном скрипте "Сетевая папка" нужно заменить на адрес общедоступной папки, в которую вы поместите файлы настроек. По умолчанию файл может быть один. Но так же существует возможность для разных баз использовать разные сервера центрального кластера и разные файлы настроек. Это нужно, к примеру, чтобы сперва в работе новую версию платформы "протестировала" бухгалтерия, а потом уже перешли на новую версию основные торгующие подразделения.
файл настроек при этом будет иметь вид:
Всего 2 строчки. В первой - версия платформы, во второй - имя центрального кластера серверов
Этот скрипт нужно положить в ту же сетевую папку (если безопасность у вас в сети позволяет запускать скрипты из сетевых папок). Если не позволяет - на локальные компьютеры пользователей, и создать ярлыки для баз 1С со строками вида:
Где Base - имя базы в кластере для запуска. Пример скрипта, самосотятельно определяющего текущий EXE-шник 1С:
После этого изменением одной строчки в файле настроек вы сможете переключить запуск пользователей на другую платформу или на другой центральный кластер 1С. Не один раз этот простой скрипт спасал от долгого простоя.
Если имя сервера используется где-то при установке COM соединений - его тоже нужно поменять.
Соответственно при окончательном и бесповоротном падении основного сервера нужно сделать:
а) Останавливаете службу сервера если она ещё сама не остановилась (обязательно нужно это сделать чтобы на сервере не осталось активных пользователей, а то может сбоить нумерация объектов)
б) Переключаете в файле запуск на новый сервер
в) net send * "Перезайдите в 1С"
г) Запускаете 1С с новго сервера - вызываете на всякий случая "ОбновитьНумерациюОбъектов"
д) Включаете фоновые задания но новом кластере серверов
После этого "чините" основной сервер (починка чаще всего заключается в очистке каталога C:\Program Files\1cv82\srvinfo)
И в конце дня те же самые процедуры (кроме оповещения) проделываете для переключения обратно на основной сервер.
Если падение сервера наблюдается после обновления платформы, то к данным действиям нужно еще добавить восстановления COM соединителя на всех клиентских компьютерах (если вы используете COM или OLE) - нудно через установку и удаление программ выбрать нужную вам версию платформы и нажать "восстановить". т.к. COM соединения обычно не используются в критических процессах - они чаще всего нужны для интеграции, то их восстановление "терпит" и вы можете позволить себе обновлять машины, или сделать это групповой политикой, если разрешения для клиентских рабочих станций позволяют.
5) Резервная копия перед обновлением. Обязательно конечно - были уже релизы где все субконто очищались... так что лучше не рисковать
6) Проверка запуска после обновления. Тоже обязательна. И обратите внмание на время запуска... Оно может вдруг увеличиться до оочень большого.
Собственно эта методика позволяет "почти безболезненно" обновлять платформу, и быстро "откатываться" к "старым" релизам в случае возникновения проблем. Так же позволяет быстро переключиться на резервный центральный кластер в случае отказа основного. Успешно работает и опробована в случае работы в едином домене и преимущественно в терминальном режиме. В случае когда не единый домен и пользователи работают не не терминальных серверах появятся ещё "заморочки" с обновлением платформы на клиентских машинах (для них придётся использовать политики групп) и создании общей папки (если не единый домен), но возможности WSH позволяют считать файл из любого места - с этим проблем не будет.
Автор: Олег Филиппов
Зарегистрированная внешняя компонента хранится в реестре следующим образом:
Предположим, что у нас есть внешняя компонента E:\Events\Events.dll.
В 1С мы пишем:
Теперь зайдем в программу regedit.exe (Пуск-Выполнить-Regedit.exe).
Если регистрация прошла успешно, то в реестре мы увидим следующие записи (я сделал поиск по подстроке "AddIn.Events" в редакторе реестра regedit.exe, нажав сочетание клавиш Ctrl-F):
Значение {2E5E6B2C-EFE0-4872-9AB6-DF187B9CE397} является уникальным для каждого OLE-объекта идентификатором (CLSID). Его должен явно задать разработчик в коде внешней компоненты.
Значение ProgID, которое в нашем случае - "AddIn.Events" также задает разработчик внешней компоненты.
Чтобы в реестре появились эти записи, необходимы права доступа:
Начиная с Windows 2000, обычный пользователь не имеет прав доступа к указанным выше ветвям реестра. Нужны права или администратора, или привилегированного пользователя Windows. После первой загрузки компонента пропишет себя в реестре, и ее смогут использовать и непривилегированные пользователи Windows.
Где 1С ищет внешнюю компоненту?
Если при загрузке внешней компоненты вы не указываете полный путь, такой как E:\Events\Events.dll или сетевой путь наподобие \\ВашСервер\ПапкаГдеЛежатВК\Events.dll, то 1С ищет внешние компоненты
-относительно папки 1Cv7\BIN (КаталогПрограммы())
-относительно каталога информационной базы (КаталогИБ())
Метод ЗагрузитьВнешнююКомпоненту(), обнаружив ВК по новому пути, обновляет ее регистрацию в реестре
Это означает, например, что на терминальном сервере программист, который вошел в тестовую базу, где лежит ВК, и потом ее стер, оставит у всех пользователей запись в реестре о несуществующей ВК.
Аналогичная проблема - когда ВК по данному пути недоступна тем или иным пользователям.
А поскольку пользователи не имеют права на изменение записей в реестре, то у них перестанет загружаться и внешняя компонента.
В 1С:Предприятие 8.0 убрана возможность загрузки ВК относительно каталога ИБ.
В 7.7 же, чтобы избежать проблем, всегда убирайте ВК из каталога ИБ, и прописывайте полные пути (или складывайте DLL в общую для всех пользователей папку BIN).
Кардинальное решение проблемы - VKLoader и RegsvrEx
Имеется компонента VKLoader.dll (автор - Александр Орефков), которая позволяет решить проблемы с регистрацией компонент.
Цитата:
"vkloader (далее ВК) - внешняя компонента для 1С-Предприятия 7.7, которая может загружаться без ее регистрации в реестре, и загружать другие внешние компоненты без их регистрации. Предназначена для беспроблемной загрузки внешних компонент пользователями, не имеющими прав на запись в HKCR ветку реестра.
Принцип работы основан на перехвате обращения 1С к WinAPI функциям CLSIDFromProgID и CoCreateInstance.
Также ВК решает проблему "зависания" процесса 1С в памяти при закрытии программы при использовании несовсем корректно написанных сторонних внешних компонент".
Пример использования vkloader:
Замечу, что сама vkloader "умеет" загружать себя без прав доступа к реестру.
Еще одно решение: RegsvrEx
Автор - AlexQC.
Регистрирует компоненты (OLE-объекты) в пользовательской ветке реестра. RegsvrEX