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)

Removing features from Office 2013 during imaging

Problem: Office 2013 is built into our base image, but some of our lab computers need Outlook and Lync removed.

First, I should say, this is not possible. You cannot simply remove Office features during the imaging process. However, there is a workaround.

What you need:

• Your custom Office installer that excludes Outlook and Lync (or whatever feature you're trying to exclude)
• The SilentUninstallConfig.xml file

In our scenario, we have a few labs that need a different Office configuration, plus some additional apps that are not included in our standard image. I set up groups for these areas in the TS (see image below) with settings only to run if certain conditions are met (ComputerName Like XXX, for example).

Create your SilentUninstallConfig.xml file, or download it here. 

SilentUninstallConfig.xml:

Place it in the ProPlus.WW folder in your Office share (be sure to update the content on your DP!).

Add a Run Command Line step in your TS before your Office 2013 custom install:

setup.exe /uninstall ProPlus /config .\ProPlus.WW\SilentUninstallConfig.xml

Be sure to include the path to your Office share in Start In:.

You're all set! This step only takes a few minutes and your custom Office 2013 install will work as expected.

Changing the ConfigMgr 2012 size and location

One of our labs requires different cache settings than the rest of the systems in our organization. I found some simple VB Scripts and PowerShell scripts that should accomplish this. Unfortunately, these would work when I ran them locally on the machine, but they would not run properly if deployed as an application.

As it turns out, modifying client cache location via app deployment does not work, because you're running the app from the existing cache location.

Rick Jones, a contributor on the ConfigMgr mailing list suggested creating a batch file that copies the VB Script to another folder and calling it from there. It's a nice little workaround!

Here's what I did (details below):

• Create a file called ChangeCacheSettings.cmd
• Create another file called ChangeCacheSettings.vbs
• Use the batch file to call the VBS file

Details of each file:

ChangeCacheSettings.cmd:

@echo off

MKDIR "C:\CCMCache"

:paths
SET loc=%~dp0

COPY "%loc%ChangeCacheSettings.vbs" "C:\CCMCache" /Y

cscript "C:\CCMCache\ChangeCacheSettings.vbs"

ChangeCacheSettings.vbs (mostly borrowed elsewhere online):

On Error Resume Next

'Sets cache size and location
Dim UIResManager 
Dim Cache 
Dim CacheSize
Dim CacheLocation

CacheSize=20480
CacheLocation="T:\"

Set UIResManager = CreateObject("UIResource.UIResourceMgr")

Set Cache=UIResManager.GetCacheInfo()

Cache.TotalSize=CacheSize
Cache.Location=CacheLocation

'Set registry key for detection method
const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set StdOut = WScript.StdOut
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_ 
strComputer & "\root\default:StdRegProv")
strKeyPath = "SOFTWARE\CustomSettings"
strValueName = "ConfigMgr-Cache-Config"
strValue = "TRUE"
oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue

'Sleep 5 minutes to allow time for for this portion of the script to complete 
WScript.Sleep 300000

'Clean-up - Delete the C:\CCMCache folder
strPath = "C:\CCMCache"

DeleteFolder strPath

Function DeleteFolder(strFolderPath)
Dim objFSO, objFolder
Set objFSO = CreateObject ("Scripting.FileSystemObject")
If objFSO.FolderExists(strFolderPath) Then
 objFSO.DeleteFolder strFolderPath, True
End If
Set objFSO = Nothing
End Function

'Sleep 30 seconds to allow time for this portion of the script to complete 

WScript.Sleep 30000

Adding the sleep command ensures everything executes properly. 5 minutes for the first one may seem excessive, but the same guy that offered this method recommended it, it worked for me, so I stuck with it.

Also, note that I did not specify a folder name for the cache folder. It will default to "ccmcache", in this case T:\ccmcache. If I specified T:\ccmcache in the script, it would have ended up being T:\ccmcache\ccmcache.

Building the Application

Create a new application, and set ChangeCacheSettings.cmd as the program in your deployment type. Set your detection method as follows:

• Setting Type: Registry
• Hive: HKLM
• Key: Software\CustomSetttings
• Value: ConfigMgr-Cache-Config

There are other ways to set your detection method. You could use a dummy text file, or a number of other options. This one was just easy for me to do.

Lastly, I added return code "1" as a success, as that is what is returned. By default, it's not included in the return codes.

Deploy to your collection as required, and you're set!

Microsoft .NET Framework 4.5 not installing during OSD

I was trying to deploy .NET 4.5 during my OSD task sequence, as another app required it. At first, it seemed like the other app was the issue, as it would take the full 120 minutes of time to run, then wouldn't install. I hit F8, ran CMTrace, then opened the AppEnforce.log file and noticed this error:

Unmatched exit code (16389) is considered an execution failure.

It sure is! I had bundled this as an application, and the program was running "NDP451-KB2858728-x86-x64-AllOS-ENU.exe" /q /norestart. This should work. It did not. In fact, besides the error, it ran this step pretty fast. The .NET 4.5 framework tends to take a long time to install, so this was definitely not right.

Buried deep in this TechNet article is a response that suggested bundling .NET 4.5 as a package instead. So I did, and created a program inside with the same command line (minus the quotes), and it installed properly! The application that required it also installed properly.

Having trouble deploying an app? Try it as a software package instead and see what happens!

EDIT: See comment section for an alternative to this using Application instead of Package.