WDS Role Disappearing from PXE Service Point After Imaging

I recently ran into a fun (by “fun” I mean “not fun”) issue during OSD. After I had PXE booted a machine and it successfully loaded PE, received policy, etc., I noticed something very peculiar…WDS was completely missing from my PXE Service Point. Not, stopped. Not improperly configured. Gone. Missing. No WDS.

After I questioned everything that I have ever learned, lived and loved, I got lucky. I checked the Site Status in SCCM (under Monitoring > System Status) and noticed that the Distribution Point role showed up twice for the same server, only one pointed to the proper drive and the other to the C drive!

After much reflecting, I came to the realization that I caused this while troubleshooting another issue. I had removed the DP role from the server, but left the SMSPKG directory in place. Therefore, when I added the role once again, SCCM attempted to install the DP to the drive with the most space. As the SMSPKG directory took up most of the space on its drive, SCCM attempted to configure the C drive.

Apparently, adding the PXE role to the DP made everything go haywire. So, I removed the DP role once again, and applied the oldest trick in the book…I created a file called no_sms_on_drive.sms and placed it on the drives in which I did not want the DP installed. After adding the DP role back and enabling PXE, WDS and I are good friends again.

Updating Java with SCCM the Easy Way

Java updates itself more frequently than we update this blog. This can make administering your environment a chore, especially if you are surrounded by a team of Chicken Littles, screaming about how vulnerable your environment is if you do not update quickly.

While I am of the mindset that, yes, the holes that have recently been exploited in Java are serious and should be patched, I also believe that, if you have the proper security measures in place, you are typically safe. Nevertheless, I decided to deploy the most recent version (as of this writing, Java 7 Update 21) to our workstations.

Obviously, the best way to deploy anything to user workstations is via SCCM. However, since Microsoft does not offer 3rd party updates through the Software Update Point, and (in my opinion) using SCUP to update 3rd party software is a chore, I decided to customize a series of scripts that I found to make updating Java a breeze. As a bonus, the script adds a registry key to disable Java auto-updates. The steps are as follows:

1)      Find and run the executable to display the splash screen, but DO NOT CLICK THROUGH THE PROMPTS (did I say that loud enough?):


2)      Browse to %userprofile%\AppData\LocalLow\Sun\Java and copy the directory (or directories if deploying both x64 and x86 versions) to the location in which you store your SCCM software packages; these directories contain the necessary .msi and .cab files for this deployment:



3)      Copy the two following scripts to the same location as you copied the Java folders; the .cmd kicks off the install, killing all open browsers and calls the .vbs which installs all previous versions of Java:

***Install.cmd ***

@echo off

taskkill /F /IM iexplorer.exe

taskkill /F /IM iexplore.exe

taskkill /F /IM firefox.exe

taskkill /F /IM chrome.exe

taskkill /F /IM javaw.exe

taskkill /F /IM jqs.exe

taskkill /F /IM jusched.exe

REM Call the uninstall script

cscript %~dp0Java_Uninstall.vbs

REM Install JRE x86

msiexec.exe /i %~dp0\Java7Update21_x86\jre1.7.0_21.msi /passive /norestart /l*v c:\windows\temp\Java7x86.log

REM Installing JRE x64

if exist %ProgramFiles(x86)%

msiexec.exe /i %~dp0\Java7Update21_x64\jre1.7.0_21.msi /passive /norestart /l*v c:\windows\temp\Java7x64.log

REM Disable automatic updates

reg delete “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run” /v SunJavaUpdateSched /f

reg add “HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Update\Policy” /v EnableJavaUpdate /t REG_DWORD /d 0 /f

REM Return the exit code to SCCM

exit /B %EXIT_CODE%



On Error Resume Next

strComputer = “.”

Set objWMIService = GetObject(“winmgmts:” _

& “{impersonationLevel=impersonate}!\\” & strComputer & “\root\cimv2”)

‘Uninstall Java 2 Runtime Environment, J2SE Runtime Environment

Set colJava4dot3 = objWMIService.ExecQuery(“Select * from Win32_Product Where Name like ‘Java 2 Runtime Environment Standard Edition %'”)

For Each objSoftware in colJava4dot3




‘Uninstall Java 2 Runtime Environment, J2SE Runtime Environment

Set colJava4dot3 = objWMIService.ExecQuery(“Select * from Win32_Product Where Name like ‘J2SE Runtime Environment %'”)

For Each objSoftware in colJava4dot3



‘Uninstall Java 2 Runtime Environment, SE *

Set colJava4dot3 = objWMIService.ExecQuery(“Select * from Win32_Product Where Name like ‘Java 2 Runtime Environment, SE %'”)

For Each objSoftware in colJava4dot3



‘Uninstall Java(TM) 6 Update *

Set colJava6dot = objWMIService.ExecQuery(“Select * from Win32_Product Where Name like ‘Java(TM) 6 Update %'”)

For Each objSoftware in colJava6dot



‘Uninstall Java(TM) 7 Update *

Set colJava6dot = objWMIService.ExecQuery(“Select * from Win32_Product Where Name like ‘Java(TM) 7 Update %'”)

For Each objSoftware in colJava6dot



‘Uninstall Java(TM) 7 *

Set colJava7 = objWMIService.ExecQuery(“Select * from Win32_Product Where Name like ‘Java(TM) %'”)

For Each objSoftware in colJava7




4)      Create a program to run the Install.cmd whether or not a user is logged on

5)      Distribute the files to the distribution point

6)      Deploy to your collection of machines that are to receive the update (after you test, of course)

7)      Repeat in 2 weeks when Java is updated again…

Now that you have these scripts, you only need to replace the files using steps one and two whenever Java needs updating. I hope this helps those who are looking for a quick way to deploy Java updates to their environment using SCCM!

SCCM 2012 Updates – Shortcut

Recently, I received the following from a reader:

“Dear Jesse-

I want to create a software update structure in SCCM 2012 that follows best practices and gives me the most efficient process possible. However, I just feel lazy today and just can’t seem to muster up the strength to right-click and create folders or collections. Do you have any way that I can cheat the system while still looking like a hero?

Yours truly,

Flabby Flabberson”

Well, Mr. Flabberson…I appreciate your lack of enthusiasm and general disdain for anything requiring effort. With that said, I have a perfect solution. Fittingly enough, I am too lazy to type that solution, so I will send you to Windows-Noob where they have a pre-created script that generates a nice little folder structure complete with all the collections you need. What nice guys!


Jesse-C-M (see what I did there?)

Forcing ETL Jobs in SCSM 2012 SP1

After a recent upgrade from SCSM 2010 to 2012 SP1 (which was done by none other than Jason Rutherford), I noticed that there were a couple Data Warehouse ETL (Extract, Transform, Load) jobs that were hanging. I determined that this was most likely due to an abundance of data that had been waiting to process, as the previous environment was unhealthy, which caused the jobs to timeout.

During my scouring of the interwebs looking for PowerShell commands, I came across a thread by the brilliant Travis Wright. As Travis constantly demos Service Manager, he found that waiting for the jobs to run according to their default setting (which is adaptable, but that’s beside the point) was holding back his progress. So, he wrote a script to constantly process the jobs until they report back as complete.

Bingo! This is exactly what I needed to ensure that the jobs would not timeout. So, I downloaded the script, changed a few variables to fit my environment and ran it against my jobs. A little bit later, all jobs were complete and all data had been processed!

Below is a link to the script. Hopefully, you find this handy for either your lab or production environment.


(It is important to note that this script will only run in SCSM 2012)

Manually Uninstall a Stubborn SCOM Agent

At work, I was recently given the task of upgrading our SCOM environment from 2007 R2 to 2012 SP1. “No problem, boss!” I said boastfully. After all, upgrades are typically seamless and always go smoothly.

After I took my medicine to cure delirium, I began flowing through and reached a point where I needed to uninstall the 2007 R2 agent from a machine. However, whenever using the SCOM console, the uninstall failed for unspecific reasons. “No big deal,” I said. “I guess I will just have to manually uninstall. That should be easy!”

The medicine had apparently worn off.

When I attempted my uninstall, I ran into the following:


Alright! I’ve seen that a million times! “Error 25205 Failed to uninstall SDK MOF blah blah stuff and things I’m totally screwed.”

After 30 minutes of pure panic and 15 more of stress-eating yesterday’s donuts, I began the troubleshooting steps that eventually fixed this issue:

1) From a machine with a healthy SCOM agent, I copied mom_tracing.mof from “%ProgramFiles%\System Center Operations Manager 2007” to the same directory on my troubled machine:



2) Then, on the machine that was barking at me, I ran (from an elevated command prompt) mofcomp mom_tracing.mof:



Naturally, I ran into the above error. Time to freak out, right? Nah…we’re good. I just went to steps 3 – 5:

3) I mapped a drive on my troubled machine to %WinDir%\system32\wbem on a machine with a healthy agent and copied *.mof and *.mfl to the same directory on my local machine:




4) Then, from an elevated command prompt, I ran for /f %s in (‘dir /b *.mof *.mfl’) do mofcomp %s to compile all that I copied over:


5) Then, a quick restart of the winmgmt service and I was able to uninstall the agent:


After I cleaned up the piles of donut crumbs and changed out of my soiled drawers, I was then able to move forward knowing that I would not run into anything else that difficult during my upgrade! (Time to take my medicine again)