Wsus Reporters and ApiRemoting30

Discussion in 'Update Services' started by Roger Abell [MVP], Mar 18, 2008.

  1. I am hoping to role out machine group based reporting to those responsible
    for the client systems, but am meeting with a deadend in troubleshooting.

    Context:
    Wsus 3 SP1, was a fresh Wsus 3 install
    When using all domain accounts, whoami shows the domain user attempting to
    connect with the Wsus admin console to be in the correct domain groups. The
    connection attempt fails with a message that account must be in the WSUS
    Admin or WSUS Reporters group.
    If on the server running WSUS the domain account is placed directly into the
    WSUS Reporters group there is no difference.
    If however it is placed into the server's Administrators group the
    connection from the Wsus admin console completes/works, showing that all
    else is in place.
    When the domain account is flowing to the server's Wsus Reporters group via
    the domain group (or when placed directly in it) the IIS logs are showing a
    500 status code for the hits on ApiRemoting30/WebService.asmx, apparently
    meaning that the webservice serverside code is failing.
    The server running WSUS was initially configured to log all NTFS access
    failures by any account anywhere, and none are being recorded to the event
    logs.
    I have reviewed the webservice appendix of the WSUS Operations doc v1.2 and
    the registry and filesystem permissions are correct.
    Enumeration of the IIS instance (the default by the way, LM/W3SVC/1) matches
    except that the doc shows the metabase should have AuthFlags 21 and
    AuthAnonymous True whereas the install I am dealing with has AuthFlags 20
    and AuthAnonymous False.
    Since the IIS logs do normally show an inital http response of 401 for hits
    on ApiRemoting30/WebService.asmx followed by the successful 200 status when
    the Wsus admin console is used by a member of the server's Administrators
    group, I am thinking that the doc is in error (besides, enabling anonymous
    on the webservice makes no difference, a http 500 response is still received
    when a wevservice enum shows AuthFlags 21 and AuthAnonymous True).

    Any ideas how to proceed ?

    Thanks in advance,
    Roger

    PS
    The operations doc is also (?) in error in table on p 107-8 in giving the
    wrong physical disk location for the vdir of the ApiRemoting30 webservice.
     
    Roger Abell [MVP], Mar 18, 2008
    #1
    1. Advertisements

  2. A true statement. :)
    WSUS Reporters cannot access the Admin Console directly.
    This makes sense, assuming that BUILTIN\Administrators is a member of
    MACHINE\WSUS Administrators.
    Have you placed the domain account in the MACHINE\WSUS Administrators group?
    If so, what were the results?

    Nothing in your message mentioned making the user a member of "WSUS
    Administrators", which is required to access the ADMIN console.

    Is the remote admin =machine= a member of the same Domain as the WSUS
    Server?


    --
    Lawrence Garvin, M.S., MCBMSP, MCTS(x4), MCP
    Senior Data Architect, APQC, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2008)

    MS WSUS Website: http://www.microsoft.com/wsus
    My Websites: http://www.onsitechsolutions.com;
    http://wsusinfo.onsitechsolutions.com
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
     
    Lawrence Garvin [MVP], Mar 19, 2008
    #2
    1. Advertisements

  3. sure, but it is in Wsus Reporters when this happens
    Then I must be using the wrong terminology.
    The account is attempting to use the remote console mmc
    installed on a domain joined machine when this fails to
    connect if the account is not in the Administrators group
    of the server where WSUS runs.
    It is not, and that is impossible as machine local groups
    cannot nest.
    Same failure to connect.
    Similar happens with a machine local account defined on the
    server running WSUS. If it is in either of the two groups that
    SP 1 introduced connection fails whereas if it is placed into
    Administrators (only, neither of the Wsus groups needed)
    then connection works just fine.
    see above about terminology
    Yes, but as just indicated the behavior is the same with a machine
    local account and a similarly defined one on the client system.

    Also, I omitted that the domain account is seen to log in successfully
    (network login type 3) when it is used
    a) with Wsus remote mmc while a member of the Wsus server's
    Administrators group
    b) when not in Administrators but only in Wsus Reporters
    c) when used to access some info pages hosted via IIS on the
    server running Wsus that are available for non-anonymous
    browser access
    Basically, the domain group is in the server's Users group and
    Wsus Reporters group.

    So what is the Wsus admin console if something other than the
    remote console mmc ??

    The IIS logs giving http status response of 500 tells me that
    something is failing unhandled in the webservice code.
    It is apparently neither a file nor registry permission issue.
    The .Net CAS policy has not been changed, i.e. it is at the
    default Full trust as the server is dedicated to Wsus.

    Roger
     
    Roger Abell [MVP], Mar 19, 2008
    #3
  4. Any entries in the security log? The account might need "Access this computer
    over the network" privilege or perhaps "Allow log on locally" in addition to
    membership in WSUS Administrators. (I'm just guessing, mind you.)
    I thought this was the scenario where you weren't able to connect?

    Harry.
     
    Harry Johnston [MVP], Mar 19, 2008
    #4
  5. That was "sort of" answered, which you did not entirely snip just below in
    that
    I am not seeing any login type 1 (local) involved but only network (type 3)
    when
    the WSUS mmc is used successfully in remote scenario. Also security event
    log
    is not recording any failed type 1 login attempts.
    But, just for the info I have added the domain account to the server's local
    login
    user right and Remote Desktop Users group, logged into the server with the
    account,
    with the account only in Users and WSUS Reporters, and when attempting to
    connect
    via the WSUS mmc have the same results, i.e. cannot connect . . . you do not
    have
    permissions required to access the WSUS server ... must be in WSUS
    Administrators
    or WSUS Reporters (it is) and in IIS logs an 401 response to an anonymous
    hit on
    /ApiRemoting30/WebService.asmx followed immediately by an authenticated (as
    the test account) hit on the same with a 500 response code. About the only
    diff is
    that the security event log only records the initial successful login type
    10 (TS login)
    and no network logins when the connection attempts are performed.
    It does fail to connect to Wsus via the mmc in that scenario.
    What I was saying is that login to the server is successful when
    local or domain account is only member in server's Users and
    Wsus Reporters groups (i.e. Administrators is not needed for
    access at the Windows level, only at the Wsus level).

    Also, I have this morning combed the SQL logs and see no mention
    of anything time-correlated with the failed attempts to use the Wsus
    mmc console as a mere WSUS Reporters member.


    Roger
     
    Roger Abell [MVP], Mar 19, 2008
    #5
  6. Recap:
    Attempts to connect to WSUS using the WSUS console mmc fail
    with a message that the account must be a member of the WSUS
    Administrators or WSUS Reporters group

    However, the account is a member (of either, happens each way).

    The WSUS was a fresh install at WSUS v3 and was updated to
    SP 1, apparently successfully except for this new feature's failure
    to function as designed.

    The accounts tried do have all server-level rights/grants and
    can log into the server running WSUS as shown both by the
    event log and by doing so.

    The account can be either a domain group or a local account
    using a matching local account (same name+pwd on client and
    server).

    The WSUS console failure to connect happens either when the
    mmc is used remote from the server running WSUS or when the
    account is logged in locally to that server. (Remote use of the
    WSUS console mmc is the intended practice, local login was
    enabled for this testing only.)

    If the account is made a member of the server's Administrators
    group connection with the WSUS console mmc works.

    The failure to connect with the WSUS console is accompanied
    by an http 500 status code in the IIS logs for the hit on webservice
    at ApiRemoting30/WebService.asmx

    The registry permissions are correct according to what is stated
    in the WSUS Operations Guide v1.2. The server running WSUS
    has an NTFS audit ACL so that any access attempt that fails by
    any account to anything in the filesystem will generate an event
    log record. No filesystem access failures are being recorded.
    The NTFS ACLing for the WSUS install areas are also correct
    according to the WSUS Operations Guide v1.2
    The .Net CAS policy is at the OS install default of Full trust.
    Nothing is showing in the SQL logs (of the bundled WSUS
    install of its modified SQL express) that is time-correlated to
    failing access attempts.

    How does one resolve this or troubleshoot it further?
    Alternatively, how does one take an in-service WSUS v3 Sp1
    that is otherwise successfully servicing clients and refresh the
    WSUS software in manner likely to cure the problem ?

    Thanks in advance,
    Roger
     
    Roger Abell [MVP], Mar 20, 2008
    #6
  7. Added info:
    I have enabled tracing for the ApiRemoting30 app via its web.config file.
    When viewing the traces via trace.axd each of them is showing nothing
    except the headers and server variables collections.
    Curiously one error message was logged in the server's application event
    log at what appears to have been the time when the app was triggered to
    compile (i.e. recorded only once, not for each connection attempt).
    It is Type Error Event ID 12012 from Source Windows Server Update
    of Category Web Service with Description:
    The API Remoting Web Service is not working

    Helpful, ey?

    Roger
     
    Roger Abell [MVP], Mar 20, 2008
    #7
  8. No, I think you're just misunderstanding the design.
    This is by design. The account *must* be in either the
    BUILTIN\Administrators or MACHINE\WSUS Administrators group to use the MMC
    tool remotely.

    Voila! By Design!
    You're right and I misspoke, local groups cannot be nested.. The
    DOMAIN\Domain Admins might be a member of either of those two local groups.
    ALL members of BUILTIN\Administrators will have access to the remote
    console.

    I'm inclined to think this is a domain trust issue, not an account issue.

    If it doesn't work with a local account in either local group or with a
    domain account in either local group, then that's too many accounts to be
    malfunctioning simultaneously.

    You might also try resetting the WSUS Server's =computer= account in Active
    Directory, and make sure the server is properly authenticating with the
    domain.

    Yes. and this configuration will NOT grant you access to the remote MMC
    admin tool, so let's terminate all discussions about the BUILTIN\Users group
    or the MACHINE\WSUS Reporters group. The *only* groups that will grant
    access to remote administration are BUILTIN\Administrators and MACHINE\WSUS
    Administrators.

    That's what it is.

    Maybe. HTTP 500 is a pretty generic error, and lots of things can be
    contributing. The related question is whether any other functionality of the
    WSUS Server is not working. Are WUA =clients= logging HTTP 500 errors in the
    %windir%\WindowsUpdate.log?
    I would agree.


    --
    Lawrence Garvin, M.S., MCBMSP, MCTS(x4), MCP
    Senior Data Architect, APQC, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2008)

    MS WSUS Website: http://www.microsoft.com/wsus
    My Websites: http://www.onsitechsolutions.com;
    http://wsusinfo.onsitechsolutions.com
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
     
    Lawrence Garvin [MVP], Mar 21, 2008
    #8
  9. I do not think so.
    As I understand it SP 1 introduced the WSUS Reporters group.
    How is a member of that group supposed to be able to get their reports?
    From what I have read the WSUS Reporters group is given read-only access
    to the WSUS management console.

    What I am seeing with this install of WSUS is that an account must be in
    the Administrators group. Being only in either WSUS Administrators or
    WSUS Reporters has no effect is enabling access via the WSUS console mmc.
    If so then a failed design. The purpose of the two WSUS groups is
    specifically so that accounts do not need to be Administrators of the
    server where WSUS is running.

    There are no trusts involved here and the server running WSUS does
    function just fine as a fully health domain member so the machine trust
    with the domain is fine.
    Yes, it is. And the number could be made greater as any account will
    not have access unless it is a member of the Administrators group.

    No necessary, not related to the issue.
    If enabled to do so, a domain account can log into the server just fine, no
    problem. It is WSUS software that is failing, not the Windows
    infrastructure.

    The Users group was mentioned in an attempt to fend off responses about
    whether the account has the need grants/rights at the Windows level.
    The WSUS Reporters group is discussed because that is what I am attempt to
    get to work.

    So, if that is correct, and only Administrators and WSUS Administrators can
    use the WSUS console mmc, then what use is the WSUS Reporters group ?

    Consider the following statement from page 39 the WSUS 3 SP1 rev of the
    WSUS Deployment Guide
    <quote>
    Access the WSUS administration console
    You must be a member of the local Administrators group or the WSUS
    Administrators

    security group on the computer on which WSUS is installed in order to use
    all the features

    of the WSUS console.

    Members of the WSUS Reporters security group have read-only access to the
    console.

    As perviously stated, this WSUS is apparently fully healthy and functional
    after
    the SP 1 update, except for this ApiRemoting30 failure.
    Roger
     
    Roger Abell [MVP], Mar 24, 2008
    #9
  10. Okay.. Roger.... most of this thread is just a ping-pong game now so I'm not
    really going to quote much of it at all, as that's not really going to
    accomplish anything.

    Either you want help troubleshooting this or not -- but arguing about what
    you will or won't do, or what will or won't work -- without even trying --
    doesn't really encourage me to keep offering help at all.

    I'm intimately familiar with, and lived through, almost =every= encountered
    malfunction that occurs between the remote MMC and the WSUS Server.

    Two things are constant in the design of this whole package:

    [1] The remote workstation and the WSUS Server =COMPUTERS= must be member of
    the same domain. But being members is not just enough. The =COMPUTER=
    accounts must also be successfully authenticating with the DOMAIN
    CONTROLLER - thus my suggestion to reset the computer account of the WSUS
    Server, but you're convinced this couldn't possibly be the issue so you've
    opted not to take that advice.

    [2] A DOMAIN account used to access the WSUS Server via the remote MMC
    =must= have membership in one of these three:
    [a] Either a member of Domain Admins, wherein Domain Admins is also a
    member of the local Administrators group on the WSUS Server.
    A member of the local Administrators group on the WSUS Server.
    [c] A member of the local WSUS Administrators group on the WSUS Server.

    In addition, if reporting-ONLY is desired, a member of the local WSUS
    Reporters group on the WSUS Server.

    But it's absolutely pointless to even worry about reporting access if the
    console isn't even accessible to those with FULL permissions!?

    If your "WSUS Administrators" group is not giving access to the remote
    console, then there's one of three known causes that need to be investigated
    and /confirmed/ not-at-fault:

    [1] The WSUS Administrators group must belong to the appropriate
    security groups, and those security groups, along with the WSUS
    Administrators group must have the appropriate security permissions, if the
    domain account is a member of the WSUS Administrators group.

    [2] The local Administrators group must have the appropriate
    permissions, if the domain account is a member of the local Administrators
    group or a member of the Domain Administrators group.

    [3] The remote computer and the WSUS Server must have a "Domain Trust"..
    that is, they must either:
    [a] be AUTHENTICATED members of the same Active Directory
    Domain, or
    the account name/password of the logged on user of the
    remote machine must be identical in the SAM of the WSUS Server,
    and have the correct group memberships
    (Administrators, WSUS Administrators)

    Now.. please don't get hung up on the term "Domain Trust" -- we're not
    talking about multiple domains here, we're talking about two systems being
    authenticated members of the same domain =and= the user account also being
    an authenticated member of the same domain. So far, the only thing you've
    actually confirmed is that the =user= account is properly authenticated.
    You've not confirmed that both =computer= accounts are properly
    authenticated.

    Now, so far, as I recall, the only thing we've demonstrated, functionally,
    is that a local ADMIN account on the WSUS Server console can successfully
    access the MMC Admin Console of the WSUS Server. Nothing else works. To
    me... that seems pretty simple... some security mechanism somewhere is
    mucked up.

    Where would you like to start?

    My suggestion was the simple one --- reset the COMPUTER account of the WSUS
    Server and confirm that the WSUS Server computer account is properly
    authenticated with the domain. Maybe this won't make any difference at all.
    But at least we will have =ELIMINATED= this possible cause!

    As for [1] and [2] above, the various security permissions and memberships
    of the various accounts and groups affecting WSUS operations are pretty
    complex. So complex, that if [1] or [2] seems to be the case, my advice,
    generally, is going to be to reinstall the entire system from scratch.


    --
    Lawrence Garvin, M.S., MCBMSP, MCTS(x4), MCP
    Senior Data Architect, APQC, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2008)

    MS WSUS Website: http://www.microsoft.com/wsus
    My Websites: http://www.onsitechsolutions.com;
    http://wsusinfo.onsitechsolutions.com
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
     
    Lawrence Garvin [MVP], Mar 25, 2008
    #10
  11. differing opinions or readings apparently
    I have tried everything so do not go making such accusations.

    I do want this resolved, but being told things that are
    not accurate nor relevant is not getting toward speedy
    resolution of the problem, which is that ApiRemoting30
    webservice is failing, and not due to account criteria.
    This may just be something new to you then.
    As I have repeatedly attempted to make clear, they are and they are.
    irrelevant
    I am attempting to get WSUS Reporters to work


    ditto

    As stated in the WSUS doc, WSUS Reporters are supposed to be able
    to use the WSUS administrative console (that is what the doc call it)
    in a read only mode.
    That is not working.

    Similarly, if the accounts are made instead members of the WSUS
    Administrators group ApiRemoting30 webservice connection fails
    with exactly the same symptoms.
    In addition to what ?
    The accounts I try can authenticate, can get served web pages
    from the same server, can (if I enable local login) remote desktop
    to the server successfully (and still fail to connect to ApiRemoting30).
    It is totally accessible to any member of the server's Administrators
    group as has been repeatly mentioned.
    OK, so shift from WSUS Administrators to WSUS Reports and
    outline what those "appropriate security groups" and "appropriate
    security permissions" are, since I have followed in detail on that
    is mentioned in the WSUS Operations Guide appendix on this and
    all are fully satisfied.


    I believe I responded to both domain and machine trusts when you
    mentioned it, just as I had earlier ruled these out as relevant by saying
    that login (type 1 and 3) is successful for the accounts.
    If it were a Windows level failure I would be picking up an event log
    entry. Authentication at Windows level works fine (for example, the
    IIS log is showing the account in the 500 status record, which it would
    not be doing if things had not progressed past authentication, and Windows
    is recording the network login).
    It is already eliminated, the machine is a production machine.
    Were that an issue
    a) domain login would not be working for accounts that are not cached
    b) the DCs would be showing 672, 675, and possibly 5722 eventids
    for the machine account and they are not.
    etc.
    Not certain which [1] or [2], from the first set or the second, but
    in either case these do not seem to be moving toward a resolution
    that has WSUS Reporters getting reports by remote use of the
    WSUS administrative console.

    Thanks anyway,
    Roger

    MVP 1999 to present, now Windows Server: Security
     
    Roger Abell [MVP], Mar 25, 2008
    #11
  12. And my very simple point is that you will *NEVER* get "WSUS Reporters" to
    work,
    until you =FIX= what's keeping 'WSUS Administrators" from working!!!


    --
    Lawrence Garvin, M.S., MCBMSP, MCTS(x4), MCP
    Senior Data Architect, APQC, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2008)

    MS WSUS Website: http://www.microsoft.com/wsus
    My Websites: http://www.onsitechsolutions.com;
    http://wsusinfo.onsitechsolutions.com
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
     
    Lawrence Garvin [MVP], Mar 26, 2008
    #12
  13. Roger Abell [MVP]

    DaveMills Guest

    On Mon, 24 Mar 2008 21:27:23 -0500, "Lawrence Garvin [MVP]"

    snip.....
    Lawrence, do you mean that adding membership of the WSUS Reporters group will
    "deny" write access. This would be a quite unusual design approach but is what
    is implied by your account.
     
    DaveMills, Mar 26, 2008
    #13
  14. I was describing the basic requirements of remote admin access
    functionality... and one of the two things required is;


    The above is required if somebody wants read-write access to the remote
    admin console.

    As an afterthought (because I knew Roger was going to focus back on "WSUS
    Reporters", I added:
    Perhaps I should have said "Alternatively..." instead of "In addition..."
    ???


    --
    Lawrence Garvin, M.S., MCBMSP, MCTS(x4), MCP
    Senior Data Architect, APQC, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2008)

    MS WSUS Website: http://www.microsoft.com/wsus
    My Websites: http://www.onsitechsolutions.com;
    http://wsusinfo.onsitechsolutions.com
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
     
    Lawrence Garvin [MVP], Mar 26, 2008
    #14
  15. Roger Abell [MVP]

    DaveMills Guest

    Oh good, sanity rules!
     
    DaveMills, Mar 26, 2008
    #15
  16. I think Dave's goal is to allow a user who can only run reports on the Windows Server Update Services server. I recently installed the latest WSUS 3.0 SP3 on Windows 2008 R2 and I got the WSUS reporter user to be able to run report on the console in READ ONLY mode. Here what you have to do:
    1. Add a user to WSUS Reporters local group (Automatically created by WSUS during installation)
    2. Add a user to Remote Desktop Users local group
    3. Install WSUS console on this user desktop and connect to WSUS server.

    Note my account is in the trusted domain different from WSUS server domain.
    Thanks to Lawrence for suggestion on social.technet.microsoft.com site to remove all security settings to get WSUS first sync to work.

    -Sam Lawhcharoen
     
    Sam Lawhcharoen, Dec 28, 2010
    #16
  17. I think Dave's goal is to allow a user who can only run reports on the Windows Server Update Services server. I recently installed the latest WSUS 3.0 SP3 on Windows 2008 R2 and I got the WSUS reporter user to be able to run report on the console in READ ONLY mode. Here what you have to do:
    1. Add a user to WSUS Reporters local group (Automatically created by WSUS during installation)
    2. Add a user to Remote Desktop Users local group
    3. Install WSUS console on this user desktop and connect to WSUS server.

    Note my account is in the trusted domain different from WSUS server domain.
    Thanks to Lawrence for suggestion on social.technet.microsoft.com site to remove all security settings to get WSUS first sync to work.

    -Sam Lawhcharoen
     
    Sam Lawhcharoen, Dec 28, 2010
    #17
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.