Проблема: После обновления на 1С:Бухгалтерию предприятия 3-й версии, при нажатии на закладку командного интерфейса 1С:предприятие, выскакивает ошибка:

Aboutsecurity_1cv8c.exe или Aboutsecurity_1cv8.exe

«Содержимое указанного ниже веб-узла в этом приложении блокировано конфигурацией усиленной безопасности Internet Explorer».

Ошибка исчезает после многократного нажатия на «Закрыть», что несколько мешает работать, мягко говоря. Похожая ошибка бывает и в конфигураторе, при обновлении конфигурации или сравнении/объединении конфигураций. Чаще всего, мне попадалась эта проблема в серверных ОС, в частности Windows 2008 r2.

Решение: нужно добавить исключение в настройках безопасности Internet Explorer (далее & IE).

Это делается просто, если у вас один или несколько компьютеров & просто открываете IE/Свойства обозревателя/Безопасность/Надёжные узлы/Сайты, добавляете Aboutsecurity_1cv8c.exe и Aboutsecurity_1cv8.exe, нажимаете Ок, и наслаждаетесь результатом.

Но вот если у вас терминал-сервер и 40/60 пользователей, или еще хуже & пользователей 150 и они ходят в SQL версию 1С с локальных рабочих станций, то бегать по всем корпусам и добавлять эту настройку весьма накладно по времени, да и отвлекать пользователей лишний раз от работы не порядочно.

В этом случае, нужно пользоваться групповыми политиками домена (который у вас должен быть настроен, если вы не офисный спортсмен-бегун).

Вариант №1. Неудавшийся.

Первое решение & прописать настройки через Group Polices (Административные шаблоны/Компоненты Windows/Internet explorer/Вкладка «Безопасность»/Список назначений зоны для веб-сайтов) & не увенчалось успехом. Настройки пользователей, как и обещалось в статьях по данному методу, перестали работать, а вот зоны, описанные в этих настройках, работать не начали. При этом, я пробовал добавлять настройки и в локальные политики, и в доменные и в политики контроллера домена. Скорее всего из-за этих экспериментов с разными зонами действия групповых политик и появилась проблема.

И так, после этих манипуляций, в настройках безопасности IE появилась надпись «Некоторыми параметрами управляет системный администратор» и добавлять/удалять сайты узлов безопасности стало невозможно. От этой надписи, почему-то, оказалось не так просто избавиться. Удаление проделанных настроек GPO не разблокировали вкладку «Безопасность», а манипуляции с реестром привели к появлению ошибок «В параметрах зоны есть ошибка. Не удалось добавить сайт.» (IE 10) или «При установке параметров безопасности зоны произошла ошибка. Добавить узел не удается.» (IE 9) & все дальнейшие действия сходили на нет.

Исправить косяк удалось следующим путём:

Обновил Internet Explorer до версии 10 (был 9-й).

Предварительно экспортировав разделы реестра в файл, на случай восстановления, удалил из следующие ключи:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\InternetSettings

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings]

Восстановил настройки Internet Explorer (Свойства обозревателя/Дополнительно/Сброс).

Проверить, что проблема не вернётся можно введя команду gpupdate /force в командной строке. После обновления политики запустите IE и проверьте, что настройки остались на месте. Если настройки опять слетели и добавление сайтов в узлы безопасности стало опять невозможно, то, скорее всего вы забыли отключить параметр «Список назначений зоны для веб-сайтов» в какой-то из зон групповой политики.

Чтобы определить в какой из зон групповых политик засела настройка (в локальных, доменных или контроллера домена), удобно пользоваться мастером отчётов «Результаты групповой политики», который находится в консоли «Диспетчер сервера», в разделе «Компоненты/Управление групповой политикой» (в Windows 2008 r2, по крайне мере он там).

Так что, здесь стоит быть осторожным, чтобы не создать себе дополнительной работы.

Вариант №2. Через GPO и реестр.

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

Что делать:

Удаляем узлы Aboutsecurity_1cv8 из настроек IE, если вы их туда уже добавили вручную & это нужно для чистоты эксперимента. Проверьте, что в 1С ошибка сохранилась.

Создаём файл 1csec.reg, с содержимым:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\security_1cv8c.exe]

«about»=dword:00000002

Небольшая ремарка: подраздел EscDomains используется в режиме расширенной настройки безопасности, если же этот режим отключен по какой-то причине, то нужно использовать раздел Domains вместо EscDomains (подробнее о записях реестра IE см. в базе знаний Microsoft).

И пробуем добавить его в реестр & если срабатывает, и в тонком клиенте 1С ошибка Aboutsecurity_1cv8c.exe исчезает, делаем дальше.

Снова открываем Default Domain Policy в диспетчере управления сервером, далее Конфигурация пользователя/Настройка/Конфигурация Windows/Реестр.

Добавляем туда две записи, где поле «Путь раздела»:

в первой записи это «Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\security_1cv8c.exe» (для тонкого клиента 1С),

во второй записи «Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\security_1cv8.exe» (для толстого клиента).

В остальном запись содержит те же данные, что и на картинке.

После этого, как положено, перелогиниваемся и проверяем результат. В толстом и тонком клиенте 1С:предприятие, ошибка должна исчезнуть.

В моём случае, для надёжности избавления от проделанных в Варианте №2 настроек, были добавлены ещё три записи в реестр:

Обновить: HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings; параметр: ListBox_Support_ZoneMapKey; значение 0 (тип DWORD десятичный)

Удалить: HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

Удалить: HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey

Вариант №3. Интерфейсный.

Есть ещё вариант, который переключит работу программы в режим интерфейса «Такси» : Администрирование/Настройки программы/Интерфейс & здесь включаем «Интерфейс «Такси»" & в этом режиме данная ошибка не появляется, но пользователям может не понравиться работать с этим вариантом интерфейса, т. к. он предназначен для мобильных устройств и планшетов (например, для работы через Web).

Источник

Связка сервера 1С:Предприятие и PostgreSQL вторая по популярности среди установок 1С и самое используемое решение на платформе Linux. В отличии внедрений на базе Windows и MSSQL, где трудно сделать так, чтобы не заработало, внедрения на базе Linux таят множество подводных камней для неопытного администратора. Часто бывает так, что вроде бы все сделано правильно, но ошибка следует за ошибкой. Сегодня мы рассмотрим самые типовые из них.

Общая информация

Перед тем, как начинать искать ошибки установки и, вообще, приступать к внедрению серверной версии 1С:Предприятия было бы неплохо освежить представление как это работает:

Сервер 1С Предприятия. Часть 1 - Общие вопросы.

В небольших внедрениях сервер 1С и сервер СУБД обычно совмещают на одном физическом сервере, что немного сужает круг возможных ошибок. В нашем случае будет рассматриваться ситуация, когда сервера разнесены по разным машинам. В нашей тестовой лаборатории мы развернули следующую схему:

В нашем распоряжении имеются два сервера под управлением Ubuntu 12.04 x64, на одном из них установлен сервер 1С:Предприятие версии 8.3, на другом PostgreSQL 9.04 от Ethersoft, а также клиент под управлением Windows. Напоминаем, что клиент работает только с сервером 1С, который, в свою очередь, формирует необходимые запросы к серверу СУДБ. Никаких запросов от клиента к серверу управления базами данных не происходит.

Сервер баз данных не обнаруженВАЖНО: пользователь "postgres" не прошёл проверку подлинности (Ident)

Данная ошибка возникает при разнесении серверов по разным ПК из-за неправильно настроеной проверки подлинности в локальной сети. Для устранения откройте /var/lib/pgsql/data/pg_hba.conf, найдите строку:

host    all    all      192.168.31.0/24 ident[/pre]
и приведите ее к виду:
host    all    all      192.168.31.0/24   md5[/pre]
где 192.168.31.0/24 - диапазон вашей локальной сети. Если такой строки нет, ее следует создать в секции IPv4 local connections.
Сервер баз данных не обнаруженcould not translate host name "NAME" to address: Temporary failure in name resolution
На первый взгляд ошибка понятна: клиент не может разрешить имя сервера СУБД, типичная ошибка для небольших сетей, где отсутствует локальный DNS-сервер. В качестве решения добавляют запись в файлhosts на клиенте, что не дает никакого результата...
А теперь вспоминаем, о чем было сказано несколько раньше. Клиентом сервера СУБД является сервер 1С, но никак не клиентский ПК, следовательно запись нужно добавлять на сервере 1С:Предприятие в файл/etc/hosts на платформе Linux или в C:\Windows\System32\drivers\etc\hosts на платформе Windows.
Аналогичная ошибка будет возникать, если вы забыли добавить запись типа A для сервера СУБД на локальном DNS-сервере.
Ошибка при выполнении операции с информационной базойserver_addr=NAME descr=11001(0x00002AF9): Этот хост неизвестен.
Как и прошлая, эта ошибка связана с неправильным разрешением клиентом имени сервера. На этот раз именно клиентским ПК. В качестве решения добавляем в файл /etc/hosts на платформе Linux или в C:\Windows\System32\drivers\etc\hosts на платформе Windows запись вида: 
192.168.31.83SRV-1C-1204[/pre]
где указываете адрес и имя вашего сервера 1С:Предприятия. В случае использования локального DNS следует добавить A-запись для сервера 1С.
Ошибка СУБД: DATABASE не пригоден для использования
Гораздо более серьезная ошибка, которая говорит о том, что вы установили несовместимую с 1С:Предприятие версию PostgreSQL или допустили грубые ошибки при установке, например не установили все необходимые зависимости, в частности библиотеку libICU. 
Если вы имеете достаточный опыт администрирования Linux систем, то можете попробовать доустановить необходимые библиотеки и заново инициализировать кластер СУБД. В противном случае PostgreSQL лучше переустановить, не забыв удалить содержимое папки /var/lib/pgsql.
Также данная ошибка может возникать при использовании сборок 9.1.x и 9.2.x Postgre@Etersoft, подробности смотрите ниже.
Ошибка СУБД: ERROR: could not load library "/usr/lib/x86_64-linux-gnu/postgresql/fasttrun.so"
Довольно специфичная ошибка, характерная для сборок 9.1.x и 9.2.x Postgre@Etersoft, также может приводить предыдущей ошибке. Причина кроется в неисправленной ошибке в библиотеке fasttrun.so. Решение - откатиться на сборку 9.0.x Postgre@Etersoft.
Ошибка СУБДERROR: type "mvarchar" does not exist at character 31
Возникает если база данных была создана без помощи системы 1С:Предприятия. Помните, для работы с 1С базы данных следует создавать только с использованием инструментов платформы 1С: через консоль Администрирование серверов 1С Предприятия
или через средство запуска 1С.
Сервер баз данных не обнаруженВАЖНО: пользователь "postgres" не прошёл проверку подлинности (по паролю)
Очень простая ошибка. Неправильно указан пароль суперпользователя СУБД postgres. Вариантов решения два: вспомнить пароль или изменить его. Во втором случае вам нужно будет изменить пароль в свойствах всех существующих информационных баз через оснастку Администрирование серверов 1С Предприятия.
Сервер баз данных не обнаруженFATAL: database "NAME" does not exist
Еще одна очень простая ошибка. Смысл ее сводится к тому, что указанная БД не существует. Чаще всего возникает из-за ошибки в указании имени базы. Следует помнить, что информационная база 1С в кластере и база данных СУБД - две разные сущности и могут иметь различные имена. Также следует помнить, что Linux системы чувствительны к регистру и для них unf83 и UNF83 два разных имени.
Источник: interface31