Discussion:
Wsus Reporters and ApiRemoting30
(too old to reply)
Roger Abell [MVP]
2008-03-18 19:32:13 UTC
Permalink
Raw Message
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.
Lawrence Garvin [MVP]
2008-03-19 00:07:18 UTC
Permalink
Raw Message
Post by Roger Abell [MVP]
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.
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.
A true statement. :-)
Post by Roger Abell [MVP]
If on the server running WSUS the domain account is placed directly into
the WSUS Reporters group there is no difference.
WSUS Reporters cannot access the Admin Console directly.
Post by Roger Abell [MVP]
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.
This makes sense, assuming that BUILTIN\Administrators is a member of
MACHINE\WSUS Administrators.
Post by Roger Abell [MVP]
Any ideas how to proceed ?
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
Roger Abell [MVP]
2008-03-19 07:22:57 UTC
Permalink
Raw Message
Post by Lawrence Garvin [MVP]
Post by Roger Abell [MVP]
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.
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.
A true statement. :-)
sure, but it is in Wsus Reporters when this happens
Post by Lawrence Garvin [MVP]
Post by Roger Abell [MVP]
If on the server running WSUS the domain account is placed directly into
the WSUS Reporters group there is no difference.
WSUS Reporters cannot access the Admin Console directly.
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.
Post by Lawrence Garvin [MVP]
Post by Roger Abell [MVP]
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.
This makes sense, assuming that BUILTIN\Administrators is a member of
MACHINE\WSUS Administrators.
It is not, and that is impossible as machine local groups
cannot nest.
Post by Lawrence Garvin [MVP]
Post by Roger Abell [MVP]
Any ideas how to proceed ?
Have you placed the domain account in the MACHINE\WSUS Administrators
group? If so, what were the results?
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.
Post by Lawrence Garvin [MVP]
Nothing in your message mentioned making the user a member of "WSUS
Administrators", which is required to access the ADMIN console.
see above about terminology
Post by Lawrence Garvin [MVP]
Is the remote admin =machine= a member of the same Domain as the WSUS
Server?
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
Harry Johnston [MVP]
2008-03-19 16:37:16 UTC
Permalink
Raw Message
Post by Roger Abell [MVP]
Post by Lawrence Garvin [MVP]
Have you placed the domain account in the MACHINE\WSUS Administrators
group? If so, what were the results?
Same failure to connect.
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.)
Post by Roger Abell [MVP]
Also, I omitted that the domain account is seen to log in successfully
(network login type 3) when it is used [...]
b) when not in Administrators but only in Wsus Reporters
I thought this was the scenario where you weren't able to connect?

Harry.
Roger Abell [MVP]
2008-03-19 17:23:34 UTC
Permalink
Raw Message
Post by Harry Johnston [MVP]
Post by Roger Abell [MVP]
Post by Lawrence Garvin [MVP]
Have you placed the domain account in the MACHINE\WSUS Administrators
group? If so, what were the results?
Same failure to connect.
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.)
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.
Post by Harry Johnston [MVP]
Post by Roger Abell [MVP]
Also, I omitted that the domain account is seen to log in successfully
(network login type 3) when it is used [...]
b) when not in Administrators but only in Wsus Reporters
I thought this was the scenario where you weren't able to connect?
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
Lawrence Garvin [MVP]
2008-03-21 00:53:07 UTC
Permalink
Raw Message
Post by Roger Abell [MVP]
Post by Lawrence Garvin [MVP]
Post by Roger Abell [MVP]
If on the server running WSUS the domain account is placed directly into
the WSUS Reporters group there is no difference.
WSUS Reporters cannot access the Admin Console directly.
Then I must be using the wrong terminology.
No, I think you're just misunderstanding the design.
Post by Roger Abell [MVP]
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.
This is by design. The account *must* be in either the
BUILTIN\Administrators or MACHINE\WSUS Administrators group to use the MMC
tool remotely.
Post by Roger Abell [MVP]
Post by Lawrence Garvin [MVP]
Post by Roger Abell [MVP]
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.
Voila! By Design!
Post by Roger Abell [MVP]
Post by Lawrence Garvin [MVP]
This makes sense, assuming that BUILTIN\Administrators is a member of
MACHINE\WSUS Administrators.
It is not, and that is impossible as machine local groups
cannot nest.
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.
Post by Roger Abell [MVP]
Post by Lawrence Garvin [MVP]
Have you placed the domain account in the MACHINE\WSUS Administrators
group? If so, what were the results?
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.
Post by Lawrence Garvin [MVP]
Is the remote admin =machine= a member of the same Domain as the WSUS
Server?
Yes, but as just indicated the behavior is the same with a machine
local account and a similarly defined one on the client system.
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.
Post by Roger Abell [MVP]
Basically, the domain group is in the server's Users group and
Wsus Reporters group.
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.
Post by Roger Abell [MVP]
So what is the Wsus admin console if something other than the
remote console mmc ??
That's what it is.
Post by Roger Abell [MVP]
The IIS logs giving http status response of 500 tells me that
something is failing unhandled in the webservice code.
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?
Post by Roger Abell [MVP]
It is apparently neither a file nor registry permission issue.
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
Roger Abell [MVP]
2008-03-24 22:46:09 UTC
Permalink
Raw Message
Post by Lawrence Garvin [MVP]
Post by Roger Abell [MVP]
Post by Lawrence Garvin [MVP]
Post by Roger Abell [MVP]
If on the server running WSUS the domain account is placed directly
into the WSUS Reporters group there is no difference.
WSUS Reporters cannot access the Admin Console directly.
Then I must be using the wrong terminology.
No, I think you're just misunderstanding the design.
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.
Post by Lawrence Garvin [MVP]
Post by Roger Abell [MVP]
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.
This is by design. The account *must* be in either the
BUILTIN\Administrators or MACHINE\WSUS Administrators group to use the MMC
tool remotely.
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.
Post by Lawrence Garvin [MVP]
Post by Roger Abell [MVP]
Post by Lawrence Garvin [MVP]
Post by Roger Abell [MVP]
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.
Voila! By Design!
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.
Post by Lawrence Garvin [MVP]
Post by Roger Abell [MVP]
Post by Lawrence Garvin [MVP]
This makes sense, assuming that BUILTIN\Administrators is a member of
MACHINE\WSUS Administrators.
It is not, and that is impossible as machine local groups
cannot nest.
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.
Post by Roger Abell [MVP]
Post by Lawrence Garvin [MVP]
Have you placed the domain account in the MACHINE\WSUS Administrators
group? If so, what were the results?
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.
Post by Lawrence Garvin [MVP]
Is the remote admin =machine= a member of the same Domain as the WSUS
Server?
Yes, but as just indicated the behavior is the same with a machine
local account and a similarly defined one on the client system.
I'm inclined to think this is a domain trust issue, not an account issue.
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.
Post by Lawrence Garvin [MVP]
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.
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.
Post by Lawrence Garvin [MVP]
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.
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.
Post by Lawrence Garvin [MVP]
Post by Roger Abell [MVP]
Basically, the domain group is in the server's Users group and
Wsus Reporters group.
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.
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.

</quote>
Post by Lawrence Garvin [MVP]
Post by Roger Abell [MVP]
So what is the Wsus admin console if something other than the
remote console mmc ??
That's what it is.
Post by Roger Abell [MVP]
The IIS logs giving http status response of 500 tells me that
something is failing unhandled in the webservice code.
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?
As perviously stated, this WSUS is apparently fully healthy and functional
after
the SP 1 update, except for this ApiRemoting30 failure.
Post by Lawrence Garvin [MVP]
Post by Roger Abell [MVP]
It is apparently neither a file nor registry permission issue.
I would agree.
Roger
Lawrence Garvin [MVP]
2008-03-25 02:27:23 UTC
Permalink
Raw Message
"Roger Abell [MVP]" <***@asu.edu> wrote in message news:#***@TK2MSFTNGP06.phx.gbl...

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.
[b] 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
[b] 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
Roger Abell [MVP]
2008-03-25 03:42:55 UTC
Permalink
Raw Message
Post by Lawrence Garvin [MVP]
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.
differing opinions or readings apparently
Post by Lawrence Garvin [MVP]
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 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.
Post by Lawrence Garvin [MVP]
I'm intimately familiar with, and lived through, almost =every=
encountered malfunction that occurs between the remote MMC and the WSUS
Server.
This may just be something new to you then.
Post by Lawrence Garvin [MVP]
[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.
As I have repeatedly attempted to make clear, they are and they are.
Post by Lawrence Garvin [MVP]
[2] A DOMAIN account used to access the WSUS Server via the remote MMC
[a] Either a member of Domain Admins, wherein Domain Admins is also a
member of the local Administrators group on the WSUS Server.
irrelevant
I am attempting to get WSUS Reporters to work
Post by Lawrence Garvin [MVP]
[b] A member of the local Administrators group on the WSUS Server.
ditto
Post by Lawrence Garvin [MVP]
[c] A member of the local WSUS Administrators group on the WSUS Server.
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.
Post by Lawrence Garvin [MVP]
In addition, if reporting-ONLY is desired, a member of the local WSUS
Reporters group on the WSUS Server.
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).
Post by Lawrence Garvin [MVP]
But it's absolutely pointless to even worry about reporting access if the
console isn't even accessible to those with FULL permissions!?
It is totally accessible to any member of the server's Administrators
group as has been repeatly mentioned.
Post by Lawrence Garvin [MVP]
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
[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.
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.
Post by Lawrence Garvin [MVP]
[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
[a] be AUTHENTICATED members of the same Active Directory
Domain, or
[b] 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.
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.
Post by Lawrence Garvin [MVP]
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.
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).
Post by Lawrence Garvin [MVP]
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!
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.
Post by Lawrence Garvin [MVP]
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.
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
Lawrence Garvin [MVP]
2008-03-26 05:24:29 UTC
Permalink
Raw Message
Post by Roger Abell [MVP]
Post by Lawrence Garvin [MVP]
[2] A DOMAIN account used to access the WSUS Server via the remote MMC
[a] Either a member of Domain Admins, wherein Domain Admins is also a
member of the local Administrators group on the WSUS Server.
irrelevant
I am attempting to get WSUS Reporters to work
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
DaveMills
2008-03-26 06:05:03 UTC
Permalink
Raw Message
On Mon, 24 Mar 2008 21:27:23 -0500, "Lawrence Garvin [MVP]"
<***@postalias.news> wrote:

snip.....
Post by Lawrence Garvin [MVP]
In addition, if reporting-ONLY is desired, a member of the local WSUS
Reporters group on the WSUS Server.
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.
--
Dave Mills
There are 10 type of people, those that understand binary and those that don't.
Lawrence Garvin [MVP]
2008-03-26 12:54:42 UTC
Permalink
Raw Message
Post by DaveMills
On Mon, 24 Mar 2008 21:27:23 -0500, "Lawrence Garvin [MVP]"
snip.....
Post by Lawrence Garvin [MVP]
In addition, if reporting-ONLY is desired, a member of the local WSUS
Reporters group on the WSUS Server.
Lawrence, do you mean that adding membership of the WSUS Reporters group will
"deny" write access.
No.
Post by DaveMills
This would be a quite unusual design approach but is what
is implied by your account.
I was describing the basic requirements of remote admin access
functionality... and one of the two things required is;
Post by DaveMills
[2] A DOMAIN account used to access the WSUS Server via the remote MMC
[a] Either a member of Domain Admins, wherein Domain Admins is also a
member of the local Administrators group on the WSUS Server.
[b] A member of the local Administrators group on the WSUS Server.
[c] A member of the local WSUS Administrators group on the WSUS Server.
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
Post by DaveMills
In addition, if reporting-ONLY is desired, a member of the local WSUS
Reporters group on the WSUS Server.
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
DaveMills
2008-03-26 21:32:45 UTC
Permalink
Raw Message
On Wed, 26 Mar 2008 07:54:42 -0500, "Lawrence Garvin [MVP]"
Post by Lawrence Garvin [MVP]
Post by DaveMills
On Mon, 24 Mar 2008 21:27:23 -0500, "Lawrence Garvin [MVP]"
snip.....
Post by Lawrence Garvin [MVP]
In addition, if reporting-ONLY is desired, a member of the local WSUS
Reporters group on the WSUS Server.
Lawrence, do you mean that adding membership of the WSUS Reporters group will
"deny" write access.
No.
Oh good, sanity rules!
Post by Lawrence Garvin [MVP]
Post by DaveMills
This would be a quite unusual design approach but is what
is implied by your account.
I was describing the basic requirements of remote admin access
functionality... and one of the two things required is;
Post by DaveMills
[2] A DOMAIN account used to access the WSUS Server via the remote MMC
[a] Either a member of Domain Admins, wherein Domain Admins is also a
member of the local Administrators group on the WSUS Server.
[b] A member of the local Administrators group on the WSUS Server.
[c] A member of the local WSUS Administrators group on the WSUS Server.
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
Post by DaveMills
In addition, if reporting-ONLY is desired, a member of the local WSUS
Reporters group on the WSUS Server.
Perhaps I should have said "Alternatively..." instead of "In addition..."
???
--
Dave Mills
There are 10 type of people, those that understand binary and those that don't.
Sam Lawhcharoen
2010-12-28 15:33:20 UTC
Permalink
Raw Message
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
Post by Roger Abell [MVP]
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.
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.
Post by Lawrence Garvin [MVP]
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
Post by Roger Abell [MVP]
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
Post by Harry Johnston [MVP]
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.
Post by Roger Abell [MVP]
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
Post by Roger Abell [MVP]
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
Post by Roger Abell [MVP]
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
The API Remoting Web Service is not working
Helpful, ey?
Roger
Post by Lawrence Garvin [MVP]
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
Post by Roger Abell [MVP]
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.
</quote>
As perviously stated, this WSUS is apparently fully healthy and functional
after
the SP 1 update, except for this ApiRemoting30 failure.
Roger
Post by Lawrence Garvin [MVP]
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.
[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
[a] Either a member of Domain Admins, wherein Domain Admins is also a
member of the local Administrators group on the WSUS Server.
[b] 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
[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"..
[a] be AUTHENTICATED members of the same Active Directory
Domain, or
[b] 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
Post by Roger Abell [MVP]
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
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
Post by Lawrence Garvin [MVP]
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
Post by DaveMills
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.
--
Dave Mills
There are 10 type of people, those that understand binary and those that don't.
Post by Lawrence Garvin [MVP]
No.
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
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
Post by DaveMills
Oh good, sanity rules!
--
Dave Mills
There are 10 type of people, those that understand binary and those that do not.
Submitted via EggHeadCafe
Microsoft SQL Server Developer For Beginners
http://www.eggheadcafe.com/training-topic-area/SQL-Server-Developer/5/SQL-Server.aspx
Sam Lawhcharoen
2010-12-28 15:36:50 UTC
Permalink
Raw Message
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
Post by Roger Abell [MVP]
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.
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.
Post by Lawrence Garvin [MVP]
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
Post by Roger Abell [MVP]
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
Post by Harry Johnston [MVP]
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.
Post by Roger Abell [MVP]
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
Post by Roger Abell [MVP]
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
Post by Roger Abell [MVP]
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
The API Remoting Web Service is not working
Helpful, ey?
Roger
Post by Lawrence Garvin [MVP]
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
Post by Roger Abell [MVP]
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.
</quote>
As perviously stated, this WSUS is apparently fully healthy and functional
after
the SP 1 update, except for this ApiRemoting30 failure.
Roger
Post by Lawrence Garvin [MVP]
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.
[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
[a] Either a member of Domain Admins, wherein Domain Admins is also a
member of the local Administrators group on the WSUS Server.
[b] 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
[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"..
[a] be AUTHENTICATED members of the same Active Directory
Domain, or
[b] 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
Post by Roger Abell [MVP]
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
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
Post by Lawrence Garvin [MVP]
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
Post by DaveMills
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.
--
Dave Mills
There are 10 type of people, those that understand binary and those that don't.
Post by Lawrence Garvin [MVP]
No.
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
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
Post by DaveMills
Oh good, sanity rules!
--
Dave Mills
There are 10 type of people, those that understand binary and those that do not.
Post by Sam Lawhcharoen
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
Submitted via EggHeadCafe
Microsoft ASP.NET For Beginners
http://www.eggheadcafe.com/training-topic-area/ASP-NET/7/ASP.aspx
Roger Abell [MVP]
2008-03-20 12:13:06 UTC
Permalink
Raw Message
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
Post by Roger Abell [MVP]
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.
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]
2008-03-20 15:34:44 UTC
Permalink
Raw Message
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
Post by Roger Abell [MVP]
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
Post by Roger Abell [MVP]
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.
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.
Loading...