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?
kassant7Asked:
Who is Participating?
 
kassant7Author Commented:
Microsoft couldn't fix it. We blew up the domain and started over.

We are already 95% complete with the creation of the new GPO's and they are working fine.
0
 
DonNetwork AdministratorCommented:
Use the script here

https://www.404techsupport.com/2014/04/script-clear-cached-group-policies/

@echo off
DEL /S /F /Q "%ALLUSERSPROFILE%\Application Data\Microsoft\Group Policy\History\*.*"
REG DELETE HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies /f
REG DELETE HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies /f
DEL /F /Q C:\WINDOWS\security\Database\secedit.sdb
Klist purge
gpupdate /force
exit
0
 
kassant7Author Commented:
Run it on the workstations?
0
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
DonNetwork AdministratorCommented:
yes
0
 
kassant7Author Commented:
No effect. I am turning on verbose logging.

RegKey: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\UserEnvDebugLevel

For full debug logging set to: 30002

Log file: c:\windows\debug\UserMode\userenv.log
0
 
DonNetwork AdministratorCommented:
Ok, then run this command on them from elevated cmd prompt

secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose

then reboot when its finished
0
 
kassant7Author Commented:
invalid path c:\windows\repair.
0
 
kassant7Author Commented:
I deleted HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\History. It had all kinds of info from the old dc in there. Ran gpupdate /force and gpresult /r and still the same results.

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\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}]

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}\0]
"Options"=dword:00000000
"Version"=dword:00010001
"DSPath"="LDAP://CN=User,cn={FDE7B6FD-BF27-4ED9-95C1-26D611F5155B},cn=policies,cn=system,DC=cpc,DC=local"
"FileSysPath"="\\\\cpc.local\\SysVol\\cpc.local\\Policies\\{FDE7B6FD-BF27-4ED9-95C1-26D611F5155B}\\User"
"DisplayName"="Enable Printer Install"
"Extensions"="[{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{D02B1F73-3407-48AE-BA88-E8213C6761F1}]"
"Link"="LDAP://DC=cpc,DC=local"
"GPOName"="{FDE7B6FD-BF27-4ED9-95C1-26D611F5155B}"
"GPOLink"=dword:00000003
"lParam"=hex(4):00,00,00,00,00,00,00,00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}\1]
"Options"=dword:00000000
"Version"=dword:00010001
"DSPath"="LDAP://CN=User,cn={FDE7B6FD-BF27-4ED9-95C1-26D611F5155B},cn=policies,cn=system,DC=cpc,DC=local"
"FileSysPath"="\\\\cpc.local\\SysVol\\cpc.local\\Policies\\{FDE7B6FD-BF27-4ED9-95C1-26D611F5155B}\\User"
"DisplayName"="Enable Printer Install"
"Extensions"="[{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{D02B1F73-3407-48AE-BA88-E8213C6761F1}]"
"Link"="LDAP://DC=cpc,DC=local"
"GPOName"="{FDE7B6FD-BF27-4ED9-95C1-26D611F5155B}"
"GPOLink"=dword:00000003
"lParam"=hex(4):00,00,00,00,00,00,00,00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}\2]
"Options"=dword:00000000
"Version"=dword:00070007
"DSPath"="LDAP://CN=User,cn={34CBDE4F-E536-4CFA-9D08-CB02A4999A4D},cn=policies,cn=system,DC=cpc,DC=local"
"FileSysPath"="\\\\cpc.local\\SysVol\\cpc.local\\Policies\\{34CBDE4F-E536-4CFA-9D08-CB02A4999A4D}\\User"
"DisplayName"="Desktop Screen Saver"
"Extensions"="[{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{D02B1F73-3407-48AE-BA88-E8213C6761F1}]"
"Link"="LDAP://OU=Office Systems,DC=cpc,DC=local"
"GPOName"="{34CBDE4F-E536-4CFA-9D08-CB02A4999A4D}"
"GPOLink"=dword:00000004
"lParam"=hex(4):00,00,00,00,00,00,00,00
0
 
kassant7Author Commented:
I think this error in the even logs is causing most of the issues:

GroupPolicy (Microsoft-Windows-GroupPolicy)
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.
0
 
kassant7Author Commented:
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.
0
 
Natty GregIn Theory (IT)Commented:
Sometimes a log file cleared and reboot of the server may fix things
0
 
kassant7Author Commented:
Which logfile on which server? There are 3 DC's.
0
 
kassant7Author Commented:
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?
0
 
kassant7Author Commented:
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.
0
 
compdigit44Commented:
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
0
 
kassant7Author Commented:
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.
1
 
compdigit44Commented:
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
0
 
compdigit44Commented:
It is to bad Microsoft was not able to fix this..... Nice work on your domain rebuild
0
 
kassant7Author Commented:
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.
0
 
DonNetwork AdministratorCommented:
0
 
kassant7Author Commented:
Domain renames dont always work, even when you get Microsoft involved.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.