By
Published
Apr 04 2019 04:46 PM
580
Views
First published on TechNet on Nov 12, 2010
Hello everybody, Ned here again to share some conversations. This week I talk some SMB security, domain renames, file compression, and DFSR DFSR DFSR!
I successfully renamed my domain some years ago and but I find some registry values that reflect the old name. Those values are also present in my test domain where I tested the rename before I renamed the production environment. They are values in HKEY_LOCAL_MACHINE\System\currentcontrolset\Services\NTDS\Parameters, such as "Configuration NC" and "Src Srv objectGuid". Do you know why those keys are not cleaned out or changed by rendom.exe? And how do I tell if a domain has been renamed?
Those value names are not vital and it’s up to LSASS.EXE and DCPROMO.EXE (not rendom.exe ) to populate them; there will be a few others, depending on the DC being first created or later added, such as “Src Root Domain Srv” and “Root Domain”. They are used during the DC promotion process but after that they are no longer used. There are a few others like this in DCs – for instance, in the NetLogon key you will often find an abandoned AutoSiteName registry value that never changes to match reality. It’s not great fit and finish, but nothing fatal here. Keep in mind that domain rename came many years after AD was created so it’s unlikely the owners of NTDS ever expected these values to change outside DCPROMO.
If you want to update them for consistency that’s perfectly ok. After all, some application might decide (incorrectly) that it should use these values to make some decisions rather than correctly querying through APIs. If you want to be ultra -paranoid, you can demote each server in turn, then promote them back up and that will change those values for you. But that is crazy with a capital K.
As for your other question: as new DC’s are created they have the updated info, so it’s not possible to rely on these registry values to tell if a domain was renamed. If you look at the oldest DCs and see that they have SPNs registered for another domain, that might hint at it. The problem is that DC attrition may eventually remove those traces, and it still doesn’t emphatically mean a rename operation happened – it only shows that someone registered some other domain as SPNs for some reason.
The best way I can think of is to look at the version of the msDS-UpdateScript attribute on the “cn=partitions,cn=configuration,dc= <domain> ” object. The only operation that’s supposed to change that attribute is a domain rename and it’s protected from direct alteration by administrators. If it’s version is higher than 1, a rename has likely been done.
KB 951003 talks about how to turn off DFSR file staging compression for certain kinds of files. Does it make sense to also add the Office 2007/2010 .docx, .pptx, and .xlsx suffixes to this list because these file formats are also ZIP files ?
It’s an excellent question and I agree: adding those to the exclusion list would generally be a good idea. For instance, here I zipped a large-ish DOCX file that did not include any pictures:
The savings with conventional WinZip against the default ZIP compression level of DOCX was only 1%. DFSR will not do any better and you will waste a (small) amount of time, disk, and CPU trying. It's such a good idea that it became the default in Windows Server 2008 R2. :)
Can you could share some background information about the "Server SPN target name validation level" GPO setting? With our current information, setting the "Accept if provided by client" seemed to be a reasonable thing to incrementally increase our security configuration on DCs. Unfortunately we immediately hit a compatibility wall with some third party file appliances not working.
We bury this explanation as deep as possible; this setting was added to all supported versions of Windows (XP and later) with KB 973811 but only Vista and later know about it via group policy (security policy). What you are really modifying is the DWORD registry setting:
This article explains the setting and its rules (see the bottom section “More information about this update”, which naturally states nothing about the group policy):
If a 3 rd party has not updated their products to act more closely like Windows for things like Extended Protection or they are not following RFC2743 or if they are based on Win2000 or older OS emulation, or a host of other issues described in that article, they will fail using settings of 1 or 2. A network capture may show the issue in this case as to see why its failing or if you need to specify SrvAllowedServerNames entries – but it may also be that your appliance will not work until you contact that vendor to see how it must be reconfigured, updated, or that it’s a known issue and the appliance is incompatible.
Can I cluster DFSR on Windows Server 2003 R2 or Windows Server 2008 non-R2? [asked by many people and seen in many support cases]
NOOOOOOOOOOOOOOOOOOO!
Are you sure I cannot cluster it?
Yes, I am sure. People don’t seem to notice that when they cluster DFSR on Win2003 R2 it explodes their database and never replicates again after a node failover. Not to mention that we obviously spent millions of dollars to create a clustered DFSR in Windows Server 2008 R2 – why bother if it already worked? Plus we say you cannot cluster except on Win 2008 R2 all over the place .
We successfully tested DFSR replication of user data across sites in our network. We now want to completely remove DFSR from both of the servers used in testing as they are going to be repurposed and I need to ensure I get back all the disk space, CPU, and memory. How can I make sure it’s totally removed?
Good question, we don’t document this (who would ever want to remove DFSR after all?!?! :p ). This assumes you already removed Replication Groups or removed the members from replication, obviously:
To fully remove DFSR, you need to do the following:
1. Uninstall the DFSR role via Server Manager (on Win2008/R2) or Add/Remove Windows Components (Win2003):
2. Delete the folder(s) that you were replicating.
3. If using Win2008/R2, give yourself access to the hidden operating system folder “System Volume Information” on the C: drive with this command (that should be run as an elevated Admin user; if on Win2003 the Admin will already have permissions):
4. Repeat step 3 on any drives that had replicated folders, changing the path to that drive.
5. In that CMD prompt (don’t use Windows Explorer) you can then delete the “DFSR” folder that was left behind on those drives. That contains all the staged, pre-existing, and conflicted files in 2008/R2. It also contains the DFSR database and XML files in all versions of Windows. For example:
6. Repeat as needed on any other drives.
7. Done.
The reason you need to use a CMD prompt on Win2008/R2 is based on how Explorer special-cases the SVI folder and prevents anyone (even admins with full control permissions) from deleting its contents. You have to want it real bad, basically. Win2003 just lets you delete it arbitrarily because he is a punk.
Thanks to everyone who sent along nice emails about the Think Positive post, there were quite a few of you and I may not have responded to everyone. If you want to give those pleasant folks in Melbourne a little jolt of cash to keep their campaign going, click here .
They also sell the posters, but I will be sticking with what I already have up in my cubicle. I can only be so positive before I have to return to my roots…
Finally, to all the former and present US Marines, happy 235th birthday from an old leatherneck. In keeping with the tradition started in 1921, here is the 13th Commandant’s message :
Have a nice weekend folks,
- Ned “0341” Pyle
Hello everybody, Ned here again to share some conversations. This week I talk some SMB security, domain renames, file compression, and DFSR DFSR DFSR!
- Domain rename registry key orphans and determining if a rename ever happened
- DFSR compression recommendations for Office 2007+
- "Server SPN target name validation level"
- Clustering DFSR on WIn2003 and Win2008 non-R2
- DFSR removal
- Other stuff
Question
I successfully renamed my domain some years ago and but I find some registry values that reflect the old name. Those values are also present in my test domain where I tested the rename before I renamed the production environment. They are values in HKEY_LOCAL_MACHINE\System\currentcontrolset\Services\NTDS\Parameters, such as "Configuration NC" and "Src Srv objectGuid". Do you know why those keys are not cleaned out or changed by rendom.exe? And how do I tell if a domain has been renamed?
Answer
Those value names are not vital and it’s up to LSASS.EXE and DCPROMO.EXE (not rendom.exe ) to populate them; there will be a few others, depending on the DC being first created or later added, such as “Src Root Domain Srv” and “Root Domain”. They are used during the DC promotion process but after that they are no longer used. There are a few others like this in DCs – for instance, in the NetLogon key you will often find an abandoned AutoSiteName registry value that never changes to match reality. It’s not great fit and finish, but nothing fatal here. Keep in mind that domain rename came many years after AD was created so it’s unlikely the owners of NTDS ever expected these values to change outside DCPROMO.
If you want to update them for consistency that’s perfectly ok. After all, some application might decide (incorrectly) that it should use these values to make some decisions rather than correctly querying through APIs. If you want to be ultra -paranoid, you can demote each server in turn, then promote them back up and that will change those values for you. But that is crazy with a capital K.
As for your other question: as new DC’s are created they have the updated info, so it’s not possible to rely on these registry values to tell if a domain was renamed. If you look at the oldest DCs and see that they have SPNs registered for another domain, that might hint at it. The problem is that DC attrition may eventually remove those traces, and it still doesn’t emphatically mean a rename operation happened – it only shows that someone registered some other domain as SPNs for some reason.
The best way I can think of is to look at the version of the msDS-UpdateScript attribute on the “cn=partitions,cn=configuration,dc= <domain> ” object. The only operation that’s supposed to change that attribute is a domain rename and it’s protected from direct alteration by administrators. If it’s version is higher than 1, a rename has likely been done.
Question
KB 951003 talks about how to turn off DFSR file staging compression for certain kinds of files. Does it make sense to also add the Office 2007/2010 .docx, .pptx, and .xlsx suffixes to this list because these file formats are also ZIP files ?
Answer
It’s an excellent question and I agree: adding those to the exclusion list would generally be a good idea. For instance, here I zipped a large-ish DOCX file that did not include any pictures:
The savings with conventional WinZip against the default ZIP compression level of DOCX was only 1%. DFSR will not do any better and you will waste a (small) amount of time, disk, and CPU trying. It's such a good idea that it became the default in Windows Server 2008 R2. :)
Question
Can you could share some background information about the "Server SPN target name validation level" GPO setting? With our current information, setting the "Accept if provided by client" seemed to be a reasonable thing to incrementally increase our security configuration on DCs. Unfortunately we immediately hit a compatibility wall with some third party file appliances not working.
Answer
We bury this explanation as deep as possible; this setting was added to all supported versions of Windows (XP and later) with KB 973811 but only Vista and later know about it via group policy (security policy). What you are really modifying is the DWORD registry setting:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
SmbServerNameHardeningLevel
This article explains the setting and its rules (see the bottom section “More information about this update”, which naturally states nothing about the group policy):
2345886 Description of the update that implements Extended Protection for Authentication in the Server service - http://support.microsoft.com/default.aspx?scid=kb;en-US;2345886
If a 3 rd party has not updated their products to act more closely like Windows for things like Extended Protection or they are not following RFC2743 or if they are based on Win2000 or older OS emulation, or a host of other issues described in that article, they will fail using settings of 1 or 2. A network capture may show the issue in this case as to see why its failing or if you need to specify SrvAllowedServerNames entries – but it may also be that your appliance will not work until you contact that vendor to see how it must be reconfigured, updated, or that it’s a known issue and the appliance is incompatible.
Question
Can I cluster DFSR on Windows Server 2003 R2 or Windows Server 2008 non-R2? [asked by many people and seen in many support cases]
Answer
NOOOOOOOOOOOOOOOOOOO!
Question
Are you sure I cannot cluster it?
Answer
Yes, I am sure. People don’t seem to notice that when they cluster DFSR on Win2003 R2 it explodes their database and never replicates again after a node failover. Not to mention that we obviously spent millions of dollars to create a clustered DFSR in Windows Server 2008 R2 – why bother if it already worked? Plus we say you cannot cluster except on Win 2008 R2 all over the place .
Question
We successfully tested DFSR replication of user data across sites in our network. We now want to completely remove DFSR from both of the servers used in testing as they are going to be repurposed and I need to ensure I get back all the disk space, CPU, and memory. How can I make sure it’s totally removed?
Answer
Good question, we don’t document this (who would ever want to remove DFSR after all?!?! :p ). This assumes you already removed Replication Groups or removed the members from replication, obviously:
To fully remove DFSR, you need to do the following:
1. Uninstall the DFSR role via Server Manager (on Win2008/R2) or Add/Remove Windows Components (Win2003):
2. Delete the folder(s) that you were replicating.
3. If using Win2008/R2, give yourself access to the hidden operating system folder “System Volume Information” on the C: drive with this command (that should be run as an elevated Admin user; if on Win2003 the Admin will already have permissions):
icacls "c:\system volume information" /grant Administrators:F
4. Repeat step 3 on any drives that had replicated folders, changing the path to that drive.
5. In that CMD prompt (don’t use Windows Explorer) you can then delete the “DFSR” folder that was left behind on those drives. That contains all the staged, pre-existing, and conflicted files in 2008/R2. It also contains the DFSR database and XML files in all versions of Windows. For example:
Rd “c:\system volume information\dfsr” /s /q
6. Repeat as needed on any other drives.
7. Done.
The reason you need to use a CMD prompt on Win2008/R2 is based on how Explorer special-cases the SVI folder and prevents anyone (even admins with full control permissions) from deleting its contents. You have to want it real bad, basically. Win2003 just lets you delete it arbitrarily because he is a punk.
Other stuff
Thanks to everyone who sent along nice emails about the Think Positive post, there were quite a few of you and I may not have responded to everyone. If you want to give those pleasant folks in Melbourne a little jolt of cash to keep their campaign going, click here .
They also sell the posters, but I will be sticking with what I already have up in my cubicle. I can only be so positive before I have to return to my roots…
No one at DePaul gets this anymore
Finally, to all the former and present US Marines, happy 235th birthday from an old leatherneck. In keeping with the tradition started in 1921, here is the 13th Commandant’s message :
On November 10, 1775, a Corps of Marines was created by a resolution of Continental
Congress. Since that date many thousand men have borne the name "Marine". In memory of them it is
fitting that we who are Marines should commemorate the birthday of our corps by calling to mind the
glories of its long and illustrious history.
The record of our corps is one which will bear comparison with that of the most famous
military organizations in the world's history. During 90 of the 146 years of its existence the
Marine Corps has been in action against the Nation's foes. From the Battle of Trenton to the
Argonne, Marines have won foremost honors in war, and in the long eras of tranquility at home,
generation after generation of Marines have grown gray in war in both hemispheres and in every
corner of the seven seas, that our country and its citizens might enjoy peace and security.
In every battle and skirmish since the birth of our corps, Marines have acquitted themselves
with the greatest distinction, winning new honors on each occasion until the term "Marine" has come
to signify all that is highest in military efficiency and soldierly virtue.
This high name of distinction and soldierly repute we who are Marines today have received
from those who preceded us in the corps. With it we have also received from them the eternal spirit
which has animated our corps from generation to generation and has been the distinguishing mark of
the Marines in every age. So long as that spirit continues to flourish Marines will be found equal
to every emergency in the future as they have been in the past, and the men of our Nation will
regard us as worthy successors to the long line of illustrious men who have served as "Soldiers of
the Sea" since the founding of the Corps.
Have a nice weekend folks,
- Ned “0341” Pyle