«Не пускает в 1С»: что на самом деле ломается, когда программа молчит
Привет, это СБиСик. Сижу утром, наливаю себе чай, открываю мессенджеры — и тут влетает паническое: «Срочно, 1С не даёт войти!». В этот момент я уже слышу скрип тормозов в голове главбуха, вижу бегущего по складу кладовщика и представляю менеджера, который не может пробить счёт. Ошибка при входе в 1С — это не про диалоговое окно, это про то, что бизнес встал на паузу.
Одна фраза — десятки сценариев
Когда человек пишет «почему не могу войти в 1С», он почти всегда думает о пароле. Ну, логично же: вчера вводил, сегодня ввожу, программа ругается. Но под капотом могло смениться совсем другое: кончилась лицензия, сервер упал, DNS не прошёл, служба агента 1С решила передохнуть, а у особо везучих — ещё и патч наложился криво. Короткое «не входит» прячет целый слоёный пирог уровней: от клавиатуры пользователя до SQL-сервера в подвале.
Мне иногда проще показать это на салфетке. Слой первый — человек: логин, пароль, права. Слой второй — рабочее место: клиент 1С, операционная система, сеть. Третий — сервер приложений. Четвёртый — база данных. Пятый — лицензия. Шестой — обновления. Поломка на любом из них выдаст одно и то же сердитое окно.
Кстати, если нужно быстро, без длинных разборов, я иногда кидаю свежие находки в наш канал в MAX. Формат короче, успеваю черкнуть заметку, пока очередной сервис перезапускается.
Вернёмся. Вот пример из вчерашнего. Бухгалтер Света. Звонит: «Идентификация пользователя не выполнена». Начали с банального — Caps Lock, раскладка. Не помогло. Захожу на сервер: вижу, что один из узлов кластера омертвел, а второму не хватает RAM, сессии висят. Света тут ни при чём, а сообщение на экране словно нарочно прячет настоящую причину.
Другой случай: склад. Работают в тонком клиенте, утром часть людей не пускает, часть работает. Первая мысль — права. Но роли вчера никто не трогал. Оказалось, сетевая карта в соседней стойке начала терять пакеты, и тонкий клиент просто не дожимает соединение. Ошибка та же, а лечим уже железо.
Вход в 1С — горлышко всего бизнеса
Представьте конвейер на заводе. Если в начале пробка, весь цех стоит. Так и тут: пока 1С не пускает, документы не создаются, заказы не выходят, отчёты не строятся. Больше всего это чувствуется в конце месяца, когда бухгалтерам надо закрыть период, а менеджерам — выбить последние реализации. Одно окно авторизации превращается в песочные часы для всего отдела.
Меня частенько спрашивают: ну и что, перезапустить не судьба? Перезапуск — полезная штука, но только если угадал уровень проблемы. Если дело в лицензии — никакая перезагрузка клиента не поможет. Если база повреждена после обрыва света, то и серверная служба не спасёт. Самая дорогая ошибка — лечить не то.
Ещё интересный нюанс: файловая база и клиент-сервер ведут себя совсем по-разному. В файловом варианте упираемся в блокировки на уровне *.1CD* или в доступ к сетевой папке. В серверном — сразу вылезают порты, кластер RAS, агенты, да ещё и SQL поверх. Сообщение на экране одинаковое, а карта поиска причин уже другая.
Усугубляет картину браузерный запуск. Веб-клиент добавляет сертификаты, HTTPS, прокси, кэш браузера. Пользователь видит: «В данный момент вход в приложение невозможен», а админ в логе лапой машет на TLS-handshake. Вот почему симпотом и причина часто живут на разных этажах.
Территория типичных мифов
Миф №1. «Раз у коллеги входит, значит система жива».
У коллеги может быть другая роль, другой способ аутентификации или он сидит на другом сервере кластера. Так что «живость» надо проверять шире, чем «ну у Пети же работает».
Миф №2. «Пароль — главный злодей».
Да, пароль неправильный встречается. Но куда чаще вижу, что истёк срок действия доменной учётки, или администратор снял роль «ПолныеПрава» после ревизии. Пользователь упорно бьёт пароль, а реальная причина в политике безопасности.
Миф №3. «После обновления хватит перезапустить 1С».
Был патч 8.3.23 EF_00_00594218, который любил блокировать вход. Программу можно было перезапустить хоть сто раз, пока не удалишь патч — всё бестолку.
Кстати, подобные истории мы обсуждали ещё в Telegram-канале, там народ часто делится свежими логами и скриншотами, прежде чем я успеваю добраться до удалёнки.
Между строк тут прячется главный урок: сообщение об ошибке — это только симптом. По нему придётся раскручивать цепочку до настоящей болячки. Иногда нужно просто добавить пользователя в группу «1С_Users» в AD, а иногда — поднимать упавший кластерыч на втором сервере, который за ночь забыл смонтировать диск данных. Казалось бы, механика та же: «не входится», а время решения разнится от минуты до полдня.
Что проверять первым делом
Я держу под рукой условный «стартовый чек-лист»:
1. Пользователь: правильный ли логин, не закончился ли срок действия пароля, не заблокирована ли учётка.
2. Рабочее место: запускается ли другой ярлык 1С, пингуется ли сервер, как ведёт себя браузер.
3. Сервер: горит ли служба RAS, что в логе событий, живы ли порты 1540/1560.
4. База: доступны ли файлы, нет ли блокировок, открывается ли база в монопольном.
5. Лицензия: не исчерпан ли пул, не обвалилась ли защита, видит ли сервер Guardant.
6. Обновления: не накатывался ли патч прошлой ночью, совпадают ли номера платформы и конфигурации.
Каждый пункт — это буквально пара кликов или одна команда в консоли, но экономия времени колоссальная. Пока кто-то вслепую ребутит всё подряд, я уже знаю, куда смотреть. Правда, иногда инфрастуктура подкидывает такие сюрпризы, что чек-лист приходится дописывать на ходу…
Кейсы из практики: коротко, без купюр
«Вчера работало, сегодня нет». Подобное почти всегда означает, что что-то изменилось за ночь. Часто это плановое обновление Windows, которое перезапустило службу SQL Server раньше, чем поднялся том с базой. Утром пользователей не пускает, база «серая».
«Только у меня ошибка, у коллеги всё ок». Нашли: у коллеги auto-login по Windows, у вас — обычный логин/пароль. Системный админ сменил политику минимальной длины пароля, ваш старый теперь не проходит, а Windows-аутентификация продолжает брать токен Kerberos. Вывод: одинаковое сообщение, разные механизмы под капотом.
«После смены модема офис не заходит в облако». Тут победил MTU. Новый провайдер режет пакеты больше 1400 байт, HTTPS-обёртка веб-клиента 1С не договаривается с сервером. Решение: правка PPPoE-настроек и увеличение Fragmentation Threshold. Пользовательские попытки «сбросить пароль» выглядели трогательно, но бесполезно.
«Файловая база повисла в монопольном режиме на одного сотрудника». Смотрим: пользователь запустил отчёт, отчёт ушёл в ECXEL с ком-объектом и сессия не закрылась. Заблокировало файл *.lck*. Остальные стоят, хотя причина — один подвисший процесс EXCEL.EXE где-то под столом.
И, знаете, всякий раз, когда кажется, что видел уже всё, появляется новый баг. Именно поэтому сейчас я готовлю вторую часть текста, где разберём каждый уровень поломки детальнее, посмотрим логи и пощупаем живые команды диагностики. Но об этом чуть позже, потому что …
Как раскрутить цепочку: семь уровней диагностики
Когда вижу фразу «1С вход не выполнен», сразу раскладываю её на уровни — словно детскую пирамидку, где кольца снимаются одно за другим. Ловите короткую карту, которая за годы стала уже рефлексом:
Уровень 1. Клавиатура. Банальный Caps Lock. Половина «ночных» заявок — именно про него.
Уровень 2. Учётка. Блокировка в конфигурации, истёкший пароль в AD, деактивация после увольнения — классика понедельника.
Уровень 3. Рабочий клиент. Повреждённый 1cv8.exe, две версии платформы на одном ПК, забытый файл conf.cfg в каталоге профиля.
Уровень 4. Сеть. Потерянный маршрут, новый VLAN без прописанных портов 1540/1560, MTU 1400, как в кейсе с модемом выше.
Уровень 5. Кластер/SQL. Упал один из RAS-процессов, забит TempDB, autogrowth по 1 МБ — база замирает, 1С молчит.
Уровень 6. Лицензия. Аппаратный ключ пересели на соседний USB-порт, сервис haspd не поднялся после обновления Windows.
Уровень 7. Платформа и патчи. Несовместимый build, «горячий» фикс, который в релиз нотах выглядит безобидно, а на проде портит 1С авторизацию.
Снял кольцо — переходишь к следующему. Главное — не перескакивать: если учётка заблокирована, нечего лезть в SQL-журналы.
Типовые ошибки пользователей: топ-5 живых примеров
1. Два ярлыка — две судьбы. На рабочем столе «УПП» и «УПП тест». Подменили иконку после миграции, пользователь кликает в боевую уверенный, что это тест. В боевой давно сменили пароль. Итог — «неверные данные» и нервы.
2. Отключённый Num Lock. На ноутбуках цифры в пароле вдруг превращаются в буквы u, i, o. Пять неверных попыток — конфигурация сама блокирует пользователя. Диалог «1С ошибка “идентификация не выполнена”» обеспечен.
3. «Сохранить пароль» в браузере. В веб-клиенте Chrome бережно подставляет старый набор символов. Человек уверен, что вводит руками, а на самом деле автозаполнил позавчерашнюю комбинацию.
4. Обновили платформу — забыли ярлык. После апгрейда до 8.3.25 старый ярлык смотрит в каталог 8.3.24. Логика железная: «почему ты, 1С, не запускаешься, ведь вчера работала?».
5. Дублирование сеанса. Пользователь шёл обедать, свернул программу, вернулся, щёлкнул второй раз. Первая сессия висит, лицензии заняты, новая — «нет свободных клиентских лицензий» — и опять тот же вопрос: «не могу войти в 1С, что делать?».
Диагностика в картинках: три сценария за 15 минут
Сценарий 1. Ошибка после обновления.
1. Смотрим номер платформы в окне входа.
2. Сравниваем с версией на сервере (ras.exe –v).
3. Если не совпало — правим ярлык или откатываем патч. Пять минут, а не час перебора паролей.
Сценарий 2. «Пользователь не найден».
1. Открываем конфигуратор в монопольном режиме.
2. Проверяем таблицу _usrv8 — бывает, имена уехали после миграции.
3. Находим пустую строку — восстанавливаем связь с объектом системы доступа. Две минуты SQL вместо десяти перезагрузок.
Сценарий 3. Не берётся лицензия Guardant.
1. На сервере: localhost:1947 — видим ли ключ?
2. В логе hasplms.log — сколько активных сессий?
3. Если ключ виден, а мест нет — снимаем «залипшие» сеансы RDP или ждём 15 минут тайм-аута. Иногда economia в пять лицензий = плюс 30 тыс. на счёте.
Профилактика: четыре привычки, которые спасают нервы
1. Раздельные учётки «Админ» и «Пользователь». Минимум ролей — минимум случайных галочек в правах, которые потом аукаются «нет доступа к объекту».
2. Мониторинг служб. Один tiny-скрипт PowerShell проверяет RAS и SQL каждые пять минут. Получаю письмо раньше, чем звонит бухгалтер.
3. Регулярные тестовые входы. После патча — не «открывается ли база», а «может ли рядовой сотрудник создать документ». В выходные такой тест экономит понедельник.
4. Квоты лицензий. Если пул на 50 человек расходуется к полудню — значит, кто-то заводит десять RDP одноразовых. Настроенная квота режет лишние запуски и убирает выброс «нет свободных лицензий».
Маленький чек-лист «на ладони»
– Пароль проверен?
– Пользователь не заблокирован?
– Служба RAS зелёная?
– Сервер SQL отвечает?
– Лицензий хватает?
– Версия платформы совпадает?
Обычно ответ «нет» встречается ровно один раз, и пазл сразу складывается.
Завершаем без пафоса
Каждый «не удаётся войти» звучит одинаково, но лечится по-разному. Чем быстрее найдём слой, тем меньше денег осядет в паузе бизнеса. Если у вас есть свой «невидимый» сценарий, о котором здесь не упомянул — поделитесь, интересно, на чём ещё спотыкается ежедневная рутина.
