Andrew Berges

Critical Vulnerability in McAfee Common Management Agent 3.5 Patch 5

As first reported by JD:

A vulnerability exists in the Common Management Agent (CMA) where an unexpected executable file can run with system privileges.

Apparently this will be addressed with VirusScan Enterprise 8.0i Patch 12, not yet released. Contact PrimeSupport if you want a fix before then.

KB Article Here

Circumventing Group Policy as a Limited User

An excellent post by Mark Russinovich of Sysinternals on ways that an end user can bypass group policy restrictions and/or software restriction policies is located here.

Any Futurama fans out there?

"Matt Groening, creator of The Simpsons and Futurama, says there may yet be hope for a renewed Futurama series, thanks to high DVD sales and syndication ratings. Comments from David X. Cohen: 'Three months ago, I would have said we were going to start tomorrow ... And one month ago I would also have said we were going to start tomorrow. So...my current estimate is that we're starting tomorrow.'"

Full article here

Link by Slashdot

Internet Explorer 6 SP1 Failed Installs

I have a collection that identifies clients in our environment that do not currently have IE 6 SP1 installed. I have a package advertised to the collection once a day to attempt an upgrade of these clients to the proper IE version.

I have 3 clients that are failing to run the advertisement successfully. The following is found in the execmgr.log for the clients:

Execution Manager timer has been fired.
Time to retry for program Unattended advertisement ERG2007A
Requesting content from CAS for package ERG0007E version 1
Execution Request for program Unattended state change from WaitingRetry to WaitingContent
Content is available for program Unattended.
Executing program ie6setup.exe /Q /R:N in Admin context
Execution Request for program Unattended state change from WaitingContent to Running
Checking content location \\somefileserver\SMS PACKAGES\SMSPKG\ERG0007E\ for use
Successfully selected content location \\somefileserver\SMS PACKAGES\SMSPKG\ERG0007E
A pre-existing usable mapped drive Z: was found
IsNetResourceAccessible failed with error code 0x00000005
IsNetResourceAccessible failed with error code 0x00000005
WNetCancelConnection2 failed with 0x000008ca.
ConnectNetResource failed with error code 0x00000005
Failed to map drive Z: with share \\somefileserver\SMS PACKAGES
EnterRsRuningState failed to run script ie6setup.exe /Q /R:N 0x80008103
Non fatal execution error 0x80008103 encountered for program Unattended
Program Unattended has been tried 250 times, will retry later
Execution Request for program Unattended state change from Running to WaitingRetry

A quick google search on 'IsNetResourceAccessible failed with error code 0x00000005' indicates that this is an access denied/insufficient rights issue. However, these clients have no issues running other advertisements from the same DP. Ive checked the permissions on the ERG0007E folder, and they match with the ones being used at the Central Site.

The clients in question are all Windows 2000 SP4, running the SMS 2003 SP1 Advanced Client.

I was able to contact one of the users and connect to their PC. Using at systemtime /interactive cmd.exe to open a window under the local SYSTEM account, I mapped a drive to \\Servername\SMS Packages (our SMS Package share).

I then tried the following commands:

(X:\ - SMS Packages Directory)

DIR -- failed.

CD SMSPKG -- success.

(X:\ - SMS Packages\SMSPKG Directory)

DIR -- success.

CD ERG0007E -- success.

(X:\ - SMS Packages\SMSPKG\ERG0007E Directory)

ie6setup.exe /Q /R:N -- success.

Does anyone know what might be causing this error?

SMS 2003 Distribution Point Issues - Resolved!

Last week, I posed about an issue I had with my distribution points. I am pleased to say that the problem is now resolved.

There were actually a few issues, all of which contributed to a less-than-healthy package distribution environment. First and foremost, two files on the SMS server "went missing".

When I looked under my inboxes/schedule.box folder, I had over 480 pending jobs. Yikes. Although the distmgr.log file indicated no errors while "pushing" packages, the job files continued to accumulate and no work was actually being done.

With the help of PSS, I was able to find this knowledgebase article which referred to job file backups. Sure enough, just like the KB referenced, my sched.log file contained entries similar to the following:

JOB XXXXXX~ Updating status of minijob "Inter Site Replication".~ Need to generate send request for minijob.~ Skipping minijob. Could not retrieve the requset ID

And I was missing files from the UID subdirectory.

After following the KB instructions and creating new token .req and .job files and restarting SMS_EXECUTIVE, the jobfiles began being processed. Horray!

Unfortunately, the problem was not completely solved yet. I was still unable to copy several packages, all of which would still give me errors similar to the following in the distmgr.log file on the DP's in question:

Processing incoming file E:\SMS\inboxes\distmgr.box\INCOMING\BLAH.PKG.
Package XXXX requires a newer version (3) of source files and the new compressed files haven't arrived yet, current version is 2, skip E:\SMS\inboxes\distmgr.box\INCOMING\BLAH.PKG

Thanks to Matt Broadstock and this blog post, however, I was able to recreate .PCK files for the affected packages, and I'm happy to say that all the trouble packages successfully copied over the weekend!

Thanks again Matt, I owe you one!

UPDATE: After receiving a few emails informing me the link above is broken, I have updated it with Matt's new link to his post.  Should it move again and anyone needs the solution, I'll breifly summarize here:

If you don't mind redeploying the package to all the DP's, the quickest method is to delete <PackageID>.PCK under the SMSPKG directory on your SMS drive, then change the source path of the package to something different and applying the changes (it doesn't even need to be a valid location), then immediately changing it back to the correct location and applying the changes again.

Doing this will force the package to be recreated, the version number will be incremented, and the new package will be sent to ALL DP's that currently have that package.

SMS 2003 Distribution Point Issues

OK, might as well start posting my troubles to the weblog as I haven't gotten a response from the SMS mailing list; maybe I'll get some help from the community via my blog, I hope!

I went on a bit of a hiatus last week, and I've come back to a bit of an issue. It seems that in my absence, a technician that Ive trained to use SMS for Software Updates updated our MBSA package to distribute November's patches to our various sites/DPs. (Yes, I know we're a month late. Don't ask...)

Today when I attempt to copy a package to any of the DPs, I see a slight activity in the distmgr log (literally for a minute or so) on the Central SMS Site, and no sender log activity. Running a web report on active package distributions shows the MBSA package from last week as "Waiting To Install Package", with a failure on one DP (this DP seems to fail for everything; a completely different issue I believe is related to our use of a VPN link between that office and the SMS Primary for that DP).

Removing the package from the DPs and adding back seems to accomplish nothing. Any packages I try to send out end up with "Waiting To Install Package" status as well, despite that the distmgr log indicates 0 of 3 threads used, and sender indicates 0 of 5 senders used.

Anyone out there in SMS-land have any pointers on where I should start the diagnosis?

Security on the Cheap

Courtesy of SunbeltBlog. Security On The Cheap

Antivirus and SMS

Because this was discussed on the SMS mailing list recently: Antivirus programs may contribute to file backlogs in SMS 2.0 and in SMS 2003

Getting the Most out of SMS

For all those that haven't already stumbled across this link: Redmond Magazine - Getting the Most out of SMS