Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Thursday, July 14, 2011 4:57 PM
This may seem like a redundant question, but I have not found a solution that works.
I have a single SBS 2008 R2 server (DC) which was migrated from SMS 2003 and 7 Windows 7 machines, 2 are 32-bit and 5 are 64-bit. I have one client computer that will not update the computer group policy (the rest update without incident). I try a gpupdate /force and it gives me an event 1055 with an error code of 5 "Access Denied". The user policy upates okay. I tried disconnecting and deleting the AD entry for the problem computer from the domain and reconnecting without success. I also deleted the the DNS entry, but it did not work. I can successfully update the group policy by logging into other computers. I can also remotely access the problem computer from the server. Other than the GP error, the computer acts as part of the domain. I did notice a difference in the GPResult reports I generated from the problem computer and another client. in the Summary-Computer Configuration-General heading the problem computer shows:
Computer Name CLIENT
Domain Local
Site (None)
On a client computer that is properly update the GP it shows
Computer Name DOMAIN\CLIENT
Domain Domain.local
Site Default-First-Site-Name
When I look at the properties for the computers (on the machines themselves) under "Computer name, domain, and workgroup settings" it shows the same information.
Based on the answer to another post I check the sysvol permissions and they did not exclude the problem computer from accessing it.
Please help.
All replies (19)
Thursday, July 14, 2011 5:15 PM ✅Answered | 1 vote
Try resetting the computer account in Active Directory Users and Computers. Then restart the client machine, and see if the problem persists.
Thursday, July 14, 2011 5:08 PM
By the way, I am the main administrator for our network and I do have full administrative rights (I didn't know if that information would help).
Thursday, July 14, 2011 6:02 PM
I had thought about that and I just tried that on an unused client (which was working properly) to test it and now when I try to login to that client as the domain administrator there is an error with an X that says "The trust relationship between this workstation and the primary domain failed." Good thing I didn't try that on the computer I'm trying to fix.
Thursday, July 14, 2011 6:57 PM
I'ts not hard to fix that. Just dis-join the computer from the domain, and re-join it. (Delete the computer account from AD if the dis-join doesn't do it).
Thursday, July 14, 2011 10:28 PM
Thanks for the help, but it didn't work. You were right, though...it wasn't hard to fix the domain problem.
The problem has been driving me crazy as there are some group policies that I would like to apply and there just does not seem to be a fix...other than reformatting & starting over. I'll just live with the problem if it comes down to that.
Friday, July 15, 2011 12:09 AM
I decided to compare the problem client's ipconfig /all results with a client's that updates okay. They compared fine except at the end of the problem client's results was
Tunnel adapter Teredo Tunneling Pseudo-Interface:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
My other clients that are updating okay do not have this last part. After some research I found that this part has to do with IPv6...could this be a problem?
Friday, July 15, 2011 12:13 AM
Did this workstation get properly SBS 'connected' and is it using DHCP or has someone done a static address assignment?/kj
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Friday, July 15, 2011 1:21 AM
Hi,
For the Event ID 1055 and error message “Access Denied” issue, please check the permissions settings by following the Microsoft TechNet blog below:
Group Policies and Access Denied
http://blogs.technet.com/b/matthewms/archive/2005/10/29/413275.aspx
For the failed trust relationship issue, please try to reset the computer account. For the detailed information, please refer to the following Microsoft KB articles:
Resetting computer accounts in Windows
http://support.microsoft.com/kb/216393
Trust Relationship Between Workstation and Domain Fails
http://support.microsoft.com/kb/162797
Regards,
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Friday, July 15, 2011 4:36 PM
Thank you for your responses.
I solved the failed trust issue (after resetting the computer account) shortly after it occurred and it is no longer a problem, I just needed to research the proper steps.
As far as the static IP assignment goes, I did create a reservation for the computer, but it was not until after I notice the problem and I noticed that if I did an NSLOOKUP for the name of the computer it found it, but it did not return a valid computer name for the IP address (I thought of reviewing the DNS after assigning the reservation). I also did it because I could not remotely access the computer (which I later found was caused by the computer's Windows Firewall not allowing it). Bottom line, the static IP reservation did nothing to fix the problem, so I removed it.
SBS Connect: I poured through the records of the problem computer and one that is updating correctly, which was SBS Connected a few minutes prior to the problem computer (The computers are spec'ed the same). It seems that the 1055 error 5 event has been occuring from the very beginning. The only other event not common between the two computers was a warning event 40961:
"The Security System could not establish a secured connection with the server LDAP/SERVER2.Domain.local/[email protected]. No authentication protocol was available."
This warning is still occurring and does so within 10 seconds of the 1055 event.
As for the permissions, I had read that article and checked them. I re-read the article and rechecked the permissions. Nothing is set to deny and there are no permissions specific to the computer. The only oddity was for the Update Services Client Computers Policy (which is not enabled, but enforced) along with Authenticated Users, each individual computer is listed. A couple of weeks ago I noticed that the problem computer was not listed (it was the only one not listed), so I added it with the exact same permissions as the rest and it had no effect that I saw. When I run the Group Policy Results for the problem computer I get the following message under Computer Configuration Summary-Component Status
"Group Policy Infrastructure failed due to the error listed below.
Access is denied.
Note: Due to the GP Core failure, none of the other Group Policy components processed their policy. Consequently, status information for the other components is not available.
Additional information may have been logged. Review the Policy Events tab in the console or the application event log for events between 7/15/2011 7:51:27 AM and 7/15/2011 7:51:29 AM."
Would it be appropriate for me to add the problem computer with read rights to all of the Computer GPO's?
Friday, July 15, 2011 5:46 PM
To answer one of your earlier questions, no IPV6 should not be a problem. All my Vista/7 clients have IPV6 protocol enabled (although it is not used), and it shoud not cause the problem you are encountering.
"This warning is still occurring and does so within 10 seconds of the 1055 event." - is this on all the clients, or just the problem one?
Maybe this is a stupid question, and maybe I missed it, but have you tried completely dis-joining the problem pc from the domain, deleting all references of it from the SBS box, and re-running the http://connect program on the problem pc?
Perhaps even give it a different name?
Friday, July 15, 2011 5:51 PM
A common problem with joining Windows 7 clients to an SBS2008 domain is that the http://connect program fails. The workaround for this is to name the client pc (NETBIOS name) BEFORE running the connect program. Do not rename it during the process of joining the domain.
Friday, July 15, 2011 5:56 PM
The warning only occurs on the problem computer.
I did dis-join it, remove it from active directory and reconnect it (//connect) prior to this post, however, I did not remove it from DNS and I don't remember if I removed it from DHCP or not. When I disjoined the computer I basically followed the same steps that I had to do to fix the domain trust issue, but removed the primary DNS Suffix as well.
Does that seem to cover "Completely Dis-joining" or are there more steps. Also should I try it again and remove the DNS and DHCP entries? Are there any other locations I need to remove it from as well?
Friday, July 15, 2011 6:06 PM
When I say remove the computer from AD, I recommend you use the SBS Console/Network tab to do this, not ADUC. This will clean out most of it. But an orphaned DHCP lease or stale DNS record could also play havoc. So, yes, remove these too.
For the sake of troubleshooting, and to eliminate a possible source of error, try removing the DHCP reservation, and let the client do 'pure' DHCP.
If you don't want to rename the client, make sure that it is removed from WSUS too after 'dis-joining' it.
Friday, July 15, 2011 6:17 PM
Thanks...I will try this later today after I run a backup on the computer. Yeah, I removed the reservation right after I determined it was not the problem.
Friday, July 15, 2011 6:39 PM
It's important for SBS client reservations to have the DHCP Domain Name, Option #15 as I recall, to be set correctly. SBS DHCP server scopes should provide that but when using alternative DHCP servers for reservations, it is very important to ensure the correct domain name is included.
It did NOT look like that it was being correctly set in your client IPconfig.
/kj
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Friday, July 15, 2011 10:53 PM
Sorry Bigteddy, it didn't work! I guess this computer is just a force to be reckoned with! I was hoping your idea would work...dang it! It's giving me the same error and warning. I have no idea where to go from here...is there some sort of setting in SBS 2008 which will cause the computer to authenticate with the server? Is that really the issue? The interesting thing is that even after I dis-joined the computer, deleted it from AD (using SBS Console), and deleted it from DNS and DHCP, it still assigned the computer the same IP...
Friday, July 15, 2011 10:53 PM
Sorry Bigteddy, it didn't work! I guess this computer is just a force to be reckoned with! I was hoping your idea would work...dang it! It's giving me the same error and warning. I have no idea where to go from here...is there some sort of setting in SBS 2008 which will cause the computer to authenticate with the server? Is that really the issue? The interesting thing is that even after I dis-joined the computer, deleted it from AD (using SBS Console), and deleted it from DNS and DHCP, it still assigned the computer the same IP...
Saturday, July 16, 2011 7:31 AM
Re the same IP, that is normal, if you haven't changed the computer name. In DHCP, the client will always try to renew it's old lease. If that lease hasn't been used by another host, it will be assigned back to the client. Nothing unusual in that.
As a last resort, RENAME the computer to something else, and try joining it then. I don't know what else to suggest, short of re-formatting the client pc.
Renaming it (after disjoining it) will force SBS to create a new Computer object in AD, and all the related settings in DNS and WSUS etc wil be new for the new name. It's just an idea, and it's what I'd try as a next step.
Wednesday, June 27, 2012 10:33 AM
I'm having the exact same problem, but with sbs2011 DC. Also tried all the forementioned steps, but to no avail. Did someone had any luck with this stupid issue?