If your existing SUSDB is hosted by the Windows Internal Database version of SQL that is installed by WSUS 3.x you may have noticed that remote connections to the database don’t work. This is actually expected behavior because the Windows Internal Database is an application version of SQL Server 2005 which is a special, limited version of SQL Server 2005 Express Edition that does not support remote access.
To perform remote queries against the database, you will need to
1. Install a full version of SQL Server 2005 or install the standalone version of SQL Server 2005 Express Edition.
2. Migrate the SUSDB
3. Use SQL Server Management Studio Express to enable remote connections.
Sounds simple enough, right? Well let’s take a look at how exactly to do this. The general steps include:
1. Download and install Microsoft SQL Server 2005 Express Edition.
2. Install the SQL Server Management Studio Express tool.
3. Detach the SUSDB.
4. Attach the SUSDB to SQL Server 2005 Express
5. Configure SQL Server 2005 Express to allow remote connections.
6. Configure user/group access to the database.
Now we’ll walk through each step in a little more detail.
1. Download and install Microsoft SQL Server 2005 Express Edition. You can download Microsoft SQL Server 2005 Express Edition from http://msdn2.microsoft.com/en-us/express/bb410792.aspx. During installation, when prompted for an instance name select "Default instance" then proceed through the installation wizard choosing the default settings.
2. Install the SQL Server Management Studio Express tool. This is available from http://msdn2.microsoft.com/en-us/express/bb410792.aspx.
3. Detach the SUSDB:
a. Stop the IIS Admin service and the Update Services service:
i. Click Start, point to Programs, point to Administrative Tools, and then click Services.
ii. Right-click IIS Admin Service, and then click Stop.
iii. Right-click Update Services, and then click Stop.
b. Open the Microsoft SQL Server Management Studio Express console (Start -> Programs -> Microsoft SQL Server 2005)
i. From the File menu, click "Connect Object Explorer" and use the following
settings:
· Server type: Database Engine
· Server name: \.\pipe\MSSQL$MICROSOFT##SSEE\sql\query
· Authentication: Windows Authentication
ii. Click the "Connect" button
iii. Expand Databases under \.\pipe\MSSQL$MICROSOFT##SSEE\sql\query
iv. Right click SUSDB, choose Tasks/Detach, enable the check boxes for Drop Connections, Update Statistics, and Keep Full Text Catalogs, then click OK.
4. Attach the SUSDB to SQL Server 2005 Express:
a. Open the Microsoft SQL Server Management Studio Express console (Start -> Programs -> Microsoft SQL Server 2005).
b. From the File menu, click "Connect Object Explorer" and use the following settings:
· Server type: Database Engine
· Server name: enter the actual name of your WSUS server here
· Authentication: Windows Authentication
c. Right click the Databases object, choose Attach, click Add in the Databases to attach area, browse to the location of your SUSDB.mdf (for example, c:\wsus\updateservicedbfiles), select the SUSDB.mdf, when the "SUSDB" database details pane is populate, highlight the susdb_log.ldf log file, click Remove, then click OK to add the SUSDB.mdf.
d. Verify that NT AUTHORITY\NETWORK SERVICE has login permissions to the SQL Server instance and to the WSUS database. If it does not, you will need to add it to both locations. This account should also be a member of the webService role on the WSUS database.
i. Verify permissions on the SQL Server instance. In SQL Server Management Studio, open the instance and select Security, then Logins. The NT AUTHORITY\NETWORK SERVICE account should be listed as a login. If it is not, it should be added.
ii. Verify permissions on the database. Right-click the database, select Properties and then click Permissions. The NT AUTHORITY\NETWORK SERVICE account should be listed as a login. If it is not, it should be added.
iii. Verify members of the webService role. Under the WSUS database, select Roles, then right-click webService and select Properties. The NT AUTHORITY\NETWORK SERVICE account should be listed as a member of this role. If it is not, it should be added.
e. Edit the registry to point WSUS to the SQL instance that now holds SUSDB.
i. Click Start, click Run, type regedit, and then click OK.
ii. Find the following key:
HKLM\SOFTWARE\Microsoft\UpdateServices\Server\Setup\SqlServerName
In the Value box enter your WSUS server name and click OK.
f. Open Services and then start the IIS Admin service and Update Services service.
i. Click Start, point to Programs, point to Administrative Tools, and then click Services.
ii. Right-click IIS Admin Service, and then click Start.
iii. Right-click Update Services, and then click Start.
g. Verify that the database migration has been successful by opening the WSUS administrative console (click Start, click Administrative Tools, and then click Microsoft Windows Server Update Services 3.0).
5. Configure SQL Server 2005 Express to allow remote connections:
a. Open Start/Programs/Microsoft SQL Server 2005/Configuration Tools/SQL Server Surface Area Configuration. This tool is used to configure services, network protocols and components for SQL Server.
b. On starting the tool, select the Surface Area Configuration for Services and Connections option to open the configuration dialog box.
c. Configure the Remote Connection Options. The configuration dialog box is divided into two areas. The left side of the window provides navigation and the right side allows modification of the available settings. Select Remote Connections from the navigation area. You will see that the server is configured to allow local connections only.
To enable remote connections, simply select the radio button for Local and Remote Connections. You may then select which network protocols you wish the server to accept. Once set, every database in the SQL Server Express instance is accessible
remotely via the network.
d. Restart the Database Engine service.
6. Configure user/group access to the database:
After you have remote connections configured via the previous steps, you may also need to configure the permissions further on the database for individual users who are not local administrators on the WSUS server but who need remote query access.
The best option here is to add these users to the built-in, local WSUS Reporters Group then configure a login for the database for this group using the following steps:
· Open Microsoft SQL Server Management Studio Express.
· Expand the Security folder on SQL Server, right click on the logins folder, and select new login.
· Add the WSUS Reporters group from Active Directory into the login name if it is not present.
· Select the User Mappings and check the box next to the SUSDB database.
· Select the WSUS Reporters group's properties within SQL Server and add the role of db_datareader for the login on the database.
After these steps, the members of the WSUS Reporters group should be able to perform the desired remote queries.
Hope this helps,
Mike Johnson | WSUS Support Escalation Engineer
Here's a new Knowledge Base article that recently published regarding Windows Server Update Services 3.0 and the Office 2003 Service Pack 1 update issue. There are download links to the fix included in the article.
========
http://support.microsoft.com/?kbid=954960
Some computers do not receive updates from the WSUS server
WSUS 3.0 SP1 AL
EN-US
========
Enjoy!
J.C. Hornbeck | Manageability Knowledge Engineer
Client communication
When troubleshooting clients, the first thing you'll want to look at is the windowsupdate.log which will be in c:\%windir%\Windowsupdate.log. In order to understand how to read the windowsupdate.log , the reference for it is located at:
http://support.microsoft.com/kb/902093
The first step is to make sure you see the actual WSUS server name in the log - if not that indicates a policy or registry setting used for the policy is not in place.
Next get the errors for the client trying to contact WSUS and check the error code against the error code reference for Windows Update agent. For a reference see:
Appendix G: Windows Update Agent Result Codes : http://technet2.microsoft.com/windowsserver/en/library/061d0423-f7f1-401e-9ef7-b7d02cd50b7a1033.mspx
Another way to obtain the logs is to use the audbgtrace.exe from www.codeplex.com/WSUS.
Using option 2 will trigger the detection cycle for the windows update agent and enable the verbose logging for winhttp and the windows update agent itself.
Check for the logs created on c:\audbgtrace\data or the cab file to send to a Microsoft Professional in c:\audbgtrace\cabs
Client errors
In order to understand the failed status for a client machine, you need to check on the WSUS console to see what caused the failed status. Clicking on the affected machine on the bottom, middle pane will show the machine status with the failed update. Click on the failed update and check for any error messages. The 2 most common errors are “download failed” and installation failed”
Download failed is usually when the patch was not downloaded from the WSUS server to the client machine . Check the link on the Windowsupdate.log from the client machine and see if the patch is available on the <drive letter>:\WSUS\WSUSCONTENT folder on the WSUS server from the client.
For Installation failed you will need to check the error code and the log generated by the installation. On Windows XP it will be on c:\%windir%\kbXXXXXXX.log.
Lastly, try to install the patch manually to understand what is causing the failure if the message on the log is not clear.
WSUS health check
A good way to test if the WSUS is working properly is by running the wsusutil checkhealth command via the command line. Wsusutil is located in c:\program files\update services\tools folder. This will create a log in the event viewer if something is not correct on the WSUS with errors/ alerts in the application log.
Reference: http://technet2.microsoft.com/WindowsServer/en/library/e0934a67-f0ed-41a3-bf57-78fd9ac949431033.mspx.
That should get you started on troubleshooting some of the more common clients issues you may run into.
Enjoy!
Joao Madureira | WSUS Support Engineer
Monday and Tuesday we talked briefly about some basic troubleshooting steps for WSUS setup and synchronization, and today I'm going to talk about troubleshooting downloads. When troubleshooting downloads to the WSUS server, WSUS sends a requests to BITS to download the patches to the WSUS local update folder (if it’s configured to download to a local storage).
If on the WSUS console the download stays at 0 MB and you have patches needed for downloads, we'll need to check the software distribution log and the event viewer to see if we can find any clues as to why the BITS download is failing.
There are a couple logs you could look at but the best resource will be softwaredistribution.log which can be found in C:\program files\update services\logfiles. Simply review the log and look for any errors relating to BITS. If you find any then that's the issue you'll want to be troubleshooting.
Another good resource will be the Event Viewer. Typically you'll see event IDs 386 and 364 describing synchronization failures and the most probable cause of the failure. With that said, the most common problem relating to downloading patches to the local WSUS will be related to the firewall configuration. For more information on this see:
· http://support.microsoft.com/kb/922330
· http://support.microsoft.com/kb/836941
· http://support.microsoft.com/kb/900935/
Also make sure you have network service and user permissions on the local storage folder, <drive letter>:\WSUS\WSUSCONTENT. If you're unsure you can use Process Monitor to check for access denied errors on this folder as well as to verify write permissions to the local content folder.
When files are missing on the content directory, to make sure the information on the WSUS database is consistent with the content for the patches you can issue a wsusutil reset . This command will check whether the patches approved have their updates downloaded. If the binary for the patch is not there, it will generate a BITS request to download the patch again.
Reference:
http://technet2.microsoft.com/WindowsServer/en/library/e0934a67-f0ed-41a3-bf57-78fd9ac949431033.mspx
That should get you started on troubleshooting any potential download issues and tomorrow I'll post some tips on troubleshooting clients.
Joao Madureira | WSUS Support Engineer
Yesterday I posted some general tips on troubleshooting the WSUS installation process and today we're going to take a quick look at troubleshooting synchronization. When troubleshooting synchronization issues you need to make sure you have the basics covered. This includes:
- Make sure you can browse to http://update.microsoft.com.
- Make sure that ports 80 and 443 are open.
- If a proxy is used, make sure it is properly configured.
In addition to the above, a couple quick tests you can do are:
- From a downstream server to an upstream server, make sure you can ping the server and the same ports are opened between the upstream server and downstream server.
- Check name resolution between both upstream server and downstream server to make sure it can be reached by the FQDN.
Reference: http://technet2.microsoft.com/windowsserver/en/library/a3635b9d-2578-40b5-bef0-2da78650ebec1033.mspx.
You'd be surprised how many issues get resolved simply be doing the steps above so if you're running into WSUS synchronization issues this should get you started in the right direction. Tomorrow I'll take a quick look at troubleshooting downloads.
Joao Madureira | WSUS Support Engineer
We get quite a few questions regarding the installation of Windows Server Update Services so I thought I would post some quick tips of troubleshooting the process for when it runs into problems. When the WSUS installation fails, it generates four logs:
- WSUSSetup.log (the summary log)
- WSUSSetupMsi_timestamp.log (the verbose MSI log)
- WSUSCA_timestamp.log (the custom actions log)
- WSUSWyukonSetup_timestamp.log (the Database installation log)
The WSUS setup log will be the general log describing what failed during the installation; you can use this as a basic reference. The WSUSMSI_timestamp.log will describe in more detail exactly where it failed. To see exactly what caused the installation to fail, scroll from bottom to the top looking for “return value 3”. Once you find this, keep scrolling up to see which action the installation was doing at the time of failure.
Once you find out where the installation failed you should also see an error code associated with the failure. You can use the error lookup tool to help you understand the error code:
Reference for the error lookup tool: http://www.microsoft.com/downloads/details.aspx?familyid=be596899-7bb8-4208-b7fc-09e02a13696c&displaylang=en
Here is the link for WSUS custom setup error codes: http://technet2.microsoft.com/windowsserver/en/library/34e14364-0b3e-4558-87f6-abf08656a0731033.mspx
For more information on troubleshooting Setup issues see: http://technet2.microsoft.com/windowsserver/en/library/c1c07604-2fca-4410-81f6-c02d2fb5c3141033.mspx
Hopefully this will get you started on troubleshooting any potential installation issues you might run into and tomorrow I'll post some tips on troubleshooting synchronization.
Joao Madureira | WSUS Support Engineer
Joe Tindale, one of our top gun WSUS Support Escalation Engineers, recently wrote up a good explanation on why the updates offered by Windows Update or Microsoft Update may differ from the number reported by WSUS as being 'Needed'. If you've ever seen this and wondered why then take a look below:
========
Issue: You may see a difference in between the number of updates offered via Microsoft Update and the updates reported by WSUS as needed.
Example: We took a machine and scanned that machine against Microsoft Update (MU) and then created a report within WSUS to list all the "needed" updates. WSUS reported 31 updates as "needed" but MU offered less. Here are some examples of where they differed:
907417 <------ this shows up because it was a duplicate on the server - two different versions of the same update. MU offers 1
890830 <------ this update is superseded by a later version (MU only offers the latest)
890830 <------ this update is superseded by a later version (MU only offers the latest)
890830 <------ this update is superseded by a later version (MU only offers the latest)
So to summarize, WSUS is going to label all updates within a supersedence chain (ie, MSRTv1, MSRTv2, MSRTv3) as needed whereas MU will only offer the latest update within that chain (ie MSRT v3). Also, when scanning against MU, if you use the
"express" scan you will only be offered "high-priority updates" whereas if you use the "custom" scan you can view both "high-priority updates" and "optional updates.
WSUS reports on updates within both of the MU categories. High-priority updates will be security fixes and critical bug fixes while optional updates are going to be tools, drivers, add-ins and other non-security/critical fixes. Another variable could be the fact that a WSUS server may have duplicate updates. In the above example, we had two KB907417 updates on the server. Even though they have the same KB article number they had different update ID's so they are treated as two totally different updates. You can get in this state by syncing from various servers such as syncing with MU and then an upstream server, etc.
To verify in your environment, perform a "custom" scan against MU and copy and paste the updates offered (high-priority and optional) and then create a report for this client with all the updates labeled as "needed". Use the export option within that report to export the report to Excel. Now you can research the differences and add any notes to the Excel spreadsheet as to why these differences exist.
The bottom line is while you may see a different number of updates depending on how you scan, each is technically correct in their own way and each should ensure you get the updates you need.
========
Thanks Joe!
J.C. Hornbeck | Manageability Knowledge Engineer
We still gets quite a few support calls concerning problems caused by some sort of prerequisite issue so I thought it might be a good idea to post a link to the pre-install considerations you should be aware of before setting up a new Windows Server Update Services 3.0 box. Some of these are obvious and some are not, and even if you're a WSUS veteran it probably wouldn't hurt to review these one more time. For example:
- Windows 2000 Server is not supported for WSUS 3.0 servers
- WSUS 3.0 is not supported on servers running Terminal Services
- If two or more Web sites are already running on port 80, delete all but one of them before installing WSUS
- WSUS 3.0 requires the nested triggers option to be turned on in SQL Server
And so on and so on....
These are all documented in the Readme but we also have them on the web at http://technet2.microsoft.com/windowsserver/en/library/94d1385f-4872-4c29-8822-3a4ec5e45ae41033.mspx?mfr=true.
Whenever you set out to install a new WSUS 3.x box I'd recommend taking 10 or 15 minutes to go over these one more time. These few minutes of preparation can end up saving you hours of troubleshooting and frustration down the road.
J.C. Hornbeck | Manageability Knowledge Engineer
There is a small misunderstanding in BITS capabilities. When we say "bandwidth-throttling technology uses only idle bandwidth" and thus "downloads do not interfere with or slow other network activity, such as Internet browsing" the bandwidth we are talking about is the individual computer bandwidth. For example if the user is simultaneously browsing the Internet, BITS will throttle itself back to allow the user to complete his downloads so that the user experience is not affected. BITS doesn’t have information on total network usage so it will not be able to throttle the download depending on the network bandwidth.
You can limit the maximum amount of bandwidth that BITS uses by editing the local computer policy on the WSUS server or you can create a GPO on the DC to do this. Below are the steps to do this. Note that we do not officially recommend editing the Default Domain Policy, it is used below simply as an example policy.
========
Open the group policy you wish to edit:
Expand Administrative Templates under Computer Configuration:
Expand Network:
Select Background Intelligent Transfer Service:
Double click Maximum network bandwidth that BITS uses:
Enable the policy and set the limits depending on what you want:
For more information see http://technet2.microsoft.com/windowsserver/en/library/01c3e082-8e15-47c2-badf-3d14554534d61033.mspx?mfr=true
and
http://technet2.microsoft.com/windowsserver2008/en/library/7243820f-435f-47a4-9d54-170528bde3a41033.mspx?mfr=true.
Ellis George | WSUS Support Engineer
Over on the WSUS Product Team blog Cecilia Cole just posted about how the WinVerifyTrust update will now be mandatory:
========
A couple of weeks ago, I posted about Windows Vista Service Pack 1’s availability to WSUS. In that post, we mentioned that you should install the WinVerifyTrust update (KB 938759) if you are running your WSUS server on a Windows 2003 server to prevent Windows Vista SP1 from being continually re-downloaded to the server once the service pack is released to WSUS.
Today, we’d like to let you know that, in order to make sure all customers are well protected, we will be marking this particular update as mandatory....
========
To continue reading see http://blogs.technet.com/wsus/archive/2008/06/19/winverifytrust-update-will-be-mandatory-for-wsus.aspx.
J.C. Hornbeck | Manageability Knowledge Engineer
Actually it looks like the issue Cecilia posted on is different. Sorry about the confusion. You'll probably want to check it out anyway if you're seeing any client/server synchronization issues in your WSUS environment:
=======
Just a quick heads up that it looks like Cecilia Cole from the WSUS product team posted some more information about a sync issue over on her blog. If you ran into this problem then you'll definitely want to check this out:
http://blogs.technet.com/wsus/archive/2008/06/18/client-server-synchronization-issues.aspx
J.C. Hornbeck | Manageability Knowledge Engineer
The hotfix to correct this problem has been publicly released and is now available online.
Microsoft Security Advisory (954474): System Center Configuration Manager 2007 Blocked from Deploying Security Updates:
http://www.microsoft.com/technet/security/advisory/954474.mspx
The Knowledge Base article is here: KB 954474. Be aware that you don't have to call us for the hotfix - the KB article links to the download center where you can download the update directly.
Enjoy!
J.C. Hornbeck | Manageability Knowledge Engineer
We recently posted some new information regarding the inability to deploy updates to SMS 2003 clients. The original post is here and the update is here. Just in case the links above don't work for you the same links are below:
----====----
Original post: WSUS Offline Scan Catalog Fails to Sync on ConfigMgr 2007:
http://blogs.technet.com/sus/archive/2008/06/12/wsus-offline-scan-catalog-fails-to-sync-on-configmgr-2007.aspx
----====----
NEW - Microsoft Security Advisory (954474): System Center Configuration Manager 2007 Blocked from Deploying Security Updates:
http://www.microsoft.com/technet/security/advisory/954474.mspx
----====----
NEW - KB954474 - Microsoft Security Advisory: System Center Configuration Manager 2007 blocked from deploying security updates:
http://support.microsoft.com/kb/954474
----====----
J.C. Hornbeck | Manageability Knowledge Engineer
Here's an interesting problem Mike Johnson, one of our top Support Escalation Engineers in the WSUS group found. If you upgrade to WSUS 3.0 SP1 and notice a problem with your clients then this may be what you're running into:
========
Problem: After a WSUS 2.0 SP1 or WSUS 3.0 server is upgraded to WSUS 3.0 SP1, you may notice that clients no longer report into the server. Additionally, you may notice that new clients show a reporting status of, "The computer has not reported status yet." Your WSUS 3.0 SP1 Application log may also show the following warning:
Event ID 13042
Self-update is not working.
Cause: After the upgrade to Service Pack 1 the /SelfUpdate virtual directories on
port 80 and/or 8530 may be missing.
Resolution: You can manually re-create these virtual directories to resolve the issue or you can run the script below that will basically rerun the Selfupdate/Clientwebservice install the same way setup does. If you use the script just remember that you'll need to run it with cscript like this:
C:\Program Files\Update Services\setup>cscript rerunSelfupdateSetup.vbs
Here's the example script:
========
Option Explicit
Dim fileSystemObject, file, text, shell
Set fileSystemObject = CreateObject("Scripting.FileSystemObject")
Set shell = CreateObject("WScript.Shell")
Set file = fileSystemObject.OpenTextFile("installselfupdateonport80.vbs")
' Read the script in, this causes the SxS code to run. This will end up getting run twice, but it is safe
text = file.ReadAll
file.Close
ExecuteGlobal text
' We need to overwrite this method or it will fail the script. We set the variables manually so its safe
text = "Sub ParseArguments" & vbCrLf & "WScript.Echo ""Skipping ParseArguments""" & vbCrLf & "End Sub"
ExecuteGlobal text
' Set the variables that ParseArguments would have
gWusWebSiteIndex = GetWUSWebSiteIndex
szTargetDirPath = shell.ExpandEnvironmentStrings("%programfiles%\Update Services\")
' Debugging, print them out
WScript.Echo "gWusWebSiteIndex: " & gWusWebSiteIndex
WScript.Echo "szTargetDirPath: " & szTargetDirPath
' Run the full SelfUpdate install
WScript.Echo "SetupSelfupdateTree returned: " & SetupSelfupdateTree
========
Hope this helps,
J.C. Hornbeck | Manageability Knowledge Engineer
If you're having sync problems or seeing an update dated 3008 with Tuesdays catalog then this one's for you:
========
The June 10, 2008 release of the WSUS Offline Scan Catalog (wsusscn2.cb) fails to synchronize on a ConfigMgr 2007 or ConfigMgr 2007 SP1 site server using the Inventory Tool for Microsoft Updates (ITMU). This prevents security update deployments to SMS 2003 clients for the June release. This is a result of an issue with updated content published for the Office 2003 Service Pack 1 update.
The issue can be identified in the Wsyncmgr.log on the ConfigMgr 2007 site server with the following entries:
//
Performing legacy sync
STATMSG: ID=6709 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_WSUS_SYNC_MANAGER" …
Started with command line: C:\Program Files\Microsoft Configuration Manager\bin\i386\updatewuscatalog.exe …
Processing security catalog C:\Program Files\Microsoft Updates Inventory Tool\PkgSource\wsusscn2.cab ...
Initializing catalog C:\Program Files\Microsoft Updates Inventory Tool\PkgSource\wsusscn2.cab for synchronization.
Pre-processing updates...
Error 0x80004005, Unexpected DeploymentAction for update 1293995. Returned from CreateUpdateNode
Updates summary: 0 processed, 0 matched, 0 outdated, 0 updated
//
A new catalog is under development at the highest priority and will be made available for automated download as soon as it has been tested.
J.C. Hornbeck | Manageability Knowledge Engineer
