Blog of Khlebalin Dmitriy

(Дорогу осилит идущий…)

Управление списками баз 1С.

По мотивам: https://habr.com/ru/post/250287/

Давно хотел написать этот пост, но все как-то «руки не доходили»…

В этот раз миграция наших серверов 1С прошла как-то тяжко. Все время что-то отваливалось или работало не так как надо, потрачено много нервов и сил. Вроде делаешь все штатно, но столько нюансов, что косяки никак не заканчиваются 😦  Бухгалтерия «стоит над душой» и мешает сосредоточиться на процессе. В общем, все как обычно…

Когда баз становится много, а в бухгалтерии много народу, то прописывать их каждому руками не вариант, поэтому следуем рекомендациям умных людей и автоматизируем процесс.

Создаем папку 1c_baselist.

В ней располагаем файлы описаний баз:

В каждом файле прописано:

Создаем в домене группы разрешений на каждую базу:

В каждую группу добавляем тех пользователей, кому будет необходим доступ к той или иной базе 1С:

На файлы описаний баз навешиваем разрешения той группы, которую создали для этого файла:

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

Краткая инструкция:

/** Описание работы 1с со списками **/
Файлы в директории 1c_baselist содержат в себе описания общих баз.
1c при запуске читает списки _файлов_ общих баз (.v8i) из файлов конфигурации %APPDATA%\1C\1CEStart\1CEStart.cfg и C:\ProgramData\1C\1CEStart\1CEStart.cfg в последнем указаны файлы из этой папки.
В каждом файле списка баз(.v8i) описание одной или нескольких баз — название в списке, папка в древовидном списке, строка подключения, версия… Длинного UID базы там быть не должно.
Далее, 1с пытается читать файлы .v8i по полученному списку, если пользователь состоит в соответствующей группе, то у 1с получается прочитать файл .v8i , и она добавляет информацию из него в список баз. Если пользователя нет в группе, то файл прочитать не может, и база в списке не появляется.
Информация о списке копируется в %APPDATA%\1C\1CEStart\ibases.v8i, который можно удалять, он пересоздастся заново.

/*** Порядок добавления новых баз ***/
1. Создаем группу в AD в контейнере (Ваш контейнер), называем по маске ACL 1c_baselist БАЗА RO (БАЗА). Именование групп по желанию.
2. Копируем файл template.v8i, скопированные именуем по маске СЕРВЕР_БАЗА1С.
3. Правим в скопированном файле три первых строчки, требуемые места замены обозначены прямо в файле.
4. Снимаем со скопированного файла наследование, убираем права на чтение у квазипользователя «ВСЕ», даем права на чтение созданной на шаге 1 группе.
5. Перелогиниваем пользователей, которым нужна эта база

/*** Порядок подключения баз пользователю ***/
1. Добавляем пользователя в группу соответствующей базы.
2. Перелогиниваем пользователя.

Наверно это все…

Всем хорошей работы!!!

17.03.2020 Posted by | ms windows 2016 | Комментарии к записи Управление списками баз 1С. отключены

Неведомый БАГ DC Windows 2016.

На минувшей неделе, столкнулись с интересным багом, по факту которого, всем отделом, так и не смогли понять, что именно произошло…

У нас 2 контроллера домена на Windows 2016 и почтовый сервак, пока на Windows 2008R2:

-GODC2 (виртуальный) SDC, DNS, GC.

-GODC3 (железный) PDC, DNS, GC.

-MAIL (виртуальный) EXCH2010.

В целом все работает достаточно стабильно и вроде без проблем. Но на минувшей неделе, при попытке зайти на GODC2 по RDP он вдруг повис и не пустил, далее впал в гидростопор и перестал отвечать.

Впал и впал, бывает… В этот момент обратили внимание, что система мониторинга  показала ошибку транспорта SMTP на «Чанге». Начали копать, и вдруг обнаружили интересную вещь: когда второй контроллер впадает в анабиоз, то «Чанга», тоже «втыкает», хотя основной контроллер GODC3 работает. Первичная диагностика показала, что  «Чанга» не видит GC основного контроллера GODC3.

Похожая проблема обсуждается здесь:

https://social.technet.microsoft.com/Forums/ru-RU/9a390d3b-4fac-4fcc-8191-34e5196622e0/-exchange-2010-could-not-find-any-global-catalog-in-forest?forum=exchange2010ru

Пытаемся провести первичную диагностику на GODC3, на контроллере все с виду в порядке: доступен и DNS и GC. Но интересный момент в том, что это все доступно только самому контроллеру, но недоступно другим серверам, в том числе «Чанге», из-за чего она и «воткнула».

В нормальной ситуации должно быть во так (если один, контроллер не доступен, то должен быть доступен второй и все равно светиться при запуске команды):

В нашей аварийной ситуации, это выглядело так: unknown query type: srv_gc.tcp.comp.loc. Как я уже выше писал, делаешь тоже самое на GODC3, и GC доступен, с других серверов соответственно нет.

Но на этом проблемы не закончились. GODC2 перезагрузился, вернулся в строй, прошла репликация, а Exchange так и не поднимался. Дальше, ровно так же, как несколько минут назад «воткнул» GODC2, «воткнул» и GODC3, при том на железке. Пришла мысль, что вероятно какое-то, вновь прилетевшее обновление, «кладет» контроллеры, при том, что все остальные сервера благополучно работали без проблем. Самое интересное, что так продолжалось часа полтора, мы несколько раз поочередно перезагружали контроллеры и пытались диагностировать, что именно их заставляет безответно подвисать (при том подвисать не сразу после загрузки, а в течении 10-15 минут после), но ничего подозрительного не было, репликация благополучно выполнялась, и все вроде как работало… Спустя пару-тройку перезагрузок обоих контроллеров, проблема исчезла также незаметно, как и появилась. Почта снова пошла и оба контроллера снова стали доступны почтовику.

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

Был всего-лишь один лог, указывающий на причину происходящего: точно уже не вспомню, но что-то типа, сервер не получил отклика от DNS по этому не смог обработать данные GC. Но в момент аварии все резолвилось… Более ничего внятного по теме…

Если кто-то сталкивался, или у кого-то есть предположения, прошу написать в комментариях? Прецедент не очень хороший.

В рамках проблемы еще раз погрузился в архитектуру (было интересно вспомнить), в случае необходимости, все это будет крайне полезно при траблешутинге:

https://blog.bissquit.com/windows/global-catalog/

https://dimanb.wordpress.com/2010/12/20/%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D1%8B-%D0%B3%D0%BB%D0%BE%D0%B1%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D1%85-%D0%BA%D0%B0%D1%82%D0%B0%D0%BB%D0%BE%D0%B3%D0%BE%D0%B2/

Всем хорошей работы!!!

 

04.02.2020 Posted by | ms windows 2016 | Комментарии к записи Неведомый БАГ DC Windows 2016. отключены

Terminal Server на Windows 2016 (часть 3).

РОЛЬ УДАЛЕННЫХ РАБОЧИХ СТОЛОВ настроена, необходимо разрешить ПОДКЛЮЧЕНИЕ К ТЕРМИНАЛЬНЫМ СЕССИЯМ ПОЛЬЗОВАТЕЛЕЙ БЕЗ ИХ РАЗРЕШЕНИЯ НА ЭТО.

Задача: Настроить удаленное подключение на терминальном сервере к RDP сеансу пользователя.

Это можно сделать и руками, например, у каждого пользователя, имеющего доступ на терминальный сервер, можем снять вот эту галку: Запрашивать разрешение пользователя.

Если таких пользователей много, то это утомительно и долго…

Поэтому снова обращаемся в GPO.

Создаем отдельную политику TerminalUsers.

Связываем ее с необходимой OU, добавляем тех, кому это необходимо.

Далее правим:

Конфигурация пользователя-Административные шаблоны-Компоненты Windows-Службы удаленных рабочих столов-Узел сеансов удаленных рабочих столов-Подключения

 

gpupdate /force

Далее пробуем на сервере подключиться к RDP сессии пользователя:

Диспетчер серверов-Службы удаленных рабочих столов-Коллекции-1C-RDP

 

Если у удаленного пользователя стол заблокирован, то сможем видеть просто черный экран, если разблокирован, то его рабочий стол. После обновления GPO, cогласие пользователя на подключение к его сессии больше не требуется.

Всем хорошей работы!!!

 

19.09.2019 Posted by | ms windows 2016 | Комментарии к записи Terminal Server на Windows 2016 (часть 3). отключены