Устранение неполадок

Каждый случай разобран по одному образцу: как проверить по журналу, в чём причина, что делать. Журнал – единственный источник, по которому видно, что решила служба; он лежит в %ProgramData%\LaPorta USB\logs, разбор полей – в journal-reference.md.

Путь к политике не задан

Как проверить. Событие service_started с версией политики 0 и рядом policy_unavailable с текстом «Путь к политике не задан: программа установлена без параметра POLICYPATH». В реестре HKLM\SOFTWARE\LaPortaUsb\PolicyPath стоит заглушка \\server\laportausb$\policy.json.

Причина. POLICYPATH при установке не передали. Нынешний пакет первую установку без него не пропускает ни в окне, ни тихо – отказ виден в журнале установки (/l*v) и в журнале событий. Заглушка остаётся от прежнего пакета, где тихая установка (/qn) проходила без параметра, или от установки руками мимо установщика.

По заглушке служба в сеть не ходит – это не адрес, а признак незаданного пути – и уходит в запасной режим: политика недоступна – разрешено всё. Программу ставили ради запрета, а машина осталась без единого запрета.

Что делать. Задать путь заново при восстановлении пакета и перезапустить службу:

msiexec /i LaPortaUsb.msi POLICYPATH="C:\ProgramData\LaPortaUsb\policy.json" REINSTALL=ALL REINSTALLMODE=amus /qn

Проверить, что в журнале появилось policy_reloaded с ненулевой версией.

Политика недоступна

Как проверить. Событие policy_unavailable; в поле message – текст отказа («Файл не найден: …»). Оно пишется один раз при входе в это состояние, а не на каждом цикле опроса, поэтому смотреть надо не последнюю строку журнала, а первую после запуска. Дальше – на версию политики в service_started и на поле policy_version у событий attach.

Причина и что делать – по тому, что видно рядом:

Проверить доступность файла из-под системной учётной записи, а не из-под своей: служба работает под ней, и права на шару у неё другие. Убедиться, что путь в реестре указывает туда, куда нужно.

Не проверено: поведение на настоящей сетевой шаре. В приёмке недоступность сводилась к отсутствию локального файла; SMB отвечает иначе – таймаутами, способными подвесить чтение политики на десятки секунд.

Запрет не применился

Как проверить. Событие apply_failed, а у соседнего attach – applied: false и enforcement_failed: true. В поле message – стадия отказа и код, который вернула система. Подробности Windows пишет в свой журнал; там же, событием 225, названы по имени процесс и командная строка того, кто держит том.

Код 5 – том занят. Кто-то удерживает открытый файл на носителе: сторонний процесс, проводник, антивирус или индексатор. Пока дескриптор держат, носитель остаётся полностью доступен.

Что делать: ничего. Служба возвращается к носителю на каждом тике рабочего цикла и применит решение, как только том освободится, – в журнале появится enforced. Журнал при этом не засоряется: отказ пишется один раз и успех один раз, сколько бы попыток ни было между ними.

Если ждать нельзя – закрыть держателя (его имя есть в журнале Windows) или перезапустить службу.

«Только чтение» на занятом томе. Здесь отказ заметнее, чем у запрета. Признак «только чтение» на диск ставится, но файловая система узнаёт о нём только при перемонтировании тома, а занятый том не перемонтируется: запись на носитель идёт, хотя политика говорит «только чтение». Так ведут себя загрузочные флешки и носители с открытыми файлами на NTFS; на свободном томе режим работает полностью. Служба пишет apply_failed с томом и кодом, пользователь видит уведомление «только чтение не включилось» с просьбой закрыть файлы и переподключить носитель. При переподключении признак встаёт раньше, чем кто-либо успевает открыть файл.

Если носитель держит сама система (загрузочная флешка), том не освободится, пока носитель в разъёме: там, где запись недопустима совсем, нужен запрет, а не «только чтение».

Код 13 – отказ установщика классов. Возникал на носителях с несколькими томами: каждая попытка начиналась с размонтирования и сама создавала условие, из-за которого отказывал следующий за ней вызов. Исправлено – повторяется отключение узла, а не вся последовательность целиком.

Что делать: если код 13 виден в журнале, версия программы старше исправления. Обновить.

Одна запись на много подключений

Как проверить. Искать события attach_blocked – по одному на каждое подключение уже заблокированного носителя. Класс в них unknown, полей решения нет, серийный номер на месте.

Причина. Узел диска у заблокированного носителя остаётся отключённым и при переподключении в системе не появляется – уведомления нет, и служба о повторной вставке не узнаёт. Заблокированную флешку можно было втыкать сколько угодно, и в журнале оставалась одна запись. Закрыто подпиской на USB-узел устройства: он поднимается даже тогда, когда дочерний узел диска отключён.

Решение по такому носителю не пересчитывается намеренно: у неработающего узла не прочитать ни томов, ни сменности, а без неё флешку от внешнего диска не отличить. Отсюда класс unknown.

Что делать. Если событий attach_blocked нет вовсе, а носитель заведомо приносили – версия программы старше исправления, обновить.

Отдельный случай – носитель, вставленный до запуска службы. Уведомление о подключении система рассылает только в момент подключения. Носитель, стоявший в разъёме при старте машины, раньше оставался доступен и в журнал не попадал – готовый обход контроля через выключение машины. Закрыто осмотром подключённых носителей при запуске службы.

Строгий режим

Превентивный слой правит ветку ограничений установки устройств (HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions) и не даёт неизвестному носителю установиться вовсе. Устройство слоя разобрано в overview.md.

Носитель перестал устанавливаться.

Как проверить: искать носитель в ветке AllowInstanceIDs. В журнале службы записи о нём не будет вовсе – Windows не дала устройству установиться, и служба о попытке не узнала. Этим случай отличается от запрета реактивным слоем, где запись attach с decision: block есть всегда.

Причина: носитель выпал из белого списка по сроку хранения журнала (retention_days) либо не регистрировался вовсе – не был подключён при выключенном strict_mode ни разу. Выпадение по сроку следует из того, как строится список: служба берёт из журнала носителей за окно retention_days, и носитель, чьи записи в него не попадают, в списке не участвует. Не проверено – на приёмке истечение срока не воспроизводили ни на живой машине, ни тестом.

Что делать: если носитель просто долго не подключали – увеличить retention_days. Если он не регистрировался никогда – выключить strict_mode, подключить носитель, дождаться в журнале решения allow по нему, и только потом включить режим снова.

Превентивный запрет не включился.

Как проверить: искать в журнале событие strict_mode_conflict; проверить, не стоит ли strict_mode в политике в паре с enforcement_mode: audit; проверить, снялась ли предохранительная копия ветки перед первой правкой – есть ли файл в каталоге %ProgramData%\LaPorta USB\registry-backup.

Причина, если в журнале strict_mode_conflict: ветка занята не программой. Либо она была занятой уже при первом обращении – в неё пишут доменная политика и средства защиты, причём под теми же именами значений, что использует программа, – либо ветка была своей, но её содержимое разошлось с записью о последней правке программы (файл restrictions-applied.json в том же каталоге) или записи нет вовсе. Такую ветку служба не трогает и остаётся на одном реактивном слое.

Ещё две причины в журнал программы не пишут ничего. Пара strict_mode с audit не включает превентивный запрет никогда: режим наблюдения ничего не ограничивает. Не снявшаяся копия ветки останавливает слой раньше, чем он дошёл бы до самой ветки, и видно это только в журнале приложений Windows.

Что делать: при занятой ветке – найти её источник (доменную политику, антивирус) и решать вопрос там, программа её не трогает. При паре с audit – перевести enforcement_mode в enforce. При не снявшейся копии – проверить права службы на каталог %ProgramData%\LaPorta USB\registry-backup и перезапустить службу.

Если содержимое разошлось с записью, а чужого в ветке заведомо нет – в журнале приложений Windows перед конфликтом стоит ошибка записи применённых ограничений, отметка об обновлении программы либо служба перед этим завершилась аварийно, не дойдя до отметки о штатной остановке (снятие ограничений прервалось на середине), – выключите strict_mode и дождитесь согласования: служба снимет содержимое как своё и заведёт запись заново. После этого режим включается обратно.

Где смотреть подробности. Что именно решил превентивный слой – сколько экземпляров разрешено, не отказала ли копия ветки, – служба пишет в журнал приложений Windows («Просмотр событий» → «Журналы Windows» → «Приложение», источник LaPortaUsb). В журнал программы попадает только strict_mode_conflict: остальное о ветке не относится к носителям и в аудит по устройствам не входит.

Машина не принимает накопители, а программы нет.

Как проверить: программа удалена или служба остановлена не штатно (например, машину выключили посреди работы, а не остановили службу или не удалили программу штатно), а ветка ограничений всё ещё на месте.

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

Что делать: вернуть копию ветки командой reg import – файл лежит в %ProgramData%\LaPorta USB\registry-backup, имя вида restrictions-<время>.reg:

reg import "%ProgramData%\LaPorta USB\registry-backup\restrictions-<время>.reg"

Файл копии не удалять. По его наличию служба узнаёт, что ветку правила она сама, а не доменная политика. Без него служба сочтёт ветку чужой и не снимет ограничения даже при штатной остановке – снимать их придётся вручную, как описано ниже.

Если до первой правки ветки не было вовсе, копия – это файл-заметка с комментарием, а не выгрузка: reg import для неё отвечает «операция успешно завершена», но ничего не делает и ветку не удаляет. В этом случае ветку нужно удалить вручную:

reg delete "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions" /f

После снятия ограничений любым из способов узел носителя, которому раньше отказали в установке, сам не оживает – pnputil /scan-devices не помогает. Узел нужно переустановить полностью:

pnputil /remove-device <идентификатор>
pnputil /scan-devices

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

Проверка обновлений не проходит

Как проверить. Открыть окно администратора, «Справка» – «Обновления…»: окно спрашивает сайт при открытии и показывает причину отказа целиком. То же самое видно в журнале приложений Windows под источником LaPortaUsb – туда служба пишет неудачные проверки. В журнале носителей их нет намеренно: машина без выхода в сеть засыпала бы его одинаковыми записями.

Причина и что делать – по тому, что написано в окне:

Служба проверяет обновления раз в сутки, а после неудачи – через час. Машина, которую включили десять минут назад, о новом выпуске может ещё не знать: первая проверка после запуска службы идёт через час. Окно администратора спрашивает сайт сразу и ждать не заставляет.

Не проверено: прокси с обязательной проверкой подлинности. На приёмке проверка шла с прямым выходом наружу; поведение с NTLM-прокси, пускающим учётную запись машины, на живом парке не проверялось.

Запрет рядом с антивирусом

Как проверить. По журналу службы. Если носитель не работает, а у события attach стоит decision: block и applied: true – запрет наш. Если decision: allow либо applied: false, а носитель всё равно недоступен, – запрет чужой, и искать его надо в средстве защиты.

Причина. У Kaspersky Endpoint Security есть собственный контроль устройств, который запрещает носители независимо от нашей политики. Два запрета не мешают друг другу, но внешне неразличимы: носитель просто не открывается.

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

Не проверено: в журнал Windows попадает лишь часть событий антивируса, остальное лежит в его собственной базе и читается только из его окна отчётов. Та часть не проверялась.

Токен

Как проверить. Событие attach с class: token, decision: allow, reason: token_never_enforced, applied: false.

Причина, если такого события нет. Токен не дошёл до службы. Устройство попадает в неё через интерфейсы диска, тома, смарт-карт-ридера и переносимых устройств либо через осмотр дисков при запуске. Токен с фирменным драйвером, не заводящий интерфейса смарт-карт-ридера, до классификатора не дойдёт вовсе – и перечень известных изготовителей токенов этого не исправит, он проверяется уже в классификаторе.

Что делать. Если токен перестал работать, а событие с классом token в журнале есть и в нём applied: false – программа его не трогала: узел устройства не менялся, в учёт отключённых узлов токен не попадал. Причину искать в другом месте.

Токены не блокируются никогда и политикой не настраиваются: класс token в defaults задавать запрещено.

Проверена одна модель, поднимающаяся штатным CCID-ридером. Каждую модель, которая используется в организации, нужно проверять отдельно – «какой-нибудь токен» за проверку не считается.

Мелочь, которая мешает разбору. Серийного номера у события токена нет (serial_trusted: false), а instance_id построен по номеру порта, а не по устройству: два одинаковых токена в журнале не различить, и тот же токен в другом разъёме даст другой идентификатор. На запрет это не влияет, но восстановить по журналу, кто каким токеном пользовался, нельзя. Поле vendor при этом показывает изготовителя драйвера, а не токена.