RM Ones (with RM pre-installed XP) do not appear in WSUS

[meastaugh1]

Has anyone had experience of using the RM factory installed XP image with WSUS? Group policies have applied correctly and the approrpriate registry value is populated with the WSUS server +port. I have a batch of computers from another supplier (with their factory loaded image) which work just fine. :?

 

The WSUS log file doesn't seem to contain anything useful. The client diagnoistc tool provided an obscure error, which didn't seem to match much on google. I can dig that out if it would be use.

[Michael]

I support one RM network and RM's official position is that they do not support WSUS, but supply their own service releases which they charge for! An absolute con if you ask me, bearing in mind every machine does have a legal Windows license. RM don't even support Windows Media Player 11 yet and will probably charge for that too...

 

The latest is SR6 (Service Release 6), which contains SP2 for Windows Server 2003 and a whole load of Windows hotfixes and improvements to the RM System Management Console. Ironically it appears to all work on top of Active Directory... You use the Management Console to distribute hotfixes and applications to Windows.

 

Now if memory serves me right, the reason RM machines do not appear in WSUS is because RM computer objects do not appear in AD as you'd expect, hence they do not communicate with your WSUS server. Apologies for going on a bit... I'm not a fan of RM and feel strongly about it. I dislike any company which are trying to reinvent the wheel...

[webman]

RM are not re-inventing the wheel, they are making the standard wheel more functional

[Michael]

So lets see, RM don't support WSUS which is 100% free, but they'll charge you a price for Service Releases just to keep Windows updated? I'd rather spend money on the pupils myself or other ICT facilities.

[webman]

So you're saying you would be happy for RM to allow WSUS, and then still support you and the network when MS releases crap and unwanted updates (which has happened - discussed recently on these forums) to all machines that may or may not work? (I'm thinking WGA, Desktop Search, IE7...)

[john]

Simple, change the way your WSUS works, tell it to probe the lan instead of reading your Active Directory, it has 2 ways of working, make it do the way that ignores the Active Directory, problem solved

[Michael]

WSUS does give you a lot of control of what's distributed through your LAN. No product or service is perfect and I do believe Microsoft have apologised for the recent problems, which some (but not all) WSUS administers have had to deal with. Windows Desktop Search is very resource hungry and unnecessary but it can be removed.

 

WGA hasn't been a problem - although WGA can affect any Windows XP installation including RM. I'm not sure what your point was there webman? WSUS also gives you full control whether IE7 is to be distributed and it's been absolutely fine in my experience. I authorised it about 4 months ago now. If you really are concerned about updates Microsoft publish to WSUS servers, you do have the option to authorise them one by one. It is a choice which is available to you.

 

I still stand by my original comments. If you look at the costs of running an RM network which is an annual subscription, you are talking thousands and thousands every year. I'm not saying their solution is bad, but Active Directory is better and there are no annual costs. WSUS is free and that money can be used more constructively towards a curriculum purpose.

 

John has suggested a workaround and he's absolutely right, WSUS can work without AD but I've never had to as Active Directory is my prime tool I use to administer all my domains.

[meastaugh1]

Annyway, back on topic, this isn't really about C3. It is an active directory domain with C3, but these clients are vanilla (without C3), they do not receive any C3 policies. As mentioned above, I have another batch of computers (from Stone) which connect to WSUS without a problem. So I guess this issue either relates to the hardware in the RM one (and the associated drivers), or the XP image shipped by RM. I've tried updated the Yukon NIC drivers to the latest version without success. Any ideas? thanks

[john]

when they were imaged by RM for you, did they sysprep them ok or are they all 110% identical clones of each other, if they are clones of each other then you will find it wont like them as they are all identical so will like maybe 1 of them if your lucky.

[meastaugh1]

Hi John,

 

I'm pretty sure they were sysprep'd around March this year.

[Michael]

Use this script - 99% of the time it does the trick. Run it once on the problematic machines:

 

@echo off
Echo Save the batch file "AU_Clean_SID.cmd". This batch file will do the following:
Echo 1.    Stop the wuauserv service
Echo 2.    Delete the AccountDomainSid registry key (if it exists)
Echo 3.    Delete the PingID registry key (if it exists)
Echo 4.    Delete the SusClientId registry key (if it exists)
Echo 5.    Restart the wuauserv service
Echo 6.    Resets the Authorization Cookie

Pause
@echo on
net stop wuauserv
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f
net start wuauserv
wuauclt /resetauthorization /detectnow
Pause

 

Hope this helps.

[meastaugh1]

Thanks Michael, I'll give it a go.

[meastaugh1]

I tried that batch file, but none of the reg values specified exist. In fact there are no values in that key, but there are values in the autoupdate child key.

 

This is the error produced by the client diagnostic tool:

WinHttpDownloadFileToMemory(szURLDest, NULL, 0, NULL, NULL, NULL, &downloadBuffer) failed with hr=0x80190194

.

 

Needless to say, RM don't want to help.

[Geoff]

This any help?

 

http://support.microsoft.com/default.aspx?scid=kb;en-us;326596

[meastaugh1]

I don't think so, as that article relates to SUS. I get the hex equivalent error codes 404 in the windowsupdate.log (once) and in the client diagnostic as mentioned. Could it be a proxy bypass problem, are there WSUS proxy specific settings? thanks

[Geoff]

Yes, WSUS uses WinHTTP to download updates. WinHTTP proxy settings are independent from IE. You must use the 'proxycfg' tool to configure it.

[meastaugh1]

Thanks, I've used proxycfg to check the settings on my working WSUS clients, and they don't have the proxy configured. I tried configuring a proxy for the RM ones, but this still doesn't work :?

[Michael]

In my opinion then meastaugh1, it's clearly something to do with the RM image these none CC3 machines come with. If you already have a group of machines which work happily with WSUS, then I cannot see what else it could be.

 

It definitely isn't a hardware limitation, but probably some custom RM registry hacks which have been implemented. Out of curiosity, can you visit Windows Update or Microsoft Update on these machines? I would also check services on the workstations which are required by Automatic Updates to function.

 

If all else fails, you could format these machines and re-install using a standard OEM disc. This would then remove any RM customisations and should connect to WSUS instantly. I know that's asking alot, but if RM won't help you, I cannot see what else you can try.

[meastaugh1]

Yeah I'm afriad we might have to do that Michael. It's just frustrating that it should work, and there's no good reason for it not to.

[Michael]

As I said from the beginning, that's RM for you... I agree with you 100% that it should just work, however on a positive, formatting should do the trick and obtaining drivers shouldn't be a problem.

 

I've come to the conclusion that RM will never support WSUS, because Windows Updates are a major source of revenue for them. They get a collection of updates, roll them up into one larger package then sell you that package or Service Release.

 

You're now in exactly the same position as I am, as now I have to administer two patching systems at the one school. Good luck

[webman]

As I've said previously, Michael, I believe RM's motives behind not supporting WSUS is because they would have to clean up after Microsoft's mistakes and software that is incompatible with the way a CC3 network runs.

 

What they do do, however, is to test Microsoft's "updates" for their compatability on a CC3 network, and release them (with RM changes if necessary) in a format that is compatible with CC3.

[PiqueABoo]

I would put MS Network Monitor 3.1 on the box and set it capturing immediately before running the client diag util. Then grope through the results to see exactly what it can't find, throw the URL in IE and see what that says.

[Geoff]

Also enable logging on the WSUS IIS web server. You can find out where it's tripping up from that too.

[meastaugh1]

Ok thanks both, will give it a go.

[Michael]

Any update meastaugh1? The suggestions put forward are all good in trying to determine the source of the problem, however it is intriguing that these machines which aren't controlled by CC3 don't just work as you say.

 

@webman - I don't wish to argue, so we'll just have to agree to disagree. Let's concentrate on supporting meastaugh1.