After a short stint in the Exchange product group, I have moved back to a product group that I just couldn't stay away from: Configuration Manager. Not only is the team great, but the community and customers surrounding this product are absolutely fantastic. This is truly a place where my passion lies. So what am I up to these days? Well, I am pleased to say that I am working on Configuration Manager v.Next and specifically the next generation Software Distribution feature. In v.Next, we are creating a true state-based application distrubution feature. Coming from a background in Software Update Management (SUM), I have always felt good about the detection of updates and the on-demand, selective download of updates to be installed. I am really excited to be working on a software distribution feature where we model software applications in much the same way. We are bringing the concepts of requirement rules, detection methods, dependencies, supersedence, and more to the distribution of software in Configuration Manager v.Next. For years, we have had Packages and Programs, and those aren't going away. There will be a place for using Packages and Programs in v.Next for running reoccuring scripts and specialized tasks. But for deploying applications, the new Application Model in v.Next is where it is at.

So please download the Beta and start evaluating it today!

As things heat up, look for more articles, tips, tricks and tidbits on Configuration Manager v.Next right here on this Blog.

Thanks!

Bryan 

If you want to learn a little bit more about what is coming in R2, or SP1 for that matter, feel free to check out some of the demonstrations recently posted on TechNet Edge.

https://myitforum.com/cs2/blogs/gramsey/archive/2006/10/12/ITMU-Update-_2D00_-November-2006.aspx

With regards to McAfee and ITMU, there are potentially two issues you can run into:

1. Wsusscan.cab archive file scanning – the wsusscan.cab is an archived archive file. The middle archive file has about 20,000 small data definition XML files that define over 6000 Microsoft updates. McAfee does a very thorough job of unpacking and scanning every file whenever the wsusscan.cab file is copied to or around on a client machine. This can cause considerable processing and disruption to the ITMU scan process as the cab is first copied from the distribution point, then to the VPCache folder and ultimately to the Windows Update Agent (WUA) cache for unpackaging and scanning by WUA. We have consulted with antivirus experts around the world who have advised two safe and secure methods of avoiding the processing. Option 1 is to exclude the wsusscan.cab file itself from scanning. I’m not sure if McAfee offers this as an option, but remember you would have to wildcard exclude it because it is copied to non-predictable directory paths in temp locations and VPCache directories. So just excluding a single full file path will not solve the issue. Remember that excluding wsusscan.cab from scanning is not a potential security risk, as the only process that would attempt to extract it is WUA, which will always check for the MS digital cert prior to processing and fail otherwise. Option 2 is to exclude scanning all archives. Contrary to urban legend, this does not pose a security risk and most A/V software has a configuration item for this. Having a virus or malware packaged in a cab is not an issue until someone or something attempts to unpack and then execute it. This action would always be caught by real time scanning, so the risk is very low of excluding archived files from A/V scans. You can read more about that here: https://support.microsoft.com/default.aspx?kbid=900638
2. The second issue is that McAfee puts a file lock on the WUA client cache edb in the %Windir%\SoftwareDistribution folder on clients. This prevents WUA from accessing it and prevents scanning from happening. You can read more about that here: https://support.microsoft.com/?kbid=922358
    

As I mentioned earlier, there is a lot of misinformation floating around the various newsgroups and discussion aliases with regards to McAfee and ITMU compatibility. Please know that there are viable and secure workarounds available to get everything in working order when using these two products side-by-side. If you have any questions or concerns, please work with your MS or McAfee contacts to learn more.

Thanks,

Bryan

One of the most compelling aspects of the custom updating technology is the schema that is used to define the updates. This schema, known as corporate publishing XML, is rich with metadata that can be used to define almost any software update. Schema elements include title, description, and other properties. Applicability and installed rules include File, Registry, MSI, and WMI checks in any combination. Installation properties are defined by filename, download URL, command-line parameters and more. This schema is not just envisioned to support custom update management in R2, but many new management products at Microsoft, including Systems Center Configuration Manager 2007 when it releases.

Tools that ship with R2 make it easy to discover, download, and create custom update catalogs that synchronize directly with the SMS 2003 software update management infrastructure.

The SMS 2003 R2 evaluation copy can be obtained here. R2 is available to active Software Assurance (SA) customers at no charge and will be part of the August volume licensing kit. Non-SA customers can purchase R2 licenses.

Please take the opportunity to send me comments/feedback on your experiences with SMS 2003 R2. I am more than happy to post articles on advanced custom update authoring topics, as well as provide samples through this blog.

Thanks,
Bryan

Thank you for your patience.

UPDATE (7/11/2006 2:44:18 PM): MSSecure.cab has been released. Wsusscan.cab is still pending.

UPDATE (7/11/2006 5:47:32 PM): Wsusscan.cab is released.

Microsoft quickly investigated the issue and determined that customers who attempted to install the MS06-007 security updates through Automatic Updates, Windows Update, Windows Server Update Services and Systems Management Server 2003 when using the Inventory Tool for Microsoft Updates (ITMU) were affected. The issue did not affect customers who installed the updates through Software Update Services or through Systems Management Server when not using ITMU, or manually installed the Security Update from the Microsoft Download Center

Our investigation has concluded that issue was an installation issue where MS06-007 was not successfully installing when users attempted to install it through affected distribution channels. The issue does not affect the security update MS06-007 itself. When successfully installed, MS06-007 fully protects against the Internet Group Management Protocol (IGMP) vulnerability. Also, the installation issue only affects MS06-007; no other security updates were affected by this issue.

Microsoft has updated these distribution channels to correct these issues. Customers who encountered this issue should take the following actions:

• Automatic Updates (AU) - AU customers need take no action: the new updates will automatically download.
• Windows Server Update Services (WSUS) - WSUS Administrators who had synchronized their WSUS Server to obtain the updates released on Tuesday 14 February, before 8:30PM PST that evening should manually synchronize their WSUS Servers and approve the new updates.
• Systems Management Server 2003 with the Inventory Tool for Microsoft Updates (ITMU) - SMS Administrators should who had synchronized their servers to obtain the updates released on Tuesday 14 February, before 8:30PM PST that evening should re-synchronize their servers for the latest updates.
• Microsoft Update (MU) and Windows Update - Customers who visited MU and WU before 8:30 PM on Tuesday February 14th, should revisit MU or WU and accept the downloads being offered to them.

Our investigation has determined there was an issue in the distribution infrastructure in handling this particular update which has been identified and resolved. Microsoft is taking steps to prevent similar issues from occurring in the future.

From an SMS ITMU perspective, this only affects customers who run both SMS ITMU and AU in their environment, becaues this issue only affected the binary delta version of the update and not the full file version (the one that ITMU always uses by default). If AU downloads the binaries before ITMU does, when ITMU tries to copy the files, it will recognize that the WUA cache already contains the updates and attempt to execute the installer package, which due to the above issue, will fail. If an SMS customer is in this situation, they simply need to just let their advertisements for ITMU re-run. When AU runs again it will detect that the binary delta update has been removed, and clear it from the cache. Then SMS ITMU will download and successfully install the update.

https://support.microsoft.com/default.aspx?scid=kb;en-us;894199