My setup has internal wsus servers which store updates locally(for internal clients) and a server which doesn't store locally (for external clients; which download direct from Microsoft)
Publishing an update with LUP works fine on the internal servers but causes the external server to error during detection ( see log ). This prevents clients detecting any updates from the external server.
The issue seems to be that the external server neither has the file nor a value in the MUURL field.
Copying the cab file that our internal wsus has created for the update to a webserver and putting that url in MUURL fixes the problem.
Can LUP configure the update so that the external server doen't error; alternatively ( as a new feature ) could LUP automatically export the cab file to a web-server and set the MUURL field.
WSUS error
When you create the update, are you putting the path to the file in the Original URL field?
It has been my understanding that with locally published updates it doesn't matter if the server is setup to store the updates locally or point them to Microsoft. Any locally published update will be stored locally on the servers and the clients pointed to the server to download the binaries.
originalurl-test
I've created another update with the originalurl set ( see originalurl-test file). The MUURL field is still NULL.
Also the update file does not sync across the the external server, so it can never be sent to any external client.
Just to clarify, our external server replicates it's update settings from our internal server; just doesn't seem to replicate the local update files.
I don't see any field in the SDP schema referred to as MUURL. The example XML you posted doesn't have any field by that name either. Where is this field documented and how are you manually setting it?
I'm setting the field directly in the table dbo.tbfile
I've tested copying the cab file from the wsus content(last2char from digest) folder on our internal server to our external but the external server still faults during detection. Populating the MUURL field seems to be the only way to make detection succeed. The latest update I've tested doesn't have any approvals, it's existence for detection is enough to break WSUS.
This is the SQL I'm using to get all fields walking the relationship from update to package/file:
select f.,u.,lp.*,lr.revisionid from dbo.tbfile as f
inner join dbo.tbfileforrevision as fr on
f.filedigest=fr.filedigest
inner join dbo.tbrevision as r on
fr.revisionid=r.revisionid
inner join dbo.tbupdate as u on
r.localupdateid=u.localupdateid
inner join dbo.tbLocalizedPropertyforRevision as lr on
r.revisionid=lr.revisionid
inner join dbo.tblocalizedproperty as lp on
lr.localizedpropertyid=lp.localizedpropertyid
where u.islocallypublished= 'TRUE'
Non-local updates in dbo.tbfile user MUURL to list the original microsoft download location for an update ( where a client should pull the file from if the server doesn't host it)
Thanks for the clarifications. I was afraid you were going to start talking about direct writes to the WSUS database. That's not something I'm comfortable doing in LUP. There must be a way via the API to populate that field. In theory, anything an official update can do a locally published one can too.
I'll have to take a deeper look into it but I can't promise anything. I'm fairly certain others have a similar setup, I'll see if I can find any thread relating as much.
Just to be clear, you are approving the updates in question right? I believe that is required for the actual data itself to sync to downstream servers.
Review the WSUS forum thread here: http://social.technet.microsoft.com/Forums/en-US/winserverwsus/thread/6eb3a591-03d1-4a88-911c-14add52a7b0b
Yes, updates have been approved
successfully synced content to the 2nd internal server.
sync'd the update info/approvals but not content to external server ( which is exactly how all the microsoft updates sync to the external server - no content but external microsoft URL in MUURL field )
Can I assume you've triple checked the certs on that external server? I don't have any downstream servers in my environment but I assume that the sync action has associated log files. Is there anything in there that might provide a clue?
Certs are fine.
The server to server sync is successful ( change.log shows the new updates/deployments )
The only time things break is when the client tries to sync during detection, that causes the server to error (see wsus-error.txt), the server then returns an error code to the client causing it to abandon detection.
If you look at the technet thread I posted below you'll see the answer. It appears that local publishing requires that the content is stored locally. That rather disappointing and someone confusing ... I would think SCCM and SEC customers would find that to be an unacceptable limitation.
That's no good :-(
Is there any way the OriginURI property of FileForInstallableItem or UpdateFile could be used? http://msdn.microsoft.com/en-us/library/ms748969%28v=VS.85%29.aspx
I know that SCUP catalogs populate that within sdp:OriginFile but I don't know if WSUS takes notice, or if it's SCCM only.
If not it looks like I'll either have to keep doctoring the database or abandon local updates entirely.
That is why I initially wanted to make sure you were populating the Original URL field. LUP uses it to populate the OriginalURI properties.