November 2006 - Posts

Re-run User or Usergroup targetted Mandatory ad - RCrumbaker Web Remote Console 3.21

There are multiple scripts, standalone tools, right-click console additions to help an SMS admin trigger a re-run of a previously run (and failed, or succeeded) mandatory advertisement targetted to a machine.

For those few of us that target advertisements to usernames or usergroups (I believe there are 3 of us, hi guys!), to re-run the ad has always meant (for me at least), remoting into the computer, going to Run Advertised Programs, and re-running the failed advertisement manually.

Attached is a zip file containing a vbscript, as well as a code snippet to insert into your machrest.asp if you prefer to add a button to your Web Remote Console. The script or button will trigger a re-run of a user-based advertisement.

Notes: unlike Machine-based resets, the trigger to re-install is not instant. 1 or 2 User Policy Refreshes are required for the client to realize it needs to rerun the user or usergroup targetted mandatory advertisement. If you need a remote User Policy refresh script, Stuart Watret's right-click tools have that, or Ron Crumbaker's Web Remote Console can have a button for that.


To add this button to your version of Ron's web page, edit MachRest.asp, and add a button by your other buttons (about line 80-ish):
<INPUT id="Button729" style='WIDTH: 180px' type='button' value='ReRun User Ad' name='Btnl729'>

Then add the attached (the Sub) probably near the bottom, just before the </script>, after all of the other Sub/end Sub routines

If you do not have Ron's page implemented, in the attached file is a standalone vbscript you can use to reset a user-based ad.

PS: The vbscript could be converted into a right-click console tool. I normally don't do that, but I've offered it to Stuart Watret, he's considering it as an addition to his next update of his tools. As of this article being written, his tools are version 1.3 Check his web site for an updated version, and the release notes to see if this script has been integrated.

PrimalScript Enterprise - quick in-the-trenches review

Until today, I had a passing familiarity with .xml files.  I've seen them.  I've tried to interpret them.  Once I had to edit one for production; but I had excellent vendor documentation.  Notepad was fine.

Today, I was asked to help edit / fix / figure out an .xml file.  I had been using PrimalScript Enterprise demo for a few weeks (for editing .vbs/.htm/.asp), and remembered it had an .xml interface.  Using PrimalScript to view / edit that .xml file at least allowed us to avoid some stupid human errors, like not closing a section with the </whatever>.

Although we technically didn't succeed (never did get that migcustomapp.xml to work w/USMT3 scanstate/loadstate as we had hoped), having PrimalScript keep us on the straight and narrow with syntax at least prevented us from wasting time testing with a bad .xml

Tomorrow's another day for usmt3 & migcustomapp testing; w/PrimalScript showing it's worth, I believe I can convince the boss to buy licenses for the whole team.

Posted by skissinger | with no comments
Filed under:

ITMU v3 and Windows Update Agent v5.8.0.2694

One of the pre-requisites for Inventory Tool for Microsoft Updates (v3, or the version released in November, 2006) is an updated Windows Update Agent, to version 5.8.0.2694.

According to the readme.htm for ITMUv3, if you need to run reports to verify WUA agent version, no problem! If you are on SMS2003 SP2, that value will be reported.  Sounds great... but if you've ever added anything to the default sms_def.mof, and have followed the practice of compiling the entire sms_def.mof that resides on your server (in inboxes\clifiles.src\hinv) on your clients... you may have inadvertently broken the ITMU v3's (scanwrapper.exe) ability to report the WUA version.

To confirm you've got this problem, after installing ITMUv3, run the scan on a client which is normal in every way.  Look at system32\ccm\logs\scanwrapper.log, and search for the line "Win32_WindowsUpdateAgentVersion", if within a line or two you get "Failed to persist Win32_WindowsUpdateAgentVersion instance. hRes = 0x80041089", you've got the same problem I had. 

You have two options, you can fix it so it will be reported correctly using win32_WindowsUpdateAgentVersion, or use the AlternateMethod.  If you want to fix it, you'll have to fix your current clients (that have already compiled the sms_def.mof), and change the way you mofcomp changes in the future.  Otherwise, skip to Alternate Method below.

Step 1:  If you version your .mof, on your server copy of sms_def.mof, modify the version.
Step 2:  Take a copy of sms_def.mof, and call it something unique, (in this document, I'm calling it Mini_mo.mof), place it in the source folder for the package you use to have your sms clients compile any mof changes.
Step 3:  Edit Mini_mo.mof, and Delete everything that was in the original sms_def.mof.  If you are on SP2, for me, that was through the section "class Win32_WindowsUpdateAgentVersion... through the };  (which for me is on line 4812.)
Step 4:  If you've compiled the entire sms_def.mof on your clients, to fix existing clients, add this to the end of your mini_mo.mof (and NOT to sms_def.mof on the server(s))

//  <:[-<>>>>>Start>>-Fix ScanWrapper Error-<<Start<<<<<<<<>-]:>
#pragma namespace ("\\\\.\\root\\cimv2\\sms") 

    [Singleton]
    class Win32_WindowsUpdateAgentVersion
    {
       string Version;         
    };
//  <:[-<>>>>END>>-Fix ScanWrapper Error-<<END<<<<<<>-]:>

Step 5: Using whatever method you prefer (I use the attached script, targetting all clients where MofVersion does not equal the version in mini_mo.mof, or the version is not reported), mofcomp the mini_mo.mof on your clients.

The next time the client runs the ITMUv3 Scan, the Scanwrapper executable populates the WMI value in root\cimv2\sms\win32_WindowsUpdateAgentVersion\Value.  Subsequent Hardware Inventory cycles will forward that value to SMS, and it will be available for reports.

Notes for future sms_def.mof updates... From now on, you will not be able to take the exact same sms_def.mof you have on the servers, and compile it on the clients.  I suspect I'll need to maintain two .mof's; one is the server one with everything, and one is *just* the custom additions.  I believe in a few months I'll be able to remove the section for 'fix scanwrapper error' in mini_mo.mof, once all the clients get fixed.

Alternate Method
Shrug your shoulders and say "so what?" The only reason this feels like it's a problem is because it's written in the ITMUv3 Readme.htm that it should report via this method.  And the only reason it's not working is because you've customized what is gathered in sms_def.mof, and mofcomp'ed those changes on your clients.  Do this instead:

Step 1: Assuming you do want to write reports about the version of Windows Update Agent, in SMS console, Site Settings, Client Agents, edit Software Inventory Client Agent, Inventory Collection, and add a rule for the file "wuaueng.dll" in the path "%windir\system32\", no subdirectories, exclude compressed, do not search subdirectories, do not exclude Windows directory.

Step 2: Edit sms_def.mof on the server in \clifiles\hinv, and change the report from "TRUE" to "FALSE".  You do not need to re-compile this change on the clients.  This next part is optional.. add a comment like
// <current date> <yourname> Do not change this report from FALSE to TRUE.
// It will not report correctly due to our customizations.  Write reports against the version of
// the file wuaueng.dll to determine version of the Windows Update Agent.

Also, if you haven't upgraded to SMS 2003 SP2 yet (still on SP1), you'd probably add a rule for wuaueng.dll to get that info, because you simply don't have the SP2 client w/the extra setup for win32_WindowsUpdateAgentVersion.

Posted by skissinger | with no comments
Filed under: ,

Local LastStatusTime in Reports

I noticed this tip in the forums from eyona, http://www.myitforum.com/forums/Help_from_a_Reporting_GURU_Need%3F/m_145775/tm.htm, and it's one of those tidbits of information I know I'll forget if I don't record it somewhere....

 As an example below, modified the default report 131 to have an additional column for last status time, translated to the computer's local time.

SELECT  adv.AdvertisementName,
 stat.LastStateName,
 pkg.Name AS C062,
 adv.ProgramName AS C071,
 adv.AdvertisementID,
                pkg.PackageID,
                dateadd(ss,@__timezoneoffset,stat.LastStatusTime) [Last Status Time (local)],
                stat.LastExecutionResult
FROM v_Advertisement adv
JOIN v_Package pkg ON adv.PackageID = pkg.PackageID
JOIN v_ClientAdvertisementStatus stat ON stat.AdvertisementID = adv.AdvertisementID
JOIN v_R_System sys ON stat.ResourceID=sys.ResourceID
WHERE sys.Netbios_Name0=@ComputerName
Order by adv.AdvertisementName

Posted by skissinger | with no comments
Filed under: ,

Book Review - SMS 2003 Administrator's Reference

Another excellent addition to the resources available for the SMS admin.  Especially for a new installation or new sms admins, follow chapters 1-13, to get up and running, and then go to Chap 15 and implement his SMS 2003 Web Remote Tools.  Don't be fooled by the fact that there's only a few pages devoted to mentioning this tool; once you have SMS, and the default SMS web reporting site running, adding this virtual web site to your web reporting server is indespensible.  It was for me; I'm pretty sure at least some of the raises I've received the last two years were justified in my review by last year: "implementing Ron Crumbaker's Web Console" and this year: "enhancing the web console". 

If you are an SMS Administrator, for the most part your work is done behind-the-scenes.  If you implement this web console and get your Managers, local technicians, helpdesk, etc. using it--it is a great way to answer that dreaded yearly review question "so, what did you do this year to help the company?"

As with almost any technology-geared guide, there is one thing I noticed that has changed.  Microsoft just released (literally, just last Friday) an updated ITMU (Chapter 13), so the .cab file is now called wsusscn2.cab (not wsusscan.cab).

Grab this, the SMS 2003 Recipes from Greg Ramsey/Warren Byle, and lurk on the www.myitforum.com sms2003 forums, blogs, or email lists, and you'll have your sms installation humming along in no time.

 The above is verbatim what I posted on amazon.comWhat I didn't write in the review was that Ron mentioned my customizations in Chapter 15 to his web console.  Way cool.  (I am such a geekette. Sigh.)

http://www.amazon.com/SMS-2003-Administrators-Reference-Management/dp/0471749508/sr=11-1/qid=1163037785/ref=sr_11_1/104-1500369-0541565