Everytime I attempt to install KB842773 (BITS 2.0) update, I get the error
that it fails and the error code 0x8007F004.
SP2 also fails with a similar code (F004) and states that I don't have
permission to update the computer.
I've used Windows update sucessfully in the past and my domain account is in
the local administrators group. Even the local administrator account logged
on locally fails.
Is my domain admin responsible, he claims he's not? Is is some sort of
policy issue? I can't find any reference to the 8007F004 error.
Thanks
Please specify how you are doing your update, using AU, WU
or doing it manually. I suspect that only by doing it manually
can you guarantee that all of the procedure is going to be run under
your local account.
To test this idea you could use FileMon and monitor the log file
or the subdirectory where the install is going to go. Highlight WRITE.
Then notice the PID of the process doing the write. Check the account
that that PID is running under using Task Manager. If it isn't being done
under your account you would have to change your assumptions and
start considering the permissions of the account that was doing it.
BTW my standard Google Groups search shows that this symptom
has been a problem with V4 too and so far seems to be unresolved.
(Google Groups search for
8007F004 OR 0x8007F004 MSFT OR MVP group:microsoft.*
)
Good luck
Robert Aldwinckle
---
"Dave" <Da...@discussions.microsoft.com> wrote in message news:<957A95C1-3AA2-403B...@microsoft.com>...
secpol.msc
Go to "SecPol.msc > Local Policies > User Rights Assignment"
The following permissions are required:
1. Back up files and directories
2. Debug programs
3. Restore files and directories
4. Manage auditing and security log
5. Take ownership of files or other objects
If after enabling these permissions you still cannot install the update then
post the contents of the file %windir%\KB842773.log.
--
Narayana Mahankali
Microsoft, BITS
This posting is provided "As Is" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Bits Friend" <bits_...@hotmail.com> wrote in message
news:9b36214e.04092...@posting.google.com...
Any idea on what might be causing this and a solution besides
reformatting the computer would be highly appreciated. Note that I use
XP Pro but I don't connect to a domain (only workgroup).
Michel
"Narayana Mahankali [MSFT]" <nara...@online.microsoft.com> wrote in message news:<u4KDiZCp...@TK2MSFTNGP15.phx.gbl>...
%windir%\KB842773.log
%windir%\bitssetup.log
%windir%\setupapi.log
%windir% is usually c:\windows but might differ on your machine depending on
how you installed the OS.
You can send these files directly to me at "narayanm at microsoft.com"
You don't have to reformat the computer to fix this problem.
--
Narayana Mahankali
Microsoft, BITS
This posting is provided "As Is" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Michel Guillet" <michel....@m4x.org> wrote in message
news:62743c8b.0410...@posting.google.com...
Does this shed any light?
Thanks again,
Ben Askew
Houston, TX
I would be happy to send files to you if that would help. Just let me know
which ones you'd like and I'll get them to you.
Many thanks,
Ben Askew
Houston, TX
I have checked the local policy as you suggested and here is what I found:
On # 5. Take ownership of files or other objects, local admin is not in
there. Instead I have domain\domain admins and the box is greyed out. Can't
do anything. I logged in as domain admin thinking that I can add local admin
group. But still no dice.
Seems, many folks have this issue. I will end up re-doing the OS, even
though this is a brand new PC out of the box.
Thanx
A
Thanx.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Amit" <Am...@discussions.microsoft.com> wrote in message
news:703167D0-EDE0-4F30...@microsoft.com...
Also on a related note, we found that the our XP machines can no longer
perform system restore citing insufficient security privleges.
Thanx.
. Manage auditing and security log
. Take ownership of files or other objects
. Shut down the system
. Back up files and directories
. Restore files and directories
I would recommend that you double-check your domain policy to be sure that
the proper users have these rights as well as the ones that Narayana listed.
Jeff
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Technocrat" <Techn...@discussions.microsoft.com> wrote in message
news:10D0EF96-CC4B-4A09...@microsoft.com...
It seems Exchange Server changed permissions on the "Manage Auditing and
Security Log" policy located under Computer configuration - Windows settings
- Security settings - Local policies - User rights assignments
It added Exchange Enterprise Servers to the policy, but there is no
Administrator permissions set. Naturally, all the workstations on the domain
were picking up this policy and could not be overidden at the workstation.
I added "Administrators" to the permissions and forced a policy refresh on
the workstations (you will need to reboot after this).
Once i logged on to the workstation with admin rights i could complete all
my updates and it fixed a problem i was having with the system restore not
functioning due to permission errors.
I am not sure why or when the permissions were changed, but it seems to be a
common problem.
you were correct. I checked my domain policy and that setting on my domain
policy only allowed the domain admins/enterprise admins the "Take ownership
of files or other objects".
Funny thing is, my account is domain admin/enterprise admin, so if I login
to the computer, theoritically, I should be able to update without any
problems. But that wasn't so.
In the domain policy, I had to undo the definition of that policy. I
basically put it back to "Not defined" by removing the domain
admins/enterprise admins.
This worked.
I could have just put "administrators" in it and it should have worked but
better safe then sorry.
Thank You.
Amit
In my case it was a group policy that was interfering with the updates.
The computer I was trying to update was in an OU that had a GP setting to
auto download Windows updates from one of the servers on our network. The
policy was in Computer Configuration>Administrative Templates> Windows
Components/Windows Updates>.
The name of the policy in that container was "Specify intranet Microsoft
update service location" and it was set to enabled and was pointing to one of
our servers on our local intranet.
To fix the problem I moved the computer that I was trying to install on to a
OU that had no Group Policy and the updates went fine after that.
So in short, you may want to have a look at your domain Group Policy not
your local.