Offline File Share Updating for Windows Defender

I ran into an interesting problem that I ended up spending way more time troubleshooting than what needed to be spent, in large part because our documentation is unfortunately incomplete.  The premise is fairly simple. You have a disconnected network that requires anti-virus definitions to be updated from a file share as opposed to Windows update because the network is disconnected. I know it’s not a common scenario, but it’s not unheard of either, and sadly our documentation is not the best here. Most our documentation on the matter can be found here, and per the doc, we need to specify the following GPO: Define Shares for Downloading Security Intelligence Updates.

The explanation on the GPO seems to agree as well, right?

image

Wrong. If all you do is set this and forget, you won’t getting updates. I did a lot of digging around and found a couple threads that touched on the issue, but not with a complete solution.

You can find them here and here.

First, what they got right. It’s not enough to simply create a share. You will also need specific folders for processor architecture. If you have a 64 bit processor, you need an x64 folder under the share. 32 bit will require an x86 folder, while ARM architecture will require an ARM folder. Defender checks the processor architecture of the system being updated and then contacts the share and looks for the folder associated with the appropriate architecture. Your file needs to be in that folder. Troubleshooting this part was more painful than I’d have liked. Log files are useless; you need process monitor. For the record, to troubleshoot this, perform the following steps:

  • Download and install Process Monitor.
  • Go to the file menu > start a capture.
  • From PowerShell, run the following Update-MPSignature -UpdateSource FileShares.  It’s worth noting you’ll probably get an error here. We continued to see an error with this even after fixing the issue. I don’t have an explanation for that as it presently stands.
  • Go back to Process Monitor, return to the file menu and deselect “start a capture.”
  • Do a search in Process Monitor for your file share in UNC format (i.e. \\servername\share)
  • Your first hit should be the the process that is attempting to access a share. You can then add a filter by the PID of this process if you so choose. It does help limit the noise.

Proc mon did confirm the folder structure mentioned above, but in two separate environments we saw different errors. One was access denied. The other was file not found. These weren’t too helpful. The issue was not permissions or even a missing file. The commenters in the links above were correct in noting the folder structure, but their perspective on permissions did not fit what we saw. They are right that the computer account needs access. It appears based on our troubleshooting that the network service account of the system doing the update is what is being used. Simply giving the domain computers group read access to our file share seemed to be enough for what that’s worth, but even with that setting we saw access denied errors. The security log on both the source and destination confirmed successful access however.

The fix was one other piece of GPO that is not clearly specified:

Define the order of sources for downloading security intelligence updates.

image

What we ended up finding out is that the first GPO does nothing but tell us what file share to go to. This GPO sets a fall back order, and by default, FileShares are not listed. Defender will check the registry and confirm the file share source, but it’s next step in updating is to following the source order, and since by default FileShares are not listed, your defender client will continue to check windows update, even though you defined a file share for it to use? Clear as mud? I thought so. Our doc does mention the source order, but it really doesn’t explain how this works. That said, it’s a requirement. FileShares must be listed as an option here. If it is not, they will not work.

Alternatively, you can use PowerShell if you’re in a one off situation:  Set-MpPreference -SignatureFallbackOrder “MicrosoftUpdateServer|InternalDefinitionUpdateServer|MMPC|FileShares”. You need the pipe to specify multiple sources, and if your network is disconnected, you can certainly remove the inappropriate values.

Hopefully that helps.