Active Directory replication failures are like a leaking water pipe in your wall. You don’t notice anything at first, but by the time you do, there is significant damage. It’s probably not altogether difficult to “repair” AD at this point and stop the "leak", but the damage remains. Monitoring Active Directory replication is essential to catching the little problems before they become major. It all starts with AD object inconsistencies between domain controllers.
Azure & Active Directory Center
ENow Software's Azure & Active Directory blog built by Microsoft MVPs for IT/Sys Admins.
Powershell functions can be created as advanced functions. These functions behave very similarly to built-in Powershell cmdlets. Because I can't do without the ability to add a -Verbose or -Debug parameter to my functions now nowadays, these are the only kind of functions I build. Advanced functions, just like "dumb" functions, have parameters. The parameters are the values that are passed into the function from your script.
Once a business begins to use Active Directory more and more, depending on how large the organization is, objects have the tendency to become "stale." Every employee typically has an Active Directory user account. They are assigned one the day they are hired. At the same time, if they received a computer, that computer was probably joined to the Active Directory domain. Now, let's say they were assigned to a personal printer and they need to share that printer with “Bob” down the hall. “Susie's” printer could now go into Active Directory. What about Susie's computer's DNS record? Many companies choose to integrate DNS with Active Directory as well which is yet another object in Active Directory! You get the point.
Now that you've got an understanding of Powershell's advanced functions and the ValidateSet() parameter validation method in the first part of this blog, “Validating Powershell Advanced Function Parameters” you can begin Part #2 of this small post series. Part 2 of this series goes deeper by demonstrating how to dynamically create your sets for ValidateSet() so they aren't hardcoded in. This is essential when dealing with values that may constantly change or even if you just want to practice writing good scripting and have no static references.
So now that I've dazzled you with the magic tab-completion of parameter attributes with ValidateSet() in my last post let's take it one step farther. In that simple instance, I only had 2 values to filter on; True and False. Simply typing them out is easy enough but what if the values you'd like to use aren't so cut and dry? Let me give you another real-world example I just finished today.
I had a need to create a function around the Set-Acl cmdlet. I needed the ability to easily change permissions on files and folders. I found a great example but I needed to set permissions on a ton of files/folders. Also, I really didn't want to have to remember the entire the 4 lines it took to get this done so I decided to create an advanced function to help me out. In my new function I just wanted to type Set-MyFileSystemAcl and add a few parameters like the username and what kind of access I'd like that username to have.
Want to learn more about Active Directory?
Active Directory Administration Cookbook, 2nd Edition
In this book, Microsoft MVP & Technical Editor of ENow's Azure & Active Directory Center, Sander Berkouwer will share the intricacies of managing Azure AD, Azure AD Connect as well as Active Directory for administration in the cloud and on Windows Server 2022.