Friday Mail Sack: Unintended Hilarity Edition
Hiya folks, Ned here again with another week’s questions, comments, and oddities. This time we’re talking:
- GPMC inconsistent permissions error
- ADMT multiple servers
- DFSR staging calculation performance
- USMT and MAX_PATH
- DFSR port 5722 on members
- Common AD support topics
- Other things
Let’s get it.
When we change security on our group policies using GPMC, we always get this disturbing message:
“The permissions for this GPO in the SYSVOL folder Are inconsistent with those in Active Directory”
We remove the “Read” and “Apply Group Policy” checkboxes from Authenticated Users by using the Delegation tab in GPMC, then substitute our own specific groups. The policies apply as expected with no errors even when we see this message.
It’s because you are not completely removing the Authenticated Users group. Authenticated Users does not only have “Read” and “Apply Group Policy”, it also has “List Object”, which is a “special” permission. The technique you’re using leaves Authenticated Users still ACL’ed, but with an invalid ACE of just “List”, and that’s what GPMC is sore about:
Instead of removing the two checkboxes, just remove Authenticated Users:
Better yet, don’t use the Delegation tab at all. The Security Filtering section on the main page sets the permissions for read and apply policy, which I presume is what you want. Just remove Authenticated Users and put in X. It gives you the desired resultant policy application, without any errors, and with less effort.
Delegation is designed for controlling who can manipulate policies. It only coincidentally manages who gets policies.
Is it possible to setup multiple ADMT servers and allow both the ability to migrate passwords? I know during the setup of the PES service on a source DC consumes a key file generated from the ADMT server. I wasn’t sure if this ties only allows that server the ability to perform password migrations.
You can always have multiple ADMT copies, as long as they point to the same database; that’s where things tie together, not in ADMT itself. You could use multiple databases, but then you have to keep track of what you migrated in each one and it’s a real mess, especially for computer migration, which works in multiple phases. You’d need multiple PES servers in the source domain and would have to point to the right one from the right ADMT DB instance when migrating users. This is highly discouraged and not a best practice.
I was looking at Warren’s post on figuring out how much DFSR staging space to set aside. I have millions of files, how long can I expect that PowerShell to run? I want to schedule it to go once a week or so, but not if it runs for hours and incinerates the server.
It really depends on your hardware. But for a worst case, I used one of my gross physical test “servers” (it’s really workstation-class hardware) and generated many 1KB files plus 64 1MB files to have something to pick:
- 500,000+64 files took 1 minute, 45 seconds to calculate
- 1,000,000+64 files took 3 minutes, 30 seconds to calculate
The CPU and disk hit was negligible, but the memory usage significantly climbed. I would do this off hours if that server is starved for RAM.
Can USMT migrate files that are longer in locations exceeding MAX_PATH rules of 260 characters?
Both scanstate and loadstate supports paths up to ~32,767 characters, with each “component” (file or folder name) in that path limited to 255 characters.
According to this article, Windows Server 2008 and 2008 R2 DCs use static port 5722 for DFSR. We mainly use Win2008 R2 member servers, so when choosing a port to set DFSR to, should I choose a different port within the range 49152 – 65535? Or would it be OK to set DFSR to 5722 on member servers too, so that all traffic on 5722 will be DFSR regardless of whether it's a DC or a member server involved in the replication?
Totally OK to use 5722 on members and makes your life easier on the firewall config. Make sure you review: http://blogs.technet.com/b/askds/archive/2009/07/16/configuring-dfsr-to-a-static-port-the-rest-of-the-story.aspx
What are the most common Active Directory-related support cases Microsoft gets? I’m planning some training and want to make sure I am hitting the most powerful topics.
In no particular order:
- Slow Logon (i.e. between CTRL+ALT+DEL and a working, responsive desktop)
- Group policy not applying
- Kerberos failures (duplicate/missing SPNs and bloated token)
- Domain upgrade best practices and failure (i.e. ADPREP, first new DC)
- AD replication failing (USN rollback, lingering objects, tombstone lifetime exceeded)
The above five have remained the top issues for 12 years now. Within the rest of Directory Services support, ADFS and PKI have seen the most growth in the past year.
Preemptive strike: I cannot talk about Windows 8.
The Cubs were robbed.
It’s time for IO9 2011 fall previews of science fiction and fantasy:
Is this the greatest movie ever created? Certainly one of the most insane. It’s safe for work.
Unless you work in an anthropomorphic cannibalism outreach center
And finally, from an internal email thread discussing some new support case assignment procedures:
From: a manager
To: all DS support staff at Microsoft
Subject: case assignment changes
For cases that are dispatched to the Tier 3 queue and assigned based on an incorrect support topic or no support topic listed. Engineers will do the following:
1. Set appropriate Support topic
2. Update the SR Title-with: STFU\[insert new skill here]
3. Correct support topic for assignment
4. Dispatch the case back to the queue for re-assignment
Five minutes later:
From: a manager
To: all DS support staff at Microsoft
Subject: RE: case assignment changes
Incidentally, the acronym STFU stands for “Support Topic Field Update” :-)
Have a nice weekend, folks.
Ned “the F is for Frak” Pyle