The final version has been released:

Windows Server Update Services 3.0 SP1 - download here.

Quote:

Overview
Windows Server Update Services 3.0 Service Pack 1 (WSUS 3.0 SP1) delivers important customer-requested management, stability, and performance improvements, while incorporating further enhancements to local publishing of drivers and the Client Servicing API addition.
WSUS 3.0 SP1 delivers new features that enable administrators to more easily manage and deploy updates across the organization. This package installs both the WSUS 3.0 Server and WSUS 3.0 Administration Console components, for all Windows Server 2003 SP1 supported languages. Additionally, the WSUS 3.0 SP1 client is included in all supported client platform languages. You must install the server components on a computer running Windows Server 2008 or Windows Server 2003 SP1 or later. You may install the Administration Console on a remote computer running Windows Server 2008, Windows Vista, Windows Server 2003 SP1, or Windows XP SP2.

Supported Operating Systems:
Windows Server 2003 Service Pack 1; Windows Server 2008
- Note: there’s a special guide for SBS 2003 environments…

Additional information:

Release Notes for Windows Server Update Services 3.0 SP1

Microsoft Windows Server Update Services 3.0 SP1 Overview

Deploying Microsoft Windows Server Update Services 3.0 SP1

Step-by-Step Guide to Getting Started with Microsoft Windows Server Update Services 3.0 SP1

Microsoft Windows Server Update Services 3.0 SP1 Operations Guide

Installing Windows Server Update Services 3.0 on Windows Small Business Server 2003

Enjoy!

.

This is just to prove my point - a single AV engine is not enough if you want to be secure.

I had this problem today at a customer - a user had received a link in her Messenger… And she clicked it and probably accepted to execute the thing => Pooof (all her MSN Messenger contacts were spammed with links to the worm)!

We tried to use some different online scanners - as the local AV engines (no names mentioned) didn’t find anything - even after updating the signatures. The online scanners I tried first didn’t show anything. So, this particular online scanner turned out to be VERY cool and effective:

I can recommend this scanning link whenever you have a suspicious file you want to scan: http://virusscan.jotti.org/

As you can see it uses several engines to determine if the file is infected or not - so nice, thanx!

.

The ability to run decade-old applications on the newest releases of Windows has almost become a rite of passage. Most people would agree that software backwards compatibility on Windows is easily one of the important factors for its success. However with each release, Microsoft digs itself deeper and deeper into this pit of support as the breadth and depth of software grows exponentially. So much so some predict it will eventually ruin Windows, if it hasn’t already.

A recently published patent application, “Environment For Executing Legacy Applications On A Native Operating System” for those of you playing at home, filed in April of 2007 by Microsoft’s Hoi Vo and Samer Arafeh (who works on the Windows kernel) reveals some details of how they might (and emphasis on might because patents are just words on a piece of paper) accommodate and dramatically improve software compatibility in future releases of Windows.

As described in the patent, the problem of legacy applications support lies in binaries (DLLs and EXEs). As operating systems are updated, system binaries change. Older system calls, callbacks and exceptions may not exist at all in the new operating system, may exist to some degree or may generate alternate responses. Any of which is likely to wreck havok on legacy applications which depend on these binaries.

Currently there are two conventional solutions to the problem. Each with their respective advantages and disadvantages.

The first employs the use of “shims”. Metaphorically speaking, it’s basically sticky tape around the edges to make sure things don’t fall out. Technically, it’s a custom-written patch that is applied on-the-fly when legacy applications are loaded and will sit in between the legacy application and the native system binaries. Reportedly Microsoft has written thousands of shims for Windows Vista, and are still writing. The upside is that shims are relatively easy to implement, but having to generate shims on a per application-by-application basis means it doesn’t scale well at all.

The second solution takes advantage virtualization technology. By hosting a legacy OS virtual machine, legacy applications won’t any know any better. Virtualization offers full application support but at a hefty performance cost. Hardware support is also primitive, making it difficult to share resources like 3D graphics for example. It also requires users to be able to install each version of the legacy operating systems.

The proposed solution in some ways takes the best bits of both. It works first by detecting if the application was written for the native operating system. If not, it will load the application with its respective legacy system binaries. The accommodate the difference in system calls between the legacy binaries and native kernel, an Application Compatibility Module is placed in between to act as a translator for these calls. In certain cases where a comparative native system calls may not exist at all, the ACM could also be smart enough to provide the same functionality as the missing system call.

Hypothetically speaking, if the system detected an XP application it would load the XP system binaries (ex. system32_xp) and then a XP-to-WinNext compatibility module.

The benefit of this solution is it offers much broader application compatibility with relatively low investment on Microsoft’s behalf on the scale of per-application - they will only have to write a ACM for each legacy system they wish to support. Legacy applications will also be able to take full advantage of the system resources as a native application, because there is no emulation involved.

Notable Windows on Windows - the compatibility system used to provide 16-bit on 32-bit systems support and 32-bit on 64-bit systems support uses a similar concept.

One of the biggest gripes from most Windows enthusiasts has been the bloat legacy compatibility forces into Windows. Whilst this patent doesn’t specifically mention so, I presume such ACMs are modular and can be installed and removed on demand. For example, if you need to run Windows Vista applications in future versions of Windows, you will only download and install the Vista ACM Pack (with Vista binaries) for that operating system. Those who do not require legacy support will then be not required to install any ACMs.

Thinking about it, it could become a business model to sell ACMs separately to Windows - reducing the overall cost of Windows and charging a tiered price for legacy support. A cheaper and less bloated Windows, wouldn’t that be nice.

Windows Media Player in Vista has Automatic Updates enabled. This means that even if you never use Windows Media Player it still downloads the updates that come available for it, as soon as you have connection with the internet.

• You can disable this by going by changing the following registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsMediaPlayer]

• Create a registry DWORD key named DisableAutoUpdate and give it a value of 1

Alternative method is to use the built in policy editor:

1. Click on ‘Start’ and in the ‘Start Search’ box type (without the quotes) “gpedit.msc”. When it shows up hit ‘Enter’
2. Now the group policy editor should be on screen, under ‘Computer Configuration’ expand ‘Administrative Templates’ - then expand ‘Windows Components - then scroll down to the ‘Windows media Player’ item and click on it to highlight it.
3. On the right side you should see a policy item named ‘Prevent Automatic Updates’ - right click on it and choose ‘Properties’.
4. Click the ‘Setting’ tab, then click the ‘Enabled’ radio button - then click ‘Apply’
5. There ya go, no more auto updates for Media Player.

Both of the above do the same thing, they both add the registry entry

Install this update to resolve a set of known application compatibility issues with Windows Vista. After you install this item, you may have to restart your computer. This is a Customer Preview Release. At the conclusion of this preview phase, the final version of the update will be released via Windows Update. This update is provided to you and licensed under the Windows Vista License Terms.

Update for Windows Vista
Update for Windows Vista x64
Microsoft Knowledge Base Article - 943302

What is an Operating System?

An operating system, or OS, is software that enables you to operate the computer. It manages the opening of files, the monitor display, printing, access to networks, and so on. The chances are you are using a version of Windows as your operating system, but this is not the only OS available. Others include the various versions of linux (such as Ubuntu) which are generally available for free, and OSX, which is the latest operating system for Apple Macs. The various operating systems will tend to look different from one another, they will store files in different ways, and will also run different programs. So, a program written for Windows will not work on Linux unless it is run through an emulator or another piece of software that acts like a translator, such as WINE.

What on Earth is a GUI?

GUI (pronounced ‘gooey’) stands for Graphical User Interface, and this refers to all the visual elements of an operating system, all the windows, icons, menus, buttons, tick boxes, etc. The user can interact with each of these elements using a mouse or other pointing device, which helped to make computers more accessible and in some ways kicked off the PC revolution.

A graphical user interface can be contrasted with old fashioned command line interfaces (CLIs) like MS-DOS (Microsoft Disk Operating System). If you are interested, you can have a glance at the past by running the command prompt which shows what a command line interface looked like: open a Run dialog (’Run’ on the start menu or Windows key & R) and type ‘cmd’ and press OK. You will then see something like this:

In the days before windows this is what most operating systems looked like. You can relive these bygone ages by typing ‘edit’ and pressing Enter, this will open the old DOS text editor: a sort of low-tech ‘Notepad’. Hold down the Alt key and press the first letter of a menu title to open the associated menu, e.g. Alt & E opens the edit menu. You can even switch to full screen mode by holding down Alt and pressing Enter for that complete retro experience, do the same again to return to Windows.

And shell?

Both GUIs and CLIs are shells. That is, they provide an interface with which the user can manipulate the operating system. On Windows machines the shell is called ‘Windows Explorer’ although there are alternative shells available for Windows such as the LiteStep GUI.