Koldov Posted May 15, 2025 Posted May 15, 2025 16 hours ago, Reecekellyy said: We've recently consolidated our servers and got all the main virtual machines onto 1 host. DC02 was migrated to the new host 103 days ago and DC01 was migrated (drumroll please...) 55 days ago. So clearly this is part of the issue. I am fairly inexperienced with servers and networks in general so we hire a consultant to do all the server heavy lifting. He dealt with getting things moved over to the new host. I did raise this problem with him but he couldn't work out what the issue was. We're planning on rebuilding the entire domain during the summer holidays, which will be great for me to learn what goes into it. I inherited this domain which was created 15+ yrs ago so I'm trying to get my head around all the intricacies. I guess I was just hoping I'd get this problem resolved before we rebuild the domain since we're due to get a load more new devices before the rebuild in the summer. I'll show him what I've found from you very helpful folk on here and see if he can piece it together. Quite the baptism of fire then... it would have been helpful to know about the migration and I don't know what your set-up is or your job role, but I think your consultant should have involved you. So, forget everything I posted... @psydii has probably hit the nail on the head as it now seems obvious that given the dates coinciding there's been some issue relating to the migration. I'm certainly no expert, but have a basic understanding as I changed our set-up and put everything in Hyper-V quite a few years ago now and I do remember reading up a lot on DCs, authoritative restores, PDCs and 'the roles' especially to be very careful on which was moved when and how long the PDC (DC1) could be off before the replication partner (DC2) decided to go it alone and take over, I'm guessing DC2 was moved first as it was expendable but maybe there was an issue when DC1 was moved and it was off too long? Or the back-up/saved version/snapshot that was moved wasn't Active Directory-aware? "If a Primary Domain Controller (PDC) is offline for a prolonged period, a replication partner, typically another domain controller, will assume the PDC's role and continue managing the domain's Active Directory. This transition ensures the ongoing functionality of the network, although certain operations, like password changes, might be temporarily affected." If DC2 then raised it's USN above the recorded value on DC1 it would not recognise it and any AD changes won't be replicated (it's far more complicated, but something like that anyway)but... "Because these destination domain controllers believe they're up to date, no replication errors are reported in Directory Service event logs or by monitoring and diagnostic tools." To check, you can run the following commands on both DCs at the same time (obviously change the {* *} information): repadmin /showutdvec {*domain-controller*} dc={*domain*},dc={*com*} I ran it this morning and it shows the following (there will be more info, but pick out the lines with your DCs). In this example: DC01 knows that the DC01 USN = 3164738 @ 09:59 but... DC02 thinks that the DC01 USN = 3164737 @ 09:58 (because 1 change has happened and they haven't replicated in the last minute) DC02 knows that the DC02 USN = 3657260 @ 09:59 but... DC01 thinks that the DC02 USN = 3657256 @ 09:58 (because 4 changes have happened and they haven't replicated in the last minute) 1
Reecekellyy Posted May 15, 2025 Author Posted May 15, 2025 1 hour ago, Koldov said: Quite the baptism of fire then... it would have been helpful to know about the migration and I don't know what your set-up is or your job role, but I think your consultant should have involved you. So, forget everything I posted... @psydii has probably hit the nail on the head as it now seems obvious that given the dates coinciding there's been some issue relating to the migration. I'm certainly no expert, but have a basic understanding as I changed our set-up and put everything in Hyper-V quite a few years ago now and I do remember reading up a lot on DCs, authoritative restores, PDCs and 'the roles' especially to be very careful on which was moved when and how long the PDC (DC1) could be off before the replication partner (DC2) decided to go it alone and take over, I'm guessing DC2 was moved first as it was expendable but maybe there was an issue when DC1 was moved and it was off too long? Or the back-up/saved version/snapshot that was moved wasn't Active Directory-aware? "If a Primary Domain Controller (PDC) is offline for a prolonged period, a replication partner, typically another domain controller, will assume the PDC's role and continue managing the domain's Active Directory. This transition ensures the ongoing functionality of the network, although certain operations, like password changes, might be temporarily affected." If DC2 then raised it's USN above the recorded value on DC1 it would not recognise it and any AD changes won't be replicated (it's far more complicated, but something like that anyway)but... "Because these destination domain controllers believe they're up to date, no replication errors are reported in Directory Service event logs or by monitoring and diagnostic tools." To check, you can run the following commands on both DCs at the same time (obviously change the {* *} information): repadmin /showutdvec {*domain-controller*} dc={*domain*},dc={*com*} I ran it this morning and it shows the following (there will be more info, but pick out the lines with your DCs). In this example: DC01 knows that the DC01 USN = 3164738 @ 09:59 but... DC02 thinks that the DC01 USN = 3164737 @ 09:58 (because 1 change has happened and they haven't replicated in the last minute) DC02 knows that the DC02 USN = 3657260 @ 09:59 but... DC01 thinks that the DC02 USN = 3657256 @ 09:58 (because 4 changes have happened and they haven't replicated in the last minute) Yeah apologies for not mentioning the migration, it wasn't until we discovered the 55 day thing did that come to mind. I do appreciate you taking the time and helping me with this, I've learnt a lot. I've ran that command on both DC's and got this: DC01 DC01 @ USN 38198459 @ Time 2025-05-15 12:32:50 DC02 @ USN 37740814 @ Time 2025-05-15 12:31:54 DC02 DC02 @ USN 37740830 @ Time 2025-05-15 12:32:42 DC01 @ USN 38198459 @ Time 2025-05-15 12:32:42
Koldov Posted May 15, 2025 Posted May 15, 2025 (edited) Honestly, from my limited knowledge/understanding... that looks OK... From the MS article: "One way to detect a USN rollback is to use the Windows Server version of Repadmin.exe to run the repadmin /showutdvec command. This version of Repadmin.exe displays the up-to-dateness vector USN for all domain controllers that replicate a common naming context. To detect a USN rollback, compare the output of the repadmin /showutdvec command on the domain controller with the output of the same command on the domain controller's replication partners. If the direct replication partners have a higher USN number for the domain controller than the domain controller has for itself, and the repadmin /showreps command does not report replication errors between direct replication partners, you have compelling evidence of a USN rollback." DC01 has a higher USN number for itself (or the same as replication just happened) than DC02 has for it DC02 has a higher USN number for itself than DC02 has for it So maybe this doesn't show a USN rollback situation. I would expect the output to identify if any domain controller has a lower USN recorded for itself than its replication partner does, but in your case: DC01 = 38198459 and DC02 thinks DC01 is the same. DC02 = 37740830 and DC01 thinks DC02 = 37740814, so a bit behind, but crucially it's not higher. For example I think if DC01 had a USN = 38198459, but DC02 thought DC01 had a USN = 38198461 you would see DC01 had been rolled back. In regedit (on both DCs) HKLM\System\CurrentControlSet\Services\NTDS\Parameters Do either have a key that says “DSA Not Writable” with a value of “4”. Also can you run repadmin /showreps on both. EDIT: Also see if the Netlogon service is paused on either DC Edited May 15, 2025 by Koldov 1
Reecekellyy Posted May 15, 2025 Author Posted May 15, 2025 5 minutes ago, Koldov said: Honestly, from my limited knowledge/understanding... that looks OK... From the MS article: "One way to detect a USN rollback is to use the Windows Server version of Repadmin.exe to run the repadmin /showutdvec command. This version of Repadmin.exe displays the up-to-dateness vector USN for all domain controllers that replicate a common naming context. To detect a USN rollback, compare the output of the repadmin /showutdvec command on the domain controller with the output of the same command on the domain controller's replication partners. If the direct replication partners have a higher USN number for the domain controller than the domain controller has for itself, and the repadmin /showreps command does not report replication errors between direct replication partners, you have compelling evidence of a USN rollback." DC01 has a higher USN number for itself (or the same as replication just happened) than DC02 has for it DC02 has a higher USN number for itself than DC02 has for it So maybe this doesn't show a USN rollback situation. I would expect the output to identify if any domain controller has a lower USN recorded for itself than its replication partner does, but in your case: DC01 = 38198459 and DC02 thinks DC01 is the same. DC02 = 37740830 and DC01 thinks DC02 = 37740814, so a bit behind, but crucially it's not higher. For example I think if DC01 had a USN = 38198459, but DC02 thought DC01 had a USN = 38198461 you would see DC01 had been rolled back. In regedit (on both DCs) HKLM\System\CurrentControlSet\Services\NTDS\Parameters Do either have a key that says “DSA Not Writable” with a value of “4”. Also can you run repadmin /showreps on both. Neither DC has the key DSA Not Writable. I've ran repadmin /showreps on both: DC01 DSA Options: IS_GC Site Options: (none) DSA object GUID: 929103cd-f24f-4de7-b329-5f09a2b9473e DSA invocationID: 146558b1-3a6b-4603-a9b0-a7ee7fd46e1e ==== INBOUND NEIGHBORS ====================================== DC=**,DC=local DC02 via RPC DSA object GUID: d111021f-068c-4d2c-bbce-c5d32fa9639c Last attempt @ 2025-05-15 13:45:28 was successful. CN=Configuration,DC=**,DC=local DC02 via RPC DSA object GUID: d111021f-068c-4d2c-bbce-c5d32fa9639c Last attempt @ 2025-05-15 12:55:55 was successful. CN=Schema,CN=Configuration,DC=**,DC=local DC02 via RPC DSA object GUID: d111021f-068c-4d2c-bbce-c5d32fa9639c Last attempt @ 2025-05-15 12:55:55 was successful. DC=DomainDnsZones,DC=**,DC=local DC02 via RPC DSA object GUID: d111021f-068c-4d2c-bbce-c5d32fa9639c Last attempt @ 2025-05-15 13:44:55 failed, result 8606 (0x219e): Insufficient attributes were given to create an object. This object may not exist because it may have been deleted and already garbage collected. 18791 consecutive failure(s). Last success @ 2025-03-20 09:18:00. DC=ForestDnsZones,DC=**,DC=local DC02 via RPC DSA object GUID: d111021f-068c-4d2c-bbce-c5d32fa9639c Last attempt @ 2025-05-15 13:41:26 was successful. Source: DC02 ******* 18777 CONSECUTIVE FAILURES since 2025-03-20 09:18:00 Last error: 8606 (0x219e): Insufficient attributes were given to create an object. This object may not exist because it may have been deleted and already garbage collected. --------------------------------------------------------------------------------------------------------------------------------------------------------------------- DC02 DSA Options: IS_GC Site Options: (none) DSA object GUID: d111021f-068c-4d2c-bbce-c5d32fa9639c DSA invocationID: 0ee61e33-007b-47f7-a8e2-f57c9dcaf42e ==== INBOUND NEIGHBORS ====================================== DC=**,DC=local DC01 via RPC DSA object GUID: 929103cd-f24f-4de7-b329-5f09a2b9473e Last attempt @ 2025-05-15 13:45:56 was successful. CN=Configuration,DC=**,DC=local DC01 via RPC DSA object GUID: 929103cd-f24f-4de7-b329-5f09a2b9473e Last attempt @ 2025-05-15 13:45:51 was successful. CN=Schema,CN=Configuration,DC=**,DC=local DC01 via RPC DSA object GUID: 929103cd-f24f-4de7-b329-5f09a2b9473e Last attempt @ 2025-05-15 13:45:51 was successful. DC=DomainDnsZones,DC=**,DC=local DC01 via RPC DSA object GUID: 929103cd-f24f-4de7-b329-5f09a2b9473e Last attempt @ 2025-05-15 13:45:53 was successful. DC=ForestDnsZones,DC=**,DC=local DC01 via RPC DSA object GUID: 929103cd-f24f-4de7-b329-5f09a2b9473e Last attempt @ 2025-05-15 13:45:51 was successful. --------------------------------------------------------------------------------------------------------------------------------------------------------------------- 18777 consecutive failures since the migration 56 days ago hmm
Koldov Posted May 15, 2025 Posted May 15, 2025 (edited) I didn't see the answers to these... Did you run that original code on both DCs? Although, I didn't really see anything in that output you posted, only the Domain/Forest level of 2012R2. What Server OS are you running? A couple of internet search results seem to suggest running full DCDIAG on both: dcdiag /c /v It will be long so just go through it and see if anything jumps out. Also, do you notice if the laptops log on to one DC they are fine, but if they log on to the other it fails to apply the GPOs? Use this in CMD (non admin): echo %logonserver% More info on the downfalls of restoring DCs: https://community.spiceworks.com/t/active-directory-problems/512067 Honestly I'm at the end of anything I even remotely understand and risk giving you bad info or making it worse as I'm just searching the internet now... It may be you'll have to find out which DC is in error and if it's the PDC, seize the roles and demote it. But... as it appears to have been some sort of error made by your consultant, I guess they need to come and fix it (and quickly if it's affecting prod... I mean T&L). Edited May 15, 2025 by Koldov
Koldov Posted May 15, 2025 Posted May 15, 2025 Your errors appear to be in the DomainDNSZones, but specifically: "Error 8606 in the DC=DomainDnsZones context, along with the "Insufficient attributes were given to create an object" message, indicates that a source domain controller is attempting to replicate changes to a deleted object that has been garbage-collected on a destination domain controller. This typically happens when an object is created, deleted, and then garbage-collected before the changes replicate to all domain controllers" So, I guess whilst one DC was down, maybe something in AD got created/deleted and the other DC is still trying to replicate it? Good article on repadmin (easier to understand than the MS stuff)... Especially: "3. Error 8606: Insufficient attributes were given to create an object This error occurs when attributes required for replication are missing. You can use repadmin /showobjmeta to inspect the metadata for the affected object and determine which attributes are causing the failure." So try repadmin /showobjmeta dc01 "<GUID=d111021f-068c-4d2c-bbce-c5d32fa9639c>" on yours
Reecekellyy Posted May 15, 2025 Author Posted May 15, 2025 24 minutes ago, Koldov said: I didn't see the answers to these... Did you run that original code on both DCs? Although, I didn't really see anything in that output you posted, only the Domain/Forest level of 2012R2. What Server OS are you running? A couple of internet search results seem to suggest running full DCDIAG on both: dcdiag /c /v It will be long so just go through it and see if anything jumps out. Also, do you notice if the laptops log on to one DC they are fine, but if they log on to the other it fails to apply the GPOs? Use this in CMD (non admin): echo %logonserver% More info on the downfalls of restoring DCs: https://community.spiceworks.com/t/active-directory-problems/512067 Honestly I'm at the end of anything I even remotely understand and risk giving you bad info or making it worse as I'm just searching the internet now... It may be you'll have to find out which DC is in error and if it's the PDC, seize the roles and demote it. But... as it appears to have been some sort of error made by your consultant, I guess they need to come and fix it (and quickly if it's affecting prod... I mean T&L). Yeah I ran all the code on both DC's. Both DC's running Server 2019 version 1809. I will try running dcdiag /c /v on both. When I power on one of the laptops, I run echo %logonserver% and it always shows DC01. Immediately after, I run gpresult /r and it says policies are being applied from DC02. I restarted the laptop, did eahc %logonserver% which showed DC01 again, I then checked gpresult /r and it says policies are being applied from DC01. So it seems that no matter which DC is applying policies, the problem persists. I did see some stuff online about lingering objects. So I used this command on DC01: repadmin /removelingeringobjects DC02 929103cd-f24f-4de7-b329-5f09a2b9473e DC=DomainDnsZones,DC=**,DC=local RemoveLingeringObjects successful on DC02 and when I run repadmin /showrepl again, it no longer says there are 18k+ errors. I don't know if that has helped anything. I've now ran repadmin /showobjmeta dc01 "<GUID=d111021f-068c-4d2c-bbce-c5d32fa9639c>" on both DC's, here are the outputs: DC01: repadmin /showobjmeta DC01 "<GUID=d111021f-068c-4d2c-bbce-c5d32fa9639c>" 14 entries. Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute ======= =============== ========= ============= === ========= 10938 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 objectClass 10938 d062f913-7c58-4bab-a2e9-e9116cc5b730 10938 2016-08-05 10:00:51 1 cn 10938 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 instanceType 10938 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 whenCreated 10938 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 dMDLocation 36856980 DC02 36286623 2025-01-30 19:01:55 4 invocationId 10938 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 showInAdvancedViewOnly 10938 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 nTSecurityDescriptor 10938 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 name 10938 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 options 10938 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 systemFlags 36856980 DC02 36286623 2025-01-30 19:01:55 3 retiredReplDSASignatures 10938 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 objectCategory 7919603 23913323-d1cd-4a58-bc46-3eaa3e35be64 8228940 2019-01-02 10:23:33 2 msDS-Behavior-Version 15 entries. Type Attribute Last Mod Time Originating DSA Loc.USN Org.USN Ver ======= ============ ============= ================= ======= ======= === Distinguished Name ============================= PRESENT hasMasterNCs 2016-08-03 14:39:39 9262ab60-6755-4db8-8f93-92d42c0780b0 10952 12704064 1 DC=**,DC=local PRESENT hasMasterNCs 2016-08-03 14:39:39 9262ab60-6755-4db8-8f93-92d42c0780b0 10954 12704063 1 CN=Configuration,DC=**,DC=local PRESENT hasMasterNCs 2016-08-03 14:39:39 9262ab60-6755-4db8-8f93-92d42c0780b0 10953 12704065 1 CN=Schema,CN=Configuration,DC=**,DC=local PRESENT msDS-HasInstantiatedNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 10958 14644 1 DC=**,DC=local PRESENT msDS-HasInstantiatedNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 10961 14607 1 CN=Configuration,DC=**,DC=local PRESENT msDS-HasInstantiatedNCs 2016-08-03 14:46:15 23913323-d1cd-4a58-bc46-3eaa3e35be64 10959 16519 1 CN=Schema,CN=Configuration,DC=**,DC=local PRESENT msDS-HasInstantiatedNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 10960 15071 1 DC=DomainDnsZones,DC=**,DC=local PRESENT msDS-HasInstantiatedNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 10957 14686 1 DC=ForestDnsZones,DC=**,DC=local PRESENT msDS-HasDomainNCs 2016-08-03 14:39:39 9262ab60-6755-4db8-8f93-92d42c0780b0 10962 12704069 1 DC=**,DC=local PRESENT msDS-hasMasterNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 10964 14643 3 DC=**,DC=local PRESENT msDS-hasMasterNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 10967 14606 3 CN=Configuration,DC=**,DC=local PRESENT msDS-hasMasterNCs 2016-08-03 14:39:39 9262ab60-6755-4db8-8f93-92d42c0780b0 10965 12704068 1 CN=Schema,CN=Configuration,DC=**,DC=local PRESENT msDS-hasMasterNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 10966 15070 3 DC=DomainDnsZones,DC=**,DC=local PRESENT msDS-hasMasterNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 10963 14685 3 DC=ForestDnsZones,DC=**,DC=local PRESENT msDS-EnabledFeature 2018-12-05 09:07:03 23913323-d1cd-4a58-bc46-3eaa3e35be64 7648835 7894896 1 CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=**,DC=local ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- DC02: repadmin /showobjmeta DC02 "<GUID=d111021f-068c-4d2c-bbce-c5d32fa9639c>" 14 entries. Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute ======= =============== ========= ============= === ========= 10942 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 objectClass 10942 23913323-d1cd-4a58-bc46-3eaa3e35be64 10942 2016-08-03 14:40:18 1 cn 10942 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 instanceType 10942 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 whenCreated 10942 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 dMDLocation 36286623 DC02 36286623 2025-01-30 19:01:55 4 invocationId 10942 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 showInAdvancedViewOnly 10942 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 nTSecurityDescriptor 10942 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 name 10942 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 options 10942 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 systemFlags 36286623 DC02 36286623 2025-01-30 19:01:55 3 retiredReplDSASignatures 10942 9262ab60-6755-4db8-8f93-92d42c0780b0 12704070 2016-08-03 14:39:39 1 objectCategory 8228940 23913323-d1cd-4a58-bc46-3eaa3e35be64 8228940 2019-01-02 10:23:33 2 msDS-Behavior-Version 15 entries. Type Attribute Last Mod Time Originating DSA Loc.USN Org.USN Ver ======= ============ ============= ================= ======= ======= === Distinguished Name ============================= PRESENT hasMasterNCs 2016-08-03 14:39:39 9262ab60-6755-4db8-8f93-92d42c0780b0 10947 12704064 1 DC=**,DC=local PRESENT hasMasterNCs 2016-08-03 14:39:39 9262ab60-6755-4db8-8f93-92d42c0780b0 10949 12704063 1 CN=Configuration,DC=**,DC=local PRESENT hasMasterNCs 2016-08-03 14:39:39 9262ab60-6755-4db8-8f93-92d42c0780b0 10948 12704065 1 CN=Schema,CN=Configuration,DC=**,DC=local PRESENT msDS-HasInstantiatedNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 14644 14644 1 DC=**,DC=local PRESENT msDS-HasInstantiatedNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 14607 14607 1 CN=Configuration,DC=**,DC=local PRESENT msDS-HasInstantiatedNCs 2016-08-03 14:46:15 23913323-d1cd-4a58-bc46-3eaa3e35be64 16519 16519 1 CN=Schema,CN=Configuration,DC=**,DC=local PRESENT msDS-HasInstantiatedNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 15071 15071 1 DC=DomainDnsZones,DC=**,DC=local PRESENT msDS-HasInstantiatedNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 14686 14686 1 DC=ForestDnsZones,DC=**,DC=local PRESENT msDS-HasDomainNCs 2016-08-03 14:39:39 9262ab60-6755-4db8-8f93-92d42c0780b0 10950 12704069 1 DC=**,DC=local PRESENT msDS-hasMasterNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 14643 14643 3 DC=**,DC=local PRESENT msDS-hasMasterNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 14606 14606 3 CN=Configuration,DC=**,DC=local PRESENT msDS-hasMasterNCs 2016-08-03 14:39:39 9262ab60-6755-4db8-8f93-92d42c0780b0 10952 12704068 1 CN=Schema,CN=Configuration,DC=**,DC=local PRESENT msDS-hasMasterNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 15070 15070 3 DC=DomainDnsZones,DC=**,DC=local PRESENT msDS-hasMasterNCs 2016-08-03 14:40:27 23913323-d1cd-4a58-bc46-3eaa3e35be64 14685 14685 3 DC=ForestDnsZones,DC=**,DC=local PRESENT msDS-EnabledFeature 2018-12-05 09:07:03 23913323-d1cd-4a58-bc46-3eaa3e35be64 7894896 7894896 1 CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=**,DC=local
Koldov Posted May 15, 2025 Posted May 15, 2025 (edited) 32 minutes ago, Reecekellyy said: I did see some stuff online about lingering objects. So I used this command on DC01: repadmin /removelingeringobjects DC02 929103cd-f24f-4de7-b329-5f09a2b9473e DC=DomainDnsZones,DC=**,DC=local RemoveLingeringObjects successful on DC02 and when I run repadmin /showrepl again, it no longer says there are 18k+ errors. I don't know if that has helped anything. Yeah, that link was in my 3rd or 4th post. So if you run repadmin /replsummary or repadmin /showreps your errors have gone (if so, leave it an hour or so or until tomorrow and run them again)? Then check if your laptops are still having issues applying GPOs. EDIT: The dcdiag /c /v and the repadmin /showobjmeta were to look for errors, if there are none now it probably isn't worth it. Edited May 15, 2025 by Koldov
Reecekellyy Posted May 15, 2025 Author Posted May 15, 2025 6 minutes ago, Koldov said: Yeah, that link was in my 3rd or 4th post. So if you run repadmin /replsummary or repadmin /showreps your errors have gone (if so, leave it an hour or so or until tomorrow and run them again)? Then check if your laptops are still having issues applying GPOs. Yeah the errors have gone when I run those commands. Source DSA largest delta fails/total %% error DC01 09m:51s 0 / 5 0 DC02 09m:51s 0 / 5 0 Destination DSA largest delta fails/total %% error DC01 09m:51s 0 / 5 0 DC02 09m:51s 0 / 5 0 ---------------------------------------------------------------------------------------------------------------------------------------------------------- DC01: DC01 DSA Options: IS_GC Site Options: (none) DSA object GUID: 929103cd-f24f-4de7-b329-5f09a2b9473e DSA invocationID: 146558b1-3a6b-4603-a9b0-a7ee7fd46e1e ==== INBOUND NEIGHBORS ====================================== DC=**,DC=local DC02 via RPC DSA object GUID: d111021f-068c-4d2c-bbce-c5d32fa9639c Last attempt @ 2025-05-15 15:41:24 was successful. CN=Configuration,DC=**,DC=local DC02 via RPC DSA object GUID: d111021f-068c-4d2c-bbce-c5d32fa9639c Last attempt @ 2025-05-15 15:31:59 was successful. CN=Schema,CN=Configuration,DC=**,DC=local DC02 via RPC DSA object GUID: d111021f-068c-4d2c-bbce-c5d32fa9639c Last attempt @ 2025-05-15 15:31:59 was successful. DC=DomainDnsZones,DC=**,DC=local DC02 via RPC DSA object GUID: d111021f-068c-4d2c-bbce-c5d32fa9639c Last attempt @ 2025-05-15 15:41:47 was successful. DC=ForestDnsZones,DC=**,DC=local DC02 via RPC DSA object GUID: d111021f-068c-4d2c-bbce-c5d32fa9639c Last attempt @ 2025-05-15 15:41:50 was successful. ---------------------------------------------------------------------------------------------------------------------------------------------------------- DC02: DC02 DSA Options: IS_GC Site Options: (none) DSA object GUID: d111021f-068c-4d2c-bbce-c5d32fa9639c DSA invocationID: 0ee61e33-007b-47f7-a8e2-f57c9dcaf42e ==== INBOUND NEIGHBORS ====================================== DC=**,DC=local DC01 via RPC DSA object GUID: 929103cd-f24f-4de7-b329-5f09a2b9473e Last attempt @ 2025-05-15 15:45:25 was successful. CN=Configuration,DC=**,DC=local DC01 via RPC DSA object GUID: 929103cd-f24f-4de7-b329-5f09a2b9473e Last attempt @ 2025-05-15 15:31:59 was successful. CN=Schema,CN=Configuration,DC=**,DC=local DC01 via RPC DSA object GUID: 929103cd-f24f-4de7-b329-5f09a2b9473e Last attempt @ 2025-05-15 15:31:59 was successful. DC=DomainDnsZones,DC=**,DC=local DC01 via RPC DSA object GUID: 929103cd-f24f-4de7-b329-5f09a2b9473e Last attempt @ 2025-05-15 15:41:32 was successful. DC=ForestDnsZones,DC=**,DC=local DC01 via RPC DSA object GUID: 929103cd-f24f-4de7-b329-5f09a2b9473e Last attempt @ 2025-05-15 15:41:35 was successful. ---------------------------------------------------------------------------- I'll wait until tomorrow and see if there are any issues on the laptops.
Reecekellyy Posted May 19, 2025 Author Posted May 19, 2025 So after leaving it over the weekend and checking the DC's, everything seems okay. When I run repadmin /showreps & repadmin /showsummary, they look normal. I can now consistently complete a gpupdate /force on the laptops after a few minutes of the laptop being logged into. However, I think part of this issue is related to the wireless network cards in the laptops. Now, when I boot up a laptop I am still seeing the same issue of the desktop icons not loading, this is because the icon files are stored in sysvol, so I know that policies haven't applied properly and when I run a gpupdate /force immediately after the laptop boots, I get the original error saying that policies can't be applied. So I go into file explorer and try to access \\domain\sysvol and I cannot access it, however, if I wait 3-5 minutes, I can access it. It seems like it just takes a while to access it, which is no good because any computer policies aren't getting applied at the point of booting up the laptop. I've connected the laptop via ethernet and I have no problem accessing sysvol immediately, so the wireless card is definitely the issue here. The laptops with the issue are brand new Lenovo V15 with wireless card of Intel Wireless-AC 9560. I've updated driver, reinstalled device, ensured fast boot is disabled, always wait for network GPO is enabled, nothing has fixed the issue. Anyone have any ideas?
Koldov Posted May 19, 2025 Posted May 19, 2025 (edited) I think GPOs themselves are normally cached on the device. I would choose another setting to determine if the policies are being applied or not (see * below). Google AI overview: "Yes, Group Policy settings are cached on client devices, so they will remain in effect through reboots even if the device cannot access a Domain Controller (DC). However, if new GPOs are published or updated on the DC, they won't be applied to the client device until the DC can communicate with it again. Here's a more detailed explanation: Caching: Group Policy settings are downloaded and stored on client machines. This allows them to remain effective even when disconnected from the network or unable to reach a DC. Persistence: These cached settings remain in effect until the client device is able to reconnect to the DC, at which point it will re-evaluate and apply any updated or new GPOs. Limited Functionality: While the cached settings remain, they are not dynamically updated. If the GPO changes on the DC, the client device will not automatically reflect those changes until it reconnects. Reboot Requirement: Some GPO settings, like security policies, may require a reboot for them to take effect, even when the client is connected to the DC" *Although iirc things like icons are read from a share each boot and that's possibly where the issue lies. I had a problem with desktop icons not being displayed though and I resorted to copying them to a folder on each machine's C:\ drive. I can't remember if it was just a delay in reading the share or a permission issue and although it adds a layer of complexity having to remember to add the icon every time a new shortcut is made, it doesn't happen that often and when the icon doesn't appear, I then remember why... 🙄 Is there any other complexity in your set-up (redirected desktops etc.)? Edited May 19, 2025 by Koldov
3s-gtech Posted May 19, 2025 Posted May 19, 2025 Hmmmm. When the question of it maybe being DNS at fault, it's usually DNS at fault. Combine that with DHCP. How are your DNS scavenging, refresh and do not refresh timings, and how do they compare to your DHCP leases? 1
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now