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