You can validating the FEP deployment using dashboard: https://technet.microsoft.com/en-us/library/ff823784.aspx. You might already know that the deployment dashboard is actually a representation
of the deployment status collections. The number of each category in the deployment dashboard is the count of the corresponding FEP deployment status collections. So if you feel that the dashboard is not as expected, you should check the collections.

This article will explain what each FEP 2010 Deployment status collection is and what the criteria for each collections is.

There are total 6 deployment status collections:

Deployment Succeeded: This collection will show all systems that have the latest FEP client agent installed.

Out of Date: This collection will show all systems that have an out-of-date FEP client installed

Not Target: This collection will show all systems that don’t have FEP client installed and is not targeted by the deployment advertisement.

Locally Removed: This collection will show all systems that whose FEP client agent is removed locally (either by a user with local administrator permission or by another software, eg: malware).

Deployment Pending: This collection will show all systems that are targeted by the deployment advertisement, but not yet started installing. This could be because the system is offline.

Deployment Failed: This collection will show all systems that the FEP deployment advertisement is failed.

Note:

ClientDeployed & ClientOutDated information is get from v_Add_Removed_Programs. This view is populated by the hardware inventory data.

It will look for record whose DsiplayName00 = ‘Microsoft Forefront Endpoint Protection 2010 Server Management’.

If the record exists and version is >= expected version, then ClientDeployed = 1 else 0

If the record exists and version is < expected version, then ClientOutDated =1 else 0

If the program is not found, then it’s null, both are set to 0 (as in the Locally Removed scenario)

LastOperationIsInstall & LastState information is get from v_ClientAdvertisementStatus

LastOperationIsInstall: check whether the last program from the FEP – Deployment packages that run on the client is the “Install” program.

LastState: check the last return code for the FEP deployment program: match by Package MIFName = “FEP – Deployment”.

If you install standalone FEP hotfix, it will update the expected version in the collections query and the FEP installation bits on the server. So whenever a new CCM client comes, it will install the new FEP client.

If you depend on MU to install FEP platform update, then the expected version on FEP server will not be changed. And whenever a new CCM client comes, it will still install the old FEP client and wait for SUM to
install the new FEP platform update.

So now back to the real problem:

What you would expect, when you deploy FEP client update through hotfix?

After site server install the hotfix and before the client re-run the advertisement to update FEP agent: ClientDeployed = 0; ClientOutDated = 1;

Depending on the last advertisement run status, it could be in any of the following catalogs:

Out of Date

Deployment Pending – I’d expect most will fall into this catalog

Deployment Failed 

What you would expect, when you deploy FEP client update through MU:

If you install the update through MU and not install the FEP hotfix on site server, so that the expected version will not change, then a client has been in the Deployment Succeded collection before, it should be
still there;

If a client is in other collections, then it should be moved into the Deployment Succeeded collection after the latest hardware inventory information is sent back to server.

There’re actually two problems when WSUS is using UNC path as Content Folder.

1. The UNC Content Folder needs to be 2 levels deep.

That is you’ll need to set the UNC Content Folder as this: \\<remoteserver>\WSUSContentFolder.

If you only set the UNC Content Folder to be one level deep like: \\<remoteserver>

You will meet error when trying to publish even from a local SCUP

Publish: A fatal error occurred during publishing :Object reference not set to an instance of an object.

2. When WSUS is using UNC path as Content Folder, you have to use SCUP locally.

Otherwise, you’ll meet error:

Publish: : Exception occurred during publishing: Unable to find database configuration value.              

There is no workaround for this so far. You need either run SCUP locally on the WSUS server or use a local folder as the WSUS Content Folder. You can use WSUS utility tool wsusutil.exe to move the content folder location.

System Center Updates Publisher 2011 (SCUP) is supported for use on computers with Windows Server 2012 R2 with the following known limitations:

1. Windows Server 2012 R2 includes Windows Server Update Services (WSUS) 4.1. WSUS 4.1 cannot communicate with WSUS 3.0 and WSUS 4.0.  If you install System Center Updates Publisher 2011 on a machine with pre-WSUS 4.1 admin console and try to publish to Windows Server 2012 R2 based WSUS Server with WSUS 4.1, you’ll get a WSUS version mismatch error in the SCUP log.

This issue doesn’t occur when System Center Updates Publisher 2011 is installed on Windows 8.1 for use with a Windows Server 2012 R2 based WSUS server.  To install System Center Updates Publisher 2011 on a Windows 8.1 system the Remote Server Administration Tools for Windows 8.1 (RSAT) https://www.microsoft.com/en-us/download/details.aspx?id=39296 is required.  Installation of RSAT 8.1 includes the WSUS 4.1 version of the WSUS admin console binary for Windows 8.1 and allows applications like System Center Updates Publisher 2011 to connect to a Windows Server 2012 R2 based WSUS Server.

2. To allow local administrators to publish updates from System Center Updates Publisher 2011 to Windows Server 2012 R2, you still need the same workaround for Windows Server 2012 as described here: https://technet.microsoft.com/en-us/library/hh134747.aspx#PublishToServer2012

3. The updated version of WSUS for Windows Server 2012 R2 no longer issues self-signed certificates as described here: https://blogs.technet.com/b/wsus/archive/2013/08/15/wsus-no-longer-issues-self-signed-certificates.aspx

When using System Center Updates Publisher 2011 this change to WSUS affects the “Create” button for the Signing Certificate group in the Update Server configuration settings (see picture).

By default because the updated version of WSUS no longer issues self-signed certificates this button will not work.  The recommended way to work around this is to use a Certificate Authority to generate the signing certificate. You can refer to this blog for a step-by-step guidance to create a signing certificate with Windows Certificate Authority:  https://blogs.technet.com/b/jasonlewis/archive/2011/07/12/system-center-updates-publisher-signing-certificate-requirements-amp-step-by-step-guide.aspx.  In addition to this recommended approach there is a way to configure the new version of WSUS to issue self-signed certificates described in the update to the WSUS Product Team blog entry referenced above. Once this is configured, the “Create” button should work as before. However as mentioned the issue of self-signed certificates by WSUS remains a deprecated feature and may be removed in the future.

In general, there’re five steps:

1.      Prepare the necessary PKI certificate

Follow the link https://technet.microsoft.com/en-us/library/gg699362.aspx for the PKI certificate requirements for Management Point, Distribution Point and mobile devices.

Follow the link https://technet.microsoft.com/en-us/library/gg682023.aspx for step by step guidance on deploy the certificate for Management Point, Distribution Point, and mobile device.

2.      Configure CA Web Enrollment server to use SSL

This is required for CM 2012

3.      Enable Device Management Point and Configure Distribution Point on CM Site Server

4.      Prepare client installation files

5.      Transfer the installation files to device and start install

Now we will give the details on step 3 & 4.

Enable Device Management Point (DMP)

Open SCCM Admin Console, and go to Administration \ Overview \ Site Operations \ Servers and Site Systems roles. In the Site System Roles panel, right click “Management Point”, and choose “Allow mobile devices to use this management point”.

 To verify DMP is installed successfully, you can either check the DMPSetup.log or use self-test URL: https://<siteserName>/devicemgmt?selftest

Configure Distribution Point (DP) with HTTPS

Open SCCM Admin Console, and go to Administration \ Overview \ Site Operations \ Servers and Site Systems roles. In the Site System Roles panel, right click “Distribution Point”, in the “General” Panel, select “Allow intranet and Internet connections”

Prepare Client Installation Files

To install mobile device legacy client, we need to prepare for the installation files. Each device platform has its own specific installation files. Generally, for all the platforms, they will need 7 files:

• EXE File to start the setup – dmclientsetup_$(arch).exe

The file is located under

%SCCM_Installed_Dir%\DeviceClientDeployment\ClientTransfer\00000409.

• EXE File to enroll the client authentication certificate – enroll_$(arch).exe

The file is located under

%SCCM_Installed_Dir%\DeviceClientDeployment\ClientTransfer\00000409.

Re-name is required. Please rename the file to “enroll.exe”.

• CAB File to install the client – deviceclient_$(platform)_$(arch).cab

The file is located under

%SCCM_Installed_Dir%\DeviceClientDeployment\ClientTransfer\00000409.

Don’t rename this file. It will fail to install if the file names changes.

• INI configuration file – clientsettings.ini

The sample setting file is located under

%SCCM_Installed_Dir%\DeviceClientDeployment\ClientTransfer\.

Don’t rename this file.

In the ClientSettings.ini, we need configure below settings before kick-off the installation.

• CA’s root certificate to trust all the certificates this CA issues.

• Site Server Signing Certificate(SSSC.cer)---The site server cert. It's under SMS in the computer cert store and has subject name hard coded to "Site Server"

• MPCERT.cer---The Web Server certificate of the DMP machine

After file preparation, we will have 7 files for each platform. Let’s take WinCE 6.0 for example, and assuming the CE machine is ARM. We will have below files.

1. Dmclientsetup_arm.exe
2. Enroll.exe (renamed from enroll_arm.exe)
3. Deviceclient_wince6.0_arm.cab
4. Clientsettings.ini
5. Root.cer
6. SSSC.cer
7. MPCERT.cer

Now to install client agent becomes easier.

Copy files to the device

Kick off the process dmclientsetup_arm.exe

Log files are located at CE machine’s \Temp\ folder. If the installation failed, please check the network connectivity between CE machine and CA, between CE machine and DMP.

--Nina Qin

<updated on 9/18/2013 to update the latest anti-malware platform update link>

Configuration Team has released anti-malware platform update for FEP 2010 SU1 and SCEP 2012 SP1 CU2:

https://support.microsoft.com/kb/2865173

These updates are server side hotfixes and should be installed on the Configuration Manager Site servers. After you install the updates, you will need to do some operations on the site to make the CCM clients automatically install the anti-malware platform update. In this blog, I will show what you should do.

FEP 2010 SU1

After you install the update on FEP 2010 SU1 (KB282764), you will need to create a new FEP client installation deployment or re-advertise the old one.

If you doesn’t have an FEP client installation deployment created, you can following the link https://technet.microsoft.com/en-us/library/ff823885.aspx to deploy the FEP client software.

If you have already an FEP client installation deployment created, you can re-use the deployment. Go to advertisements node and you can see the FEP-Deployment advertisement and then click Re-run Advertisement.

Wait till the client receives the policy changes and install the latest FEP client software.

It takes time for the client to update to the latest FEP client software. During the intermittent, these computers will be moved out of the Deployment Succeeded collection and be temporally moved to other collections (depending on the previous status of these clients, the computers may be move to any collections, but most likely they will be moved into “Deployment Pending” collection). Once the install succeeds and the next hardware inventory cycle returns back the new inventory data, these computers will be moved back to the “Deployment Succeeded” collection.

SCEP 2012 SP1

After you install the SCEP hotfix, you will need to enable Automatic Client Upgrade.

Automatic Client Upgrade is new feature introduced in SCCM 2012 SP1. It can be used in the following scenarios:

• The client version is lower that the version being used in the hierarchy.
• The client on the central administration site has a language pack installed and the existing client does not.
• A client prerequisite in the hierarchy is a different version than the one installed on the client.
• One or more of the client installation files are a different version.

As SCEP client software is one of CCM client’s prerequisite, so we can leverage this new feature here.

To enable the client auto upgrade

1)       In the Configuration Manager console, click Administration.

2)      In the Administration workspace, click Site Configuration.

3)      Click Sites.

4)      On the Home tab, in the Properties group, click Hierarchy Settings.

5)      Enable Upgrade client automatically when new client updates are available

After that, CCM client will find that there is a new SCEP client software available and install it automatically. Depending on the policy retrieval interval and the setting of “Automatically upgrade client within days”, it could be from 4 hours to several days.

--Nina Qin

• CU will not update the Admin Console even though it’s on the same machine
• CU will generate catalog to be consumed in SCUP 2011.

One thing many people confuse is that they think of CU as a service pack. Actually, CU is lighter than a service pack. You can think of CU as a bigger update that contains more bug fixes and affects more files than normal hotfix. So it doesn’t increase all the file versions or change the version in registry key as a service pack would do.

In this blog, I will take SCCM 2012 SP1 CU1 (KB2817245) as an example; show what you would expect to see and what you would not see after installing the update.

There’re three steps to upgrade your whole Configuration Manager 2012 SP1 infrastructure to CU1 level:

1. Install update on all sites: you need to install CU on all sites: Central Administrative Sites (CAS), Primary Sites, Secondary Sites and Providers.
2. Install update on all admin consoles
3. Install update on all clients

Step 1   Install hotfix on all sites.

First, run the CU installation wizard on CAS or your single primary site. If you choose all the defaults, it will help you update the database and create the software distribution packages for SMS Site Server, Admin Consoles and Clients. You can choose to update the database later (run <SMS Installation Folder>\Hotfix\KB2817245\update.sql) or create the software distribution packages later. But it’s more convenient for the installation wizard to do all the work for you.  To troubleshoot, you can check the CU1 installation log under c:\windows\temp.

Now to upgrade all the other sites and providers, you can deploy the SP1 Cumulative update 1 – server update – XXX to all the primary sites, secondary sites and providers. Or, you can just run the installation executive on those machines.

To verify installation status, you can go to the following places to check:

In Control Panel -> Programs and Features -> Installed Updates

In SMS installation folder, you’ll see a folder contains the updates for admin console, clients and the sql script:

Under <SMS installation folder>\bin\x64, some files are upgraded to 5.0.7804.1202. That is the version for CU1.

Open the Configuration Manager Console, the four packages are created under Packages-> Configuration Manager Updates.

Note: You cannot upgrade Secondary Site by click the Upgrade in UI or see the version change in registry key or in database. As is stated before, CU is lighter than Service Pack. It’s not a major upgrade.

Step 2 Install hotfix on all admin consoles.

You can use the packages created above to deploy admin console update to all admin consoles, or you can just run the configmgr2012adminui-sp1-kb2817245-i386.msp from the folder <SMS Installation folder>\hotfix\ KB2817245\AdminConsole\i386.

To verify installation status, you can go to the following places to check:

In Control Panel -> Programs and Features -> Installed Updates

Under <SMS installation folder>\AdminConsole\bin, some files will be upgraded to version 5.0.7804.1202. It’s the version of CU1.

In Configuration Manager Console -> About

Note: install the hotfix on a site server with admin console will not automatically upgrade the admin console. If you install the site update but don’t install the admin console update, you’ll still see 5.0.7804.1000 here. And you will not see some admin console fixes.

Step 3 Install hotfix on all clients.

You have three options:

1. With SCUP: The installation wizard will help generate the SCUP catalog for each update: defining the installable rules and installed rules. You can use SCUP 2011 to import and publish the update to WSUS and deploy it to CM client through Software Update Manager feature.
2. Software Distribution: The installation wizard will help generate two client update packages: one for 32-bit client and one for 64-bit client.
3. Manually run the client hotfix on the client. You can find the update under <SMS Installation Folder>\hotfix\KB2817245\Client

To verify installation status, you can go to the following places to check:

Under CCM Client folder, some files will be upgraded to 5.0.7804.1202. It’s the CU1 build number.

In Control Panel -> Configuration Manager -> Components, some component version will be updated:

Note: You cannot upgrade the client by enabling the “Automatic Client Upgrade”. That feature is for major version of CM client upgrade and prerequisite upgrade: for example you can upgrade your CM07 & CM2012 RTM client to SP1 version with this feature enabled; or you can upgrade you end point protection client to the latest version. But this feature will not install hotfix/update to the client.

A summary of what you need to remember: CU is an update not a service pack level change. You need to install admin console update even if it’s on the same machine with the site server.

“FEP Service Policy” is an undocumented policy. “FEP Service Policy” is not created by default when you install FEP 2010 (with or without Update Rollup 1). It is created when the last FEP policy associated with one collection is deleted. The purpose of this policy is to make sure FEP clients always have one policy applied.  Upon FEP policy modification, the old advertisements/assignments related to that policy will be deleted and a new advertisement/assignment will be created. If there’s a delay between the deletion and the creation of the assignment on the CM/FEP clients, these clients will end up applying the “FEP Service Policy”.

In most cases, applying “FEP Service Policy” accidently is fine. As the correct FEP policy will be applied at the next cycle. But some customers may find it unacceptable as it means they lose control on their clients at the intermit time. Because they don’t have control on “FEP Service Policy” as it’s not shown on UI and they cannot update it. For these customers, I wrote the following script for them to configure the “FEP Service Policy”.

The usage of this script is to:

1)                Run FEPServicePolicy.vbs export FEPServicePolicy.xml to export the policy file

2)                Update FEPServicePolicy.xml as needed.

3)                Run FEPServicePolicy.vbs import FEPServicePolicy.xml to import the updated policy file.

If the script shows there’s no “FEP Service Policy”, you can trigger the creation of “FEP Service Policy” by:

1)                Create a fake collection

2)                Create a FEP Policy and assign to that collection.

3)                Delete that policy.

 Sample Scripts:

'Usage: FEPServicePolicy <export|import> <policyfilename>

'Parse Parameters

if (WScript.arguments.count<>2) then

 Wscript.echo "Usage: FEPServicePolicy <export|import> <policyfilename>"

 wscript.quit

end if

Command = Wscript.arguments(0)

FileName = Wscript.arguments(1)

ProgramName = "FEP Service Policy"

Dim PackageID

Wscript.Echo "Impurt Parameters: " & Command & " " & FileName

Wscript.Echo "Connecting to SMS WMI namespace.."

Set Conn = Connect

Wscript.Echo "Getting the PackageID for the FEP Service Policy Program"

Set Programs = Conn.ExecQuery("select * from SMS_Program where ProgramName='FEP Service Policy'")

if Programs.Count <> 1 Then

   Wscript.Echo "FEO Service Policy not found or instances are more than 1. Fatal Error, quit."

   Wscript.quit

End If

For Each objItem In Programs

  PackageID = objItem.PackageID

  Wscript.Echo "Found Program. PackageID = " & PackageID

Next

if  Command = "export" Then

 Wscript.Echo "Export the existing FEP service Policy"

 Export Conn, FileName

 Wscript.quit

end if

If Command = "import" Then

 Wscript.Echo "Import the FEP service Policy from file " & FileName

 Import Conn, FileName

 Wscript.quit

end if

Function Export(connection, exportFileName)

  Dim oFilesys, oFileLog, sFilename, sPath

  Set oFilesys = CreateObject("Scripting.FileSystemObject")

  Set oFiletxt = oFilesys.CreateTextFile(exportFileName, True)

  Set FEPServicePolicyProgram = connection.Get("SMS_Program.PackageID='" & PackageID & "',ProgramName='" & ProgramName & "'")

  hexarray = FEPServicePolicyProgram.ISVData

  'wscript.echo UBound(hexarray)

  For i = 0 To UBound(hexarray)

    'oFiletxt.Write(HexToString(HEX(hexarray(i))))

    oFiletxt.Write(Chr("&h" & (HEX(hexarray(i)))))

  Next

  oFiletxt.Close

  Wscript.Echo "Export succeed"

End Function

Function Import(connection, importFileName)

  Dim oFilesys, oFileLog, sFilename, sPath

  Set oFilesys = CreateObject("Scripting.FileSystemObject")

  Set oFilereader = oFilesys.OpenTextFile(importFileName,1,False)

  contents = oFilereader.ReadAll

  Length = Len(contents)

  'Wscript.Echo Length

  dim hexarray()

  ReDim hexarray(Length)

  For i = 1 To Length

                    sub_string = Mid(contents,i,1)

                    'hexarray(i-1) = CInt("&h" & StringToHex(sub_string))

                    hexarray(i-1) = CInt("&h" & Hex(Asc(sub_string)))

        'Wscript.Echo hexarray(i-1)

  Next

  Set FEPServicePolicyProgram = connection.Get("SMS_Program.PackageID='" & PackageID & "',ProgramName='" & ProgramName & "'")

  FEPServicePolicyProgram.ISVData=hexarray

  FEPServicePolicyProgram.Put_

  oFilereader.Close

  WScript.Echo "Import succeed"

End Function

Function Connect()

    On Error Resume Next

    Dim net

    Dim localConnection

    Dim swbemLocator

    Dim swbemServices

    Dim providerLoc

    Dim location

    Set swbemLocator = CreateObject("WbemScripting.SWbemLocator")

    ' Connect to the server.

    Set swbemServices= swbemLocator.ConnectServer(".", "root\sms")

    If Err.Number<>0 Then

        Wscript.Echo "Couldn't connect: " + Err.Description

        Connect = null

        Exit Function

    End If

    ' Determine where the provider is and connect.

    Set providerLoc = swbemServices.InstancesOf("SMS_ProviderLocation")

        For Each location In providerLoc

            If location.ProviderForLocalSite = True Then

                Set swbemServices = swbemLocator.ConnectServer(location.Machine, "root\sms\site_" + location.SiteCode)

                If Err.Number<>0 Then

                    Wscript.Echo "Couldn't connect:" + Err.Description

                    Connect = Null

                    Exit Function

                End If

                Set Connect = swbemServices

                                        Wscript.Echo "Successfully comment to root\sms\site_" & location.SiteCode

                Exit Function

            End If

        Next

    Set Connect = null ' Failed to connect.

End Function

-- This script is provided AS IS. Please test it out before apply to production.

1. On Windows Server 2012, the WSUS version is 4.0. While on all other OSes, you can only install WSUS 3.0 (with or without service pack). WSUS 3.0 & WSUS 4.0 cannot communicate with each other. So if you install SCUP on a machine with WSUS 3.0 admin console and try to publish to Windows Server 2012 with WSUS 4.0, you’ll get a WSUS version mismatch error in the SCUP log.

You can, however, install SCUP 2011 on Windows 8 and publish to the WSUS on Windows Server 2012. You need to install Remote Server Administration Tools for Win 8 https://www.microsoft.com/en-us/download/details.aspx?id=28972 on Windows 8 machine. It will install the WSUS 4.0 version of the WSUS admin console binary on Win 8. And with that, you can talk with WSUS 4.0 on Windows Server 2012.

2. Low right user scenario is broken currently on Windows Server 2012. Normally, the user should only be in the WSUS administrative group to publish updates successfully. But the user to use and publish update to Windows Server 2012 must be a member of the local administrator.

Workaround for this: (do the followings on the Windows Server 2012)

(1)    Change the ownership of HKEY_CLASSES_ROOT\AppID\{8F5D3447-9CCE-455C-BAEF-55D42420143B} to Administrators

https://technet.microsoft.com/en-us/library/cc786173(v=WS.10).aspx

(2)    Change the permission on that key. Make sure Administrators and System have full control on that.

(3)    launch Dcomcnfg.exe in elevated mode.

(4)    Select “Component Services”àComputeràMy Computerà”Dcom Config”àWSusCertServer. Right Click and select “Properties”.

(5)    “WSusCertServer Properties” dialog will show up. Switch to“Security tab”

(6)    Set “Launch and Activation Permissions” and “Access Permissions” like the following

(7)    restart WSusCertServer (net stop/net start)

 Hope you enjoy using SCUP 2011 with Windows Server 2012.

If you use Software Update Point (SUP) in a System Center Configuration Manager 2007 hierarchy, you may face the problem of expired updates.

Consider the following scenario:

Updates are saved in the SMS database as CIs (Configuration Items). All CIs will flow downward to the child sites in the hierarchy.

If the updates are expired, the CI will also be marked as expired. Each site (central or child primary) has the Delete Aged Configuration Manager Data job that removes CIs that have been expired for 90 days (by default) which are not locally referenced. -- “Locally referenced” means it’s not used in any Update Lists created by this site.

So if you create Update Lists on the child site which contains a CI (Update) that has been expired, the CI is not removed from the child site since it is referenced by an local Update List; But the CI is removed from the parent site by the “Delete Aged Configuration Manager Data” job because Update Lists don’t flow up to the parent site.

Now if there is a new third tier primary site (a grandchild site), its SUP WILL NOT get this CI from the central site’s SUP because it has already been removed from the top-most SUP. Its SUP WILL get the Update List which contains the expired CI from its parent site. So the new grandchild site will fail to process this Update List that reference the now-missing CI.

To solve this problem, we have written a script that can clear expired updates from the Update Lists, Update Deployment and Update Packages. As a best practice, we’d suggest to clear up the expired updates and in a one day schedule:

• Set the update cleanup age to 1 day. Site Settings->Site Maintenance->Tasks-> Delete Aged Configuration Manager Data Properties->Set Delete data older than (days): to 1
• Run the attached script on the site where you create Update Lists every day. You can use Windows Task Schedule to do it.

Here comes the sample script:

Dim Debugging        'If debug logging is enabled

Dim connection       'the Service Object

Dim context              'SMS WMI context

Dim SMSSiteCode    'The site code of the site that we peform clear up

Dim SMSServer         'The machine name of the site server

Dim SMSProvider     'The machine name of the provider

Dim UserName        'username used to connect to the remote server

Dim Password          'Password used to connect to the remote server

DebugLogging = false

Set objArgs = WScript.Arguments

call ParseParameters(objArgs)

Log("SMSServer: "&SMSServer)

Log("UserName: "&UserName)

Log("Password: "&Password)

Set context = CreateObject("WbemScripting.SWbemNamedValueSet")

' Add the standard SMS context qualifiers to the context object.

context.Add "LocaleID", "MS\1033"

context.Add "MachineName", SMSServer

context.Add "ApplicationName", "ClearExpiredUpdates"

Set connection = Connect(SMSServer,UserName,Password)

If Err.Number<>0 Then

    Wscript.Echo "Call to connect failed"

End If

'collect all expired CIs

'save to Variable - ExpiredCIs

Query = "SELECT * FROM SMS_SoftwareUpdate " & _

        "WHERE IsExpired='TRUE'"

Set ExpiredCIs = connection.ExecQuery(Query, ,wbemFlagForwardOnly Or wbemFlagReturnImmediately, Context)

Log("Expired CI IDs: ")

For each ExpiredCI in ExpiredCIs

    Log(ExpiredCI.CI_ID)

Next

'Remove from UpdateList

call RemoveExpiredUpdatesFromUpdateList(connection,context,SMSSiteCode,ExpiredCIs)

'Remove from Deployment

call RemoveExpiredUpdatesFromDeploymens(connection,context,SMSSiteCode,ExpiredCIs)

'Remove Expired updates' content from the packages

call RemoveExpiredUpdatesContent(connection,context,SMSSiteCode,ExpiredCIs)

If Err.Number<>0 Then

    WScript.Echo "Clear Failed"

Else

    WScript.Echo "Clear Successfully, please trigger a Full Update Synchronization"

End If

WScript.Quit

Function Connect(server, userName, userPassword)

    Dim net

    Dim localConnection

    Dim swbemLocator

    Dim swbemServices

    Dim providerLoc

    Dim location

    Set swbemLocator = CreateObject("WbemScripting.SWbemLocator")

    swbemLocator.Security_.AuthenticationLevel = 6 'Packet Privacy

    ' If  the server is local, don't supply credentials.

    Set net = CreateObject("WScript.NetWork")

    If server = "." Then

        localConnection = true

        userName = ""

        userPassword = ""

        server = "."

        Log("Connecting to local machine...")

    Else

        Log("Connect to remote machine: "&server&"...")

    End If

    ' Connect to the server.

    Set swbemServices= swbemLocator.ConnectServer _

            (server, "root\sms",userName,userPassword)

    If Err.Number<>0 Then

        Wscript.Echo "Couldn't connect: " + Err.Description

        Connect = null

        Exit Function

    End If

    Log("Connected successfully")

    ' Determine where the provider is and connect.

    Set providerLoc = swbemServices.InstancesOf("SMS_ProviderLocation")

        For Each location In providerLoc

                SMSProvider = location.Machine

                SMSSiteCode = location.SiteCode

                If UCase(net.ComputerName) = UCase(SMSProvider) Then

                    SMSProvider = "."

                    userName = ""

                    userPassword = ""

                End If

                Log("SMSProvider: "&SMSProvider)

                Log("SMSSiteCode: "&SMSSiteCode)

                Set swbemServices = swbemLocator.ConnectServer _

                 (SMSProvider, "root\sms\site_" + _

                    SMSSiteCode,userName,userPassword)

                If Err.Number<>0 Then

                    Wscript.Echo "Couldn't connect:" + Err.Description

                    Connect = Null

                    Exit Function

                End If

                Log("Connected to provider")

                Set Connect = swbemServices

                Exit Function

        Next

    Set Connect = null ' Failed to connect.

End Function

Sub ParseParameters(Parameters)

    For each objArg in Parameters

        CorrectParametersSofar = false

        objArgShort = left(objArg,2)

        If objArgShort = "-d" Then

            DebugLogging = true

            CorrectParametersSofar = true

        End If

        If objArgShort = "-l" Then

            SMSServer = "."

            UserName = ""

            Password = ""

            CorrectParametersSofar = true

        End If

        If objArgShort = "-r" Then

            SMSServer = Right(objArg,Len(objArg)-3)

            CorrectParametersSofar = true

        End If

        If objArgShort = "-u" Then

            UserName = Right(objArg,Len(objArg)-3)

            CorrectParametersSofar = true

        End If

        If objArgShort = "-p" Then

            Password = Right(objArg,Len(objArg)-3)

            CorrectParametersSofar = true

        End If

        If CorrectParametersSofar = false Then

            WScript.Echo "Wrong parameters"

            call PrintUsage

            WScript.Quit

        End If

    Next

End Sub

Sub Log(message)

    If DebugLogging = true Then

        WScript.Echo message

    End If

End Sub

Sub PrintUsage

    WScript.Echo "Usage of this script: "

    WScript.Echo "cscript ExpireClear.vbs [-d] -l|-r:<remoteserver> -u:<Username> -p:<password>"

    WScript.Echo "-d enable debug logging"

    WScript.Echo "-l connect to local machine"

    WScript.Echo "-r connect to remote machine"

    WScript.Echo "If you use -r, you need to specify the username and password"

End Sub

Sub RemoveExpiredUpdatesFromUpdateList(swbemServices,  swbemContext,   siteCode, ExpiredCIs)

    Log("====Removing Expired Updates From Update List====")

    Query = "SELECT * FROM SMS_AuthorizationList " & _

            "WHERE SourceSite='" & siteCode & "'"

    Set UpdateLists = swbemServices.ExecQuery(Query, ,wbemFlagForwardOnly Or wbemFlagReturnImmediately, swbemContext)

    For each UpdateList in UpdateLists

        Log("Checking UpdateList CI_ID = "&UpdateList.CI_ID)

        Set UpdateListLazy = swbemServices.Get("SMS_AuthorizationList.CI_ID=" & UpdateList.CI_ID)

        UpdatesNumOrg = UBound(UpdateListLazy.Updates) + 1

        Log("Updates Number Before: " & UpdatesNumOrg)

        ResultUpdates = UpdateListLazy.Updates

        For each ExpiredCI in ExpiredCIs

            Resultupdates = Filter(Resultupdates,ExpiredCI.CI_ID,FALSE)

        Next

        UpdatesNumAfter = UBound(Resultupdates) + 1

        Log("Updates Number After: " & UpdatesNumAfter)

        UpdateListLazy.Updates=Resultupdates

        UpdateListLazy.Put_

    Next

End Sub

Sub RemoveExpiredUpdatesFromDeploymens(swbemServices, swbemContext,  siteCode,  ExpiredCIs)

    Log("====Removing Expired Updates From Update Deployments====")

    Query = "SELECT * FROM SMS_UpdatesAssignment " & _

            "WHERE SourceSite='" & siteCode & "'"

    Set UpdateAssignments = swbemServices.ExecQuery(Query, ,wbemFlagForwardOnly Or wbemFlagReturnImmediately, swbemContext)

    For each UpdateAssignment in UpdateAssignments

        Log("Checking UpdateAssignment AssignmentID = "&UpdateAssignment.AssignmentID)

        Set UpdateAssignmentLazy = swbemServices.Get("SMS_UpdatesAssignment.AssignmentID=" & UpdateAssignment.AssignmentID)

        ContainsExpired = UpdateAssignmentLazy.ContainsExpiredUpdates

        If ContainsExpired = true Then

                      Log("ContainsExpired=true")

            CINumOrg = UBound(UpdateAssignmentLazy.AssignedCIs) + 1

            ResultCIs = UpdateAssignmentLazy.AssignedCIs

            Log("Updates Number Before: " & CINumOrg)

            For each ExpiredCI in ExpiredCIs

                ResultCIs = Filter(ResultCIs,ExpiredCI.CI_ID,FALSE)

            Next

            CINumAfter = UBound(ResultCIs) + 1

            Log("Updates Number After: " & CINumAfter)

            UpdateAssignmentLazy.AssignedCIs=ResultCIs

            UpdateAssignmentLazy.Put_

        Else

            Log("ContainsExpired=false")

        End If

    Next

End Sub

Sub RemoveExpiredUpdatesContent(swbemServices, swbemContext, siteCode, ExpiredCIs)

    Log("====Removing Expired Updates Content From Deployment Packates====")

    For each ExpiredCI in ExpiredCIs

        Log("Checking ExpiredCI: "&ExpiredCI.CI_ID)

        Query = "SELECT * FROM SMS_CIToContent " & _

                "WHERE CI_ID=" & ExpiredCI.CI_ID

        set ExpiredContents = swbemServices.ExecQuery(Query, ,wbemFlagForwardOnly Or wbemFlagReturnImmediately, swbemContext)

        For each ExpiredContent in ExpiredContents

            Log("Corresponding ContentID = "&ExpiredContent.ContentID)

            Query = "SELECT * FROM SMS_SoftwareUpdatesPackage " & _

                    "WHERE SourceSite='" & siteCode & "'"

            set Packages = swbemServices.ExecQuery(Query, ,wbemFlagForwardOnly Or wbemFlagReturnImmediately, swbemContext)

            For each Package in Packages

                Log("Checking Deployment Package PackageID= " & Package.PackageID)

                Query = "SELECT * FROM SMS_PackageToContent " & _

                        "WHERE PackageID = '" & Package.PackageID & "'"         

                set Contents = swbemServices.ExecQuery(Query, ,wbemFlagForwardOnly Or wbemFlagReturnImmediately, swbemContext)

                For each Content in Contents

                    Log("ContentID: "&Content.ContentID)

                    If Content.ContentID = ExpiredContent.ContentID Then

                        Log("ExpiredContent: " & Content.ContentID & " - will be delete")

                        Content.Delete_

                    End If

                Next

            Next

        Next

    Next

End Sub

--- The script is provided as is. Please test before implement in the product environment

This update is now released to download center only and not yet be enforced to MU. So customers have some time to review all their certificates used and see if they meet the key length requirement.

System Center Update Publisher requires a certificate to sign the 3^rd party updates and that certificate need to be trusted by all the WU Agent clients. We support two ways to create this signing certificate: Create one from an existing Public Key Infrastructure or create a self-sign certificate through SCUP console. The later one will call WSUS API to create the self-sign certificate.

https://blogs.technet.com/b/jasonlewis/archive/2011/07/12/system-center-updates-publisher-signing-certificate-requirements-amp-step-by-step-guide.aspx shows the step to create a certificate from windows PKI. It mentions the minimum key size is 2048.

Every modern security algorithm can be cracked by brute force. It’s just a matter of the time. When the key length is longer enough, it can take decades to brute force crack it. Recent research shows: 512 is not a safe key length for RSA, so MS release the update to require key length of 1024. 1024 is safe for now, but with the development of computing capacity, it might not be safe in the future. So if you can control the length, we’d suggest it to be at least 2048.

If you choose to use self-sign certificate through SCUP, then you cannot decide the key length of the certificate you created. WSUS API will decide the key length.

For WSUS 3.0 SP2 without hotfix, the key length will be 512.

For WSUS 3.0 SP2 with hotfix KB2530678 or KB2530709 (the two updates that are pre-requisites for SCUP 2011) or KB 2720211 (the WSUS hardening update which included the KB2530678 and KB2530709), the key length will be 1024.

So check the SCUP signing certificate on your environment, if it’s 512, then you’ll need to re-create it. Otherwise, OS applied KB2661254 (the RSA key block update) will fail to install the 3^rd party updates published with SCUP.

You will see the following error in WUAHandler.log (and WindowsUpdate.log):

Failed to download updates to the WUAgent datastore. Error = 0x80096004

0x80096004 means “The signature of the certificate cannot be verified”.