To whom it may concern;

I am an engineer with a large seat management company. We ran into
considerable problems with deploying sp2. In short the service pack
installs with no errors but key services never reached a started state. The
services were shell hardware detection, network connections and com+ event
system.
We spent a significant amount of time running down the exact cause and
finally resorted to calling Micrsoft tech support. The tech support folks
were unable to find any reason why it would not work. After fixing
everything that could be an issue I noticed that a protected service account
was being rejected in the security event log. I placed that service in the
admin group and the issues magically disappeared.
I called and spoke to the escalation engineer assigned to our ticket and he
said that they (support) suspected something like this but that the software
writers were refusing to release information about the security changes so
that a work around could be found. I let him know I was going to post to
the newsgroups and let them know the resolution that I found. The tech
admitted that there were several distinct problems like ours that had been
unable to come to a resolution.
I personally find that to be abject stupidity not to release information on
this type of issue. I urge all admins, users and/or groups having a problem
remotely like what I described to place the "NT Authority\Network Service"
in the admin group and see if your issues are resolved on the next boot.
The indicated account should have the correct rights and Microsoft could not
tell me why it needed to be done this way.
If you are having issues like this and don't understand what I am addressing
as a fix, send me an email and I will help you as much as I can.

Thanks for listening,

Carroll Iverson
Senior Systems Consultant

[Jim Vierra]

Do NOT! do this.

Permissions on specific resources may be missing from the net service
account and placing this in the admin group proves this. Te NW Service
account should NEVE be given admin privileges. It exists for exactly this
reason - "Security".

Carroll - You need to escalate this up the chain at MS tech. The answers
you are getting are not good or correct.

I have been through many go-arounds with this type of issue. Either the NET
service account is missing DCOM privileges or security on key folders is
missing this account. Start with DCOM permissions and work out from there.

In my experience some piece of software you have installed before the SP2
upgrade has altered the DCOM or other COM permissions.

Working with MS support to get these permissions set correctly will
guarantee that you do not reduce the security of your systems.

--
Jim Vierra

<Carroll.IversonAT@REMOVEncmail.net> wrote in message
news:OlcJyQIbFHA.3328@TK2MSFTNGP09.phx.gbl...
> To whom it may concern;
>
> I am an engineer with a large seat management company. We ran into
> considerable problems with deploying sp2. In short the service pack
> installs with no errors but key services never reached a started state.
> The services were shell hardware detection, network connections and com+
> event system.
> We spent a significant amount of time running down the exact cause and
> finally resorted to calling Micrsoft tech support. The tech support folks
> were unable to find any reason why it would not work. After fixing
> everything that could be an issue I noticed that a protected service
> account was being rejected in the security event log. I placed that
> service in the admin group and the issues magically disappeared.
> I called and spoke to the escalation engineer assigned to our ticket and
> he said that they (support) suspected something like this but that the
> software writers were refusing to release information about the security
> changes so that a work around could be found. I let him know I was going
> to post to the newsgroups and let them know the resolution that I found.
> The tech admitted that there were several distinct problems like ours that
> had been unable to come to a resolution.
> I personally find that to be abject stupidity not to release information
> on this type of issue. I urge all admins, users and/or groups having a
> problem remotely like what I described to place the "NT Authority\Network
> Service" in the admin group and see if your issues are resolved on the
> next boot. The indicated account should have the correct rights and
> Microsoft could not tell me why it needed to be done this way.
> If you are having issues like this and don't understand what I am
> addressing as a fix, send me an email and I will help you as much as I
> can.
>
> Thanks for listening,
>
> Carroll Iverson
> Senior Systems Consultant
>
>
>