Wsus Reporters and ApiRemoting30

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]" <> wrote in message
news:...
> 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.

A true statement. :-)

> 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.

> 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.

> 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/pro...awrence.Garvin

"Lawrence Garvin [MVP]" <> wrote in message
news:...
>
>
> "Roger Abell [MVP]" <> wrote in message
> news:...
>> 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.
>
> A true statement. :-)

sure, but it is in Wsus Reporters when this happens

>
>> 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.

>> 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.

>
>> 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.

> 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

> 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

Roger Abell [MVP] wrote:

>> 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.)

> 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.

"Harry Johnston [MVP]" <> wrote in message
news:%23HOm$...
> Roger Abell [MVP] wrote:
>
>>> 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.

>> 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

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]" <> wrote in message
news:...
>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.
>

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]" <> wrote in message
news:...
> 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]" <> wrote in message
> news:...
>>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]" <> wrote in message
news:#...

>>> 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.

> 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.

>>> 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!

>> 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.


>> 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.

>> 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.


> 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.


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

That's what it is.


> 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?

> 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/pro...awrence.Garvin

"Lawrence Garvin [MVP]" <> wrote in message
news:077E8A07-D36A-4D86-909D-...
> "Roger Abell [MVP]" <> wrote in message
> news:#...
>
>>>> 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.


>> 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.

>>>> 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.


>>> 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.
>
>
>>> 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.
>
>>> 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.

> 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.


> 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.


>
>> 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>

>
>> So what is the Wsus admin console if something other than the
>> remote console mmc ??
>
> That's what it is.
>
>
>> 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.

>> It is apparently neither a file nor registry permission issue.
>
> I would agree.
>

Roger

"Roger Abell [MVP]" <> wrote in message
news:#...

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/pro...awrence.Garvin