💾 Об окне форматирования томов в Windows

На этой неделе все профильные и даже непрофильные каналы потешаются над Microsoft - мол, за 30 лет так и не обновили древний диалог 🤡

Отдельно доставило глумление над UX, который в этом окне абсолютно нормальный для классического Win32. Попадались даже придирки к непоследовательности двоеточий в названиях элементов. Да, техническим писателям или инженерам QA это бросается в глаза. Но предъявлять за такое махровому легаси... 🙄

Ноги у веселья растут из твита Дэйва Пламмера, бывшего разработчика Windows, который когда-то этот диалог и написал на коленке. Сейчас он на пенсии развлекает публику такими вот историями.

👉 При этом петросяны массово не в курсе, что диалог уже обновили! Вот же он на картинке↓ - с тёмной темой и масштабированием. Даже опция сжатия тома появилась. И с двоеточиями нет проблем.

Управление дисками начали добавлять в Параметры еще летом 2020 года, в сборке Windows 10 20197. Фичу долго мариновали в предварительных версиях, и в Windows 10 она уже не попала. Однако точный момент появления в Windows 11 трудно определить.

Разумеется, никто не будет вносить изменения в древний диалог. Ну, поправит вам разработчик двоеточия, сделает юнит-тест. А регрессионного тестирования-то нет. И вот уже ничего не форматируется 🤔

И убирать старое окно не стали намеренно. Потому что привычка вызывать его из контекстного меню диска у многих выработана годами. Можно автоматически перекидывать в Параметры, но в данном сценарии UX лучше не станет. А если еще и новый диалог сразу не открыть, пользователь точно отложит кирпич 🧱

Поэтому никуда не денется и оснастка управления дисками, не говоря уже о diskpart. Microsoft много за что можно предъявить. Но компания точно впереди планеты всей по длительности поддержки старых функций и хранения в системе разнообразного легаси. Да, выглядит оно несовременно и не масштабируется. Зато лежит под рукой и работает ✌️

📉 О производительности оболочки Windows

К сожалению, в Windows 11 обертка проводника получилась тормозной. И новые контекстные меню тому лучшее свидетельство. Они открываются с заметной задержкой, а пункты некоторых приложений иногда даже не отображаются с первого раза 🤦‍♂️

С видимыми лагами сопряжен и прямой вызов старого меню, в том числе из сторонних файловых менеджеров. При этом в моих замерах классика появляется примерно на треть быстрее нового меню 👈

Хотя с первого выпуска Windows 11 прошло уже больше двух лет, существенных улучшений в производительности не наблюдается. Прикручивание к проводнику бессмысленных вкладок только усугубило ситуацию. И окончательно подвигло меня к возврату на 💾Total Commander после многолетнего перерыва.

🙄 Однако команда оболочки Windows делает вид, что проблемы нет, и такие тормоза — нормально!

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

Исключение шести программ из меню ускорило его открытие в проводнике примерно в три раза❗️ У классического меню, вызываемого из Total Commander, разница была не столь драматичная, но все равно без программ оно открывалось на 23% быстрее.

Я тестировал MP3-файлы вне сферы облачного диска OneDrive. Конкретно с этим типом файлов были связаны две программы из шести. Остальные четыре были сопоставлены с любыми файлами.

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

Отдельно доставляет, как значки команд подгружаются уже после отображения всех пунктов меню. В ролике↓ скорость воспроизведения сначала 100%, а потом замедлена до 30%, чтобы получше рассмотреть происходящее. Первый вызов меню всегда неприемлемо тормозной, даже если несколькими минутами ранее я уже открывал его в том же окне.

📊 Недавний опрос читателей показал, что как минимум 6 из 10 человек не устраивает скорость открытия меню и/или лишние пункты в нем. Скоро я опубликую в блоге статью с подробными инструкциями по зачистке от ненужных программ контекстного меню в Windows 11 и 10. Там будет скучный ручной метод и быстрый скрипт для тех, кто не боится консоли.

Но в любом случае полная очистка контекстного меню ради ускорения не имеет смысла. Многие программы там нужны, их выпиливание лишь замедлит выполнение пользовательских задач. Проблему должны решать разработчики Windows! ✌️

⚙️ Новое в блоге: Edge - быстрая настройка браузера и отключение раздражителей скриптом

Microsoft Edge — мой основной браузер, и в целом он меня устраивает. При этом есть набор параметров, которые я всегда изменяю на своих многочисленных системах, в том числе экспериментальных ВМ.

👉 Я предпочитаю групповые политики Edge по ряду причин:

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

Я неоднократно публиковал в канале отдельные политики в виде команд reg add. Сегодня я делюсь полным скриптом #PowerShell для быстрой настройки Edge 🎉

На картинке вид новой вкладки при первом запуске браузера (или нового профиля) после применения скрипта.

➡️ Читайте в блоге: https://www.outsidethebox.ms/22326/

▶️ Простой пример оптимизации скрипта #PowerShell с помощью хэш-таблицы

Первые два отзыва на мой скрипт для настройки браузера Edge с помощью политик были критические. Мне попеняли на его перегруженность множеством вот таких↓ однотипных команд. Действительно, в них отличаются только названия параметров и значения, а всё остальное неизменно.

New-ItemProperty -Path $path -Name HideFirstRunExperience -Type Dword -Value 1 -Force | Out-Null

Но эта история изначально была не про PowerShell, а про коллекцию политик. В скрипте же я исходил из того, что многих заинтересуют лишь некоторые твики. И такие люди будут копипастить отдельные строки прямо с веб-страницы в консоль. Я сам так неоднократно делал :)

👉 Если же не думать об этих людях и задействовать фирменные возможности PowerShell, скрипт получится намного аккуратнее и компактнее. К таким фичам относятся хэш-таблицы. Причём дальше примера из справки ходить не надо.

[hashtable]$hash = @{
HideFirstRunExperience = 1
AutoImportAtFirstRun = 4
BrowserSignin = 0
}

foreach ($key in $hash.keys) {
New-ItemProperty -Path $path -Name $key -Type Dword -Value $($hash[$key]) -Force | Out-Null
}

Хэш-таблица создается первой строкой и далее наполняется парами "параметр = значение". В реестр изменения вносятся с помощью выражения foreach - перебором всех пар.

Все прочие аспекты скрипта неизменны. Я добавил в архив версию с хэш-таблицей ✌️

🤦‍♂️ Ловушка MBR для продуктовой группы Microsoft

Сегодня в рубрике "Возвращаясь к напечатанному" эпичная ошибка в статье базы знаний (MSKB) KB5028997. А также на всех сайтах, которые перепечатали эту инструкцию по ручному увеличению раздела для установки обновления WinRE. Тысячи их ©

Upd. Вскорости после публикации моего поста ошибку исправили. Совпадение? Не думаю ©

⌛️ История и контекст
В январе 2024 года Microsoft выпустила обновление безопасности для среды восстановления Windows 10. Однако у многих оно не устанавливалась из-за слишком маленького раздела RE. В связи с чем компании пришлось выпустить инструкцию по его увеличению.

Тогда же я опубликовал в блоге большой FAQ, который поможет вам освежить память. Чтобы проникнуться эпичностью ошибки в MSKB, нужно понимать, зачем RE размещают на отдельном разделе:

Это необходимо для восстановления при включенном шифровании BitLocker. Если среда на разделе с ОС, в нее невозможно загрузиться с зашифрованного раздела. В этом случае для входа в Windows RE понадобится установочный диск.

🐞 Суть ошибки
О ней мне рассказал читатель блога Артём. Он следовал инструкциям в разметке MBR и обнаружил, что в итоге среда восстановления оказывается вовсе не на увеличенном разделе RE, а на разделе с Windows! Сопоставив инструкцию Microsoft с материалами моего блога, Артём вышел на причину ошибки - она в шаге 5.

На шаге 5a создается новый раздел. И, что несколько необычно, в команде создания сразу указывается GUID, задающий тип раздела (управление служебными атрибутами я подробно разбирал в блоге). Дальше на шаге 5b раздел форматируется в NTFS.

В разметке GPT форматирование раздела не затрагивает его служебный идентификатор (см. строки 84-105). Но в разметке MBR ИД 0х27 после форматирования сбрасывается. И раздел становится обычным, с ИД 0х7! 🙈 Я демонстрирую это на картинке↓

Upd. В исправленной версии статьи появился шаг 5c, которым в MBR заново задается правильный ИД.

Дальше включается среда восстановления, и образ должен оказаться на разделе Windows RE. Но поскольку правильного ИД у него нет, по алгоритму образ размещается на разделе с ОС - в папке C:\Recovery.

Разумеется, после этого злосчастное обновление RE устанавливается без проблем - ведь на разделе Windows полно места :) Но это делает бессмысленным всё мероприятие! Поскольку при таком раскладе в RE не загрузиться с зашифрованного диска.

⚙️ О важности тестирования
Я не случайно упомянул ресурсы, перепечатавшие инструкцию. Так, я ссылался на русскоязычный гайд COMSS в своем FAQ - там много картинок, всё как вы любите :)

Безымянный автор тщательно проследовал по шагам на MBR (!) и ничего не заметил. Хотя на первом и последнем скриншоте командной строки с выводом утилиты reagentc видно, что среда восстановления в итоге переехала с partition3 (RE) на partitoin2 (Windows).

Я, кстати, протестировал инструкцию Microsoft, прежде чем советовать её. Но только на GPT. С MBR у меня сейчас и виртуалок-то нет. Видимо, так же обстоят дела и у продуктовой группы, которая опубликовала инструкцию в MSKB :)

В заключение я просто оставлю здесь практические советы по переходу с MBR на GPT ✌️

⚙️ Облачная переустановка поверх в параметрах Windows 11

Осенью 2019 года в Windows появилась функция облачного сброса. Тогда я доставил ПМу, что куда полезнее была бы функция переустановки поверх, которая сохраняет программы и настройки в отличие от сброса.

По его просьбе я отправил развёрнутые аргументы в центр отзывов, и ныне удаленное предложение набрало более 100 голосов 👍 Это очень много для такой технической функции. На русском языке я озвучил тезисы в канале. Прочтите их, чтобы прочувствовать важность фичи!

🎉 И спустя 4.5 года в параметрах появилась облачная переустановка поверх!

Фичу доставили в рамках обновления Moment 5. Она описана в статье базы знаний KB5036436. Помимо прочего там:

• отмечается, что в центре обновления может появиться предложение выполнить облачную переустановку в случае неудачной установки исправлений
• приводится список условий и групповых политик, при наличии которых функция недоступна

🔄 Прогресс загрузки установочных файлов и ход установки отображаются в центре обновления. В целом - это стандартный процесс переустановки поверх, хотя и без присущих ему экранов. Кстати, в РФ фича обретает дополнительную ценность на фоне препятствий загрузке MCT и ISO.

Но есть и ложка дегтя 🤷‍♂️ Поскольку процесс завязан на Windows Update, неподдерживаемые конфигурации блокируются. И не прокатит обходной путь AllowUpgradesWithUnsupportedTPMOrCPU, т.к. он для установки с флэшки.

Так или иначе, фича ценная, и новость отличная! #Классика блога про переустановку поверх обновлена ✌️

🔒 KeePass: автоматический ввод учетных данных в браузере по URL страницы

Я уже рассказывал в канале про годную функцию автонабора у KeePass. И как выяснилось, почти половина пользователей этого менеджера паролей о ней не знала. Там речь шла о порядке записей в результатах поиска. Сегодня - о вводе в браузерах, причем без плагинов KeePass.

На картинке↓ настройки автоматического ввода, где цифрами отмечены ключевые. Пункты 2 и 3 по сути относятся только к браузерам. Давайте разберем их на примере входа в GitHub https://github.com/login

1️⃣ В заголовке окна есть совпадение с названием записи KeePass

Здесь заголовок - Sign in to GitHub · GitHub. Поэтому сработает любое из этих слов в названии записи KeePass - например, Sign in и GitHub. Но во избежание ложных срабатываний лучше использовать что-то уникальное - строку целиком или ее существенную часть.

Это - самый удобный способ, но не лишенный недостатков. С ними я регулярно сталкиваюсь в рабочей среде. Например, заголовок страницы авторизации у разных внутренних веб-сервисов одинаковый - Sign in. Или он более информативный, но одинаковый в разных средах разработки ПО - Dev, QA, Integration.

2️⃣ В заголовке окна есть URL целиком из записи KeePass

Это - большая редкость, т.к. сайтам нет смысла прописывать адрес страницы в её заголовок. И как раз это я разберу подробнее чуть ниже.

3️⃣ В заголовке окна есть домен, который присутствует в URL из записи KeePass

Это чаще встречается у иностранных сайтов. Допустим, прописав https://www.google.com/ в поле URL, вы сможете входить на любой странице сервисов компании. Потому что слово Google есть в заголовке страницы и в поле URL. С GitHub та же история. Но у прочих сервисов Microsoft такое не сработает, равно как у Яндекс и Госуслуг.

////

В итоге пункт 2 выглядит самым бесполезным, однако он очень перспективный! Как справедливо заметил в чате dartraiden, если в KeePass корректно заполнено поле URL, задача сводятся к тому, чтобы прописать URL веб-страницы в её заголовок 👈
И она элементарно решается с помощью расширений для Chromium и Firefox.

Однако мне не нравится, что только ради этого расширение получает право читать и изменять данные на всех сайтах. Поэтому я предпочел более контролируемый вариант - скрипт для Tampermonkey 🐵 Сходу нагуглился такой. Из коробки результат страшноват, но это легко допилить. И не забыть отключить автоматическое обновление скрипта!

С браузерами разобрались, но остается проблема с однотипными окнами Sign in в других приложениях. Она, кстати, недавно обострилась у меня на работе. И я обязательно поделюсь решением в канале ✌️

⚙️ Как настроить открытие ссылок в приложении YouTube Revanced без рута и ADB

Мой друг на новом телефоне возжелал привычный YouTube с фоновым воспроизведением. С установкой клиента Revanced проблем не возникло. Однако ссылки на видео все равно открывались в официальном приложении, которое нельзя просто взять и удалить. Телефон Xiaomi с MIUI, но такое возможно и с другими оболочками.

В настройках Android есть управление ссылками, но пляски с бубном вокруг обоих клиентов YouTube ни к чему не привели. Я спросил чат - Niks быстро доставил решение. И оказалось, что именно его я применил когда-то на своем телефоне, о чем успешно забыл 🤦‍♂️ Поэтому оставлю его здесь - в своей публичной записной книжке.

⏯ Процесс показан на видео, которое надо смотреть во весь экран.

1. Установите Better Open With.
2. В разделе Browser выберите из списка сайтов YouTube и задайте приложение для открытия ссылок.

Поскольку у обоих приложений одинаковые значки, Revanced определяется экспериментально. Чтобы не путаться, можно задать разные темы оформления✌️

⚙️ Новое в блоге: Как убрать ненужные программы из контекстного меню Windows

Проводник Windows 11 получил новое контекстное меню и способы интеграции приложений в него. Поначалу в меню было пустовато. Но со временем разработчики освоились и начали добавлять туда свои программы.

Сегодня я расскажу, как убрать ненужные пункты, чтобы улучшить UX и ускорить открытие меню. И нет, старые утилиты от NirSoft вам с этим не помогут.

В этой статье:
🔹 принцип регистрации в новых меню (а заодно и в старых, т.е. в Windows 10)
🔹 ручной способ удаления ненужных программ
🔹 скрипт #PowerShell для быстрого удаления 🚀
🔹 различные нюансы

➡️ Читайте в блоге: https://www.outsidethebox.ms/22361/

❌ Об ошибках в журналах событий Windows

Помимо пристрастия к чистке реестра есть еще один тип виндовой озабоченности, хотя и менее распространенный. Это устранение ошибок из журналов событий. Читатель блога WhiteRabbit попросил в почте разобраться с некой ошибкой, но даже с двух попыток не смог объяснить, в чем конкретно проблема. В смысле, проблемой он считал сам факт наличия ошибки в журнале 🙄

Это не так работает. У журналов событий три основных применения:

🔹 Проверка работы конкретных процессов или компонентов, аудит и прочий превентивный мониторинг. Это больше свойственно организациям.

🔹 Изучение работы Windows. Выполнили какое-то действие - посмотрели, что записалось в журнал.

🔹 Устранение неполадок. Это самый распространенный сценарий. Однако здесь изначально должна быть какая-то проблема 👈 Далее вы используете журнал событий в качестве диагностического средства, чтобы выйти на причину проблемы. Примеры в канале: раз, два.

В многочисленных журналах регистрируются тысячи ошибок. В моей системе #PowerShell насчитал↓ 463 обычные и критические ошибки за последние 24 часа, треть из которых Windows провела во сне. Но многие по сути даже не являются ошибками!

Например, у меня практически каждая перезагрузка основной ОС сопровождается событием 100 с критической ошибкой. Система перезапускается в основном для установки обновлений. Поэтому длительность процесса выходит за рамки нормы. Ну и ладно, я вообще в это время сплю!

ℹ️ В базе знаний Microsoft описано немало безвредных ошибок, которые можно можно смело игнорировать. Вот некоторые примеры. Видимо, объем обращений по ним в поддержку вынудил продуктовые группы отразить это в документации.

Резюме: жизнь слишком коротка, чтобы пытаться устранить все ошибки в журналах событий Windows ✌️

🔒 Гадание по картинке: доступ из-под Linux к зашифрованному тому BitLocker

Обычно я гадаю по логам, но на сей раз участник чата Michael отправил только картинку с описанием:

UEFI, TPM2. Windows 10 21h2. При попытке читать раздел C: с Linuxа спрашивает пароль. Раздел определяется как "BitLocker". При этом винда утверждает, что битлокер для C: отключен (насколько я понял, т.к. там только надпись: "turn BitLocker on"). Что делать-то?

Я ничего не знал про поддержку BitLocker в Linux, но товарищ dartraiden сразу подтвердил ее наличие. Тогда происходящее вполне объяснимо, если поверить Linux.

А вот что там "винда утверждает" - вопрос. Поэтому я запросил состояние BitLocker:
manage-bde -status c:

Michael с ответом не спешил, но вполне можно разобраться даже по имеющейся скудной информации. Важно сочетание трех фактов:
🔹 Linux требует пароль от BitLocker.
🔹 При запуске Windows этот пароль не запрашивается. Иначе бы автор вопроса знал его наизусть, а по факту...
🔹 Он вообще ничего не знает про это шифрование.

Отсюда мои предположения:

🔸 Включилось автоматическое шифрование устройства, раз человек не в курсе. TPM 2.0 сочетается с ПИН- кодом и аппаратным ключом, но не с паролем при запуске.

🔸 При таком раскладе Michael может предложить Linux только 48-значный пароль восстановления. Иногда его ошибочно называют ключом восстановления (это - другое).

🔸 Не покидая Linux, извлечь этот пароль он может из облачных настроек учетной записи Microsoft (MSA), если уже входил с ней в Windows. В любом случае в Windows можно посмотреть это командой
manage-bde -protectors -get c:

Всё это мы обсудили даже без автора вопроса :) А когда он наконец вернулся, оказалось, что шифрование таки есть:

Volume C: []
[OS Volume]

Size: 138.17 GB
BitLocker Version: 2.0
1️⃣ Conversion Status: Encryption in Progress
Percentage Encrypted: 90.5%
Encryption Method: XTS-AES 128
2️⃣ Protection Status: Protection Off
Lock Status: Unlocked
Identification Field: Unknown
3️⃣ Key Protectors: None Found

Процитирую свою статью об автоматическом шифровании:

Во время чистой установки по окончании этапа OOBE шифрование раздела с ОС и прочих несъемных дисков инициализируется с незащищенным ключом и приостанавливается. Когда первый вход выполняет администратор с MSA, шифрование активируется и защищается TPM. Одновременно 48-значный пароль восстановления сохраняется в облачных настройках MSA.

Я почти угадал! 🎉

По пунктам:
1. Диск еще не полностью зашифрован, а значит система была установлена совсем недавно. О незавершенном шифровании догадаться по картинке было невозможно.
2. Защита отключена. Michael еще не входил с MSA. Еще бы - потом выяснилось, что у него LTSC N 🌈
3. Предохранителей нет. После входа с MSA в списке предохранителей появляются TPM и Recovery Password.

🐧 С Linux же получается зачетная нестыковка, которая вызвана именно автоматическим шифрованием Windows. Зашифрованный диск не защищен, потому что не имеет предохранителей. Однако для доступа к диску Linux требует один из них - пароль. Пользователь же о нем понятия не имеет :)

Оставался лишь вопрос, примет ли Linux 48-значный пароль восстановления. И дальнейший тест это подтвердил! Обе ОС работают штатно.

////

С осени подобных случаев будет множество. Причину я буду разбирать отдельно. Не переключайте каналы ✌️