Windows 11, 10, etc - Вадим Стеркин

☁️ OneDrive: как исключить определенные типы и имена файлов из синхронизации

Допустим, вы синхронизируете в облако папки "Рабочий стол" с двух разных компьютеров. Их содержимое смешивается. Это неудобно, когда у вас там ярлыки на разные программы либо на папки, которые не входят в сферу синхронизации. С таким подтекстом Aliaksandr задал в чате вынесенный в заголовок вопрос, хотя звучал он совсем иначе.

🐞 В принципе, в параметрах клиента OneDrive есть настройка для исключения расширений. Но с ней есть две проблемы:
1. Расширения должны состоять не менее чем из трех символов. Например, md не исключить.
2. Настройка не работает :) По крайней мере так, как люди ожидают. Множество жалоб в интернете подтвердили, что это не просто моя локальная проблема. Некоторые также правят INI-файл политик клиента, но безуспешно.

///

👉 Мы пойдем другим путем © У OneDrive есть групповые политики, и в изданиях Pro и выше можно решить вопрос политикой Exclude specific kinds of files from being uploaded (Исключить отправку определенных видов файлов).

⚠️ Учтите, что:
1. Политика применится только к новым файлам, то есть не будут исключаться уже существующие файлы, втч переименованные после включения политики. Поэтому придется навести порядок руками - например, пересоздать ярлыки.

2. Политика работает только с именами файлов и не действует на имена папок. Но папки можно исключить в настройках клиента.

3. Чтобы эта и другие политики OneDrive отобразились в графическом интерфейсе gpedit.msc, нужно закинуть административные шаблоны из папки с клиентом OneDrive в %systemroot%\PolicyDefinitions. Но прямая правка реестра работает и без этого.

⚙️ Изменения в реестр можно внести из консоли от имени администратора или REG-файлом. В этих примерах не будут синхронизироваться ярлыки и файлы с именем вроде mytest.txt.

reg add "HKLM\SOFTWARE\Policies\Microsoft\OneDrive\EnableODIgnoreListFromGPO" /v "*.lnk" /t REG_SZ /d "*.lnk" /f

reg add "HKLM\SOFTWARE\Policies\Microsoft\OneDrive\EnableODIgnoreListFromGPO" /v "*test*" /t REG_SZ /d "*test*" /f

После внесения изменений в реестр перезапустите клиент OneDrive и ваш файловый менеджер.

Теперь можете закинуть в папку OneDrive несколько попадающих под действие политики файлов и убедиться, что они получили особый статус и значок. В тултипе поясняется, что файл исключен из синхронизации ✌️

⚙ Об изменениях в создании локальной учётной записи при установке Windows

В конце прошлой недели всплыли две новости.

1️⃣ Файл bypassnro.cmd выпилят из дистрибутива 25H2. Сам метод пока работать не перестанет, но вместо одной короткой команды для запуска файла придётся вводить две, которые в нём содержались. Это внесение изменений в реестр и перезагрузка.

2️⃣ Нашлась другая короткая команда, которая открывает диалог создания локальной учётной записи.

На первом экране OOBE нажмите Shift+F10, ткните в окно командной строки и введите:

start ms-cxh:localonly

Предположу, что это выпилят довольно быстро - может не дожить до 25H2. И напомню, что все это время неизменно рабочим способом остаётся файл ответов. Его можно применять:

🔹 с первого этапа установки
🔹 для автоматизации этапа OOBE

Учите матчасть ✌

⚙️ Об изменениях в создании локальной учётной записи при установке Windows

В конце прошлой недели всплыли две новости.

1️⃣ Файл bypassnro.cmd выпилят из дистрибутива 25H2. Сам метод пока работать не перестанет, но вместо одной короткой команды для запуска файла придётся вводить две, которые в нём содержались. Это внесение изменений в реестр и перезагрузка.

2️⃣ Нашлась другая короткая команда, которая открывает диалог создания локальной учётной записи.

На первом экране OOBE нажмите Shift+F10, ткните в окно командной строки и введите:

start ms-cxh:localonly

Предположу, что это выпилят довольно быстро - может не дожить до 25H2. И напомню, что все это время неизменно рабочим способом остаётся файл ответов. Его можно применять:

🔹 с первого этапа установки
🔹 для автоматизации этапа OOBE

Учите матчасть ✌️

▶️ Простой и эффективный поиск текста в PowerShell - Select-String

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

Как правило, люди открывают Notepad++, загружают туда пачку логов и выполняют поиск во всех открытых файлах. На предложение использовать скрипт пожимают плечами - мол, это же разовая задача. И так сойдет 👌

У этого подхода много проблем:
1. Медленно.
2. Не выгружается сводка и найденные данные.
3. При большом количестве / размере файлов это работает плохо или вообще никак.

Да и не разовая это у них задача, поэтому скрипт подходит отлично.

👉 В #PowerShell для этой цели есть командлет Select-String. Он умеет искать простое совпадение или регулярное выражение.

Select-String -Path 'C:\logs\*.log*' -Pattern '0x800f0805' -SimpleMatch
Select-String -Path 'C:\logs\*.log*' -Pattern '0x800f0805|0x80070490'

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

🤖 Чат-боту задача по поиску текста ставится общими словами. Например, найди все строки с 'exception ' в этих файлах, посчитай количество на каждый файл, запиши в файл эту строку и 20 следующих, выведи на экран сводку и т.д.

И бот быстро пишет рабочий скрипт. Только он зачастую использует другой командлет - Get-Content и передает весь массив на поиск командлету Where-Object. А для такой задачи это неэффективно - слишком медленно!

Простое сравнение. Ищем ошибку '0x800f0805' десяти файлах cbs.log общим объемом около 1.2GB.

$logpath = "C:\temp\logs\*cbs*.log"
Measure-Command {
    $a = Select-String -Path $logpath -Pattern '0x800f0805' -SimpleMatch
}
$a.count
Measure-Command {
    $b = Get-Content -Path $logpath | where $_ -match '0x800f0805'
}
$b.count

У меня Select-String справился за 7.5 секунд, а Get-Content | where понадобилось 4 мин и 40 секунд.

💡 И кстати по поводу контекста, у Select-String есть очень полезный параметр -Context, который выводит строки до и после найденного совпадения.

Select-String -Path $logpath -Pattern 'exception ' -SimpleMatch -Context 2,20

////

В общем, если вам нужно дальше работать с чистыми найденными строками в качестве объектов, Get-Content имеет смысл. Но просто для поиска текста Select-String вполне достаточно. И да, можно сказать чат-боту, чтобы применял конкретный командлет!

🍪 Бонус - #классика канала про мониторинг логов в реальном времени при помощи:
• командлета PowerShell
• утилиты CMTrace

▶️ Простой и эффективный поиск текста в PowerShell - Select-String

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

Как правило, люди открывают Notepad++, загружают туда пачку логов и выполняют поиск во всех открытых файлах. На предложение использовать скрипт пожимают плечами - мол, это же разовая задача. И так сойдет 👌

У этого подхода много проблем:
1. Медленно.
2. Не выгружается сводка и найденные данные.
3. При большом количестве / размере файлов это работает плохо или вообще никак.

Да и не разовая это у них задача, поэтому скрипт подходит отлично.

👉 В #PowerShell для этой цели есть командлет Select-String. Он умеет искать простое совпадение или регулярное выражение.

Select-String -Path 'C:\logs\*.log*' -Pattern '0x800f0805' -SimpleMatch
Select-String -Path 'C:\logs\*.log*' -Pattern '0x800f0805|0x80070490'

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

🤖 Чат-боту задача по поиску текста ставится общими словами. Например, найди все строки с 'exception ' в этих файлах, посчитай количество на каждый файл, запиши в файл эту строку и 20 следующих, выведи на экран сводку и т.д.

И бот быстро пишет рабочий скрипт. Только он зачастую использует другой командлет - Get-Content. А для такой задачи это неэффективно - слишком медленно!

Простое сравнение. Ищем ошибку '0x800f0805' десяти файлах cbs.log общим объемом около 1.2GB.

$logpath = "C:\temp\logs\*cbs*.log"
Measure-Command {
    $a = Select-String -Path $logpath -Pattern '0x800f0805' -SimpleMatch
}
$a.count
Measure-Command {
    $b = Get-Content -Path $logpath | where $_ -match '0x800f0805'
}
$b.count

У меня Select-String справился за 7.5 секунд, а Get-Content понадобилось 4 мин и 40 секунд.

💡 И кстати по поводу контекста, у Select-String есть очень полезный параметр -Context, который выводит строки до и после найденного совпадения.

Select-String -Path $logpath -Pattern 'exception ' -SimpleMatch -Context 2,20

////

В общем, если вам нужно дальше работать с чистыми найденными строками в качестве объектов, Get-Content имеет смысл. Но просто для поиска текста Select-String вполне достаточно. И да, можно сказать чат-боту, чтобы применял конкретный командлет!

🍪 Бонус - #классика канала про мониторинг логов в реальном времени при помощи:
• командлета PowerShell
• утилиты CMTrace

▶️ Простой и эффективный поиск текста в PowerShell - Select-String

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

Как правило, люди открывают Notepad++, загружают туда пачку логов и выполняют поиск во всех открытых файлах. На предложение использовать скрипт пожимают плечами - мол, это же разовая задача. И так сойдет 👌

У этого подхода много проблем:
1. Медленно.
2. Не выгружается сводка и найденные данные.
3. При большом количестве / размере файлов это работает плохо или вообще никак.

Да и не разовая это у них задача, поэтому скрипт подходит отлично.

👉 В #PowerShell для этой цели есть командлет Select-String. Он умеет искать простое совпадение или регулярное выражение.

Select-String -Path 'C:\logs\*.log*' -Pattern '0x800f0805' -SimpleMatch
Select-String -Path 'C:\logs\*.log*' -Pattern '0x800f0805|0x80070490'

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

🤖 Чат-боту задача по поиску текста ставится общими словами. Например, найди все строки с 'exception ' в этих файлах, посчитай количество на каждый файл, запиши в файл эту строку и 20 следующих, выведи на экран сводку и т.д.

И бот быстро пишет рабочий скрипт. Только он зачастую использует другой командлет - Get-Content и передает весь массив на поиск командлету Where-Object. А для такой задачи это неэффективно - слишком медленно!

Простое сравнение. Ищем ошибку '0x800f0805' десяти файлах cbs.log общим объемом около 1.2GB.

$logpath = "C:\temp\logs\*cbs*.log"
Measure-Command {
    $a = Select-String -Path $logpath -Pattern '0x800f0805' -SimpleMatch
}
$a.count
Measure-Command {
    $b = Get-Content -Path $logpath | where $_ -match '0x800f0805'
}
$b.count

У меня Select-String справился за 7.5 секунд, а Get-Content | where понадобилось 4 мин и 40 секунд.

💡 И кстати по поводу контекста, у Select-String есть очень полезный параметр -Context, который выводит строки до и после найденного совпадения.

Select-String -Path $logpath -Pattern 'exception ' -SimpleMatch -Context 2,20

////

В общем, если вам нужно дальше работать с чистыми найденными строками в качестве объектов, Get-Content имеет смысл. Но просто для поиска текста Select-String вполне достаточно. И да, можно сказать чат-боту, чтобы применял конкретный командлет!

🍪 Бонус - #классика канала про мониторинг логов в реальном времени при помощи:
• командлета PowerShell
• утилиты CMTrace

😎 Сегодня у меня для вас рекомендации по автообрастаниям и автосхрюнку (или автохрюнку, это неточно :)

И не отрежьте там себе ничего автосхромкой! 🪚

Microsoft прогрессирует - переходит от ручного ухуренивания к автоухрюнку.

Этот #автоперевод документации SQL Server прислал Romchik Alekseev ✌️

😎 Сегодня у меня для вас рекомендации по автообрастаниям и автосхрюнку (или автохрюнку, это неточно :)

И не отрежьте там себе ничего автосхромкой! 🪚

Microsoft прогрессирует - переходит от ручного ухуренивания к автоухрюнку.

Это был #автоперевод в документации SQL Server ✌️

😎 Сегодня у меня для вас рекомендации по автообрастаниям и автосхрюнку (или автохрюнку, это неточно :)

И не отрежьте там себе ничего автосхромкой! 🪚

Microsoft прогрессирует - переходит от ручного ухуренивания к автоухрюнку.

Этот #автоперевод документации SQL Server прислал Romchik Alekseev ✌️

⚙️ Как удалить ассоциацию программы с типом файлов

В чате Zubastic задал этот вопрос в контексте файлов без расширения - некая программа предательски захватила ассоциацию с ними.

Вариантов регистрации много. Самый простой и работающий с незапамятных времен - программа прописывает себя в разделе HKCR\ProgramName, в том числе команду на запуск в разделе HKCR\ProgramName\shell\open\command. А для каждого расширения вносит указатель на этот раздел в HKCR\.ext, где ext - расширение.

ℹ️ В случае с файлами без расширения - раздел будет HKCR\.. По умолчанию он отсутствует. Более того, Windows не позволяет вам создать его путем "Открыть с помощью": для файлов без расширений нет опции всегда открывать этой программой! Однако вот пример связи таких файлов с блокнотом по описанной выше схеме старыми добрыми командами assoc и ftype.

assoc .=NoExtFile
ftype NoExtFile="notepad.exe" "%1"

В нашем случае автор вопроса в безуспешных попытках решить проблему удалил раздел HKCR\., тем самым уничтожив указатель на программу. А назвать свой подраздел в HKCR она могла как угодно. С помощью Process Monitor мы определили конкретное название раздела - HKCR\PhotonWorkShop. После его удаления проблема решилась ☑️

Но заодно создалась другая. Она не волновала ТС, хотя это скорее исключение. Теперь даже легитимно связанные с программой типы файлов в ней не откроются, потому что их расширения в реестре ссылаются на отсутствующий раздел. Кроме того, остался нераскрытым вопрос, почему даже после удаления раздела HKCR\. файлы без расширения продолжали открываться в этой программе 🤷‍♂️

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

Пользовательская регистрация расширений прописана в разделе
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\

Для каждого расширения там есть подразделы:
• OpenWithList - список программ в "Открыть с помощью"
• OpenWithProgids - список зарегистрированных программ или отсылка к типу файлов в HKCR
• UserChoice - текущая программа по умолчанию, выбранная пользователем (при наличии - преобладает над подразделами выше)

✅ Отсюда следует решение вынесенного в заголовок вопроса.

🔹 Если вы желаете сменить одну зарегистрированную программу на другую, не нужно лезть в реестр. Это можно сделать из диалога "Открыть с помощью" (за исключением файлов без расширений).

🔹 Если вы хотите удалить пользовательские ассоциации и убрать указатели на них в "Открыть с помощью", зачищайте подразделы OpenWithProgids и OpenWithList в HKCU. В этом случае при открытии файла будут отображаться системные ассоциации ↓

🔹 Если требуется удалить системную связь программы с расширением, анализируйте раздел HKCR\.ext. Там тоже могут быть подразделы OpenWithProgids и OpenWithList. Универсального рецепта здесь нет ввиду различных способов регистрации.

У проблемной программы был еще один нюанс. После своего обновления она восстанавливала ассоциации файлов. В таком случае придется регулярно зачищать их скриптом. Альтернатива - отобрать разрешения на пользовательский раздел реестра по такой же схеме как с нежелательным значком OneDrive в панели навигации проводника ✌️