Group Policy Preprocessing Error (ID: 1058)

Question

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.

Solution

(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 127.0.0.1 with another DC IP address):

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

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

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

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.

Comments

[Greg Askew]

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).

[Brandon]

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.

[joeqwerty]

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.

[Brandon]

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.