I'm testing the implementation of roaming profiles into my Windows infrastructure and testing on a clean workstation. After adding the workstation to the domain and logging in, I receive the error that the roaming profile could not be loaded, and a temporary local profile is being used. Event Viewer shows error ID 1058, and in the details under EventData, the value for DCName is my secondary (backup) domain controller, not the primary. I logged in to the backup domain controller and successfully verified that the PDC is indeed set as the operations master. All other AD functions on the workstation are operating normally -- DNS, file replication, etc. -- even the path to gpt.ini linked in the event viewer's general details when clicked open right up to the GPT.ini file without issue.

Additionally, the RODC configured at a remote location loses all access to the PDC when I shut down the backup domain controller. Again, operations master is the the PDC. DNS on all workstations, and the RODC, is pointing to the PDC.

Seems like I'm overlooking something relatively simple here. Any thoughts?

EDIT: After re-reading this, perhaps it's pertinent to note that the PDC is indeed online and accessible.

| improve this question | | | | |
  • 1
    You need to specify the location of the roaming profile, and the permissions on the roaming profile folder. It would also be a lot simpler to configure the account for a roaming profile and validate it works independent of group policy before going off in the weeds on things that aren't relevant (operation master roles). – Greg Askew Dec 9 '16 at 19:00
  • Hello Greg. Yes, the profile repository is specified, shared, and permissions are configured with full access to the respective user and admins with the user being the owner. Further, the user's account is configured for roaming profiles with the correct profile path. Perhaps its not as obvious as I thought that I came across this error while validating the profile works, hence my post. Appreciate the reply. – Brandon Dec 9 '16 at 19:12
  • 3
    1. Stop calling them PDC and BDC. 2. A user can authenticate to any Domain Controller. The fact that your users is authenticating to your other DC is perfectly normal. – joeqwerty Dec 9 '16 at 19:58
  • I never mentioned the acronym "BDC". Likewise, I also did not reference authentication is at all an issue, nor did I raise any question as to why my users are authenticating to my secondary domain controller. Simply mentioned that's the DCName in the details. – Brandon Dec 9 '16 at 22:06

(Sorry for the markdown, I'm on a phone)

The issue is one of the following three things:

a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.

That's the easy bit, as that's Microsoft's documentation), now for more detail:

Option A:

This is almost certainly your issue; if you are turning off a Domain Controller (what you refer to as a backup domain controller) and losing access to your PDCe role holder (what you refer to as your PDC), then a misconfigured DNS is almost certainly at play, even if it's not the root cause. If all your DCs are also DNS server please ensure the following DNS client settings are true (if a DC is not a DNS server also, replace with another DC IP address):

For DC1:
Primary DNS Server: IP Address of DC2
Alternative DNS Server:

For DC2:
Primary DNS Server: IP Address of DC1
Alternative DNS Server:

For all other DCs:
Primary DNS Server: IP Address of DC1 OR DC2
Alternative DNS Server:

For clients and member servers ensure that two valid, internal DNS server addresses are listed in the DNS client settings, based on proximity/ network speed to the DNS Server.

Do not have more than two DNS servers listed for any domain member.

If it a network connectivity issue I would suggest you use Microsoft Port Query. Run it on the client, point it towards the DC in the 1058 event, use the Domains and Trusts option. Look for error code 1.

Option B:

This is most probably caused by the same problems as above. From an elevated cmd perform: DCDIAG /c /v /e
repadmin /replsum
ipconfig /all

Post these to a receive help, but a break down is;
DCDIAG: identifies the issue, look at all failures apart from event viewer
Repadmin: shows which DC(s) are having the issue
ipconfig: ensure you haven't cocked up you DNS settings

Option C:

check the service.

| improve this answer | | | | |

I realize this post is old. Adding my experience on a 2016 Server connected to 2016 DC. In my case, the services were running and configured correctly. DNS working, able to ping and communicate with DCs from server. DCs have communication. Everything appeared fine except the Event ID 1058 w/ error code 3.

To resolve it, I removed server from the DC in Active Directory Users and Computers. Following that, I restarted the server and logged in with local administrator. I recreated the server in the DC (because it expects it will be there for the next step). From the server, I ran Test-ComputerSecureChannel -Servers DCaddress.local -Verbose -Repair -Credential to repair the connection to the DC. After that, I ran gpupdate /force successfully. No more error message and GPO successfully applied as expected.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.