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 :)
These are the ramblings of a 30 something (going on 60) year old disgruntled IT Professional. This is gradually evolving into a Windows SCCM blog but there's a bit of "me stuff" in here too as I like to write so have a look at some of my work. Please feel free to leave a comment...
Friday, 25 May 2012
Friday, 11 May 2012
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 :)
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 :)
Tuesday, 8 May 2012
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
If you're lucky I'll bring you up to speed later.
#mmsuk
Thursday, 3 May 2012
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...
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.
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!!
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***
***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.
Thursday, 8 March 2012
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:
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
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
Thursday, 2 February 2012
This task sequence cannot be run because a package referenced by the task sequence could not be found.
If like me you have been bashing your head against many firewalls during Windows 7 OSD via SCCM you will probably sometime come across the error:
More annoyingly it doesn't reference the guilty package in the onscreen error. After checking the many log files CCM generates I found within the RAM drive path: x:\windows\temp\SMSTSLog resides the relevent SMSTS.LOG file.
The full error I recieved was after selecting the relevant OSD TS; resolving polices and then BAM :
I also noticed (and please use SMS Trace to view error logs):
I found it was a Lenovo Graphics Driver Package causing the issue; it appears SCCM has yet another little "quirk" where the hash isn't written sometimes upon creation of a package and the initial ditribution. If the version number of the guilty package is "1" try right clicking on the DP of the package and select "Update Distribution Points".
After some time the Source Version will increment to "2" and the date will be current - give your OSD another try and then see if it works - if it fails - check the log file again as this time the guilty package may have changed and it may be a case of trawling through a few before you resolve the issue.
I hope this helps.
Many thanks to J over at ManagedUX for the pointer!
This task sequence cannot be run because a package referenced by the task sequence could not be found.
More annoyingly it doesn't reference the guilty package in the onscreen error. After checking the many log files CCM generates I found within the RAM drive path: x:\windows\temp\SMSTSLog resides the relevent SMSTS.LOG file.
The full error I recieved was after selecting the relevant OSD TS; resolving polices and then BAM :
This task sequence cannot be run because a package referenced by the task sequence could not be found. For more information, please contact your system administrator or helpdesk operator.
I also noticed (and please use SMS Trace to view error logs):
Failed to find CCM_SoftwareDistribution object for AdvertID="xxx", PackageID="xxx", ProgramID="*"
I found it was a Lenovo Graphics Driver Package causing the issue; it appears SCCM has yet another little "quirk" where the hash isn't written sometimes upon creation of a package and the initial ditribution. If the version number of the guilty package is "1" try right clicking on the DP of the package and select "Update Distribution Points".
After some time the Source Version will increment to "2" and the date will be current - give your OSD another try and then see if it works - if it fails - check the log file again as this time the guilty package may have changed and it may be a case of trawling through a few before you resolve the issue.
I hope this helps.
Many thanks to J over at ManagedUX for the pointer!
Subscribe to:
Posts (Atom)