WindowsITPro - winitpro.ru

⌨️Встроенный в Windows компонент Keyboard Filter позволяет администратору запретить использование определенных сочетаний клавиш. Это может пригодиться на киосках, операторских рабочих станциях, терминалах и других компьютерах с ограниченным пользовательским интерфейсом. Например, можно заблокировать как стандартные сочетаний Alt+Tab, Alt+F4, Ctrl+Alt+Del, Ctrl+Shift+Esc, Ctrl+C/Ctrl+V , так и произвольные комбинации клавиш или отдельные символы. Компонент устанавливается командой: Enable-WindowsOptionalFeature -Online -FeatureName Client-KeyboardFilter В ветке реестра HKLM\SOFTWARE\Microsoft\Windows Embedded\KeyboardFilter уже есть список предопределенных (стандартных) сочетаний клавиш Windows. Чтобы заблокировать одно из них, достаточно изменить значение соответствующего параметра на Blocked. Например, чтобы запретить Alt+F4: reg add "HKLM\SOFTWARE\Microsoft\Windows Embedded\KeyboardFilter" /v "Alt+F4" /t REG_SZ /d "Blocked" /f Произвольное сочетание можно добавить в CustomFilters: reg add "HKLM\SOFTWARE\Microsoft\Windows Embedded\KeyboardFilter\CustomFilters" /v "Ctrl+C" /t REG_SZ /d "Blocked" /f Отдельную клавишу можно заблокировать по ее сканкоду. Например, левую клавишу Win: reg add "HKLM\SOFTWARE\Microsoft\Windows Embedded\KeyboardFilter\CustomScancodes" /v "E05B" /t REG_SZ /d "Blocked" /f 📚 В статье также показано, как создавать собственные фильтры для отдельных клавиш и комбинаций, блокировать клавиши по scan code и проверять активные политики через Event Viewer и PowerShell. ⚠️ Ложка дегтя - Keyboard Filter поддерживается только в редакциях Enterprise, Education, IoT Enterprise и LTSC. В RDP-сессиях фильтр не работает. Как запретить некоторые сочетания клавиш в Windows с Keyboard Filter

📝 В сложных PowerShell/BAT-скриптах помимо текстового логирования часто имеет смысл записывать ключевые события непосредственно в Windows Event Log. Собственные события Event Viewer можно использовать для мониторинга, запуска задач по триггеру в Task Scheduler или централизованного сбора журналов.    Для записи событий в Windows Event Log можно использовать встроенный PowerShell командлет Write-EventLog. 🔹 Чтобы записать простое событие в стандартный журнал Application, выполните: Write-EventLog -LogName Application -Source "Application" -EntryType Information -EventID 1001 -Message "DB backup script completed successfully"   🔹 Можно создать отдельный кастомный источник для более удобной фильтрации событий по источнику: New-EventLog -LogName Application -Source "MyScript" Записать информационное событие в журнал Application с собственным источником: Write-EventLog -LogName Application -Source "MyScript" -EntryType Information –EventID 1 –Message "Запущен PowerShell cкрипт опроса состояния сервера " Событие будет добавлено в журнал. 🔹 Либо можно создать отдельный EVTX журнал для ваших событий: New-EventLog -LogName CustomPSLog -Source PS1Script ✅ В BAT скриптах для отправки событий в журнал Event Viewer используется команда eventcreate: eventcreate /t information /l application /id 1 /d "BAT script started" Запись событий в журнал Event Viewer из PowerShell/CMD

🤷 Права доступа в Битрикс24 часто настраивают по ходу дела: одному сотруднику дали лишнее, другому закрыли нужное, а руководитель видит не те данные.  В итоге страдают безопасность, процессы и контроль над коммерческой информацией. 🔗 10 августа в 19:00 МСК приглашаем вас на открытый урок, где разберём, как выстроить организационную структуру, группы пользователей и ролевую модель прав в CRM. На практическом примере покажем: ➖ как создавать роли; ➖ задавать доступ к лидам, сделкам, контактам и отдельным стадиям воронки; ➖ также проверять пересечение прав, если сотрудник входит в несколько групп. Открытый урок проходит в преддверии старта курса «Интегратор Битрикс24». ➡️ Зарегистрируйтесь, чтобы научиться настраивать доступ точно: только к тем данным и действиям, которые действительно нужны для работы:  https://otus.pw/3HAK/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

⚠️ После июльского Patch Tuesday многие администраторы начали массово жаловаться на многократное увеличение времени синхронизации WSUS, ошибки таймаута и рост нагрузки на IIS.  Причина: ошибочная публикация Microsoft большого количества тестовых Detectoid-объектов в каталоге WSUS. Из-за резкого увеличения объема метаданных существенно выросло время синхронизации и обработки каталога обновлений. На клиентах Windows Update могут появляться ошибки 0x80244010 (WU_E_PT_EXCEEDED_MAX_SERVER_TRIPS), 0x80244022, 0x80072EE2, HTTP 503 и другие проблемы при поиске обновлений.   ⚙️ Microsoft уже устранила проблему на стороне серверов обновлений, поэтому новые WSUS-серверы ей не подвержены. Однако существующие серверы, успевшие синхронизировать ошибочные метаданные, необходимо очистить вручную. Подробно шаги исправления описаны в статье базы знаний KB5121986 ✅ Краткий порядок действий: 1️⃣ Подключаемся к базе SUSDB через  SQL Server Management Studio 2️⃣ Делаем бэкап базы данных WSUS 3️⃣ Снимаем ограничение на MaxXMLPerRequest: UPDATE tbConfigurationC SET MaxXMLPerRequest = 0;  (убирает 5 Мб лимит на размер XML данных, которые клиент может получить от сервера обновлений за один запрос) 4️⃣ Выполнить опубликованный SQL-скрипт для удаления ошибочно опубликованных Detectoid-объектов (полный скрипт приведен в статье KB5121986). 5️⃣ Вернуть исходное значение MaxXMLPerRequest: UPDATE tbConfigurationC SET MaxXMLPerRequest = 5242880; 6️⃣ Перезапустить пул WsusPool или IIS IISReset 7️⃣ При необходимости выполнить переиндексацию SUSDB и запуск WSUS Server Cleanup Wizard.    Процедуру рекомендуется выполнить на всех WSUS-серверах инфраструктуры, включая upstream/downstream-серверы и реплики, которые успели получить проблемные метаданные.

⚡️ Каналы для вашего развития в IT и DevOps Рекомендуем качественный контент знакомого ИТ-сообщества с 15-летним стажем: ⚪️ ITKB_channel (в MAX 📲 IT-KB) — бесплатное обучение по Windows, Linux, DevOps, Security, Network, программированию. ⚪️ ITKB_Archive — цифровая библиотека (книги, курсы, ИТ литература по Windows, Linux, сети, программирование, Project, DevOps)

📚 В групповых политиках Windows есть раздел для централизованной установки приложений на компьютеры пользователей Computer/User Configuration -> Policies -> Software Settings -> Software installation. Однако пользуются этой фичей редко, т.к. она умеет работать только с приложениями, упакованными в MSI установщики, а если вам нужно задать определенные параметры установки пакета, придется пилить свой файл трансформации MST для MSI пакета. ❓ Однако мало кто помнит, что кроме MSI формата инсталляторов, через групповые политики Windows можно устанавливать произвольные EXE приложения. Для этого достаточно создать текстовый конфигурационный файл с расширением ZAP (Zero Administration Package, пакет нулевого администрирования), в котором указать команду запуска установки приложения из EXE файла. По сути, ZAP файлы имеют структуру INI файла. 1️⃣ Например, для установки клиента Obsidian, создадим такой ZAP файл:  [Application] FriendlyName = "Obsidian - Notes and knowledge-base editior for Markdown files" SetupCommand = "\\s-fs01\Install\Obsidian-1.13.4.exe" /S DisplayVersion = 1.13.4 Publisher = "Dynalist"   2️⃣ Здесь указано, в какой сетевой папке хранится установщик приложения и с какими параметрами его нужно установить. В данном случае опция /S указывает, что нужно выполнить установку программы в "тихом" режиме без вывода графического интерфейса. 3️⃣ Затем путь к ZAP файлу указывается в GPO и назначается на OU с пользователями. 4️⃣ Пользователи в классической панели управления (control appwiz.cpl,,1) увидят это приложение, как доступное для установки из сети (Install a program from the network) и могут запустить его установку в любой момент. В новую панель Параметры этот пункт не перенесли, видимо считая ZAP файлы древним legacy (хотя, наверное, так и есть🤷‍♂️).   Важный нюанс – установка запускается с правами текущего пользователя, и если приложение потребует прав администратора, то появится запрос повышения привилегий UAC. Таким образом этот способ установки преимущественно подходит для приложения, который ставятся в профиль пользователя (AppData) и не требуют прав администратора (таких сейчас много на самом деле). В общем, довольно интересный и простой способ создать такой себе список установки приложения “по требованию”, когда любой пользователь может выбрать из коллекции опубликованных программ и установить себе нужные.  👌   ✅ Установка программ (MSI и EXE) с помощью групповых политик в домене Active Directory

🍺 Сегодня последняя пятница июля, а это значит, с днем Системного Администратора, дорогие друзья и коллеги😎! ✅ Всех причастных с праздником! 🎉 Тех, кто легко может починить то, что не ломал сам, чье любимое правило “Работает? Не трогай!”, кто сначала читает документацию и только потом щелкает далее-далее, тех из чьих нервов можно плести канаты,.   Пусть баги обходят Вас стороной, дашборды мониторинга остаются зелёными, пользователи - благодарными, а терпение и кофе в кружке- бесконечными☕️ Сисадмин это состояние души! 👨🏻‍💻

⚙️ Кстати, для упрощения миграции Windows машин в Proxmox (как для P2V, так и для V2V сценариев) нашел полезный PowerShell скрипт, который нужно запускать на исходной машине перед миграцией: https://github.com/croit/load-virtio-scsi-on-boot Скрипт подготавливает Windows к миграции в среды KVM/Proxmox без необходимости лишних перезагрузок и предотвращения BSOD INACCESSIBLE_BOOT_DEVICE при попытке загрузить систему с диска на нативном контроллере VirtIO SCSI: powershell.exe -ExecutionPolicy Bypass -File .\Downloads\load-virtio-scsi-on-boot.ps1   ⚠️ Как это работает: Скрипт через Win32 API создает временное программное (фантомное) устройство и затем pnputil ставит для него дрйвер из INF-файла. Windows связывает драйвер с железом, разворачивает службы в реестре и переводит тип запуска драйвера в Boot Start. Поддерживаются как VirtIO SCSI (vioscsi), так и VirtIO Block (viostor). ✅ В результате на этапе миграции отпадают лишние танцы с бубном вроде временного подключения диска через IDE/SATA контроллер или создания мусорных SCSI-дисков для подкладывания драйверов.    О миграции Windows хостов в гипервизор Proxmox

📦 В WIM образе среды WinPE содержаться только базовые универсальные драйвера, необходимые для корректного обнаружения основного оборудования компьютера. Поэтому случается, что установщик Windows, загрузочный диск на базе WinPE или среда восстановления WinRE не видят локальных дисков или сетевые адаптеры. ⚠️ В моем примере после миграции виртуальной машины с ESXi на Proxmox, оказалось что в гостевой Windows отсутствуют драйвера VirtIO. В результате при загрузке гостевой Windows в ВМ появилась ошибка 0x0000007B: INACESSIBLE_BOOT_DEVICE. Для предотвращения таких ситуаций нужно устанавливать драйвера VirtIO в гостевую Windows до начала миграции ВМ. ✅ Либо можно динамически загрузить нужные драйвера прямо в среде WinPE. Для этого нужно смонтировать образ с драйверами VirtIO и установить драйвер SCSI адаптера с помощью команды drvload: drvload d:\vioscsi\2k22\amd65\vioscsi.inf Проверьте, что драйвер SCSIAdapter VirtIO загружен в память среды WinPE: pnputil /enum-drivers После того, как стал доступен локальный диск с установленной Windows, можно добавить драйвер паравиртуализированного контроллера SCSI в офлайн Windows образ на диске: DISM /Image:C:\ /Add-Driver: /driver:D:\vioscsi\2k22\amd64\vioscsi.inf Загрузка драйверов из командной строки в среде WinPE

🕐 При запуске ресурсоемких заданий через Task Scheduler можно заметить, что процесс, запущенный планировщиком, выполняется значительно медленнее, чем при ручном запуске. В моем случае на одном из довольно загруженных серверов задание резервного копирования с помощью robocopy не успевало завершиться за ночь при запуске через планировщик, тогда как при ручном запуске выполнялось всего за пару часов. Причина в том, по умолчанию задания планировщика Windows создаются с приоритетом 7 (Below Normal). Поэтому процессы, запускаемые планировщиком, получают меньше процессорного времени, чем процессы с обычным приоритетом. На нагруженных серверах это может существенно увеличить время выполнения ресурсоемких задач. ⚙️ Традиционный способ изменения приоритета задания планировщика, который работает во всех версиях Windows, - экспорт, ручное редактирование и импорт XML файла с настройками задания. Задание экспортирует в XML файл, который нужно открыть в редакторе и увеличив значение Priority с 7 (значение по умолчанию для всех заданий Task Scheduler) до 5 (Above Normal) или 6 (Normal). После этого исходное задание нужно удалить и импортировать из XML файла уже с новыми настройками. Однако, если кто-то в дальнейшем изменит настройки этого задания из графической консоли taskschd.msc, приоритет задания будет сброшен на исходный (7). ✅ Поэтому для изменения приоритета заданий в планировщике лучше использовать PowerShell командлеты из встроенного модуля ScheduledTasks. Вывести текущий приоритет задания $myTaskName=”py_Task_InspectResult” (Get-ScheduledTask -TaskName $myTaskName).Settings.Priority Увеличить приоритет: Set-ScheduledTask -TaskName $myTaskName -Settings (New-ScheduledTaskSettingsSet -Priority 5) Управление приоритетом задач в планировщике заданий Windows

🛠 Классический “трюк” для сброса пароля локального администратора и восстановления административных прав в системе, если утрачен или успешно забыт пароль локального администратора в Windows.   1️⃣ Загружаем компьютер в среде восстановления WinRE или с любой установочной флешки с Windows 2️⃣ Открываем командную строку (Shift+F10) 3️⃣ С помощью diskpart выясняем букву диска, назначенную разделу, на котором установлена Windows 4️⃣ Создаем копию системного файла utilman.exe: copy C:\windows\system32\utilman.exe C:\windows\system32\utilman.exebak Затем заменяем исполняемый файл utilman.exe на cmd.exe: copy c:\windows\system32\cmd.exe c:\windows\system32\utilman.exe /y 5️⃣ Перезагрузка компьютера: wpeutil reboot 6️⃣ На экране входа в Windows жмем на иконку специальных возможностей в правом нижнем углу 7️⃣ Прямо на экране входа в систему откроется окно командной строки, запущенной с правами NT Authority\SYSTEM. 8️⃣ Из этой командной строки можно сбросить пароль любого локального пользователя: net user localadm * Включить аккаунт, если он был ранее отключен: net user localadm /active:yes Или создать нового пользователя с правами администратора: net user newuser1 /add * net localgroup Administrators newuser1 /add В русской версии Windows имя группы нужно заменить на Администраторы.   9️⃣ После того, как пароль пользователя сброшен, проверьте что можете войти под ним, после чего еще раз загрузитесь с внешнего носителя и замените файл utilman.exe на исходный:  copy c:\windows\system32\utilman.exebak c:\windows\system32\utilman.exe /y    ✅ В общем, простой сценарий для запуска командной строки с привилегированными правами прямо на экране входа в Windows (без аутентификации), не требующий сторонних программ и утилит. Позволяет как сбросить пароль любого пользователя, добавить его в локальную группу администраторов, создать нового администратора или устранить другие причины, которые препятствуют входу в Windows (например, сбросить настройки GPO, отключить/удалить службу или программу и т.д.).   Сброс пароля локального администратора в Windows

⚙️ После массового обновления сертификатов Secure Boot Windows UEFI CA 2023 начали встречаться неожиданные проблемы. ⚠️ На некоторых моделях ноутбуков после разряда батареи CMOS (сезон отпусков 🤷), сброса настроек или обновления прошивки UEFI, Windows перестает загружаться с ошибкой: Secure Boot Violation Invalid Signature Detected. Check Secure Boot Policy in Setup. Проблема возникает из-за того, что новый загрузчик Windows подписан сертификатом Windows UEFI CA 2023, а сам сертификат отсутствует в базе Secure Boot (db) прошивки UEFI после сброса. 📚 В статье мы рассмотрели как продиагностировать и решить проблему: 🔹 Как проверить наличие сертификатов Windows UEFI CA 2023 🔹 Каким сертификатом подписан файл загрузчика в Windows (bootmgfw.efi) 🔹 Для исправления проблемы воспользуемся встроенным официальным инструментом Microsoft Secure Boot Recovery (файл SecureBootRecovery.efi), позволяющим в офлайн режиме установить новые сертификаты Windows UEFI CA 2023 в db в NVRAM материнской платы. 🔹 Покажем, как подготовить загрузочную USB флешку c SecureBootRecovery.efi),  для офлайн обновления сертификатов в UEFI https://winitpro.ru/index.php/2026/07/22/oshibka-invalid-signature-detected-check-secure-boot-policy/

🕐 Синхронизация времени домена Active Directory с внешним NTP сервером точного времени В Active Directory используется строгая иерархическая схема синхронизации времени: 🔹PDC-эмулятор (в корневом домене) является основным источником времени домена 🔹Остальные DC получают время от PDC-эмулятора 🔹Рядовые рабочие станции и сервера берут время у ближайшего контроллера домена ⚙️По умолчанию PDC синхронизирует время с аппаратными часами физического сервера (или гипервизора, если DC запущен на ВМ). Соответственно, если время на аппаратных часах неточное, это может вызвать проблемы при взаимодействии со внешними системами. Поэтому нужно обязательно настроить синхронизацию времени на PDC с внешним надежным источников времени (NTP) и отключить синхронизацию с локальными часами/гипервизором. ✅В этой статье мы рассмотрели, как правильно настроить синхронизацию времени в домене, и что делать если что-то работает некорректно. Настройка синхронизации времени в домене Active Directory

Как обнаружить атаку на Active Directory, когда в логах всё чисто? В реальной инфраструктуре атакующий не оставляет очевидных следов. Чтобы его найти, нужно сначала самому пройти путь атаки — от первого доступа до захвата домена. На курсе Codeby по анализу защищённости AD вы отрабатываете всё на практике: 30+ виртуальных машин, которые вам предстоит скомпрометировать и в них закрепиться. Внутри: ⏺️AD-сети на миксе Windows/Linux ⏺️Поиск слабых конфигураций, добыча критичных данных, продвижение по инфраструктуре ⏺️Захват и укрепление позиций в домене ⏺️Разбор и применение популярных эксплойтов Авторы курса: HackerRalf (Михаил Порываев) и BlackRabbit (Павел Никитин), 5-кратные победители The Standoff. При оплате курса сразу дарим скидку -30%. Доступна поэтапная оплата. 🎇Дарим доступ к 20+ заданиям на взлом AD на hackerlab.pro при записи на курс! Старт курса 7 cентября ➡️Программа курса

📚 До Windows Server 2016 для автоматического запуска приложений при входе на RDS можно было указать путь к исполняемому файлу в свойствах учетной записи пользователя (доменного или локального) на вкладке Среда. Когда пользователь закрывает окно назначенной программы в RDP сессии, терминальный сервер автоматически завершал сеанс пользователя. В более новых версиях Windows Server это поведение по умолчанию не работает и назначенное приложение игнорируется, вместо него всегда открывается полноценный рабочий стол. Вместо ранее используемого подхода Microsoft предлагает публиковать приложения в виде RemoteApp или назначать приложение, запускаемое при входе в сеанс через GPO. ⚙️ Можно вернуть поведение диспетчера удаленных подключений RDS к тому, как оно работало в Windows Server 2008 R2 и 2012/2012 R2. Для этого нужно создать параметр реестра fQueryUserConfigFromDC со значением 1: reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fQueryUserConfigFromDC /t REG_DWORD /d 1 reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v fQueryUserConfigFromDC /t REG_DWORD /d 1 После этого терминальный сервер снова начнет опрашивать конфигурацию пользователя при входе. Для применения изменений может потребоваться перезагрузка сервера. Автозапуск приложения при RDP входе на терминальный сервер Windows