Deleting Updates from WSUS

After we migrated our first SCCM server to Windows 2008 R2, we were dealing with a problem with the WSUS components.  It had over 40k updates which clients were having issues described here in the link below. I'd definitely recommend pruning the upstream server if your other site servers are half way around the world before re-installing WSUS.

https://blogs.technet.microsoft.com/sus/2008/09/18/wsus-clients-fail-with-warning-syncserverupdatesinternal-failed-0x80244010/

The workaround was to test the component to see if it was working was to set the value for the item below, of course this caused issue for sites in slow links the next morning so it was reverted back to the default size of 5MB.

USE SUSDB
GO
UPDATE tbConfigurationC SET MaxXMLPerRequest = 0

https://social.technet.microsoft.com/Forums/en-US/29c7952e-6eb3-41e7-87f0-bc1162953179/wsus-30-sp1-client-update-failure?forum=winserverwsus

To prevent the next WSUS sites from inheriting unnecessary updates, there's a script to delete the updates that the Server Wizard is not removing after declining.

Using the script from the link below, we used it to remove the Drivers.

http://runesk.blogspot.com/2012/09/delete-oldunwanted-updates-from-wsus.html

For other updates, I modified it some to read it from a text file so I can review the updates and add it into one txt file and let it run overnight to remove all unneeded updates for OS we no longer use or never used like XP, Vista, Windows 8, Server 2003, etc.  When I first ran it, it was faster than the query method but on subsequent it took just as long.  Or if decline the updates, you can just change the script to delete declined updates.

Here's a good reference link on the updates you can decline from the WSUS console.

https://blogs.technet.microsoft.com/configurationmgr/2015/04/15/support-tip-configmgr-2012-update-scan-fails-and-causes-incorrect-compliance-status/


Delete Updates from list - Powershell

$wsusserver = "localhost"
$ids = get-content 'c:\Vista-guid.txt'
[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | out-null
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($wsusserver,$False,"8530")
ForEach ($id in $ids){$wsus.DeleteUpdate($id); Write-Host $id removed}

or replace the red text with the below to delete the recently declined updates.

$wsus.getupdates() | Where {$_.IsDeclined -eq 'True'} | ForEach-Object { $wsus.DeleteUpdate($_.Id.UpdateID); Write-Host $_.Title removed }

To get the updates, you'll need to open up the SQL console and connect to the WSUS DB, this is a sample query for declined items.  Copy the UpdateID column into the txt file of updates you want to delete.   Depending on your server resources, using the script to delete a criteria may be slower than from a list.

Get Declined Updates SQL

select UpdateID from PUBLIC_VIEWS.vUpdate
where isDeclined = '1'

Once you have cleaned it up, here's another good reference below on maintaining it.  If you are in a multi-hierarchy site you may want to configure it as a downstream replicas if the software update deployments are centrally managed on the parent site and no SUP deployments are managed from the child primaries.

https://blogs.technet.microsoft.com/configurationmgr/2016/01/26/the-complete-guide-to-microsoft-wsus-and-configuration-manager-sup-maintenance/

Refresh All Packages on a DP

Having a recent DP suddenly die and no way to bring it back up to properly decommission, you can spend some MS hours for a SQL script to delete everything or rebuild a computer with the same name and decommission it properly by "adding" the packages back to it using a script. 

The script refreshes all packages and what's interesting to note is that it doesn't matter that the drive on the old server wasn't the same location.  Of course, if you are rebuilding for production use and have a specific drive to use, put the NO_SMS_ON_DRIVE file where you don't want it to create it and be mindful of the bandwidth to whatever site because it will transmit all the packages again.

This isn't the same as adding packages to a DP that was never on it and will only refresh the packages  SCCM shows up with the server.

The script below reads from a list of packageIDs that I exported into a txt file.

Check the distmgr.log on the site server where the DP is to see the progress.

A note that if your site is  multi-site hierarchy, you'll need to enter the site code where the DP is in not the parent site where the package was distributed from.

Dim StrSMSServer, DPs, ObjFS, StrFile, ts, strPackageID, DP

'On Error Resume Next

strSMSServer = ""
strDPserver = ""

strSMSSiteCode = ""

Set objLoc =  CreateObject("WbemScripting.SWbemLocator")
Set objSMS= objLoc.ConnectServer(strSMSServer, "root\sms")

Set Results = objSMS.ExecQuery _
  ("SELECT * From SMS_ProviderLocation WHERE ProviderForLocalSite = true")
For each Loc in Results
  If Loc.ProviderForLocalSite = True Then
    Set objSMS = objLoc.ConnectServer(Loc.Machine, "root\sms\site_" & _ 
        Loc.SiteCode)
    'strSiteCode = Loc.SiteCode
  end if
Next

Set objFS = CreateObject("Scripting.FileSystemObject")
strFile = "c:\dp1.txt"

Set objFile = objFS.GetFile(strFile)
Set ts = objFile.OpenAsTextStream(1,-2)

Do Until ts.AtEndOfStream

    strPackageID = ts.Readline()


Set DPs = objSMS.ExecQuery ("Select * From SMS_DistributionPoint WHERE ServerNALPath like '%" & strDPserver & "%' and siteCode='" & strSMSSiteCode & "' and PackageID='" & strPackageID & "'")
For Each DP In DPs
    wscript.echo strPackageID
    DP.RefreshNow = True
    DP.Put_
Next

Loop

SCCM 2007 Backup Failing - Hangs Indefinitely At SCOM Maintenace Mode

For the last 2 days, I've been on the phone with MS engineers and they haven't been able to figure out the issue to unstuck the MaintenancemodeSCOM.  We don't use SCOM in our environment and on working servers, it goes right by this error in a matter of seconds.   This didn't continue after the 1 hour timeout but shouldn't have to wait that long.  We are working with a partner for a project to upgrade our server OS and they were able to escalate this and on the 2nd day get the best of the best SCCM engineers, they tried their best but still weren't able to get any further than the first day going in with deeper dives and traces.

Still continuing working on day 2, I tried a different approach that we didn't try earlier with MS.  We already tried putting the services into a stopped state or stopping it when it gets stuck but it doesn't work but had before but what I always noticed is that after VSS was stopped then SMS_SITE_BACKUP was able to continue to stop the services.  At that point the backup would be logged as failed.  The logs however doesn't indicate anything in an unstable state or errors so that appears to be fine.

So what was tried differently was putting those 2 services in a paused state first and stopped VSS.  Let the backup or the writer start the VSS service and tehn start the backup.  This worked correctly 4 out of 5 times with the logs showing both writers are in a stable state on a successful completion with the correct event ID of 6833.  I think the 4th time VSS was already running so it should be stopped before a backup is enabled.  

Writers are Stable

It was a repeatable process and hopefully it will allow us to progress with upgrading these servers off 2003 R2 to 2008 R2 which I hope have more stable back up.  Not quite sure if the smsbkup.exe or the VSS is the issue but I believe somewhere with the 2 services. 

On Monday, we'll have MS validate this is a workable solution that can be used to get working backups.

Event ID 6833 indicates succesful backup

Update 3/7/2016: The Microsoft engineer validated that the method used to produce the backups is good in the sense the manual method is essentially the same as sms backup performing it and going by the official documentation that as long as the Event ID is produced the backup is successful.  To really confirm however the backups are valid, is to do restore it on the new server.