Failed to start the ccmsetup service (1068)

If you are finding that the SCCM client is failing to install on some of your machines you may find this error message in the CCMSETUP.LOG file.

I'm currently going through a collection populated by machines without the SCCM Client - I found on some of these machines (this may not be that eureka fix) that the BITS service wasn't running.

By going into remote computer management I was able to set the Background Intelligent Transfer Service (BITS) to Automatic and then Start it up.

No pressure!

So today I'm pushing out the pilot PCs in our finance team - a mixture of in situ upgrades from XP to 7 and also a portable media (USB) build.

If they let me back into the office tomorrow I know it's gone ok!

Windows 7 Pilot

So the pilot went live today. Our rollout contractor and supplier were both at HQ to watch our first presaged machine go from warehouse to desk and thankfully it built without a hitch.

3 more were put in situ with a further 2 having to go on hold as we had a [unrelated] network outage - apparently it was a touch too warm today for our aircon units in the datacentre.

Really happy with the outcome of Prestaged Media within SCCM and will continue to blog further findings :)

Empty program list in SCCM Task Sequence

I've just come in to find our Windows 7 builds are failing on a specific program that is installed during the task sequence.  It happens it was Trend Anti Virus which I had been working on the previous day.

Before getting into the log files I had a look at the task sequence and noticed that there was no program listed.  Ah ha!  Problem solved > click drop down and select program....  No programs are listed ??!!  I checked the package and I have two programs in there - a standard install and one with verbose logging enabled...

Tried deleting the step in the TS and recreating it... Still nothing...

Resolution

I hold my hand up here - I had changed the interaction to "Only when a user is logged in"

Changed it back and sure enough it was back to normal.


Not so much a problem but it's worth noting - if it's a Friday morning and you haven't had your coffee yet it may catch you out...

Hope this helps someone :)

Best of MMS 2012 Manchester

So I've been dispatched off to the big smoke that is Manchester, the Hilton in fact, for the 1st UK leg of their MMS seminar. I've survived the first leg and made it to brew time and now about to kick off with round 2.

If you're lucky I'll bring you up to speed later.

#mmsuk

SCCM Collections not updating - eggtimer displays

I've had a problem with the old girl recently - our SCCM 2007 environment had been chugging along nicely until a few weeks ago.

We have approx. 500 collections with update schedules running pretty evenly throughout the day.  As I'm sure you will agree the annoyance of the the old Update Collection Membership and then refresh the console is a blight on our day - but when that little red eggtimer WILL NOT DISAPPEAR it sends my SCCM OCD twitching and I just cannot carry on with my day until I've sorted it...

 

I've done a fair bit of Googling and not really found that many comprehensive solutions to this other than those that point to the Microsoft KB982400.  I was checking the Colleval.log and kept seeing Checking collection: 0x18, EvaluationCRCChanged=FALSE, ScheduleCRCChanged=FALSE, AwaitingRefresh=TRUE - which is fine, yes it's awaiting a refresh - SO REFRESH ALREADY!!!!

The D:\PROGRAM FILES\MICROSOFT CONFIGURATION MANAGER\inboxes\COLLEVAL.box seemed fine and the BADRELP and RETRY folders were empty - so what was causing this???

Finally I spotted a few references to AV related issues (which I suspected were responsible for another issue I have with slow PXE boots).  Sure enough, when I killed off all the Trend related services from Windows Task Manager and did another update and refresh of the collection - IT WORKED!!

Trend Services Running on the SCCM Server

I've since added an exception to Trend File scanning for the PROGRAM FILES\MICROSOFT CONFIGURATION MANAGER\inboxes folder and I've noticed a considerable improvement - I'll post back after a week or so to let you know how it's going.

Hope this helps someone else...

DocN

***UPDATE***

It seems the actual problem here was down to the sheer volume of collections running updates.  There was a cumulative effect of the schedules and come 1pm the collection action list was backed up with about 3 hours of updates pending.

I've gone through and removed all update schedules from our collections (yes - it was a lengthy monotonous task) and all is well.

 

Error 1723: Can not uninstall JRE update X from Windows 7

I came across this today whilst helping one of our install techs update Java for a customer on a machine he was installing.

It was Windows 7 Ent 64bit SP1 with Java v19 installed.  Upon attempting to uninstall he received the error:

Error 1723: Can not uninstall JRE update from Windows 7.

After a bit of digging around I discovered the error was referring to a missing DLL.

By going into the registry and finding the MSI entry I tried an uninstall using the following command:

msiexec.exe /x{26A24AE4-039D-4CA4-87B4-2F83216019FF}

This was found here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall   -  this is a great tip for any app packagers needing to discover the msi registered to a piece of software for uninstalls etc...

Again I received the same error message.  To enable error logging I added /L javauninst.log and discovered it was missing the "regutils.dll" located here: C:\Program Files (x86)\Java\jre6\bin

I copied the file across from an existing machine and voilà - it worked !

Another Java/MSI quirk but non the less slightly perplexing to say the least. 

Hope this helps someone else sometime...

C