Latest Event Updates

Blocked Executables

Posted on Updated on

When distributing software through SMS/SCCM, occasionally the advertisement will reach the time limit threshold of the package/program, which will generate an error for the advertisement.  There are two things that likely have caused this: first and foremost, the program truly didn’t finish installing in time.  Simply readjust the run time value in the program. 

Secondly, the execuble could be getting “blocked” and requesting the end-user to accept the Open File Security Warning.  If the program (for the package) is configured to be hidden and/or does not allow user interaction, then the user will never see such prompt (which is a good thing I might add).  Heck, even in your troubleshooting, you will never see the prompt (side note: if you are troubleshooting, then be sure to configure the program to run normal and allow user’s to interact with the program).  If you can see it, it would look like this below:


This is caused by the Windows Attachment Manager marking the file with a property that helps in the system security.  The quirky thing is that, if the executable is indeed blocked, not ever system is affected.  Though there are several variables that can contribute to the issue, the quick fix is to (in the original package source) right-click on the .exe, select Properties, click “Unblock”, then click “OK”


Going back to how this impacts SCCM software distribution, unblocking the .exe does little to change the actual file itself.  So if all you do is update your distribution points, then readvertise the distribution, the clients will not download the modified file…so the blocking will still occur.  It is easiest to simply delete the package and recreate it.  Keep in mind, if you did already modify the original package source files, then you can reuse the same source file location.


Scripting Windows Live 2009/2011

Posted on Updated on

The Windows Live Essentials suite comes bundled with various applications, such as Messenger, Mail, Writer, Toolbar, etc etc.  No suppose you need to script this install.  Well, it’s easy!  That is, it’s easy if you just want intall ALL of the applications.  But what if you only need to install Messenger?  Or Writer?  Or both?  Unfortunately, Microsoft hadn’t published anything publically yet on how to achieve this, so I had to contact PSS to get the information I needed.  Below are instructions for solely installing Messenger, but I’ll list the switches for the other applications.

  1. Download the WLSetup
  2. Install Messenger only by creating a scripted install that triggers WLSetup.exe /AppSelect:Messenger

Additional switches are as follows:

  • AppSelect:[ProductID] or ![ProductID]
  • log:log_location
  • NOToolbarCEIP (to not opt into Toolbar CEIP)
  • NOhomepage (to not set home page defaults)
  • Nolaunch (blocks all applications from running automatically after your installation is complete)
  • NOMU (to opt the computer into Microsoft Update)
  • nosearch (to not set search defaults)
  • q (for a silent/unattended install)

SCCM Task Sequence Error Codes & Fixes

Posted on Updated on

When performing a bare-metal image install in SCCM, occasionally an error will occur that will halt the initiation of a task sequence.  Below are a few errors I have experienced, which I have compiled with my own [brief] explanation and what to do to fix it.  This post will be updated as I come across new errors, explanations, alternate fixes, etc.

Error: 0x800701E7
Cause: Unknown.
Fix: Restart with boot CD or PXE.

Error: 0x80070032
Cause: No file system
Fix: Using command support, format (quick) the disk or recreate the disk using diskpart.exe

Error: 0x80070490
Cause: Failed to find driver for PCI\VEN device
Fix: Review SMSTS.log for driver info. Likely need to add the PCI\VEN into an .inf or txtsetup.oem file

Error: 0x80070241
Cause: Error during TS user interface caused in memory
Fix: Restart with boot CD or PXE.

Error: 0x80072EE7
Cause: IP address is not on a subnet that connect to the SCCM server
Fix: Change the port the Ethernet cable is connected on. Restart with boot CD or PXE.

Fix for SCCM Remote Tools

Posted on

After a recent upgrade of SMS 2003 clients to SCCM, we had some diffucult with remote tools not being able to connect.  All components were installed correctly, drivers installed/registered, and files existed.  While I’m still unsure of the cause, I managed to find a fix.  So if you’re having diffuculties with using remote tools, give this a try.  Even if you didn’t recently upgrade from SMS.

  1. Delete directory %windir%\system32\ccm\clicomp\Remtrl\ 
  2. Run %windir%\system32\ccm\ccmrepair.exe

Scripting HKCU Changes

Posted on Updated on

In a corporate environment, distributing software can frequently be tricky.  One thing that can cause the most headaches is when there are registry changes that need to be made within the HKCU hive of any or even every user.  For example,  Apple designed QuickTime to allow every user to decide whether or not to enable automatic updates.  So this value is set in HKCU\Software\Apple Computer, Inc.\QuickTime\LocalUserPreferences\.  But in a controlled environment, you really don’t want the users doing their own thing.  So the package needs to be designed in such a way that edits the aforementioned registry key.

With SMS/SCCM, one could always build a script to make the change and configure the Program to run every time a user logs on.  I used to do it this way, but grew tired of constantly needing to monitor that the advertisement is successful and there are not alot of failures…so I became my own thinktank to figure out a new process.  What I realized is that I could use the existing WinXP registry tool (reg.exe) to make all the changes I need.

The process kind of looks like this: once there is no user logged into Windows, I run a script that

  1. Parses HKLM for every user profile
  2. Loads the discovered user’s registry hive
  3. Makes the HKCU change
  4. Unloads the user’s registry hive
  5. Moves onto the next profile

This even modifies the Default User’s profile so that anyone who logs onto the computer for the first time will already have this setting!  Rinse.  Repeat.  Done.

NOTE: If you’re looking for a sample script to delete a registry key or value, see

' Author: Nick Moseley,
' Comments: This script will parse all User profiles on the computer, load their  HKCU hive, 
'    then set the appropriate registry keys. 
' History: 
'    1.0 (04/07/2009) - Initial script 
'    1.1 (06/03/2009) - Added example for setting dword values based on MyITForum question
'    1.2 (06/05/2009) - Added additional comments to identify the section where to define the values to be set
'    1.3 (09/23/2010) - Corrected comment typos
Option Explicit
Const ForAppending = 8
Const HKLM = &H80000002
' ************************************************ 
' Configure the following values to define the HKCU keys to be set 
' ************************************************ 
Const sStringUserKey = "\Software\SampleKey"
Const sStringUserKeyValueName = "SampleValueName"
Const sStringUserKeyValue = "SampleValue" 
Const sDwordUserKey = "\Software\SampleKey"
Const sDwordUserKeyValueName = "SampleValueName"
Const sDwordUserKeyValue = "SampleValue"
' ************************************************
Dim oReg, oFSO, oFile, oUserSubkey, aUserProfiles, oShell
Dim sProfileLCase, sRegExe, sRegLoad, sRegUnload, sHiveName, sSubPath, sProfile, sValueName, sKeyPathUserProfiles, sValue, ReturnVal
Set oReg = GetObject("winmgmts:\\.\root\default:StdRegProv")
Set oShell = CreateObject ("WScript.Shell") 
Set oFSO = CreateObject ("Scripting.FileSystemObject")

' Begin configuration of existing user profiles
sValueName = "ProfileImagePath"
sKeyPathUserProfiles = "SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList"
sRegExe = "C:\Windows\system32\reg.exe"
oReg.EnumKey HKLM, sKeyPathUserProfiles, aUserProfiles
For Each oUserSubkey In aUserProfiles
    sSubPath = sKeyPathUserProfiles & "\" & oUserSubkey
    oReg.GetExpandedStringValue HKLM,sSubPath,sValueName,sValue
    sProfile = Split(sValue, "\")
    sProfileLCase = LCase(sProfile(2))
    If sProfileLCase = "system32" Then
     ' Do nothing
    ElseIf sProfileLCase = "localservice" Then
     ' Do nothing
    ElseIf sProfileLCase = "networkservice" Then
     ' Do nothing
    ElseIf sProfileLCase = "serviceprofiles" Then
     ' Do nothing
     sHiveName = "TempHive_" & sProfileLCase
     ' Load user's profile hive into a temp location
     sRegLoad = " LOAD HKLM\" & sHiveName & " """ & sValue & "\ntuser.dat"""
     oShell.Run sRegExe & sRegLoad, 0, True
     ' Call subroutine to change registry key
     SetConfigUserHive (sHiveName)
     ' Unload user's profile hive
     sRegUnload = " UNLOAD HKLM\" & sHiveName
     oShell.Run sRegExe & sRegUnload, 0, True
    End If 

' Default User Profile
sHiveName = "TempHive_DefaultUser"
sRegLoad = " LOAD HKLM\" & sHiveName & " ""C:\Documents and Settings\Default User\ntuser.dat"""
oShell.Run sRegExe & sRegLoad, 0, True
SetConfigUserHive (sHiveName)
sRegUnload = " UNLOAD HKLM\" & sHiveName
oShell.Run sRegExe & sRegUnload, 0, True
WScript.Quit ()
Sub SetConfigUserHive (sTempHive)
Dim sTempHiveStringKeyPath, sTempHiveDwordKeyPath

' Path of registry keys
sTempHiveStringKeyPath = sTempHive & sStringUserKey
sTempHiveDwordKeyPath = sTempHive & sDwordUserKey

' Create String registry key if the value doesn't already exist
If oReg.GetStringValue(HKLM, sTempHiveStringKeyPath & "\", sStringUserKeyValueName) <> 0 Then
    ReturnVal = oReg.CreateKey(HKLM, sTempHiveStringKeyPath)
End If
' Create Dword registry key if the value doesn't already exist
If oReg.GetDwordValue(HKLM, sTempHiveDwordKeyPath & "\", sDwordUserKeyValueName) <> 0 Then
    ReturnVal = oReg.CreateKey(HKLM, sTempHiveDwordKeyPath)
End If
' Create String value
ReturnVal = oReg.SetStringValue(HKLM, sTempHiveStringKeyPath & "\", sStringUserKeyValueName, sStringUserKeyValue)

' Create Dword value
ReturnVal = oReg.SetDwordValue(HKLM, sTempHiveDwordKeyPath & "\", sDwordUserKeyValueName, sDwordUserKeyValue)
End Sub

Duplicate SCCM Client GUIDs / Full Client Reinstall

Posted on Updated on

This was an issue that I came across from our recent upgrade from SMS 2003 to SCCM 2007.  While we were still using SMS, some systems had been cloned/p2v’d from a production system to a virtual then renamed.  It wasn’t caught at the time, but it appears SMS may have been unable to automatically give the cloned SMS clients a new GUID.  When we migrated to SCCM, these clients were fighting over which of them was the real and live system in SCCM, such that some client records would suddenly disapper from the console…then if they’re client was fixed, a different client record would disappear.

However, simply uninstalling/reinstalling the SCCM client was not resolving the issue.  After some digging around, I found a couple of utilities to help rip out the SCCM client and force a new GUID to be assigned.  I brought these utilities together and created a simple executable to coordinate the process.  This was created with the old, but very reliable, SMS Installer, the code below is for that, but can easily be rebuilt as a vbscript.

If you have any questions about this process, feel free to leave me a comment and I can respond!

  1. On your computer, download and install the SMS 2003 Toolkit v2
  2. In the directory containing your SCCM client install, create a subdirectory (such as “SOURCE”)
  3. From the Toolkit directory, copy ccmdelcert.exe and tranguid.exe to the newly created subdirectory in previous step
  4. In the SCCM client install directory, create an executable or script that does the following in order
    • Execute ccmdelcert.exe (wait for process termination)
    • Delete the file %WINDIR%\SMSCFG.ini
    • Execute ccmsetup.exe /uninstall (wait for process termination)
    • Delete directory %WINDIR%\system32\ccm\
    • Delete registry key HKLM\SOFTWARE\Microsoft\CCMSetup
    • Delete registry key HKLM\SOFTWARE\Microsoft\SMS
    • Execute ccmsetup.exe (wait for process termination)

Below is the ‘code’ for the SMS Installer executable that I built to facilitate this.

Document Type: IPF
item: Global
  Title English=Duplicate SCCM GUID Repair
  Languages=0 0 65 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  Default Language=2
  Copy Default=1
  Japanese Font Size=9
  Start Gradient=0 0 255
  End Gradient=0 0 0
  Windows Flags=00000100000000010010110000011000
  Message Font=MS Sans Serif
  Font Size=8
  Disk Filename=SETUP
  Patch Flags=0000000000000001
  Patch Threshold=85
  Patch Memory=4000
  FTP Cluster Size=20
item: Check Disk Space
item: Set Variable
item: Get Environment Variable
item: Execute Program
item: Delete File
item: Execute Program
  Command Line=/uninstall
item: Insert Line into Text File
  New Text=TEMP
  Line Number=0
item: Delete File
item: Insert Line into Text File
  New Text=TEMP
  Line Number=0
item: Delete File
item: Edit Registry
  Total Keys=1
item: Edit Registry
  Total Keys=1
item: Execute Program

Troubleshooting with System Context

Posted on Updated on

When creating a Program for a Package, there are essentially two Environment options for how the Program run – with the user’s rights, or with administrative rights.  Using administrative rights will cause the program to run the command line under system context (svchost). 

I recently needed to test an install (when running under system context and when running from the SCCM server) as I was unable to visually see the behavior first hand (e.g. errors).  To do this type of testing, follow these simple instructions.

  1. Log in to Windows with an account that has admin privileges
  2. Launch cmd.exe
  3. Enter “time” and get the value. 
  4. Enter “at time+1min /i cmd” – this will open another command prompt at that time
    For example, if the time is 14:18, the value time+1min will be 14:19
  5. Once the next command prompt opens, you’ll notice that process listed in the title bar is “svchost.exe”
  6. Enter “net use z: \\servername\share”
  7. Enter credentials that have access to the share, such as your own
  8. Then change to new driver letter and then to the directory.  From there you can launch whatever .exe, .msi, script, etc, that you need visually see.

I used this process to confirm that executables and .msi files were being blocked with an Open File – Security Warning when running from a server share.