Windows 10 enable Developer Mode error 0x80004005

We want to use the new Windows Subsystem for Linux (Beta) feature that was included with the 1607 build of Windows 10. To do that, you have to enable Developer Mode. But when we tried, we would get the error:

"Developer mode package failed to install. Error code 0x80004005"

The articles I've found that address this error refer to versions that are using a non EN-US language. That is not the case in our organization. In our case, our group policy settings were preventing the OS from downloading the package from Microsoft Update. The following is a workaround that has worked for us. Just be sure to reverse the settings when you're done.

• Launch regedit.exe and modify this key:
• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
• UseWUServer to 0 (to disable), restart
• Enable Developer Mode, restart
• Enable Windows Subsystem for Linux (Beta), restart
• Launch regedit.exe and modify this key:
• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
• UseWUServer to 1 (to enable), restart

Hope this helps you as well.

ConfigMgr wake-up proxy and port security

FYI, got the below message from one of our network guys. This involved another location, not us (thankfully!). Bottom line, if you're implementing port security, do NOT use ConfigMgr wake-up proxy:

We ran into a really “interesting” issue this week.  The SCCM guys decided to implement the SCCM “wake-proxy” feature on the SCCM.  Not quite the normal magic packet WOL procedure.  This has the SCCM server hit specific machines, which then go and hit the machines in their vlan.  However, these “manager machines” also spoof the mac addresses of the machines that go to sleep in their vlan in order to keep the MAC alive in the switch tables.

This is quite fun when you have port-security turned on that limits the number of mac addresses on the ports!  We had random machines dropping off the network, DHCP issues, etc.  It was quite fun to chase down what exactly was going on.  The only indication that we saw was that ports were showing multiple MAC addresses when we knew that there was only one device connected to it and it was not running a VM.  Wasn’t even logged into.

Fortunately, something ticked the back of my mind about a feature they were thinking about implementing on the SCCM and we were able to put the pieces together.  Otherwise, we would still be scratching our heads over this.

Bottom line?  DO NOT implement SCCM wake-proxy with any sort of port-security enabled.  Better yet, just don’t implement wake-proxy at all.

Here is a discussion we found afterwards, once we knew what to look for.
https://supportforums.cisco.com/discussion/11835361/mac-address-flapping-and-sccm-wake-proxy

I worked with ALU TAC all afternoon on this.  The only weirdness that we could see was that the packet capture showed that the computer was sending out replies to ARP packets that were not for his MAC address.