You are currently browsing the category archive for the 'Troubleshooting' category.

I finally completed upgrading our SCCM 2007 central site (and two secondary sites) to SP2.  Though it was successful, there were two issues that occurred as a result of the upgrade which may be useful for you to watch for. 

The first issue is that I was unable to update any distribution points for packages or adding new distribution points to a package.  This was being caused by a malfunctioning Distribution Manager in which the changes were being queued and not processed.

  • Issue can first be identified by noticing that updating package distribution points is “stuck” in a state of “Install Pending”
  • Check the distmgr.log – it may show that every the manager is attempting to validate every single package on every single distribution point…one at a time. 
  • If the distmgr.log will show a line that says “GetObject Failed error 0×8007003
  • If a file named “RESETISAPI.TRN” exists within  the DistMgr.box
  • Then the solution is founded in http://support.microsoft.com/default.aspx/kb/969163 for the second solution. 

The second issue that I experienced with the inability for unknown computers to know that there was a task sequence assigned to run.  Short of the long story is that I fixed the situation by deleting the existing advertisements and recreating them.

Sometimes when troubleshooting SCCM client software inventory, it is useful to retain the XML file which contains details on what the scan discovered.  To do this, simply create a file named “archive_reports.sms” within C:\WINDOWS\system32\CCM\Inventory\temp\.  If the scan is just reporting a delta, the file will be small.  But if it is a full SINV scan, then it could be large (the biggest I’ve seen is around 75 MB)

I have been struggling with a problem all day that, when I was inches from giving up, I found the cause and the workaround.  Thought I’d share it too.

Sometimes it is necessary to not force a mandatory start time for an SMS/SCCM advertisement, but intead to allow the end-user to manually trigger the advertisement/program from the control panel applet “Run Advertised Programs”.  The situation was that, for all servers within the targeted collection (only 4 servers total), the Run Advertised Programs applet was blank.  And there was no “New Program Available” system tray icon.  I tried everything from different Program settings, different Advertisement settings, reviewed the Advertised Programs Client Agent, collection settings, etc etc etc.

After taking a short break to play company softball, I came back to the office to practiced my Google-foo skills.  I stumbled upon a forum posting about RDP interfering with the applet.  With my fingers crossed, I launched RDP in admin mode (e.g. mstsc /admin), logged into the server, launched the Run Advertised Program applet, and voila …there was my advertisement.

Hopefully one day I’ll find the solution and update this post…or maybe someone will read it who already knows the solution!

When troubleshooting WMI on SMS/SCCM clients, I’ve frequently used the following command to attempt a repair of the WMI repository.  I don’t recall where I found it (several years ago), but I also don’t want to ever forget it!

  1. Open a command prompt
  2. Change to directory C:\Windows\system32\wbem\
  3. Run for /f %s in (‘dir /b *.mof *.mfl’) do mofcomp %s

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:

openfilesecuritywarning

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”

unblockexe

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.

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: 0×800701E7
Cause: Unknown.
Fix: Restart with boot CD or PXE.

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

Error: 0×80070490
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: 0×80070241
Cause: Error during TS user interface caused in memory
Fix: Restart with boot CD or PXE.

Error: 0×80072EE7
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.

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

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: Check Disk Space
end
item: Set Variable
  Variable=ROOT
  Value=C:
end
item: Get Environment Variable
  Variable=WINDIR
  Environment=WINDIR
end

Full DuplicateGUIDRepair.ipf Code Here

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.

Queue of Upcoming Posts

  1. Scripting XP Power Settings
  2. "Homegrown" Client Health Solution
  3. SCCM Superflows
  4. Creative Solution for Using Different Network Settings in Task Sequences
  5. Scripting the backup of VMWare Server 2 VMDKs

Blog Stats

  • 13,594

World Map of Blog Hits

Most Recent Visitors!

 

December 2009
M T W T F S S
« Nov    
 123456
78910111213
14151617181920
21222324252627
28293031