none
WUA API for /reportnow ?

    Pregunta

  • We are controlling the behavior of the Automatic Updates service via the WUA COM API. The Automatic Updates service has been changed to Manual start, because our systems are embedded and we can only apply updates when the machine is in service mode.

    At the end of service mode, our service reboots the machine to put it back into embedded/production mode, halting the Automatic Updates service. The problem I'm seeing is that the reports do not always get uploaded.

    I noticed there is the wuauclt /reportnow option, but since it is asynchronous it would be hard to tell when the report upload has completed or failed. Is there an equivalent COM API?

     

    Thanks in advance!

    miércoles, 14 de julio de 2010 18:36

Respuestas

  • A *bump* from seven months ago? :-)

    There is an equivalent COM API call for /reportnow because the EminentWare Extension Pack provides that capability, but I am not immediately familiar with what class that method call would be found in.

    The AU service does need to be running to faciliate the calls to the reporting service. The better solution here would be to find a way to defer placing your machines back in embedded/production mode until after the WUAgent has had a chance to complete the last reporting event, which will always occur after a WUAgent-initiated system restart.

    Scripting this solution is possible. Since a WUAgent-initiated system restart will always have a pending reporting call after the restart, running wuauclt /reportnow after that restart, and then waiting sufficient time for the call to complete (usually 1-2 minutes is more than sufficient), and then placing your machine into embedded/production mode should solve that problem.

    Note: the wuauclt /reportnow command is not asynchronous -- it just only executes under very specific conditions (i.e. there must be already pending events to be reported). Once you issue that command, the WUAgent executes an immediate call to the ReportingEventWebService, and this can be confirmed in the WindowsUpdate.log when the command is executed under the correct conditions.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    jueves, 03 de febrero de 2011 3:54
    Moderador

Todas las respuestas

  • *bump*
    jueves, 03 de febrero de 2011 1:02
  • A *bump* from seven months ago? :-)

    There is an equivalent COM API call for /reportnow because the EminentWare Extension Pack provides that capability, but I am not immediately familiar with what class that method call would be found in.

    The AU service does need to be running to faciliate the calls to the reporting service. The better solution here would be to find a way to defer placing your machines back in embedded/production mode until after the WUAgent has had a chance to complete the last reporting event, which will always occur after a WUAgent-initiated system restart.

    Scripting this solution is possible. Since a WUAgent-initiated system restart will always have a pending reporting call after the restart, running wuauclt /reportnow after that restart, and then waiting sufficient time for the call to complete (usually 1-2 minutes is more than sufficient), and then placing your machine into embedded/production mode should solve that problem.

    Note: the wuauclt /reportnow command is not asynchronous -- it just only executes under very specific conditions (i.e. there must be already pending events to be reported). Once you issue that command, the WUAgent executes an immediate call to the ReportingEventWebService, and this can be confirmed in the WindowsUpdate.log when the command is executed under the correct conditions.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    jueves, 03 de febrero de 2011 3:54
    Moderador
  • I'm more familiar with the Administration namespace of the WSUS API, but the ClientServicing namespace has the ClientServicingProxy.ReportClientStatus method which at least sounds right. http://msdn.microsoft.com/en-us/library/microsoft.updateservices.clientservicing.clientservicingproxy.reportclientstatus%28v=VS.85%29.aspx
    viernes, 04 de febrero de 2011 16:17
  • I'm more familiar with the Administration namespace of the WSUS API, but the ClientServicing namespace has the ClientServicingProxy.ReportClientStatus method which at least sounds right. http://msdn.microsoft.com/en-us/library/microsoft.updateservices.clientservicing.clientservicingproxy.reportclientstatus%28v=VS.85%29.aspx


    But it's not the WSUS API he needs to attach to, rather the COM API of the Windows Update Agent.

    Also, the ClientServicingProxy namespace is designed for non-Windows based agents, so that they can talk to WSUS. Of necessity, it would need to be used in conjunction with Local Publishing, in order to get those non-Windows updates into the WSUS infrastructure. Also, you cannot access the ClientServicingProxy namespace remotely.

    The ReportClientStatus method is used to provide status information to the WSUS server (essentially a substitute for calling the ReportingEventWebService via the WUAgent), but to use that method call, something would need to have collected that status information from the client system.

    One other note for kcdixon... when you make a COM API call to the WUAgent ... that is going to cause the START of the Automatic Updates service. (Another reason for completing the reporting calls before placing the machine back in embedded mode.)


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com

    viernes, 04 de febrero de 2011 22:46
    Moderador
  • The AU service does need to be running to faciliate the calls to the reporting service. The better solution here would be to find a way to defer placing your machines back in embedded/production mode until after the WUAgent has had a chance to complete the last reporting event, which will always occur after a WUAgent-initiated system restart.

    Scripting this solution is possible. Since a WUAgent-initiated system restart will always have a pending reporting call after the restart, running wuauclt /reportnow after that restart, and then waiting sufficient time for the call to complete (usually 1-2 minutes is more than sufficient), and then placing your machine into embedded/production mode should solve that problem.

    Note: the wuauclt /reportnow command is not asynchronous -- it just only executes under very specific conditions (i.e. there must be already pending events to be reported). Once you issue that command, the WUAgent executes an immediate call to the ReportingEventWebService, and this can be confirmed in the WindowsUpdate.log when the command is executed under the correct conditions.

    That's kind of the problem. I don't know when the command completes. Does anyone happen to know if SoftwareDistribution\EventCache gets cleared out on success? That might be a hint....

    Also our machines are typically on cellular links, so sometimes we may run into transmission errors.

    sábado, 19 de febrero de 2011 0:52
  • Note: the wuauclt /reportnow command is not asynchronous -- it just only executes under very specific conditions (i.e. there must be already pending events to be reported). Once you issue that command, the WUAgent executes an immediate call to the ReportingEventWebService, and this can be confirmed in the WindowsUpdate.log when the command is executed under the correct conditions.

    That's kind of the problem. I don't know when the command completes.

    Command completion can be verified by parsing the tail of the WindowsUpdate.log. The last two lines of the logfile will be of this form:

    2013-05-11 14:59:10:074 1084 2b4c Report Uploading [#] events using cached cookie, reporting URL = http://[WSUSServerName]/ReportingWebService/ReportingWebService.asmx
    2013-05-11 14:59:10:082 1084 2b4c Report Reporter successfully uploaded [#] events.

    Parsing the last line of the logfile for the three words in boldface (and maybe validating the timestamp as being in the current moment) should be sufficient to verify the completion of the reporting event.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    sábado, 11 de mayo de 2013 21:22
    Moderador
  • I'm running into a similar question.  Does anyone know if this was every resolved?  Specifically, a COM API to have an equivalent behavior to /reportnow.
    viernes, 13 de julio de 2018 12:14
  • We've been doing thins since Windows NT, but we can't tail the Windows Update Log in Windows 10. Do anyone know another solution to this issue?
    martes, 17 de julio de 2018 19:00