I have an interesting issue with ISA2006 and WSUS on secondary site not letting clients to scan for updates properly.

My config is Primary site CEN with main WSUS and secondary site SEC with WSUS role installed. There were already some threads stating that CAPITAL letters in WSUS server's DNS suffix causing ISA not to pass requests even with "direct" configuration, please check these posts to understand what is going on in that case exactly: http://social.technet.microsoft.com/Forums/en-US/configmgrsum/thread/95aa4832-ab89-45fd-b444-9f68a0ee2e44 and http://social.technet.microsoft.com/Forums/en/configmgrsum/thread/0abd07d9-875a-4f0f-8d34-346fa66d2ca7 . The solution for ConfigMgr2007 cannot be applied as you can't change site server's FQDN after the install.

When you install the secondary by using low-case letters in FQDN you get the following situation:

In the table dbo.SysResList on CEN site ServerRemoteName for secondary site's roles are all lower-case.
In the table dbo.SysResList on SEC site ServerRemoteName for secondary site's roles are lower-case for DP,MP and SUS, but they are upper-case for other roles, including 'SMS Site System'.

As i know MP uses stored procedure called dbo.MP_GetWSUSServerLocations for feeding results on client's request. If you inspect its code (actually I tried to run it providing necessary parameters) - it uses such rules that finally give us address of 'SMS Site System' on which WSUS is located, and it seems to always be upper-case in secondary site's DB.

So if the client queries for WSUS location on secondary site he gets something like:

WSUS Path='http://SEC.DOMAIN.LOCAL:80', Server='SEC.DOMAIN.LOCAL', Version='8' LocationServices 5/4/2012 2:37:28 PM 2260 (0x08D4)
WSUS Path='http://cen.domain.local:8530', Server='CEN.DOMAIN.LOCAL', Version='8' LocationServices 5/4/2012 2:37:28 PM 2260 (0x08D4)

On the primary site:

WSUS Path='http://sec.domain.local:80', Server='SEC.DOMAIN.LOCAL', Version='8' LocationServices 5/4/2012 2:37:28 PM 2260 (0x08D4)
WSUS Path='http://cen.domain.local:8530', Server='CEN.DOMAIN.LOCAL', Version='8' LocationServices 5/4/2012 2:37:28 PM 2260 (0x08D4)

As all clients in my hierarchy are using their proxy MP's they get capital-lettered WSUS location, which causes problems with update scan (if i force them to get policy from central with small-letter address the scan immediately works).

Having such a situation I want to modify dbo.MP_GetWSUSServerLocations procedure and change a line
END AS WSUSURL,
to
END AS LOWER(WSUSURL),
so that I avoid upper-cases in URL's completely.

Can such a modification cause any potential problems in future somehow? Share your mind please.

• Moved by Stan White [MSFT]Microsoft employee Friday, May 04, 2012 1:26 PM Moving to category that matches more closely (From:Configuration Manager 2012 - General)

Hi,

Had a look into this myself recently and found the same after a while.  However, I then went into all the DBs and changed the ServerRemoteName in dbo.SysResList to lowercase and did a policy update on the client.

Each client now has a lowercase server name and no longer tries to go via the proxy.

Regards,

BryCel

• Proposed as answer by Tom Aguero Tuesday, October 09, 2012 6:09 PM
• Marked as answer by Garth JonesMVP, Moderator Sunday, December 30, 2012 4:10 PM

I made the changes to the dbo.SysResList table, simply changing from FQDN to fqdn. Then for all clients who were having issues checking in (which were about 60% of them) I ran a task sequence that stopped wuauserv, deleted the %winddir%\SoftwareDistribution folder, started wuauserv, and ran a software update scan cycle.

This has completely resolved the issue 200 (and climbing) clients in about 2 hours time.

• Proposed as answer by Tom Aguero Tuesday, October 09, 2012 6:17 PM

Apologies for my lack of expertise in this area. I can see "dbo.SysResList", and can see that "MP_GetWSUSServerLocations" is a dependency of "SysResList". But how did you actually modify "MP_GetWSUSServerLocations"?

update: i see it now in the Management Studio in Programability, Stored Procedures,

but which strings did you edit? thanks

• Edited by nhelen Wednesday, June 12, 2013 4:08 PM

Hi Everyone,

We experienced the same issue with a client. The solution was simple once we realised how the whole thing tied together.

The client had the following networking setup

- No default route to the internet (All through Proxy - IronPort I believe)

- WPAD file published in DNS and DHCP

- WPAD file had http://*.domain.local to go DIRECT

We found that all clients were getting a 0x80244019 error when synchronising updates from the local Software Update Point over HTTP://<SERVERNAME>.DOMAIN.LOCAL:8530.

Couldn't explain why this was happening.

A netmon revealed that clients were going to the Proxy Server via the DNS Server.

After reading the following article: http://support.microsoft.com/kb/900935 we found that Automatic Updates uses the published WPAD file from DNS if it finds one... which explained why clients weren't going direct to the ConfigManager 2012 SP1 server.

We updated the WPAD with a *.DOMAIN.LOCAL to go DIRECT and this solved the issue.

If you don't have a proxy server / WPAD configured in your environment, this wouldn't happen. 

Instead of manually changing the SCCM DB, change how you are routing.

Hope this helps others out :)

Regards,

Stefano

Hi Stefano,

I have the same problem, I tried to set *.MYDOMAIN.LOCAL (uppercase) on ISA 2006 but when I open the wpad.dat (to confirm it is uppercase)  the exception is lowercase.

Do you have some ideas? MAybe I have done some mistaken.

Could you tell me what exactly did you change and where ?

is it in CM_(site code)

dbo.SysResList  all ServerRemoteName ?  what about Server name ? and NAL path ?

Ive tried changing all ServerRemoteName but it didnt work.