Microsoft's official enterprise support blog for AD DS and more
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.
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:
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
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
I've always liked adfind by Joe Richard's for reporting. I really like his count switch (-c) for number of objects. Tons of great shortcut commands too.
Good info about the empty root. There are also discussions about people wanting to collapse empty roots that were stood up 8-10 years ago. There was a great discussion on activedir in 2007
I agree with Dmitri Gavrilov's comment in that thread. If you have an empty root now is the work required to collapse it worth it? For a new pristine forest/domain the single domain model is the way to go. If the empty root is already there then I say keep it as is.
Copy/pasted the past part of the blog to my sup, I'm sure he'll get a laugh.
I'd tend to agree - all but the most heinously unreliable and unmanageable empty root will be less work than a full forest migration. Unless the whole forest is tiny (under a hundred computers/users).
“dfsutil.exe link add” is a pretty straightforward answer. But what if I need to create an EMPTY DFS folder (i.e. a link with no targets)? That's easily achievable in GUI (via DFSMgmt.msc), but what if I want to script it?
Seems that “dfsutil.exe link add” always requires no less then TWO arguments—namely link and target.
Hmmm... I haven't tried to think of a way. Maybe you can convince me why I'd want to do that? :-)
Say I gonna create DFS structure like this:
Well, it may look redundant or even ridiculous, but I think you got the idea. In this example
- both “User” and Data\Profile\Setting levels are emty links (i.e. with no targets). And I need a plenty of these!
- “JDoe” level folders are actual links WITH targets, and
- Documents\Profile\AppData level are regular file system folders on file shares.
Still not understanding the "why". As in why the GUI allowing this is good, not in why dfsutil.exe not allowing it is bad. :-)
I think I didn't get it. You want to know why I wish to create a separate folder for each user, or why I don't want to do it for every user manually using the MMC? :)
Okay, here's another example. Say one is going to create a link WITH targets. But he needs to fill the list of targets dynamically based on some conditions. E.g. to supply the actual list of fileserers as a script input instead of hard-coding them.
So it seems logical to break the operation into the following steps:
1. Create an EMPTY link.
2. Evaluate the conditions.
3. Fill the list of targets using “target add”.
Does this make sence for you? :)
I guess. But why not share things prior to creating link. The links are useless until they point to something after all. Seems to fall under the "can do in MMC" as opposed to "a good idea to do in MMC".
Okay, this way we need:
1. Evaluate the conditions.
2. Build the list of targets.
3. Take the first target from the list.
4. Execute Link add.
5. Take all the targets from the list EXCLUDING the first one.
6. Execute Target add for each of them.
Well, step 5 looks too complex to me. I wish life was much easier and I could follow easy 3-step workflow mentioned in my previos comment here :)
And I still completely disagree with “Links are useless unless they have targets”. Here's the third argument :)
I believe that it's a great idea to logically separate different groups of links WITH targets (e.g. “Projects” vs. “Divisions”) by putting them into different “Folders” (i.e. links WITHOUT targets). Something like this:
|-Projects <-- This is a “Folder” (i.e. a link with no targets)
| |-Project A <-- This is a regular link with target(s)
| |-Project B
|-Divisions <-- This is a “Folder” (i.e. a link with no targets)
Ned, I guess if you put up a paypal account on the blog you'll get enough $$$ to buy an up-to-date texture highlightning tool :)
(unless you're a über-mspaint fan)
I don't need no fancy tools!