Summary Most Active Directory object types have hundreds, if not thousands, of attributes. It's obviously not reasonable to put them all in the GUI, and even though Microsoft did everyone a favor by introducing the Attribute Editor tab in Server 2008, that doesn't help those looking to manage access to those attributes in the Advanced Security section. Yes, the security assignment can be done via PowerShell, but I often encounter users who aren't familiar with its syntax/output, and a screenshot showing checkboxes is far more useful than trying to explain a block of PowerShell text. There are ways to display attributes via Active Directory Users and Computers (ADUC) by modifying the schema, but customizing the schema is bad (mmkay?), and we're more concerned with displaying these attributes in the Advanced Security list than on reporting the values in them. Thankfully, we can accomplish this on a per-client basis without affecting the directory itself: the dssec.dat

Summary A significant portion of being a good systems administrator is knowing how to accomplish tasks without doing more than is required. Maybe the best example of this is granting access to resources in Active Directory. When a user or team needs access to something in the directory, the beginner/bad sysadmin will take the easy way out, probably by using a default role like Account Operators or granting full control over the OU where the resources reside. After a while, you'll start seeing users in places where only groups should be or realize you've given someone the ability to reset the passwords on your elevated or production service accounts when you only wanted them to be able to unlock standard users. I'm not overstating things when I say the ACLs below are the basis for my entire directory design. AD's ability to grant permissions on a per-attribute level is what makes things like the separation of resources, the deployment of a proper role-based security

Summary Several things suck about Microsoft's DNS implentation, but the top two for me have to be security and backups. I don't know how many times I've had to explain to a team that I was not going to give them access to the DNS MMC snap-in because it would mean dozens or hundreds of Deny ACLs on zones in that environment. But that's another post. This post is about DNS backups. After experiencing the kind of event that causes one to review one's DNS backup plan, I found there wasn't a tidy way to back up AD-integrated zones like the options for AD, DHCP, and other infrastructure services. I started with a 36-line .bat file that required modification and an individual scheduled task for each zone that needed to be backed up. With the advent of the basic DNS cmdlets in Server 2008 R2, I moved on to an unholy combination of a PowerShell script that gathered zone info and called my old script in a loop. Not efficient, but it only needed one scheduled task.

If you're in IT, you've been there: something is broken/not working, and you've exhausted both your knowledge and your internal documentation (if you have any). So you start searching, scouring the web for any clue that might make some part of the puzzle fall in place or at least change the error code. Over my 15+ years in the industry, I've found personal blogs to be the most useful resources in these situations, mostly because they're written by peers who have no style guidelines or forced biases toward/against certain companies or technologies. I've benefited enough from these kind people that I feel I need to start giving back. Everything I write here will have roots in an actual issue/build I've experienced, so I hope it will eventually become a useful repository. So the goal of this blog is to help people, either by aiding to fix a problem or giving them knowledge that will help them avoid problems. It should go without saying, but I feel like I ha