😎 Как восстановить настройки, выпиленные из параметров папок

Upd. Разработчики получили тонны кирпичей и откатили изменение уже в следующей сборке 23486. Вне зависимости от их метаний техническая информация ниже верна.

Мы с Сергеем Ткаченко активно обсуждали изменения в сборке 23481. Понятно, что можно рулить параметрами в реестре. Но есть и способ поинтереснее на основе древней фичи Windows.

👉 С помощью реестра в параметры папок можно добавить свои флажки и радио-кнопки, управляющие нужными значениям в реестре!

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

Все параметры с вкладки "Вид" прописаны в разделе реестра
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder

По образу и подобию туда можно добавить свои подразделы, контролирующие заданные параметры реестра. Вопрос был в том, как разработчики выпилили ненужное - удалением разделов реестра или фильтром по какому-то принципу.

ℹ️ Выяснилось, они выбрали второй путь, причем решили фильтровать по имени подраздела реестра, 2️⃣ на картинке↓ Куда хуже был бы фильтр по названию значения в реестре, 1️⃣ на картинке. В этом примере, когда вы ставите или снимаете флажок отображения защищенных системных файлов, по пути RegPath для параметра ShowSuperHidden задается значение 1 или 0. Если такое ValueName игнорировать, настройка в GUI работать не будет.

А так задача сводится к переименованию подразделов реестра. Для программной реализации предусмотрена функция WinAPI RegRenameKey. А скриптом проще всего разрулить с #PowerShell:

Rename-Item -Path HKCU:\SOFTWARE\XXX -NewName YYY

⬇️ В архиве скрипты PowerShell для восстановления выпиленных настроек и отката изменений. В принципе, restore-checkboxes.ps1 можно применить уже сейчас на стабильной версии. Когда дойдет до установки версии с изменениями в параметрах папок, у вас там все останется как прежде 👌

У Сергея на Winaero опубликованы подробные пошаговые инструкции, но они на английском языке.

🌎 Как изменить язык установки Windows

Вопрос задал коллега, у которого ряд клиентов не обновлялись до новой версии Windows 11 посредством WSUS. Он предположил, что на WSUS нет обновления для языка этих систем. Язык установки ОС легко проверить в #PowerShell:

(Get-CimInstance Win32_OperatingSystem).OSLanguage

На выходе: 1033 - en-US, 1049 - ru-RU, а остальное тут. Страница в веб-архиве удобна тем, что содержит одновременно десятичные и шестнадцатеричные значения. В актуальной документации нашлось только раздельно: HEX и DEC.

И ви таки не поверите, с каким языком эникейщики раскатали Windows 11 😎

Между тем, сегодня двойная рубрика "Возвращаясь к напечатанному". До сих пор был ремейк поста блога 12-летней давности об установке SP1 на Windows 7. А смену языка установки ОС я показывал в канале почти 6 лет назад - с помощью DISM из Windows RE:

dism /image:C:\ /set-uilang:en-us

Тестирование на актуальных версиях Windows 10 и 11 выявило нестыковку. Переключение с русского на английский язык работает как и прежде, а вот с английского на русский в Windows 11 уже не сработало, втч на чистой ВМ. Лог dism ничего не прояснил.

📃 Возможно, это связано с изменениями в обработке языка в процессе установки ОС. Про нововведения в 20H1 я рассказывал в блоге. А сейчас в документации /set-uilang добавилось примечание, что начиная с Windows 11 заданный язык установки ОС не переопределяется пользователем при выборе языка на этапе OOBE (за исключением домашних изданий).

👉 К счастью, команда DISM просто изменяет параметр InstallLanguage в реестре. Скрипт ниже задает английский язык установки ОС, если задан любой язык кроме русского или английского.

$Language = (Get-itemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Nls\Language" -Name InstallLanguage).InstallLanguage
#0419 - ru-RU, 0409 - en-US
if ($Language -ne "0419" -and $Language -ne "0409") {
Write-host "Current: "$Language
Set-itemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Nls\Language" -Name InstallLanguage -Value 0409
}

После смены языка клиенты успешно получили новую версию ОС с WSUS ✌️

🌎 Как изменить язык установки Windows 11 на русский для переустановки поверх

Сегодня в рубрике "Возвращаясь к напечатанному" тема, которая поднималась в канале месяц назад. Напомню, что в контексте ключа DISM /Set-UILang остался нерешенным один вопрос.

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

Я думал, что предложенный в статье твик реестра InstallLanguage снимает вопрос. Однако там мы решали конкретную задачу: сменить язык для получения исправлений посредством WSUS. В Windows 10 22H2 твик сработал. В Windows 11 не тестировалось, но выглядело перспективно.

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

👉 Необходимо задать русский язык ключом DISM /Set-SKUIntlDefaults. Я проверил, и хочу добавить, что необходимо соблюдение трех условий.

1. Убедитесь, что установлен русский языковой пакет.

2. В #PowerShell от имени администратора выполните:
Set-itemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Nls\Language" -Name InstallLanguage -Value 0419

3. Загрузитесь в среду восстановления и в командной строке выполните:
dism /image:C:\ /Set-SKUIntlDefaults:ru-RU

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

🖊 О выпиливании WordPad из Windows

На прошлой неделе проскочила драматическая новость о том, что Microsoft убивает WordPad после 28 лет службы верой и правдой 😱

Он и так уже является необязательным компонентом, однако установленным по умолчанию.

Get-WindowsCapability -Online | where name -like *wordp*

И конкретной даты удаления не озвучили. Пока WordPad получил статус deprecated (значение термина я объяснял в канале). Предположу, что какое-то время компонент будет поставляться в отключенном состоянии, прежде чем его совсем выпилят.

Но зачем вообще может понадобиться WordPad? Давайте представим Windows из коробки без подключения к интернету 👈

1️⃣ Сохранение текстовых файлов в кодировке MS-DOS (OEM-866)

Для пакетных файлов bat и cmd, обрабатывающих кириллицу в путях, это было нужно испокон веков. Размещение ответа в FAQ намекает, что наступавших на грабли было великое множество. А олды смахнут скупую слезу, увидев альтернативные редакторы :)

Кстати, несмотря на способность сохранять в кодировке OEM-866, WordPad некорректно отображает кириллицу при открытии файла, см. картинку ↓ Исправить это можно, выбрав шрифт Terminal (спасибо, Сергею Ткаченко за напоминание:).

Взамен Microsoft предлагает использовать Блокнот, но он не умеет в OEM-866. Однако в качестве замены подойдет #PowerShell. Командлеты Out-File и Set-Content умеют задавать кодировку.

Write-Output привет | Out-File oem.txt -Encoding oem

2️⃣ Открытие DOCX

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

Взамен Microsoft предлагает использовать Word. Видимо, будет стандартное предложение поискать в магазине.

И кстати вместе с WordPad надо будет выпилить еще и write.exe!

fsutil hardlink list c:\windows\write.exe

#Классика блога про это: Зачем Windows нужно два блокнота (и точно ли их два) ✌️

⚙️ Почему точки восстановления создаются сериями

Готовя предыдущий пост о пользе точек восстановления, я заглянул в список своих точек и увидел странную картину↓ Налицо две серии точек, созданных Windows Update в течение минуты: две точки подряд 23 августа и три подряд 19 августа. Я не раз видел такое и раньше, но на сей раз решил покопаться в причинах.

▶️ В истории центра обновлений Windows в эти дни нет ничего кроме сигнатур защитника. Придётся срывать покровы с журналов событий с помощью #PowerShell. Я показывал в канале работу с датами с Get-Date и быстрый опрос всех журналов сразу (и возвращался к теме в контексте Windows 10). Сводим все вместе, выбрав четырехминутный диапазон вокруг даты создания точки.

$s = Get-Date -Year 2023 -Month 08 -Day 23 -Hour 00 -Minute 04
$e = Get-Date -Year 2023 -Month 08 -Day 23 -Hour 00 -Minute 08
Get-WinEvent -ErrorAction 0 -FilterHashTable @{
LogName='*'
StartTime=$s
EndTime=$e
} | sort ProviderName | Out-File -FilePath "$ENV:TEMP\sr.txt"

🛍 Сходу выяснилось, что 23 августа основной активностью было обновление магазинных приложений. Связанных с этим событий было множество, но в итоге все свелось к обновлению двух приложений - непосредственно магазина и StorePurchaseApp, компонента для покупок. Поставщик Microsoft-Windows-Install-Agent тщательно протоколирует загрузку, а приложение легко определить по ИД вроде 9WZDNCRFJBMP.

8/23/2023 12:06:39 AM 2006 Information
Progress Update: Item = 9WZDNCRFJBMP  
Progress Stage = DownloadingProduct, Completed = 332800,
Total = 19636239, Total = 3

Аналогично 19 августа обновились три приложения - WhatsApp, DesktopAppInstaller и почта/календарь.

👉 Количество обновленных приложений совпало с числом созданных точек восстановления!

Созданные подряд точки не должны влиять на расход места на диске. Ведь за несколько секунд существенных изменений в системе не происходит. Поставщик Volsnap, чтобы высвободить место, удаляет самую старую теневую копию лишь однажды - 23 августа для создания первой точки.

Однако смысл всего мероприятия от меня ускользает. По умолчанию Windows не создаёт точки чаще 24 часов. Это обходится твиком реестра и, как мы видим, программным способом. Но зачем? 🤷‍♂️

Ведь точки восстановления создаются для конечного пользователя. Допустим, мне нужно восстановить систему. Я вижу три точки, созданные в один день с разницей в несколько секунд 🤔 Ну, наверное, я выберу самую раннюю... или любую :)

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

🔐 О состоянии шифрования BitLocker по умолчанию в Windows

Второй день из каждого утюга вещают, что в Windows 11 Pro по умолчанию включено шифрование BitLocker, что влечет снижение производительности SSD до 45%. Первоисточник - Tom's Hardware, а дальше уже может зависеть от фантазии переводчика.

Я хочу прокомментировать заявления автора статьи, касающиеся работы BitLocker в ОС Windows. В разных местах материала он делает массу обтекаемых и неверных заявлений. Я не буду цитировать, а просто изложу их своими словами.

Эти утверждения в совокупности вводят в заблуждение:

• Windows 11 Pro форсирует включение шифрования, а на Windows 10 Pro шифрование скорее всего не включено.

• Если у вас [в Windows 11] локальный аккаунт нежели учетная запись Microsoft (MSA), шифрование не включается.

• Windows 11 Home не поддерживает BitLocker, поэтому там шифрование не включается. (Однако автор тут же оговаривается: кажется, на некоторых ноутбуках включено :)

👉 У меня есть подробная #классика блога на эту тему: Автоматическое шифрование BitLocker в Windows. И подзаголовок там в самый раз :) Рекомендую вам прочесть рассказ целиком, а здесь задействую некоторые моменты.

ℹ️ На самом деле шифрование устройств с помощью BitLocker автоматически включается начиная с Windows 8.1 во всех изданиях. Но происходит это только на устройствах, соответствующих определенным требованиям, которые со временем слегка ослабили. Поддержка автоматического шифрования проверяется элементарно.

🔓 Если устройство подходит, BitLocker включается во время установки с незащищенным ключом и приостанавливается. В английской терминологии это состояние называется Suspended, и задать его можно командлетом #PowerShell Suspend-Bitlocker. На картинке↓ шифрование включено, но приостановлено - диск зашифрован, но не защищен. Поэтому неверно заявление автора тестов, что с локальным аккаунтом диск не шифруется.

🔑 Когда первый вход выполняет администратор с MSA или компьютер вводится в домен, шифрование активируется и защищается TPM. Одновременно 48-значный пароль восстановления сохраняется в облачных настройках MSA, а в домене – в Entra ID или AD DS при включенной политике.

Проверка заявлений, касающихся производительности, тоже не помешала бы. Но я оставляю ее вам. С помощью CrystalDiskMark можно относительно быстро прикинуть влияние любого программного шифрования на свою систему. Только, пожалуйста, тестируйте производительность диска, а не его кэша ✌️

⚙️ Как получить доступ к служебному разделу, не изменяя его свойства

Сегодня в рубрике "Возвращаясь к напечатанному" получение доступа к разделу со средой восстановления. Чуть менее года назад я разбирал это в блоге наряду с тем, как предотвратить назначение буквы диска. Там решение крутилось вокруг снятия и присвоения служебных свойств с помощью diskpart.

А тут я изучал содержимое раздела Windows RE на разных системах. Менять свойства туда-сюда утомило с третьего раза, и я посмотрел в сторону #PowerShell. С целью прямого доступа нежели изменения свойств, потому что у Set-Partition не реализовано свойство Required.

ℹ️ В блоге я приводил GUID - идентификатор раздела восстановления, поэтому легко сделать выборку из списка разделов. Нас интересует свойство AccessPaths, т.е. путь доступа. (Его также можно посмотреть нативной командой mountvol, но в списке может оказаться без буквы также раздел MSR - на глаз не отличить.)

$id = "{de94bba4-06d1-4d40-a16a-bfd50179d6ac}"
Get-Partition | where GptType -eq $id | select Type,AccessPaths

Type AccessPaths
---- -----------
Recovery {\\?\Volume{9896bfe9-69de-4db1-a6f4-ba4630addab3}\}

Теперь легко вывести содержимое раздела - рекурсивно, включая скрытые папки и файлы. Можно даже ванлайнером, но так нагляднее:

$id = "{de94bba4-06d1-4d40-a16a-bfd50179d6ac}"
$lpath = (Get-Partition | where GptType -eq $id).AccessPaths[0]
Get-ChildItem -Force -Recurse -LiteralPath $lpath

Меня интересовало содержимое winre.wim, и скопировать его не составило труда:

Copy-Item -LiteralPath "\\?\Volume{9896bfe9-69de-4db1-a6f4-ba4630addab3}\Recovery\WindowsRE\Winre.wim" -Destination C:\temp\

В данном случае файл скрытый и системный, но про управление атрибутами файлов в PowerShell я уже рассказывал ✌️

▶️ Как массово удалить папки, распакованные из архивов

В чате участник Павел задал такой вопрос:
В папке ~450 разных файлов, папок и архивов *.rar. Периодически рары разархивируются, и получается папка с тем же именем, что и rar. Стоит задача удалить эти папки, оставив при этом архивы. Как отсортировать, чтобы снизу папки сразу был её родительский архив?

Очевидно, он рассматривал вариант сортировки в файловом менеджере. Хотя надо сразу смотреть в сторону #PowerShell. Для начинающих это отличное практическое упражнение! Впрочем, этому унылому занятию Павел предпочел ожидание поста в канале 😎

Я бы решал задачу в лоб:
1. Отбираем только папки.
2. Для каждой проверяем наличие архива с таким же именем, "приклеивая" к имени папки расширение.
3. При совпадении удаляем.

$folders = Get-ChildItem -Path "C:\test" -Directory
foreach ($folder in $folders) {
if (Test-Path "$($folder.FullName).rar")
{Remove-Item $folder -Recurse -WhatIf}
}

Василий Гусев предложил нестандартное решение - группировка! 🤔 Мне оно в голову не пришло, хотя я трижды показывал Group-Object в блоге:
• поиск дубликатов драйверов
• выборка уникальных ссылок с веб-страниц
• замена дубликатов файлов на жесткие ссылки

Доработав идею, я получил такой конвейер:
1. Группируем по имени папки и файлы без расширения с помощью свойства BaseName.
2. Отбираем группы, где с одинаковыми именами ровно два объекта - файл и папка!
3. Из каждой группы выбираем папки и удаляем их.

Get-ChildItem -Path "C:\test" | Group-Object -Property BaseName |
Where-Object {$_.Count -eq '2'} | ForEach-Object {$_.group} |
Where-Object {$_.Attributes -eq 'Directory'} | Remove-Item -Recurse -WhatIf

⌛️ Примечательно, что с обоими способами перекликается #классика блога Как массово переименовать файлы по маске в PowerShell. Там я склеивал имя файла из фрагментов, одним из которых было свойство BaseName.

🤖 И неудивительно, что ChatGPT тоже задействовал это свойство, когда я поставил задачу перед ним. Он пошел тем же путем что и я, но выбрал перебор архивов нежели папок и создал побольше переменных. В свою очередь чат-бот Bing практически повторил мой способ. Но для определения папки он использовал старое свойство объекта PSIsContainer (параметр -Directory у dir доступен более 10 лет, с версии 3.0).

Короче, получив направление в PowerShell, Павел мог сразу спросить чат-бота. И не дожидаться, пока кожаный мешок опубликует решение его простенькой задачи в канале ✌️

🛍 Как удалить новые приложения Dev Home и Outlook в Windows 11

Вчера был второй вторник, а следовательно в Windows 11 22H2 всем пришло накопительное обновление с функциями Момент 4 - KB5032190. Оно или его превью необходимы для обновления до версии 23H2 - KB5027397. Это опять #тумблер - номер версии меняется переключателем, потому что у них одинаковая кодовая база. Если вам не предлагают 23H2 в центре обновления, проверьте эти причины. 👈

Обновление до 23H2 отчасти формальное, потому что большинство новинок доставляет Момент 4. Именно после его установки через диспетчер доставки содержимого принудительно прилетают два магазинных приложения - превью Dev Home и Outlook for Windows (замена магазинной Почте). У некоторых от этого подгорит. А уж когда они обнаружат, что не могут удалить Dev Home в графическом интерфейсе... 🍑🔥

Эти две команды в #PowerShell от имени администратора решают вопрос:

Get-AppxPackage -AllUsers | where Name -match 'DevHome|OutlookForWindows' | Remove-AppxPackage -AllUsers
Get-AppxProvisionedPackage -Online | where PackageName -match 'DevHome' | Remove-AppxProvisionedPackage -Online

ℹ️ Первая команда удаляет пакеты из всех учетных записей, вторая - из локального хранилища (туда внедряется только Dev Home). Оно служит источником установки при первом входе в систему. Подробнее об этих командах читайте в блоге. И не поленитесь поискать названия командлетов в канале - там много любопытного.

Однако удаление не блокирует доставку этих приложений в новые учетные записи. Если вы знаете поддерживаемый способ предотвратить установку, сообщите мне. О кривых обходных путях я, возможно, напишу отдельно ✌️

▶️ Новое в блоге: Нюансы полной локализации Windows с помощью PowerShell

Сегодняшний рассказ продолжает серию публикаций о языковых настройках. Для управления ими в Windows 11 появились новые командлеты: Install-Language и Copy-UserInternationalSettingsToSystem. С ними стала возможна полная локализации системы командлетами #PowerShell. Но понадобятся еще пять других :)

👉 Цель упражнения — полностью локализовать установленную Windows на русский язык для текущего пользователя и всех созданных впоследствии аккаунтов.

Я не призываю переводить английскую ОС с ног до головы на русский язык. Тогда уж проще взять русский дистрибутив. Я показываю тонкости работы языковых командлетов. А вам нужно отталкиваться от практической задачи, выбирая только необходимые составляющие локализации.

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