Wednesday, July 11, 2018

"New software is available"...

Are you seeing this in the system tray every time you log in to your computer? It's pretty annoying. There's even a Microsoft User Voice entry for it.

There is a workaround - set all your application deployment User Experience settings to "Display in Software Center, and only show notifications for computer restarts".

If you have a lot of applications already deployed, going through them one by one would be quite a chore. But, you can easily change all their settings via PowerShell.

In the code below, it changes the settings for every application we have deployed to the "User Optional - Software Center" collection.

#Import ConfigMgr PS module
Import-Module "$env:SMS_ADMIN_UI_PATH\..\configurationmanager.psd1"

#Connect to ConfigMgr drive
$SiteCode = Get-PSDrive -PSProvider CMSITE
Push-Location "$($SiteCode.Name):\"

#Change User Experience
Get-CMApplicationDeployment | Where-Object { 
    $_.CollectionName -eq 'User Optional - Software Center' 
} | Set-CMApplicationDeployment -UserNotification DisplaySoftwareCenterOnly

H/T Reddit

Thursday, May 24, 2018

Failed to install distribution point. Error 0x800706BA.

I was trying to install an additional distribution point and was getting the errors below in distmgr.log:


CWmi::Connect() failed to connect to \\server.domain.com\root\CIMv2. Error = 0x800706BA
DPConnection::ConnectWMI() - Failed to connect to  server.domain.com.
Failed to install DP files on the remote DP. Error code = 1722

Lots of Googling suggested the following suggestions:

I had done all this. Still seeing the same error. Then we checked NSLOOKUP. There was no record in DNS for our server name.

As it turns out, the IP address for our server was previously assigned to another server in DNS. Our network department swapped it to our new server, and I was able to install the DP role.

I hope this helps someone, as I could not find this info anywhere!

Tuesday, April 3, 2018

Uninstall Office 365 via script

I had trouble finding this, so I'm documenting here. Need to uninstall Office 365? Here you go.

Create an uninstall.xml file:
<Configuration>
<Display Level="None" AcceptEULA="True" />
<Property Name="FORCEAPPSHUTDOWN" Value="True" />
<Remove>
    <Product ID="O365ProPlusRetail">
      <Language ID="en-us" />
    </Product>
</Remove>
</Configuration>

Create a batch file with the following:
set loc=%~dp0
"%loc%setup.exe" /configure "%loc%uninstall.xml"

Friday, March 9, 2018

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:





Tuesday, January 16, 2018

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

Friday, December 1, 2017

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"

Monday, November 20, 2017

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.



Monday, September 26, 2016

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.

Thursday, March 10, 2016

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.

Tuesday, July 14, 2015

“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/

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"
}
} 

Friday, September 26, 2014

Dell OptiPlex 9020 Windows 8.1 OSD Black Screen, No Cursor

When we tried to image a Dell OptiPlex 9020 with Windows 8.1, the screen would go black after applying the drivers, and we never got a logon screen. I had heard of this issue, but people would also get the mouse cursor. We were not. I tried multiple driver cabs from Dell, all had the same issue.

First, I disabled the 9020 driver step:


I ran the task sequence again, and the system imaged fine. There were only 3 devices missing drivers on the small form factor, and 2 on the tower. I was able to apply those from our existing extracted driver cab. 

I noted the missing drivers and then disabled all the 9020 drivers excepts these 4:


Both versions of the 9020 started imaging properly. I had one more issue, though. The deployment would fail after hanging on installing software updates. I found this article which recommends updating your WIM with the software updates to avoid this issue. That did the trick, and our 9020's are imaging happily!

Monday, July 14, 2014

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!

Thursday, July 10, 2014

Task sequence fails with 0x80004005 - error while retrieving policy

One of our technicians was getting this error on two Dell OptiPlex 980's. WinPE would boot, he would click Next, then instead of getting the task sequence selection window, it would bomb out with the error above.

I found many possible solutions, and some were pretty extreme (deleting the MP and re-adding it, rebuilding packages, etc.). I'm glad I didn't try the most extreme solution first. As always, start simple!

I found this article which suggested it might be a date/time issue. We checked the BIOS, and the date/time was way off. After setting it to the correct date & time, the task sequence window came up and he imaged with no issue!