Hey folks, Ned here again. For those keeping score, you’ve probably noticed the full-on original article content has been a bit thin in the past few weeks. We have some stuff in the draft pipeline so hang in there. In the meantime, here’s a weeks worth of.. stuff.
I like to move it, move it.
- Windows edition differences for DFS
- MIGUSER and MIGAPP xml compatibility between versions
- AD reporting tools
- USMT and security migration
- Empty forest root recommendations
- Scripting DFSN link creation
I am confused on what DFS features are different between Standard Edition and Enterprise Edition versions of Windows Server. This includes DFSN and DFSR.
There are only two* differences:
DFS Replication – Enterprise edition gives you the ability to use cross-file RDC. Cross-file RDC is a way to replicate files by using a heuristic to determine similar data in existing files on a downstream server and use that construct a file locally without the need to request the whole new file over the network from an upstream partner.
DFS Namespace – A Standard Edition server can host only one root standalone namespace. It can, however, host multiple domain-based namespaces if running Win2003 SP2 or later. Nice bullet points here.
* There was a third difference prior to Windows Server 2003 SP2 and in Windows 2000 SP4 – those Standard Edition servers can only run one DFS root namespace, no matter if domain-based or standalone. Since 2000 is nearly dead and you are not supported running Win2003 non-SP2, don’t worry about it further.
Can I use the miguser.xml and migapp.xml from USMT 3.01 to migrate data using USMT 4.0?
Yes, but with plenty of caveats. You would not have any errors or anything; the schema and migxml library are compatible. But you are going to miss out on plenty of new features:
- New applications that were added will not migrate
- New types of helper functions will not work
- Updated migration features will not work
- f you use an old config.xml it will be missing settings.
Plus if you are using miguser.xml, you are not using the new migdocs.xml, which is vastly improved in most scenarios for what it gathers and for performance. It’s a much better idea to use the new XML files and simply recreate any customizations that you had done if 3.01 – if you still need to use them, that is. A lot of 3.01 customizations may be duplication of effort in 4.0.
You can steer a car with your feet, but that doesn’t make it a good idea.
Are there any free tools out there for reporting on AD? Stuff like number of objects, installed OS’s, functional levels, disabled user accounts, locked out users, domains, trusts, groups, etc. The gestalt of AD, basically.
You can pay for these sorts of tools, of course (rhymes with zest!). If you dig around the intarwebs you will also find some free options. You could of course script any of this you want with AD PowerShell – that’s why we wrote it. One fellow on my team recommends this nice free UNSUPPORTED project that lives on CodePlex called “Active Directory reporting”. It’s a way to use SQL Reporting Server to analyze AD. Feel free to pipe up in the comments with others you like.
Does USMT migrate file information like security & attributes? The “metadata” aspects of NTFS.
USMT preserves the security (DACL/SACL) as well as the file attributes like hidden, read-only, the create date, etc. So if you have done this:
It will end up migrating the same:
Note that if you are using the /NOCOMPRESS option to a non-hard-link store, these permissions and attributes will not be set on that copy of the file. That extra data is stored in the migration catalog. So don’t use the data in an uncompressed store to see if this is working, it is not accurate. When restored, everything will get fixed up by USMT based on the catalog.
Don’t confuse all this with EFS though – that requires use of the /EFS switch to handle.
When I deploy new AD forests, should I continue to use an empty root domain?
We stopped arbitrarily recommending empty forest roots a while back – but instead of saying that we just stopped talking about them. Documentation through omission! But if you read between the lines you’ll see that we don’t think they are a great idea anymore. Brian Puhl, the world’s oldest AD admin wishes they had never deployed an empty root in 1999. Mark Parris and Instan both provide a good comprehensive list of reasons not to use an empty root.
For me, the biggest reason is that it’s a lot more complex without providing a lot more value. Fine Grain Password Policy takes care of differing security needs since Win2008. The domain does not provide enough admin separation to be considered a full security barricade, but merely a boundary of functionality – meaning you are now maintaining multiple copies of group policy, multiple SYSVOLs, etc. All with more fragility. Better to have a single domain and arrange your business via OU’s, if possible.
PS: I mean that Brian runs the world’s oldest AD, not that he is old. Well, not that old.
Is there a command-line way to create DFS links (i.e. “folders”)? I need to make a few hundred.
In 2008/2008R2 & Vista/7 RSAT:
dfsutil.exe link add
In 2003/XP Support Tools:
Finally – the clock is ticking down on Windows 2000 end of life – now just 7 weeks to go. If you have not begun planning your upgrade, migration, or removal of Windows 2000 in your environment, you are officially behind the eight ball. Soon you will be running an OS that does not get security updates. Then it will be immediately owned by some new malware that your AV vendor fails to catch.
Then your boss will be all like
and you will be all like
and your users will be all like
and your week will be all like
and your company’s bottom line will be all like
and you don’t want that. So get to our Windows 2000 portal and make your move to a supported operating system before it’s too late: Windows 2000 End-of-Support Solution Center. Also, Windows Server 2003 enters extended support the same day, so don’t bother asking for bug fixes after that. Get on Win2008/R2 and we’ll be all ears…
Until next time,
– Ned “like” Pyle