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.

Modifying anything in the database is absolutely unsupported (although it might work ;-) ).

Modifying anything in the database is absolutely unsupported (although it might work ;-) ).

Well, I could bet 10$ that would be the first answer. But in fact I've got in rather unresolvable scenario using only approved methods. What I see from the dependencies this SQL's SP is just a SELECT and is used only by MP to retrieve locations. So I wanted to ask about personal, non-official thoughts on that from people deep-diving in SCCM DB structure.

Hi,

As it is not supported as Torsten writes, I would open a support case with Microsoft Support and get it sorted out with their assistance.

Regards,
Jrgen

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

BryCel, I just thought that changing data in dbo.SysResList is more dangerous due to more possible dependencies on it, so I implemented my method - altered the dbo.MP_GetWSUSServerLocations procedure with the LOWER function in all strings that return the value. From what I can see after a couple of weeks - everything works OK. Hope Microsoft implements that tweek in future releases.

As Speedimon suggested, i altered the sp. Now it works fine. Thanks!

First I tried lots of things:

- change site system FQDN to lower-case

- Change wsus regkeys to lowecase

- use gpedit to change FQDN of Windowsupdate server to lower case.

All no result.

We are using a TMG proxy server, which aparently does not work ok with uppercase urls.

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.

Hey Guys,

I know its abit of an old post but I have the same situation with ISA2006/Webmarshal Proxy with SCCM 2012 SP1.

If I change the registry value of HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate from UPPERCASE to lowercase I can see that when using the manual method of selecting 'Windows Updates' proxy authentication no longer appears.

I still haven't found out the real answer, I don't really like having to modify the DB but have to if I cant get this sorted.

I've opened a similar query, but would also be interested to know if anyone had a "better" solution to this issue than modifying the DB? Thanks

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

Hey

I have similar issue. SCCM 2012 SP1 using third party network configuration, The wpad is configured with an exemption, in lower case. Continuous proxy related errors as described above while trying to deploy SUP updates during OSD.. this is a new environment so no domain clients yet.

ERROR:

Scan failed with error = 0x8024401b

If I manually change the registry after a failed deployment (HKLM\Software\Polices\Windows\WindowsUpdate) to lowercase then no more proxy authentication requests on the client.

I have also modified the WSUSServerName to lowercase in the dbo.MP_GetWSUSServerLocations procedure as suggested here by speedimon. Same result. Will continue to test.  

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