GPO applied from old server
About 2 years ago we properly decommissioned a 2008R2 DC. DC promo was ran, server demoted, then we removed AD from the system. The DC was the fsmo role holder. We transferred all the roles 2 weeks before the decom. We ran netdom query fsmo from each DC and they all reported the new DC was indeed the role holder.
We ran through adsi and DNS to remove any remnants of the old server. Netdiag and dcdiag checks all good afterwards. We ran repladmin tests to make sure there were no sysvol issues.
We recently made some major AD changes including a domain rename. Ran through all the proper rename steps and even ran rename /end. All users could log in, all server shares and namespaces were working, not a single user reported an issue. We were happy.
A few weeks later we noticed some updated GPO's were not being applied. Mainly the folder redirections.
gpresult /v shows the group policy is being applied from the old 2008 server that was decom'd years ago. When we run gpupdate /force user policy will not update because the system cant figure out which forest the computer/user is in.
On a few test machines, we unjoined the domain and rejoined. Same issue. We did it again and changed the computer name (same issue). User processing will stioll not run and again group policy is applied from the old 2008 server.
Something is pointing to the old DC somewhere but i cant find it. Every computer on the network says policy applied from that 2008 server.
Where should I look?
We ran through adsi and DNS to remove any remnants of the old server. Netdiag and dcdiag checks all good afterwards. We ran repladmin tests to make sure there were no sysvol issues.
We recently made some major AD changes including a domain rename. Ran through all the proper rename steps and even ran rename /end. All users could log in, all server shares and namespaces were working, not a single user reported an issue. We were happy.
A few weeks later we noticed some updated GPO's were not being applied. Mainly the folder redirections.
gpresult /v shows the group policy is being applied from the old 2008 server that was decom'd years ago. When we run gpupdate /force user policy will not update because the system cant figure out which forest the computer/user is in.
On a few test machines, we unjoined the domain and rejoined. Same issue. We did it again and changed the computer name (same issue). User processing will stioll not run and again group policy is applied from the old 2008 server.
Something is pointing to the old DC somewhere but i cant find it. Every computer on the network says policy applied from that 2008 server.
Where should I look?
ASKER
Run it on the workstations?
yes
ASKER
No effect. I am turning on verbose logging.
RegKey: HKLM\Software\Microsoft\Wi
For full debug logging set to: 30002
Log file: c:\windows\debug\UserMode\
RegKey: HKLM\Software\Microsoft\Wi
For full debug logging set to: 30002
Log file: c:\windows\debug\UserMode\
Ok, then run this command on them from elevated cmd prompt
secedit /configure /cfg %windir%\repair\secsetup.i
then reboot when its finished
secedit /configure /cfg %windir%\repair\secsetup.i
then reboot when its finished
ASKER
invalid path c:\windows\repair.
ASKER
I deleted HKCU\Software\Microsoft\Wi
On one machine we get no RSOP data, on another it still says gp applied from old DC. Here are some of the old settings:
[HKEY_CURRENT_USER\Softwar
[HKEY_CURRENT_USER\Softwar
"Options"=dword:00000000
"Version"=dword:00010001
"DSPath"="LDAP://CN=User,c
"FileSysPath"="\\\\cpc.loc
"DisplayName"="Enable Printer Install"
"Extensions"="[{35378EAC-6
"Link"="LDAP://DC=cpc,DC=l
"GPOName"="{FDE7B6FD-BF27-
"GPOLink"=dword:00000003
"lParam"=hex(4):00,00,00,0
[HKEY_CURRENT_USER\Softwar
"Options"=dword:00000000
"Version"=dword:00010001
"DSPath"="LDAP://CN=User,c
"FileSysPath"="\\\\cpc.loc
"DisplayName"="Enable Printer Install"
"Extensions"="[{35378EAC-6
"Link"="LDAP://DC=cpc,DC=l
"GPOName"="{FDE7B6FD-BF27-
"GPOLink"=dword:00000003
"lParam"=hex(4):00,00,00,0
[HKEY_CURRENT_USER\Softwar
"Options"=dword:00000000
"Version"=dword:00070007
"DSPath"="LDAP://CN=User,c
"FileSysPath"="\\\\cpc.loc
"DisplayName"="Desktop Screen Saver"
"Extensions"="[{35378EAC-6
"Link"="LDAP://OU=Office Systems,DC=cpc,DC=local"
"GPOName"="{34CBDE4F-E536-
"GPOLink"=dword:00000004
"lParam"=hex(4):00,00,00,0
On one machine we get no RSOP data, on another it still says gp applied from old DC. Here are some of the old settings:
[HKEY_CURRENT_USER\Softwar
[HKEY_CURRENT_USER\Softwar
"Options"=dword:00000000
"Version"=dword:00010001
"DSPath"="LDAP://CN=User,c
"FileSysPath"="\\\\cpc.loc
"DisplayName"="Enable Printer Install"
"Extensions"="[{35378EAC-6
"Link"="LDAP://DC=cpc,DC=l
"GPOName"="{FDE7B6FD-BF27-
"GPOLink"=dword:00000003
"lParam"=hex(4):00,00,00,0
[HKEY_CURRENT_USER\Softwar
"Options"=dword:00000000
"Version"=dword:00010001
"DSPath"="LDAP://CN=User,c
"FileSysPath"="\\\\cpc.loc
"DisplayName"="Enable Printer Install"
"Extensions"="[{35378EAC-6
"Link"="LDAP://DC=cpc,DC=l
"GPOName"="{FDE7B6FD-BF27-
"GPOLink"=dword:00000003
"lParam"=hex(4):00,00,00,0
[HKEY_CURRENT_USER\Softwar
"Options"=dword:00000000
"Version"=dword:00070007
"DSPath"="LDAP://CN=User,c
"FileSysPath"="\\\\cpc.loc
"DisplayName"="Desktop Screen Saver"
"Extensions"="[{35378EAC-6
"Link"="LDAP://OU=Office Systems,DC=cpc,DC=local"
"GPOName"="{34CBDE4F-E536-
"GPOLink"=dword:00000004
"lParam"=hex(4):00,00,00,0
ASKER
I think this error in the even logs is causing most of the issues:
GroupPolicy (Microsoft-Windows-GroupPo
EID 1110
The processing of Group Policy failed. Windows could not determine if the user and computer accounts are in the same forest. Ensure the user domain name matches the name of a trusted domain that resides in the same forest as the computer account.
The computer and user are in the same OU.
GroupPolicy (Microsoft-Windows-GroupPo
EID 1110
The processing of Group Policy failed. Windows could not determine if the user and computer accounts are in the same forest. Ensure the user domain name matches the name of a trusted domain that resides in the same forest as the computer account.
The computer and user are in the same OU.
ASKER
Here is the real problem. The computer or user or something doesn't know what domain it belongs to. Whatever this issue is, disjoin/rejoining the computer to the domain doesnt fix it.
I ran a gpresult /v c:gpresult.html and it shows the old domain before the rename.
Here is a snippet:
User name CPC\cdanger
Domain cpc.local
Organizational Unit cpc.local/CS Systems
Old domain was cpc.local. New domain is ad.all.com
To eliminate a user/profile issue, i created a new user (that didnt exist before the rename) and ran gpresult /h on the same machine. We again got the no RSOP data.
I ran a gpresult /v c:gpresult.html and it shows the old domain before the rename.
Here is a snippet:
User name CPC\cdanger
Domain cpc.local
Organizational Unit cpc.local/CS Systems
Old domain was cpc.local. New domain is ad.all.com
To eliminate a user/profile issue, i created a new user (that didnt exist before the rename) and ran gpresult /h on the same machine. We again got the no RSOP data.
Sometimes a log file cleared and reboot of the server may fix things
ASKER
Which logfile on which server? There are 3 DC's.
ASKER
I found the issue extends much deeper than i thought. It looks like the trust relationship between the DC and the domain is broken. To test and get to the bottom of things i removed the other 2 dc's. Transferred the fsmo roles and demoted dc1 and dc2. Now the only dc is dc3.
running: nltest /server:dc3 /sc_query:ad.all.com says"1311 0x51f error_no_logon_servers
I tried to reset the trust by running: nltest /server:dc3 /sc_reset:ad.all.com\dc3 but was told no such domain.
Things are really screwed up here. I think this goes back to the domain rename. I can only assume the domain is looking for an old dc as the logon server. One would assume that with only 1 DC it is the login server. When i run echo %loginserver% the result is dc3.
Questions:
How do i switch the logon server to the new domain?
Exactly what is broken?
How does the only DC not know what domain it is in?
running: nltest /server:dc3 /sc_query:ad.all.com says"1311 0x51f error_no_logon_servers
I tried to reset the trust by running: nltest /server:dc3 /sc_reset:ad.all.com\dc3 but was told no such domain.
Things are really screwed up here. I think this goes back to the domain rename. I can only assume the domain is looking for an old dc as the logon server. One would assume that with only 1 DC it is the login server. When i run echo %loginserver% the result is dc3.
Questions:
How do i switch the logon server to the new domain?
Exactly what is broken?
How does the only DC not know what domain it is in?
ASKER
Microsoft has been working on the issue for 4 days now. Looks like it is much harder to fix than I realized.
If they don't fix it soon, i will just create a new domain. We cant have group policy broken for this long.
If they don't fix it soon, i will just create a new domain. We cant have group policy broken for this long.
Did you run gpfixup after renaming the domain?
You could use dc3 as your source of truth and demote dc1 and dc2 then promoto them again
You could use dc3 as your source of truth and demote dc1 and dc2 then promoto them again
ASKER
We did run gpfixup.
I demoted dc1 and 2 and re-promoted dc2. schannel works but it probably did already.
M$ said any schannel tests fail when ran from a DC.
I demoted dc1 and 2 and re-promoted dc2. schannel works but it probably did already.
M$ said any schannel tests fail when ran from a DC.
ok so two out of your there DC's are up..
Can you run a dcdiag /v /e >c:\diag.txt and post results
In ADUC, enabled advanced view, Expand the System container and view the policies container. Review all GP GUID's to make sure they are correct
Can you run a dcdiag /v /e >c:\diag.txt and post results
In ADUC, enabled advanced view, Expand the System container and view the policies container. Review all GP GUID's to make sure they are correct
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
It is to bad Microsoft was not able to fix this..... Nice work on your domain rebuild
ASKER
I had hoped.
Actually, besides recreating all the user accounts, the only thing that takes the most time is recreating all the GPO's.
If we could import them, creating a new domain would be rather easy.
Actually, besides recreating all the user accounts, the only thing that takes the most time is recreating all the GPO's.
If we could import them, creating a new domain would be rather easy.
ASKER
Domain renames dont always work, even when you get Microsoft involved.
https://www.404techsupport.com/2014/04/script-clear-cached-group-policies/
@echo off
DEL /S /F /Q "%ALLUSERSPROFILE%\Applica
REG DELETE HKLM\SOFTWARE\Microsoft\Wi
REG DELETE HKCU\SOFTWARE\Microsoft\Wi
DEL /F /Q C:\WINDOWS\security\Databa
Klist purge
gpupdate /force
exit