The following information and links explains about the The Local System Account.
What is NT Authority\System (Local System) account?
Is it a part of Authenticated Users ??
Service running in local system account. Will it be able to access the AD/GP objects which are only accessible to Authentticated users?
The Local System account is a powerful account that has full access to the computer. The actual name of the account is NT AUTHORITY\System. The Local System account does not have any rights to access the network. When network access is necessary, Local System uses the account Domain\computername$.
With the release of Windows Server 2003, two new built-in account types similar to Local System were added: the Network Service account and the Local Service account.
Read the below articles for more information:
Problem Statement :
We are in the process of deploying Windows 7 and started getting this error: “Trust relationship between this workstation and primary domain failed”. FYI – We started getting this error after our server team started deploying Server 2008 R2 Domain Controllers. Rebooting seems to fix the problem, but we need a permanent preventative solution!
- Make sure that the workstations are pointing to local DNS server IP as preferred DNS in NIC.
- Also make sure that you “Enable NETBios over TCP/IP” under WINS tab at both places (Server, Workstation).
- Dis-join the workstation from domain, delete computer account from ADUC and rejoin problem workstation again to the domain.
NOTE : If you are on Windows 2008R2 and Windows 7 platform, Install this hot-fix .
This error usually indicates that the user or computer does not have the appropriate permissions to access the GPO or or GPO has been corrupted/deleted.
Authenticate Users – Read & Apply Group Policy
Creator Owner – Special permission
Domain Admins – Full Control & Special permission
Enterprise Admins – Full Control & Special permission
Enterprise Domain Controllers – Special permission
System – Full Control except Apply Group Policy
1. First of all check the SYSVOL and NETLOGON shares are available and on server, problematic GPO is present.
2. Run Group Policy Best Practice Analyzer to check errors.
3. Right click on the problematic gpt.ini file and click Permissions.
4. Switch to Security tab and click Edit.
5. Highlight Authenticated Users, remove all the boxes under Deny and check the following items under Allow.
Read & execute
6. Click OK twice to test the issue.
For more information,Event ID 1058 — Group Policy Preprocessing
If the issue persists, please run the following command and check output:
Note: Replace DomainName and GUID with the real DomainName and GUID.
If it still cannot work, follow the troubleshooting suggestions in KB article provides:
Userenv errors occur and events are logged after you apply Group Policy to computers that are running Windows Server 2003, Windows XP, or Windows 2000
Resolution: This happens only when IPC$ share is missing in your server. Clients make remote connections with the help of IPC$ and Namedpipes slots. This is a default administrative share. This should appear in each machine on the network or your network is not going to function properly or clinets can’t connect to each other.
These shares are lost when the value of “AutoShareServer” is 0 in registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
It should be 1.
When it happens simply restart “Server service” from services.msc snap-in. It is just to make sure that there is nothing wrong with Administrative Shares (IPC$).
Moreover, when happens again, go to a client machine and try to access server using UNC path (\\IP_Address_of_SBS).
Also you may also want to look at your DNS configuration, if you are mapping using name of the server you can try mapping few user with IP address of the server. If this keeps them connected it might be DNS issue. There are variety of other things you can check, I would start with Network cable, next go to Switch or the hub, check the network cards drivers and firmwares on the server