System Center Essentials Team Blog

News and support on Microsoft SCE

SCE 2010:
The System Center Essentials Team Blog

Unified physical and virtual IT management for midsized businesses

May, 2008

  • System Center Essentials Team Blog

    Essentials Team at TechEd US 2008!

    • 0 Comments

    We'll be at TechEd again this year with our demo packed sessions!  We'll also have a booth on the expo floor that you can drop by anytime to ask questions of the Essentials product team.

    IT Conference MGT60-TLC Ask about Simplifying IT Management with Microsoft System Center Essentials
    Session Day/Time: 6/11/2008 12:00PM-12:45PM
    Room: Blue Theater 1
     
    IT Conference MGT353 Supporting Your End-Users with Microsoft System Center Essentials 2007
    Session Day/Time: 6/10/2008 3:00PM-4:15PM
    Room: S310 E (ITPRO)

    Check out our sessions and more at http://www.msteched.com!

  • System Center Essentials Team Blog

    Caching Microsoft Update content in System Center Essentials

    • 0 Comments

    A question came up in the Technet forums around content caching, and what variables exist to adjust it.   The footprint of cached content on the wSUS/SCE server take into consideration four variants:

    • Products (XP/2K3 as examples)
    • Classifications (Seciruty / Critical / Service packs)
    • Languages (EN, DE, JA, etc..)
    • Choosing to utilize Express files ( I will explain this one in more detail below)

    SCE default configuration will bring in nearly 8GB of content; provided your needs stay within one language. 

    ...Now about Express files..

    There are two ways that a package can install on your managed systems; Stand-alone, or Express.  For stand-alone, all the possible changes which can happen during that installation are contained in the package.  Let's say Foo.Dll is revising to 1.2, and Bar.Exe is revising to 1.3.  In this case, the old Foo.Dll and Bar.exe would be removed from the system, and the new ones applied.  This is the safest, and most common way patching happens.  However, it means that the entire package travels across the LAN/WAN when installation is necessary.

    In the Express scenario, it may be that Workstation1 already had Foo.dll version 1.2, but not the latest version of Bar.dll.  It's neighbor, Workstation2 had just the opposite.  If the EXPRESS files were present, Workstation1 and 2 would ask the SCE/WSUS server for only the binary ranges it needed, and the acutal bytes which went across your LAN/WAN would be very close in footprint to the bytes which were needed to simply replace the specific files targeted. 

    So, Express seems to be the winner here (almost).  In order to provide this optimization, the Update Services infrastructure needs to have fault tolerance.  Express packages will not work for 100% of the systems in need of patching.  Therefore, enabling express option means that the system will download the standalone version of an update as well as the Express version of that update.  Should it need to fall-back due to failure, the standalone version will be locally available.  Also, the express files are 2-4 times as large as the standalone packages. 

    The tradeoff question is:  Should the optimization target ingress to the WSUS server at the cost of more LAN/WAN traffic, or the converse? 

Page 1 of 1 (2 items)