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.

“Cannot edit the object, which is in use by ‘username’ at Site ‘configmgr site’

If you've ever been in the middle of editing an application and had the ConfigMgr console crash, you've likely seen this message.

myitforum.com has a quick and easy way to unlock the object so you can get back to editing! Article is linked below, but here are the two queries to run in SQL Server Management Studio:

This query gets the ID of the locked object:
select * from SEDO_LockState where LockStateID <> 0

This query will delete the locked object, allowing you to get access again:
DELETE from SEDO_LockState where LockID = ‘<LockID of the record identified in the previous query>’

http://myitforum.com/myitforumwp/2013/02/22/unlocking-configmgr-2012-objects/

Computer in console not showing client as installed

We found a handful of computers that had the ConfigMgr client installed, but the console was not reflecting this. After some investigation on an affected computer, I noticed the client certificate said "none":

This is not normal. In addition, some of the items under the Actions tab were missing. Fortunately, I found this blog post that contained the solution. 

The computer was stuck in provisioning mode. The simple fix was to change the HKLM\SOFTWARE\Microsoft\CCM\CcmExec\ProvisioingMode registry key to "false", then reinstall the ConfigMgr client.  SEE UPDATE BELOW

NOTE: The safest bet is to reimage the system in question. If the step that removes the computer from provisioning mode didn't work, it's quite possible there were other issues during imaging. But this is a quick fix if you can't reimage for some reason.

H/T Daniel Classon

UPDATE: Thank you to Microsoft MVP and all-around swell guy Nash Pherson for pointing out that the registry method does not entirely remove the computer from provisioning mode. This article shows how to do it properly via a WMI method:

Invoke-WmiMethod -Namespace root\CCM -Class SMS_Client -Name SetClientProvisioningMode -ArgumentList $false

Or, run the following from an elevated command prompt:

powershell Invoke-WmiMethod -Namespace root\CCM -Class SMS_Client -Name SetClientProvisioningMode -ArgumentList $false

Gotcha - setting registry values via ConfigMgr

We have a package with a program that is supposed to set a registry value. This is a simple command, right?

reg add HKLM\Software\Whatever /v "KeyName" /t REG_SZ /d "Value" /f

When we deployed the program, the value would not be where we expected it, instead we found it here:

HKLM\SOFTWARE\Wow6432Node\Whatever

This blog post explains why this happens (32-bit process running on a 64-bit OS).

The fix is easy, simply add "%windir%\SysNative\" in front of your REG ADD command, like this:

%windir%\SysNative\reg add HKLM\Software\Whatever /v "KeyName" /t REG_SZ /d "Value" /f

Works like a charm!

H/T Brpo's Blog

PowerShell App Deployment Toolkit - "Launching this application has been temporarily blocked..."

I am a huge fan of the PowerShell App Deployment Toolkit. It allows us to deploy or upgrade applications that require certain applications to be closed in a friendly manner. Instead of just killing a process (say, Internet Explorer) before running a Java upgrade, you can let the user know that that IE needs to be closed and let them finish any unsaved work before closing it. There are numerous other wonderful features of this utility, I encourage you to read more at the link above.

That said, we had a strange experience with a recent upgrade from Java 1.7 to 1.8. A number of users were unable to launch Internet Explorer after the upgrade. They all had this error message, which is a window from the PS App Toolkit:

A little Googling led me to this article, which suggested a registry key may be the problem, Indeed it was:

The full value of the key was wscript.exe "C:\Users\Public\PSAppDeployToolkit\AppDeployToolkit_BlockAppExecutionMessage.vbs"

Removing this registry key solved the issue. This is unexpected behavior from this utility, it typically would remove this key upon completion. Perhaps it's a bug in the current version (v3.5.0). Still, it's a problem for us, so we needed to make sure this wouldn't affect any other users.

The solution was to add a line of code in the post-installation section of Deploy-Application.ps1.

Remove-RegistryKey -Key 'HKLM:SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\iexplore.exe' -Name 'Debugger' -ContinueOnError $True

The full post-installation section is shown below:

##*===============================================
##* POST-INSTALLATION
##*===============================================
[string]$installPhase = 'Post-Installation'

## 

## Clean up IE registry key
Remove-RegistryKey -Key 'HKLM:SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\iexplore.exe' -Name 'Debugger' -ContinueOnError $True
      
## Display a message at the end of the install
Show-InstallationPrompt -Message 'Installation complete.' -ButtonRightText 'OK' -Icon Information -NoWait

This solved our issue, and clients are upgrading and working as expected.

UPDATE: We still see a handful of computers that experience this issue. We resolve it by pushing them the below PowerShell script. It also adds a registry value in a hive we often use for other things (and we use this for the detection logic in this app), then it notifies the user with a popup window that IE should be working properly.

# Delete registry key
remove-itemproperty -path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\iexplore.exe" -name Debugger

# Create and set value in Chico registry section for detection method purposes
New-ItemProperty -Path HKLM:\SOFTWARE\Chico -Name IEDebugger -PropertyType String -Value "Fixed"

# Notify user
$wshell = New-Object -ComObject Wscript.Shell
$wshell.Popup("Your Internet Explorer issue should be resolved. Please try running it again. If there are still issues, please contact ITSS at x4357.",0,"Done",0x1)

ConfigMgr clients using previous server site code

I've run into a handful of systems with this issue since we migrated to our new CM2012 server. Some clients still have the old server's site code, no matter how we install the new client. The site code value can be found in the registry, and removing the value and installing the new client did the trick for us.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Mobile Client\

Source: http://myitforum.com/myitforumwp/2012/10/05/configmgr-client-gpo-assignment-removal/