Menu

#47 Local updates missing MUURL

open
nobody
5
2012-08-24
2011-08-23
CGretski
No

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.

Discussion

  • CGretski

    CGretski - 2011-08-23

    WSUS error

     
  • Bryan Dam

    Bryan Dam - 2011-08-23

    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.

     
  • CGretski

    CGretski - 2011-08-24

    originalurl-test

     
  • CGretski

    CGretski - 2011-08-24

    I've created another update with the originalurl set ( see originalurl-test file). The MUURL field is still NULL.

     
  • CGretski

    CGretski - 2011-08-24

    Also the update file does not sync across the the external server, so it can never be sent to any external client.

     
  • CGretski

    CGretski - 2011-08-31

    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.

     
  • Bryan Dam

    Bryan Dam - 2011-09-06

    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?

     
  • CGretski

    CGretski - 2011-09-07

    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.

     
  • CGretski

    CGretski - 2011-09-07

    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)

     
  • Bryan Dam

    Bryan Dam - 2011-09-11

    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.

     
  • CGretski

    CGretski - 2011-09-16

    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 )

     
  • Bryan Dam

    Bryan Dam - 2011-09-19

    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?

     
  • CGretski

    CGretski - 2011-10-12

    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.

     
  • Bryan Dam

    Bryan Dam - 2011-10-20

    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.

     
  • CGretski

    CGretski - 2011-10-24

    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.

     
  • Bryan Dam

    Bryan Dam - 2011-10-24

    That is why I initially wanted to make sure you were populating the Original URL field. LUP uses it to populate the OriginalURI properties.

     

Log in to post a comment.

MongoDB Logo MongoDB