Назад | Перейти на главную страницу

Попытка обновить защитник Windows с пути UNC постоянно терпит неудачу

Я пытаюсь обновить Защитник Windows (в Win 10), используя определения, хранящиеся в UNC-пути.

Я устанавливаю путь к файлу mpam-fe.exe вот так

Set-MpPreference -SignatureDefinitionUpdateFileSharesSources \\path\to\mpam.exe

Затем я запускаю Get-MpPreference, чтобы убедиться, что путь установлен (он есть). Убедившись, что путь верен для SignatureDefinitionUpdateFileSharesSources я бегу

Update-MpSignature -UpdateSource FileShares

Я сразу получаю ошибку

Update-MpSignature : Virus and spyware definitions update was completed with errors.
At line:1 char:1
+ Update-MpSignature -UpdateSource FileShares
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound:    (MSFT_MpSignature:ROOT\Microsoft\...SFT_MpSignature) [Update-MpSignature], CimException
+ FullyQualifiedErrorId : HRESULT 0x80070002,Update-MpSignature

Этот сбой происходит практически мгновенно. Просто чтобы убедиться, что конкретный экземпляр PowerShell может получить доступ к рассматриваемому файловому ресурсу - я последовал за этим, просто выполнив файл mpam-fe.exe, и он сработал.

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

Итак, вот что я обнаружил при использовании Process Monitor. Мне удалось успешно заставить Защитник обновляться из источника файла.

  • Во-первых, пакеты обновлений состоят из трех файлов: mpam-fe.exe, mpam-d.exe, и nis_full.exe. Я пробовал использовать только mpam-fe.exe и это не удалось.
  • Во-вторых, есть 32-битные и 64-битные версии обновлений. Когда вы запускаете Update-MPSignature команда ожидает найти обновления под x64 или x86 папка в исходном пути. Итак, вам нужно создать дополнительные папки под исходным путем и поместить туда файлы обновления.
  • В-третьих, процесс обновления Защитника Windows - это wmiprvse.exe (WMI) - он работает как локальная система. Имейте в виду, что подключение к источнику файла осуществляется с помощью учетной записи компьютера, а не учетной записи пользователя. Я пробовал несколько разных вещей, чтобы попытаться заставить его подключиться к общей папке на сервере, присоединенном к домену. Это включало добавление учетной записи компьютера, domain computers, Everyone, и Anonymous. Ничего не получилось. Каждый раз он терпел неудачу с отказом в доступе. Я смог заставить его работать только тогда, когда я поместил файлы на свой NAS, который не имеет никаких ограничений безопасности.

Вот сценарий, который может помочь с загрузкой пакетов обновлений: https://www.powershellgallery.com/packages/SignatureDownloadCustomTask/1.4/DisplayScript

Вот другие ссылки, которые я использовал, чтобы заставить это работать: https://technet.microsoft.com/en-us/itpro/powershell/windows/defender/update-mpsignature?f=255&MSPPError=-2147217396

https://technet.microsoft.com/en-us/itpro/powershell/windows/defender/set-mppreference

Как предоставить сетевой доступ учетной записи LocalSystem?

https://docs.microsoft.com/en-us/windows/threat-protection/windows-defender-antivirus/manage-protection-updates-windows-defender-antivirus

https://docs.microsoft.com/en-us/windows/threat-protection/windows-defender-antivirus/deployment-vdi-windows-defender-antivirus

http://ccmexec.com/2016/01/download-and-deploy-windows-defender-definitions-for-windows-10-during-osd/

У меня была именно эта проблема. Проблема была решена путем создания папки x64 в общей папке и перемещения определений в эту папку. Я нигде не могу найти это требование, но оно работает. SCEP использует эту структуру папок, поэтому я и получил эту идею. Даже сценарий предоставлен Microsoft не создает папку архитектуры!

Настройка сервера:

  • Общий доступ к файлам (например, \\ Server \ Share $) с полными разрешениями общего доступа и разрешениями на чтение для Все (Компьютеры домена не требуются!)
  • Папка x64 содержащий 64-битные файлы определений (например, \\ Server \ Share $ \ x64 \ mpam-fe.exe)

Настройка клиента (powershell):

Set-MpPreference -SignatureDefinitionUpdateFileSharesSources \\Server\Share$
Set-MpPreference -SignatureFallbackOrder 'FileShares'
Update-MPSignature

Ответ Appleoddity дает все, что вам нужно. Однако есть некоторые предостережения;

  • Update-MpSignature никогда не работал у меня в PowerShell. Я потратил много времени, пытаясь настроить среду для работы этих обновлений, и использовал в качестве теста Update-MpSignature.
  • Как только я на самом деле запустил встроенную функцию обновления Defender / MSE и понял, что обновление работает правильно в ситуации, когда Update-MpSignature не работает, я начал отслеживать и тестировать другие сценарии, которые, хотя я, не работали, потому что они не работали через PowerShell

Итак, в основном, когда вы работаете над проблемой с помощью руководства Appleoddity, не полагайтесь исключительно на powershell и Update-MpSignature для проверки того, что вы делаете. YMMV, но в моем случае мне так и не удалось успешно запустить Update-MpSignature. Я быстро пришел к выводу, что я что-то настроил неправильно, но после дополнительных тестов я увидел, что сам Defender обновлялся без проблем, и только у PowerShell были проблемы.

Сообщение об отказе в разрешении вызвано Доступ запрещен к файлу журнала

C:\Windows\Temp\MpSigStub.log

Просто удалите этот файл журнала перед запуском 

Update-MpSignature -UpdateSource FileShares -Verbose

Вот сценарий PowerShell, который я ежечасно запускал на сервере, а затем я просто указываю на него своим клиентам. Важным моментом было НЕ извлекать файл. Защитник Windows указывает на сам исполняемый файл.

$vdmpathbase = 'E:\VirusDef\latest\x64'
$vdmpackage = $vdmpathbase + '\mpam-fe.exe'
cmd /c "del $vdmpackage /q"
Invoke-WebRequest -Uri 'https://go.microsoft.com/fwlink/?LinkID=121721&arch=x64' -OutFile $vdmpackage