By
Published
Apr 04 2019 03:38 PM
528
Views
First published on TechNet on Apr 16, 2010
Hello all, Ned here again. After a brief absence, the rocket sled that I use to carry my disembodied head around has brought me back to AskDS headquarters. The coup is over and I have emerged triumphant again. You won’t be hearing from Jonathan until the truth serum wears off.
So let’s talk some talk.
There was a tool called ntrights.exe in the Win2003 resource kit tools, but we couldn't find one for Windows Server 2008. I need a command-line based tool to add security privileges for users.
The ntrights.exe tool still works fine even in Windows Server 2008 R2 and Windows 7 so feel free to use it. You could also use secedit.exe /configure with a custom INF file that added the user rights (good idea Mike ). Not to mention group policy – adding privs with the command-line sounds like a lot of extra work to me.
How much free space is needed for temporary files doing a USMT 4.0 scanstate? I grok that it arbitrarily requires at least 250MB as stated here , but could I need more? I plan to have the store file written to a network drive.
By default, the USMT temp/working folder is the operator's %TEMP% folder (obviously, this is local to the computer). The full set of files is not gathered here; the store is updated in a serialized fashion directly. The temporary file that USMT 4.0 creates is used purely to track work and back the stores catalog data and non-file data.
When running scanstate /p the estimator for space figures how big the backing file will get, then adds an additional 1MB of "fudge factor". The binary size of gathered user data files never matters -just the quantity of units to be migrated.
For example, in a repro I had a Windows 7 client with eight profiles. This created a temporary backing file that was 44MB. Then when I cut the migration down to a single user profile the temporary file was only 9MB. When I added 300+MB of data to my profile (so only 20 files, but each being very big), the temporary space usage estimate did not get appreciably larger.
Also, you can use the USMT_WORKING_DIR override environment variable to make the temporary folder a remote server path. But the migration is going to get much slower. My repro scanstate ran ~2-3 times slower because I had traded fast local I/O for comparatively slow network I/O. That was on gigabit network with no contention. A hard-link migration would be much faster.
Is there a way to isolate a DC in order to do an AD Schema upgrade? I cannot find any documentation on how to do this.
Isolating the Schema Master for ADPREP /FORESTPREP is not tested by the Product Group and not recommended*; we intentionally try to block you from this scenario starting in Win2003 SP1. Attempting to do so will return:
This was added back in Win2003 SP1, based on the fact that customers were causing horrendous issues trying to isolate their Schema Master FSMO servers during a migration or never verifying that the Schema master was healthy, then incorrectly (or never) reattaching them to their domain while the now split schemas diverged.
Our supported and recommended methodology is for you to test the migration in your lab with a copy of your current forest/schema; if there are going to be problems in the schema upgrade, they will happen in your lab. Likewise if there are going to be problems with the Schema itself, they would occur there as well. Prior to upgrading your schema, we recommend that you get a good System State backup on all DC’s; but we recommend you do this every day, not just for Schema upgrades. If there was some irreconcilable issue you could restore your forest from backup using those system states using our forest recovery info here: http://technet.microsoft.com/en-us/library/planning-active-directory-forest-recovery(WS.10).aspx...
This was an especially excellent question – sometimes we imply through an absence of documentation rather than stating things flat out, unfortunately.
* And to be clear here , yes it is possible to disable replication temporarily. Older documentation even used to say things like "disconnect your schema master" or "block outbound replication". Newer documentation does NOT, as we now have a decade's worth of experience with customers using those techniques in lieu of proper testing. And dealing with the fallout of that! We've had customers disable the replication then forget to ever turn it back on again; guess what happened after 61 days?
When the AskDS team says something is possible, it often gets construed as it's recommended and supported. It's not. Testing your schema update in a lab costs nothing thanks to free virtualization products aplently. Do that and you cannot go wrong.
Do the registry values in KB954968 apply to Windows Server 2008 and 2008 R2 also, in regards to configuring FSRM hard quotas to work with DFSR?
The registry values still work, yes. But they shouldn’t be as necessary in 2008/2008 R2 DFSR because all of the folders and files that FSRM would count against quota are now under a reparse point. The reparse point will prevent the quota from being enforced in this circumstance.
So for example, if you set an FSRM quota against c :\condelrf , it would not affect the contents of the c:\condelrf\dfsrprivate folder:
Because that is actually this reparse point target location:
So the data in there is not covered for quota. The KB and registry change from 2003 R2 were necessary because back then, dfsrprivate was a real folder under the DFSR replicated folder. When quota was hit there, kaboooooom.
You still need to make sure that you approach hard quotas with extreme caution though:
http://technet.microsoft.com/en-us/library/cc773238(WS.10).aspx#BKMK_064
DFSR and FSRM do not really have a good interop story – using them together is not something I’d personally recommend, after many, many support cases fixing the fallout of inappropriately configured hard quotas.
Finally, some sad news. Our fearless manager Mike O’Reilly - he of the swapped desk and the cubicle tree - has left us for greener pastures. At least as green as pastures get in Newfoundland. Mike is now a director at a large construction firm back on his native island in his pseudo-country we call America’s Hat. In fond memory, here is his email address: moreilly1974vw@hotmail.com . I sure hope it doesn’t get crazily inappropriate spam, what with it being out here on the Internet forever.
That’s all, have a nice weekend folks,
Ned “
“ Pyle
Hello all, Ned here again. After a brief absence, the rocket sled that I use to carry my disembodied head around has brought me back to AskDS headquarters. The coup is over and I have emerged triumphant again. You won’t be hearing from Jonathan until the truth serum wears off.
So let’s talk some talk.
Question
There was a tool called ntrights.exe in the Win2003 resource kit tools, but we couldn't find one for Windows Server 2008. I need a command-line based tool to add security privileges for users.
Answer
The ntrights.exe tool still works fine even in Windows Server 2008 R2 and Windows 7 so feel free to use it. You could also use secedit.exe /configure with a custom INF file that added the user rights (good idea Mike ). Not to mention group policy – adding privs with the command-line sounds like a lot of extra work to me.
Question
How much free space is needed for temporary files doing a USMT 4.0 scanstate? I grok that it arbitrarily requires at least 250MB as stated here , but could I need more? I plan to have the store file written to a network drive.
Answer
By default, the USMT temp/working folder is the operator's %TEMP% folder (obviously, this is local to the computer). The full set of files is not gathered here; the store is updated in a serialized fashion directly. The temporary file that USMT 4.0 creates is used purely to track work and back the stores catalog data and non-file data.
When running scanstate /p the estimator for space figures how big the backing file will get, then adds an additional 1MB of "fudge factor". The binary size of gathered user data files never matters -just the quantity of units to be migrated.
For example, in a repro I had a Windows 7 client with eight profiles. This created a temporary backing file that was 44MB. Then when I cut the migration down to a single user profile the temporary file was only 9MB. When I added 300+MB of data to my profile (so only 20 files, but each being very big), the temporary space usage estimate did not get appreciably larger.
<?xml version="1.0" encoding="UTF-8"?>
<PreMigration>
<storeSize>
<size clusterSize="4096"> 96075776 </size>
</storeSize>
<temporarySpace>
<size> 10576664 </size>
</temporarySpace>
</PreMigration>
<?xml version="1.0" encoding="UTF-8"?>
<PreMigration>
<storeSize>
<size clusterSize="4096"> 425594880 </size>
</storeSize>
<temporarySpace>
<size> 10617624 </size>
</temporarySpace>
</PreMigration>
Also, you can use the USMT_WORKING_DIR override environment variable to make the temporary folder a remote server path. But the migration is going to get much slower. My repro scanstate ran ~2-3 times slower because I had traded fast local I/O for comparatively slow network I/O. That was on gigabit network with no contention. A hard-link migration would be much faster.
Question
Is there a way to isolate a DC in order to do an AD Schema upgrade? I cannot find any documentation on how to do this.
Answer
Isolating the Schema Master for ADPREP /FORESTPREP is not tested by the Product Group and not recommended*; we intentionally try to block you from this scenario starting in Win2003 SP1. Attempting to do so will return:
“Adprep was unable to extend the schema.
[Status/Consequence]
The schema master did not complete a replication cycle after the last reboot. The schema master must complete at least one replication cycle before the schema can be extended.
[User Action]
Verify that the schema master is connected to the network and can communicate with other domain controllers. Use the Sites and Services snap-in to replicate between the schema operations master and at least one replication partner. After replication has succeeded, run adprep again.”
This was added back in Win2003 SP1, based on the fact that customers were causing horrendous issues trying to isolate their Schema Master FSMO servers during a migration or never verifying that the Schema master was healthy, then incorrectly (or never) reattaching them to their domain while the now split schemas diverged.
Our supported and recommended methodology is for you to test the migration in your lab with a copy of your current forest/schema; if there are going to be problems in the schema upgrade, they will happen in your lab. Likewise if there are going to be problems with the Schema itself, they would occur there as well. Prior to upgrading your schema, we recommend that you get a good System State backup on all DC’s; but we recommend you do this every day, not just for Schema upgrades. If there was some irreconcilable issue you could restore your forest from backup using those system states using our forest recovery info here: http://technet.microsoft.com/en-us/library/planning-active-directory-forest-recovery(WS.10).aspx...
This was an especially excellent question – sometimes we imply through an absence of documentation rather than stating things flat out, unfortunately.
* And to be clear here , yes it is possible to disable replication temporarily. Older documentation even used to say things like "disconnect your schema master" or "block outbound replication". Newer documentation does NOT, as we now have a decade's worth of experience with customers using those techniques in lieu of proper testing. And dealing with the fallout of that! We've had customers disable the replication then forget to ever turn it back on again; guess what happened after 61 days?
When the AskDS team says something is possible, it often gets construed as it's recommended and supported. It's not. Testing your schema update in a lab costs nothing thanks to free virtualization products aplently. Do that and you cannot go wrong.
Question
Do the registry values in KB954968 apply to Windows Server 2008 and 2008 R2 also, in regards to configuring FSRM hard quotas to work with DFSR?
Answer
The registry values still work, yes. But they shouldn’t be as necessary in 2008/2008 R2 DFSR because all of the folders and files that FSRM would count against quota are now under a reparse point. The reparse point will prevent the quota from being enforced in this circumstance.
So for example, if you set an FSRM quota against c :\condelrf , it would not affect the contents of the c:\condelrf\dfsrprivate folder:
Because that is actually this reparse point target location:
So the data in there is not covered for quota. The KB and registry change from 2003 R2 were necessary because back then, dfsrprivate was a real folder under the DFSR replicated folder. When quota was hit there, kaboooooom.
You still need to make sure that you approach hard quotas with extreme caution though:
http://technet.microsoft.com/en-us/library/cc773238(WS.10).aspx#BKMK_064
DFSR and FSRM do not really have a good interop story – using them together is not something I’d personally recommend, after many, many support cases fixing the fallout of inappropriately configured hard quotas.
Finally, some sad news. Our fearless manager Mike O’Reilly - he of the swapped desk and the cubicle tree - has left us for greener pastures. At least as green as pastures get in Newfoundland. Mike is now a director at a large construction firm back on his native island in his pseudo-country we call America’s Hat. In fond memory, here is his email address: moreilly1974vw@hotmail.com . I sure hope it doesn’t get crazily inappropriate spam, what with it being out here on the Internet forever.
That’s all, have a nice weekend folks,
Ned “
“ Pyle