Wireless clients not trusting well-known Certificate Authorities by default??

Question

I'm using PEAP-MSCHAPv2 for wireless authentication.  The radius server is a Windows 2008 server running NPS.  The clients consist of a bunch of laptops (mostly running Windows).  Not all of these laptops are members of Active Directory.  So, pushing any type of policy out to all clients isn't feasible (ie. using a private PKI and using AD to push the server cert and wireless config to all domain members).  So we decided to use a public PKI and obtained a certificate for our radius server through a well known CA.  So far, so good.
When clients to go connect, they still get a nasty warning saying:
--START--
The credentials provided by the server could not be validated. We recommend that you terminate the connection and contact your administrator with the information provided in the details. You may still connect but doing so exposes you to security risk by a possible rogue server.
Details
Radius Server:           $radius
Root CA:                    $ca
The server "$radius" presented a valid certificate issued by "$ca", but "$ca" is not configured as a valid trust anchor for this profile. Further, the server "$radius" is not configured as a valid NPS server to connect to for this profile.
--STOP--
(I replaced the actual radius server name with $radius and the CA with $ca).
Doing a little digging, it appears this is just the expected behavior of the Windows wireless client???  What's the point of getting a signed cert by a well-known CA if the client is still going to get a nasty warning like this?
Web browsers certainly don't behave like this.  The only difference between a web browser and the wireless client is with a browser, you're always going after a URL (ie, you can match what the browser wants to connect to versus what the CN on the server's cert comes back with) whereas on the wireless client, you generally won't know the radius server you're going to authenticate against.  But, in either scenario, the server's cert is signed by a well known CA.
I found a nice post that mentions this, but no solution:
http://social.technet.microsoft.com/Forums/en/winserverNIS/thread/26886f09-e424-48da-9ecc-cf7efd9dccc0
Well, I suppose a solution is to manually configure the client to trust certs issued by the CA and/or configure my radius server in the connection profile.  But that requires configuring each client.  And there's no way we can use AD to push a policy/cert to all clients.
So my questions are:
-is this really the expected behavior?
-so browsers generally trust the default CAs whose certs are stored on the OS by default but the wireless adapters don't?

Answer 1

This is a limitation of the Windows wireless client.
http://support.microsoft.com/kb/2518158
Somewhere was an artical the described that Microsoft wirless client does not trust public root CAs by default.  Using a 3rd party utility like Intel Pro Set trusts all the 3rd party root CAs by default so you dont get this message.
Please respond to Microsoft and voice your problem maybe they will fix their wireless client to trust public root CAs.
Justin.