Hello Earthlings, Ned here again with this week’s interesting conversations within Microsoft DS support. Today we talk DFSR, ILM, DFSN + VPNs, DNS, group expansion, Applocker, and friggin’ huge files.

OG OG OG!

Question

I am running dsget.exe –user –memberof –expand on some new Windows Server 2008 R2 DC’s. It seems to be running very slowly in my very large domain. Win2003 has no issues doing the same exact commands.

Answer

Buggity. Grab this:

980254  The "dsget user -memberof -expand" command returns incorrect results in Windows Server 2008 R2 and in Windows 7
http://support.microsoft.com/default.aspx?scid=kb;EN-US;980254

The bug makes it return all users and groups, no matter if they were related to your query. The “very large domain” made that slow.

Question

I am considering using DFSR on Windows Server 2008/R2 to replicate some really huge files – hundreds of GB. I know that this isn’t supported [the supported limit is 64GB – Ned]  but will it work? Some early testing shows that just copying these giant files manually with robocopy is faster than DFSR.

Answer

There’s a good reason not to go that large on files in DFSR: DFSR has a default RPC context inactivity timeout setting of 30 minutes. If replication of a file is  “inactive” in RPC after that 30 minutes, the session is torn down and DFSR starts over. Which means it may never finish if the file is big enough and the network is small enough. In Win2008/R2 you can modify this timeout to wait as long as 4 hours, by setting:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\Settings
RpcContextHandleTimeoutMs=14400000

(This is a DWORD value and the number should be entered in decimal, not hex; it’s in milliseconds)

But how could the session be inactive, you ask? Because the DFSR’s RPC worker is considering the period where RDC signatures are generated to be part of the timer – many minutes or even hours might be spent on creating all the RDC signatures, and in the meantime DFSR will keep resetting itself. If you want to see how long signatures took on a ginormous file, examine for this:

20090924 13:42:51.421 2616 RDCX   467 StreamToIndex RDC generate begin: (0..6), uid:{01F12108-393C-49B3-835B-4B1214755EAF}-v20 gvsn:{01F12108-393C-49B3-835B-4B1214755EAF}-v34 fileName:D_SEBLDWIN7BLD22.vhd csId:{B1758DF8-51F6-4BB1-B5D7-A7256BF88CD1}
20090924 16:16:09.880 2616 RDCX   509 StreamToIndex RDC generate end: (0..6), uid:{01F12108-393C-49B3-835B-4B1214755EAF}-v20 gvsn:{01F12108-393C-49B3-835B-4B1214755EAF}-v34 fileName:D_SEBLDWIN7BLD22.vhd csId:{B1758DF8-51F6-4BB1-B5D7-A7256BF88CD1}

That was a 240GB file and it took roughly 1.5 hours. Yeowza.

As a side note, robocopy is not the fastest way to copy these huge files either. You can use tools that send data as unbuffered I/O which will make very large files fly over a network. In fact you have to be careful as you will quickly reach true network saturation (even in 1Gbps LAN’s) with these tools. Some Microsoft options would be ESEUTIL.EXE /Y and XCOPY.EXE /J (starting in Windows 7 and R2).

Let me also take a moment to get on my soapbox around DFSR and file copy speeds with a “30 second SME rant”:

It is a common misapprehension that DFSR is designed to be faster than raw file copying. It is not. It is designed to be very resilient on high loss/error prone networks and be very efficient on low bandwidth networks, all while keeping files in sync with loose convergence in a multi-master topology. On a LAN it will underperform compared to just copying files around with robocopy or xcopy. On a WAN with poor bandwidth and files using RDC/cross-file RDC it will greatly outperform file copy tools. Within a LAN you will see some performance improvements turning off RDC on those connections as it will be faster to stage and copy the files without RDC signature computation or cross-file sparse file computation. But it will never, ever be faster than just copying some specific files by hand when doing a simple raw file and no RDC on a LAN. That’s not what it was designed to do. The same way that robocopy and xcopy were not designed to replicate 60KB of a 2GB file that was just modified, saving 99.997% of bandwidth used, all automatically between 1000 servers.

If you just want to sync two computers on a LAN, robocopy /mot /mir <etc> is a faster solution. There are also a hundred other free and vendor tools out there. DFSR is a branch office product, not a shared disk cluster. If you have gigabit LAN connectivity, using DFSR is sometimes the wrong solution. Don’t try to make it be everything in your main office.

/end rantsmission

Question

I’ve run into issues where VPN users stop being able to connect to DFS paths, they get “The network path was not found”. They can ping the servers without issues.

Answer

One thing we have seen with VPN clients is cached credentials causing issues. You can see by logging on as that test user and running this in a CMD prompt:

CMDKEY.EXE /LIST

If there are cached creds, you can use CMDKEY.EXE /DELETE to remove them individually or flush the cache and disable it with:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
Value Name: disabledomaincreds
Value Type: REG_DWORD
Value: 0

(And reboot; this is just for testing to isolate the issue, but some folks leave it like this forever to avoid any possibility of the issue happening.)

At some point the user saved mapped drive credentials in there with an old password and there those creds have remained, unable to be updated thanks to the lack of frequent network access that lead you to use a VPN in the first place. Bleh. Go use DirectAccess, VPN’s are gross.

Question

I have an ILM question around---

Answer

Stop right there bub! Despite the fact that AD and ILM/FIM are both identity products, the latter is supported by a different group. They haven’t gotten an official blog off the ground, but there are some good sites here:

http://blogs.technet.com/b/doittoit
http://blogs.msdn.com/b/imex
http://blogs.technet.com/b/shawnrab

And forums are here:

http://social.technet.microsoft.com/Forums/en-US/identitylifecyclemanager/threads

And you can open a support case too, naturally.

Question

I’m using a third party monitoring tool that states that my _msdcs zone has an SRV record for a global catalog that does not correspond with any of the known global catalogs that serve the forest. I've looked up the GC SRV records in the root domain and found a pretty long list (the forest contains 100 global catalogs). Unfortunately my tool doesn’t state which SRV record appears to be stale.

How can I get a list of all the GC SRV records and compare them to my list of GC’s?

Answer

To figure this out, I’d:

1.    Dump out that list of all the GC SRV records using DNSCMD.EXE /ZoneExport <zonename> <somefile>.
2.    Then I would dump out a list of all the DC’s in the forest (lots of ways to do this; for example, in DSA.MSC can just right click on the Domain Controllers OU in each domain and choose Export. Could also use a variety of command-line tools, AD PowerShell, joeware, etc).
3.    Then I would drop both of those lists into their own columns in Excel, and I’m left with all the servers in DNS and in AD. I can sort and easily see the differences of any missing or extra records.

Long term, you should ask the vendor to alter this monitor so that it returns the record(s) that tripped its rule. A monitoring tool should never raise more questions than it answers.

Question

I’ve been using AppLocker to control which programs my users can run on some terminal servers. I just found that one of the applications I need to allow/block is an MMC snap-in not included in Windows. I can’t just block/allow MMC.EXE, some of the other snap-ins get used by everyone. What can I do here?

Answer

Group policy supports allowing and restricting snap-ins, but only a specific set that are included in the OS. You can use this to your advantage here.

1. For all non-“special snap-in” users, you could configure this GP:

User Configuration->Administrative Templates->Windows Components->Microsoft Management Console
Restrict Users to the explicitly permitted list of snapins = ENABLED

2. Then for those same large population of users, you could configure the list of any snap-ins you want them to be able to load, and the rest will be implicitly denied (including the third party one; most standard users do not need to access many snap-ins, they are mainly for admin usage). To add those exceptions for your users, you would modify here as needed:

User Configuration->Administrative Templates->Windows Components->Microsoft Management Console -> Restricted/Permitted Snapins
<all the goo in here>

Here I turned on the restriction. When I try to run this ‘3rd party’ snap-in that’s not in my list, I get:

Nice.

Mike O’Reilly took umbrage with my iceberg comments last week. Not because it wasn’t true, but because he’s sad over the limited amount of Newfoundland iceberg vodka made this year. I bet it goes great with Jiggs dinner, fish and brewis, and seal flipper pie. Newfoundland’s motto: “All of our cuisine is based on a drunken bet.”

Finally, this is what happens when you leave a nice vegetable tray out for a minute in my house. Note how the ranch dressing container appears to have been professionally cleaned. Also note how the healthy veggie bits were left completely unmolested.

It’s a mystery…

Have a great weekend

- Ned “Hidden Valley” Pyle