A cleaner looking restart application

We recently started testing Anders Rodland's client health script. I really like the script, it does a great job of reporting client health issues and remediates some common client health problems.

One of the sections of his script checks to see if the client is in a pending reboot state and uses a shutdown utility by Coretech that displays a message to the end user:

This utility works perfectly fine, but my users were quite put off by its appearance. Some thought it might be malware. Unfortunately, there is no way to modify the appearance of the popup message, other than the text ("we are about to install a new version...").

If we were going to use this script and take advantage of the restart option, we needed a friendlier looking restart prompt.

Enter the PowerShell App Deployment Toolkit. This utility is excellent for a wide array of things. We typically have used it for deploying applications where we want to provide some user notification or interaction.

By using a couple of the built-in features of this utility, I was able to create a very simple restart app that uses our logo, colors, and text. We added a countdown timer to the restart window to allow the user some time to save work and close apps.

You can read their instructions for customizing the appearance and how to deploy it, but here are the commands I used for this purpose. No steps are needed in any of the sections in Deploy-Application.ps1 except for the post-installation section.

##*===============================================
##* POST-INSTALLATION
##*===============================================
[string]$installPhase = 'Post-Installation'
  
## Perform Post-Installation tasks here
        
Show-InstallationPrompt -Message 'Your computer must be restarted to complete installation of important security updates. You will be given 10 minutes to save your work and close any open applications.' -Icon Information -ButtonMiddleText 'OK'
        
Write-Log -Message "Restarting computer"
        
Show-InstallationRestartPrompt -Countdownseconds 3600 -CountdownNoHideSeconds 60

You can modify the number of seconds to suit your needs. The first number is the initial countdown, the second number is the countdown if the user clicks "Restart Later". When it runs, it looks like this:

Error: 80004005 during imaging

I saw this error in smsts.log when installing applications during OSD. AppEnforce.log had no errors.

I then found this error in CITaskMgr.log:

A little more sleuthing in the CAS.log showed the problem:

The cache was not big enough to download all of the required content. You can change your ConfigMgr client install parameters to increase the cache size (SMSCACHESIZE=XXXXX) to resolve this. In my case, I didn't want all clients to have the larger cache size, so I only applied this to one group of systems. In the section where I'm installing these apps, I add a PowerShell script to increase the cache size:

$Cache = Get-WmiObject -Namespace 'ROOT\CCM\SoftMgmtAgent' -Class CacheConfig
$Cache.Size = '20480'
$Cache.Put()
Restart-Service -Name CcmExec

Adobe Acrobat Pro DC installation failure - exit code 1603

I was getting this error when imaging a new machine. Other apps were installing fine. The error itself didn't offer much information.

I modified the command line to include verbose logging:

MSIEXEC /i "%loc%AcroPro.msi" /q /norestart TRANSFORMS="%loc%AcroPro.mst" /L*V "%loc%Acrobat.log"

I ran the install again and looked at the log file. There I found an error regarding Visual C++ Redistributable 2013. The install failed because this was not present.

Adobe kind of buries the workaround in their documentation, but addding "IGNOREVCRT64=1" to the command line ignores the Visual C++ Redistributable 2013 requirement and installs cleanly.

MSIEXEC /i "%loc%AcroPro.msi" /q /norestart IGNOREVCRT64=1 TRANSFORMS="%loc%AcroPro.mst" /L*V "%loc%Acrobat.log"

Class not registered (Error: 80040154; Source: Windows)

After setting up a new ConfigMgr site, I was testing OSD using a migrated task sequence. We use an HTA front end that collects some basic information about the user: department, building, room, role, etc. This HTA is part of a small package we built in ConfigMgr. However, when we selected the task sequence and the package tried to load, the task sequence failed:

A Google search did not shed any light on the issue. That's why I'm posting this blog, maybe it will help some poor soul.

The reason for this error is HTA support is not enabled by default in WinPE. Without it, HTA files fail to run. You can enable this by doing the following:

From the ConfigMgr console, navigate to Overview - Operating Systems - Boot Images. Right click your boot image (we use the x64 image), and select Properties. Click the Optional Components tab and check HTML (WinPE-HTA). We also added a few more options, such as PowerShell.

Once you do this, you will need to follow the steps to update your boot image.

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/