Re: Workaround for 0x8007045A (!)

From: Tony Vaughan (TonyVaughan_at_discussions.microsoft.com)
Date: 09/20/04 

Date: Mon, 20 Sep 2004 13:03:01 -0700

Hi Torgeir

Thanks for your reply. I understand what you mean about top posting. The
problem is, that if I spread my reply over the attached document, it's
difficult to see the logic of the reply, which is why I couldn't understand
what you found irrelevant.

Now, lets be crystal clear about what I have found. Doug indicated that WU5
works if you log on to the administrator account of a workstation attached to
a SBS 2003 network. I confirm that this is the case for me as well.

I then thought, in a fit of social conscience that might help other WU5
users, that perhaps there was a problem with domain accounts, set up as
administrator accounts in SBS 2003, being able to perform administrator
duties while logged on to the domain. So, I tried adding group policy
accounts to the domain user to see if permissions that used to belong to the
domain account under previous versions of SBS were now missing.

The result of these tests indicate to me that WU5 works under a local
administrator account but not under any domain account user. It seems to me
that the problem is more than just about permissions.

This is simple and clear. Log on as local administrator, and WU5 works. Log
on as domain user and WU5 doesn't work. The reason for this is beyond the
scope of my expertise. I am a .NET developer and have far better things to do
than chase this problem.

I am simply trying to help other people like me, who have been disgusted by
the response from Microsoft, to get along, which I thought was the point of
this forum. Doug has achieved this and I am truely thankful to him.

Point scoring doesn't help or contribute to resolution of the problem.

And, bye the way, I will continue to post my reply where it is logically
most appropriate as I see it.

Tony

"Torgeir Bakken (MVP)" wrote:

> (Please do not top post, it makes it difficult to follow the
> discussion flow. Post re-arranged)
>
> Tony Vaughan wrote:
>
> > "Torgeir Bakken (MVP)" wrote:
> >> Tony Vaughan wrote:
> >>
> >>> Bye the way, I couldn't find a group user with
> >>> NT AUTHORITY\Interactive.
> >>
> >> In the "Select Users, Computers, or Groups" (when selecting what to
> >> add to the Administrators group), you need to select the local computer
> >> in "From this location" (and be sure that "Built-in security principals"
> >> are selected under object types to select from).
> >>
> >>
> >>> Shouldn't NT AUTHORITY\Authenticated Users have
> >>> been enough?
> >>
> >> That would give the same effect (for the admin part) as
> >> NT AUTHORITY\Interactive, but if you put that in the Administrators
> >> group on all computers you open up for cross network admin rights
> >> (remote access) that you avoid if using NT AUTHORITY\Interactive.
> >>
> >>
> >>But I would thing none of this is relevant for the WU error at hand.
> >
> > We know that WU runs Ok on the administrator/local account of a
> > client machine but does not run on a domain user account of the
> > SBS 2003 same machine.
> >
> > You say that you think none of this is relevant to the WU error at hand.
> > Why is that?
>
> Sorry, I wasn't very clear, but that was not I meant. I meant that it
> shouldn't matter which of those two you use ("NT AUTHORITY\Interactive"
> or "NT AUTHORITY\Authenticated Users"), if one works, the other will
> work as well (so it is irrelevant which to use for the WU issue, but
> it is not irrelevant in a security context though).
>
> > Do you know some thing we don't?
>
> Nope.
>
>
> > Surely the workaround suggests that there is something about a
> > domain user that prevents WU5 from operating correctly. This seems
> > to me to mean that SBS 2003 must be part of the problem. The only
> > way I can explain that would be in the way that SBS 2003 implements
> > Group Policy. Do you agree that this is part of the problem and,
> > if not, what do you think this suggests?
>
> As I understood from Doug's post, you need to use a local user to
> make WU work, or have your testing found that it works if you add
> the domain user to the local Administrators group also?
>
>
> --
> torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
> Administration scripting examples and an ONLINE version of
> the 1328 page Scripting Guide:
> http://www.microsoft.com/technet/scriptcenter/default.mspx
>

Relevant Pages

  • Re: Win98 user acct cant connect - admin acct can
    ... I have made sure that everybody can login from the ... >If the administrator is the Domain Administrator, ... >account used a password that had a letter in it that ... A standard domain user account gets the ...
    (microsoft.public.windows.server.networking)
  • Re: Workaround for 0x8007045A (!)
    ... Here's another SBS 2003 user that can vouch for the workaround! ... I'm reduced to logging onto each machine as a local administrator to perform ... Doug indicated that WU5 ... > domain account under previous versions of SBS were now missing. ...
    (microsoft.public.windowsupdate)
  • Re: Running Connectcomputer Wizard
    ... tried NOT using a local account the same name as the domain user? ... Administrator) and supply the domain administrator credentials when prompted ... >> The user account you log on with must belong to the 'local' machine's ...
    (microsoft.public.windows.server.sbs)
  • user and group permissions
    ... Is it possible to deny access to local NT administrator ... cluster runs under domain user account with adminstrator ... should have no access to the sql server database. ...
    (microsoft.public.sqlserver.clustering)
  • Re: Event 1202 Warnings after Renaming Administrator Acct on SBS2003
    ... policy to rename the account although it is not really necessary or useful. ... Did I check Group Policies for references to the Administrator ... Failed to perform redirection of folder Desktop. ...
    (microsoft.public.windows.server.general)