Windows Application Log: Persistent errors BINLSVC 1284

Question

This is WSE 2016 with the Client Restore Service enabled.

We're getting persistent errors in our single DC's event log:

I found this related documentation:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc726671(v=ws.10)

It provides some guidance, but it stops short of explaining what to do if the command output does NOT contain entries for each of our boot images.

We have this for two of our architectures:

C:\>bcdedit.exe /store C:\RemoteInstall\Boot\x64uefi\default.bcd /enum

Windows Boot Manager
--------------------
identifier              {bootmgr}
path                    \Boot\x64\bootmgfw.efi
fontpath                \boot\fonts
inherit                 {dbgsettings}
bootems                 Yes
timeout                 30

C:\>bcdedit.exe /store C:\RemoteInstall\Boot\x86uefi\default.bcd /enum

Windows Boot Manager
--------------------
identifier              {bootmgr}
path                    \Boot\x86\bootmgfw.efi
fontpath                \boot\fonts
inherit                 {dbgsettings}
bootems                 Yes
timeout                 30

But this for the other two:

C:\>bcdedit.exe /store C:\RemoteInstall\Boot\x64\default.bcd /enum

Windows Boot Manager
--------------------
identifier              {bootmgr}
fontpath                \boot\fonts
inherit                 {dbgsettings}
timeout                 30

C:\>bcdedit.exe /store C:\RemoteInstall\Boot\x86\default.bcd /enum

Windows Boot Manager
--------------------
identifier              {bootmgr}
fontpath                \boot\fonts
inherit                 {dbgsettings}
timeout                 30

As we can see, the second set contains no boot image entries. I believe this to be the source of our errors, but I'm not sure how to proceed.

What should I do to create these entries?

Solution

It sounds like what you need to do is to recreate your RemoteInstall folder. This will regenerate the boot files and the required directories while providing a working default configuration.

---

How to rebuild the RemoteInstall folder:

You can rebuild the RemoteInstall folder by doing the following:

1. Remove WDS role from the server.

2. Remove the folder share on your current RemoteInstall folder.

If you do not unshare the folder, you will get the following error:

So, don't forget to remove the folder share before you configure the server!

3. Rename (incase you need some of the images files still) or remove the folder.

4. Install the WDS role back to the server.

5. Configure the server.

After the server configuration has completed you will have a new RemoteInstall folder. Here is the output of a server 2016 RemoteInstall folder right after the configuration of the WDS role on the Server.

---

Tl;Dr:

• Remove the WDS role
• Unshare the current RemoteInstall share.
• Install WDS role back to server.
• Configure the server.
• Profit!

---

Links:

• WDS Powershell CMDLets: https://technet.microsoft.com/en-us/library/dn283416(v=wps.630).aspx
• Manual build of PE network boot resources: https://docs.microsoft.com/en-us/windows/deployment/configure-a-pxe-server-to-load-windows-pe

Comments

[Elliot Huffman]

I missed where the boot images were in your bcd readout. All I saw was the bootmgr settings. Can you post your full readout?

[Elliot Huffman]

Something that I do is completely rebuild the remoteinstall folder when I have wierd errors. I also use the default folder layout.

[InteXX]

@ElliotLabs—I missed where the boot images were I'm not sure I follow you. What I've posted is the full output of the bcdedit command. Could you clarify?

[InteXX]

@ElliotLabs—completely rebuild the remoteinstall folder Say, I like that idea. How do you do it?

[InteXX]

@ElliotLabs—completely rebuild the remoteinstall folder If you can explain this in an answer, I'd like to try it with hopes of accepting it.

[Elliot Huffman]

Sorry, I have been busy rebuilding my cloud infrastructure. I will post it as soon as possible.

[InteXX]

Profit is not a dirty word :-) This looks good, although I'm a bit concerned. My WDS role was originally installed and configured by the Server Essentials wizard. I don't know if this is going to muck with that. I'll set a checkpoint just in case.

[Elliot Huffman]

I used RSAT for all of this. You should have all of these options available to you if you use that.

[InteXX]

WSE shoves a 'user-friendly' UI shim into the works, so that you often don't get full functionality if you use the native tools rather than the wizard. So for this reason I'm hesitant to use RSAT. But I should be OK with the checkpoint backing me up.

[Elliot Huffman]

The above screenshots were taken on data center Edition. If you have the WDS roll available to you then you should have full functionality with it on your specific SKU.

[InteXX]

Pardon me, I meant to say 'full functionality via the WSE GUI.' With some stuff, if you configure it using lower-level native tools it becomes unavailable for management via the WSE GUI. And then you get nasties in your daily health report. So to keep everything clean you have to do your configurations with the wizards. WSE has its upsides and its downsides. This is one of its downsides.

[Elliot Huffman]

@InteXX Were you able to uninstall and reinstall the WDS service to get it working?

[InteXX]

Not yet... I'm presently under siege :-)

[InteXX]

I haven't had time to try this, but meanwhile I've discovered something interesting. I filtered the Application Event Log by the BINLSVC source and found that for each 1812 error there's a corresponding 1813 success, approx. 15 minutes later. The BINLSVC query gets refused the first try but is allowed through on the second. I'm not sure what to make of this, but I accepted your answer because I don't want to hold you up anymore. It's clearly the answer to my question from the comments, and apparently it's worked for you many times. So I have every expectation that it'd work for me. Thanks.