Wednesday, April 29, 2015

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.


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

Monday, March 30, 2015

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

Friday, February 20, 2015

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)

Monday, January 5, 2015

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/

Thursday, November 6, 2014

Windows not activated after OSD, ConfigMgr client not fully installed

I saw this email the other day on the Windows - Higher Ed mailing list:

I have run into a strange issue that I have not encountered before. I am trying to image a new Dell Precision T1700 desktop with Windows 8.1 using SCCM. I have imported all the drivers from the Dell CAB into CM. The machine images fine, loads software, joins the domain, etc. When I login, it fails to have the CM client fully installed, doesn't see our KMS server for activation, and oddly enough, is missing all the event logs that are normally found under “Applications and Services”. 

The exact same thing had happened to me the day before imaging a Dell OptiPlex 9020. The cause was a recent Microsoft security update that required two restarts. These updates sometimes will completely kill your task sequence, but sometimes will allow the image process to complete, only to find oddities like the emailer mentions above.

An easy workaround is to inject the problem updates directly into your WIM and update the distribution point in ConfigMgr. This way they won't cause any reboots during the task sequence. You can also just inject all updates if you choose (I do, as it makes the imaging process go a bit faster), but I've heard some users say they've had issues with this.

There are a couple ways to do this, one is using the DISM tool, which works great, but is done via command line. The other is to use the built-in ConfigMgr feature, Schedule Updates, which uses a GUI and is really easy. I prefer easy.

This should resolve this issue. Let's hope Microsoft doesn't release any more of these double restarters, but I'm sure they will. You can keep track of the known troublemakers here.

H/T to ConfigMgrBlog (although this is not just a Windows 7 issue)

Thursday, October 16, 2014

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.

Wednesday, October 8, 2014

PowerShell script to disable computers in Active Directory, update the description, and move to a disabled OU

We have always disabled stale AD accounts using a list of computers that hadn't logged onto the domain for a certain number of days (rather than just disabling them without the list). This allowed us to make sure we weren't disabling any known good computers.

We also moved the computer to a disabled computers OU and updated the computer description to indicate when it would be safe to delete the computer account.

We had been using a VB script to disable accounts, but it was unreliable. It never seemed to take care of every computer on the list, and I would have to manually disable these computer accounts that it missed.

This script also was fairly large and complex. Enter PowerShell! The script below was modified slightly from a script I found in the comments of this article. The script performs the following actions:
  • Reads in a list of computers (c:\Scripts\ADCleaner\computers.txt) to be disabled.
  • Updates the computer description to "ITSS - Delete on xx/xx/xxxx". The date it sets is 90 days from the current date.
  • Disables the account
  • Moves the account to the Disabled - PC & User folder in AD
  • Logs the action (c:\Scripts\ADCleaner\computers.log)
This should only require minimal modification to work in your environment. Download script below.

AD-Disable.ps1.txt

$Today = Get-Date
$Desc = "ITSS - Delete on: " + $Today.AddDays(90)

$Computers = Get-Content c:\Scripts\ADCleaner\computers.txt

ForEach ($Computer in $Computers)
{ $ADComputer = $null
$ADComputer = Get-ADComputer $Computer -Properties Description

If ($ADComputer)
{ Add-Content c:\Scripts\ADCleaner\computers.log -Value "$Today - Found $Computer, disabled and moved to Disabled - PC & User OU"
Set-ADComputer $ADComputer -Description $Desc -Enabled $false
Move-ADObject $ADcomputer -targetpath "ou=Disabled - PC & User,dc=csuchico,dc=edu"
}
Else
{ Add-Content c:\Scripts\ADCleaner\computers.log -Value "$Today - $Computer not in Active Directory"
}
}