This post is part four in the "PowerShell: SID Walker, Texas Ranger" series on documenting and remediating SID history in your AD forest. In today's post we will look at the final step of remediating SID history: removing the SID history data from our migrated AD objects using PowerShell. Cleaning up this stale data will greatly reduce the chance of token size issues for your users.
Usually I like to offer deep technical content on the blog, but today I’m going to keep it simple. Everyone should be keenly aware that Windows XP support officially ends on April 8, 2014. Many companies are migrating from Windows XP and need a quick script to check their progress. This is a simple solution with a couple variations to meet your needs.
In Active Directory we need to know who has the keys to our organizational units (OUs), the place where our users and computers live. Over the years OUs have grown to meet needs. Different teams may have been delegated access for managing users, groups, and computers. Then you come along as the new administrator. You probably have no idea where permissions have been granted to your OUs. And the scary thing is… neither does anyone else. I know, because I’ve been there. I hear the same thing from our customers.
Out-of-the-box we do not have a specific tool to report all of the OU permissions. You have to click each OU and view the security tab one-by-one, and we all know that is entirely impractical. Today’s post contains a free script download to generate a report of this vital information.
I would advise all Active Directory shops to review this report on a quarterly basis to make sure there are no surprise administrators lurking in your domain.
Before we jump into today’s script here are some current events:
Now for today’s topic…
Maybe I haven’t looked hard enough, but I’ve just not found any clear documentation aimed at IT Pros for what I am posting today. As an IT Pro type guy (not a .NET type guy) I have avoided XML for years. CSV and HTML are so much easier. XML seems to be a labyrinth of complexity in my mind, and it still is, at least from a PowerShell perspective. The object model is convenient, but trying to navigate it loses me. Yeah, I know XML makes the world a happy place, but I’m just not there yet.
Despite this disparaging disclaimer I believe I have drafted a script that will help many of us IT Pros as we weed through event logs (or ETL trace files or EVTX files).
The good: PowerShell works with event logs out of the box. You have two cmdlets: Get-EventLog and Get-WinEvent. Get-WinEvent is the one we’re all supposed to use now.
The bad: All of a sudden reading event logs gets complicated. The filtering in particular requires some crazy syntax. We are far removed from the simplicity of DUMPEL. PowerShell team blog posts from 2009 here and here attempt to make this look routine. Um… yeah.
The ugly: All of the juicy nuggets of event data in the message body are stored in XML. And nearly every combination of event ID and provider has a unique event schema for storing the data we want. Neo’s MSDN blog post gets us most of the way there. AskDS and Hey Scripting Guy show how we can use the GUI to help write the XML filter syntax. Now my head is spinning. This is the farthest point from intuitive. Don’t even get me started on XPATH.
Note: In all fairness to the product this data structure is necessary. All events have a few common properties like provider, ID number, date/time, source, etc. But in order to capture the unique details of each event we needed a way to store a variable number of properties. So the design is good, just a bit complicated to script.
In the life of every scripter you will come to challenges like this. You just have to cowboy up and dive in.
The thing I’ve not seen in these blog posts is how to dump out the event message data in a CSV file where I can easily report and manipulate the data I need. For example, if I’m collecting logon failure event 4625, then I want the guts of the message body in separate columns where I can easily summarize and report on the user and computer accounts involved. While I can harvest event logs from multiple servers in the GUI, it is just not friendly for mass reporting, sorting and visualization like Excel. This is the problem I am trying to solve.
This post describes the exact steps to use the Active Directory PowerShell cmdlets in your 2003 environment today.
Today we will address the token size SID history scenario with a PowerShell script that documents the extent of SID history in your environment and creates a SID mapping file for use with the ADMT to migrate security resources to the new SIDs.
Get-GPOReport from the Group Policy PowerShell module can report all GPOs, but it can be a bit overwhelming. What if you want a simple spreadsheet listing of the same information? This script gives you a thorough CSV report of all GPO links, where enforced, where blocked, and more. If you support group policy, then this script is guaranteed to please.
Today we have several domain controller operating systems that support the Active Directory module cmdlets. Clients on Windows 7 and 8 can install the Remote Server Administration Tools (RSAT) to script with the Active Directory module against these DCs.
With all of these versions now the first question that comes to mind is compatibility.
The Windows Server 2012 Active Directory PowerShell module has some handy new cmdlets. However, many IT shops struggle to stay current on the latest operating system releases due to a variety of issues (budget, resources, compatibility, etc.). They desperately want to use the latest features, but their deployment standards have not caught up yet. This leaves them with workable, but sometimes inefficient, tools from previous releases.
Today’s article will show you how to use the latest Windows Server PowerShell modules in a legacy Windows 7 environment. As a bonus we’ll explore compatibility of the AD cmdlets across the different operating systems.
Today I am releasing updated functionality in the PowerShell Active Directory SID History module. New features include: inventory SID history in share permissions, new Access database reporting template, bug fixes, and more!
As a Microsoft Premier Field Engineer I frequently get asked for more information on Active Directory topics. Most of the time I end up passing along one or more of the links in today's post. This list will be extremely valuable for anyone who wants to get started with Active Directory or even for a seasoned AD admin who wants to go deeper.
Have you ever needed to copy data between attributes in Active Directory? Maybe you need to copy an ExtensionAttribute value into a different ExtensionAttribute. Maybe you need to copy email, UPN, or SIP addresses. You may even want to move the EmployeeNumber value into the EmployeeID attribute instead. What if you needed to create a new Description based on a combination from other attributes?
Today's post gives you a script to crawl your file shares and document the AD users and groups referenced in NTFS permissions. I’m sure others have published similar scripts, but I want to approach it from the angle of Active Directory group cleanup. Using this output together with the script from my last post will give you plenty of insight to go after stale groups.
Finish this familiar quote, “I can’t delete that group, because ______________ .” Multiple choice:
What would we do without file shares? Well, actually, we would use SharePoint or OneDrive. The truth is file shares have been around for decades, and in most cases mission critical data resides there. But who can access that data? That is the big question, and many of us cannot give a complete answer.
Today's post will help you clean up site link descriptions and give you some nice reporting capability. Some folks like to set their site link description field to list each of the member sites in the link. If that is you, then you'll love this script. Today's script enumerates all of the member sites in a site link and then concatenates their names into the description of the site link. Also, it will make a note in the description for any site links that have change notification enabled. Now that's handy! There is also a bonus site reporting script in the download attached.
I have often told customers…
“Most companies clean up stale users, a few companies clean up stale computers, but no one cleans up stale groups.”
“Most companies clean up stale users, a few companies clean up stale computers, but no one cleans up stale groups.”
Generally it is easy enough to tell if a computer or user account is stale, but how do we do that for groups? Today’s post is going to give you some reports to analyze group staleness, population, and duplication.
Have you ever had to repopulate a batch of corrupted attributes or properties for a large set of Active Directory objects? (Think Exchange or Lync, for example.) The Active Directory Recycle Bin is great for recovering deleted objects, but it will not help with corrupted objects. Authoritative restore is the textbook option, but there is a better way. Yes, you can buy expensive third-party products to do this, or you can use the free features in the box for your own attribute-level recovery solution for Active Directory. This blog post will explain how.
Back in May I released a post on the Hey Scripting Guy blog showing how to create a shortcut to unlock a user account with a PowerShell desktop shortcut. That post was very popular, and the comments evolved into another shortcut to reset passwords. Due to the popularity and utility of the idea I decided it deserved its own blog post. I’ve also learned a little more about the Set-ADAccountPassword cmdlet to simplify my previous code.
You know the drill. It’s Monday morning. Last Friday 47 users decided it was a good idea to change their password before the weekend. It’s Monday. They forgot, just like I would. Personally I never change my password on a Friday for this reason. I need a couple days to use it before the weekend.
What could make this worse? Holiday weekends… like US Thanksgiving. (grin) Now it’s been at least five days since I reset that password. There’s no chance I’ll remember it unless it’s written down on that sticky note under the mouse pad.
Now all 47 of those users must call the helpdesk first thing Monday before they can begin another week of productivity for the company. The self-service password project has not gotten enough budget or resources for implementation, and until it does every Monday morning is going to look very familiar. That’s where we come in with PowerShell.
Have you ever wanted to copy all of your production Group Policy Objects (GPOs) into a lab for testing? Do you have to copy GPOs between domains or forests? Do you need to migrate them to another environment due to an acquisition, merger, or divestiture? These are common problems for many administrators.
There are VBScripts provided with the Group Policy Management Console (GPMC), but that is so "last decade". (Really. They were published in 2002.) What about WMI filters, OU links, login scripts, and embedded credentials? I’ve drafted a PowerShell module to do this with speed and style. This post discusses the pitfalls, preparations, and scripts for a successful GPO migration.
The very same day I posted the SID history script I found a shorter way to do it. I'm calling a "do over". When you display a list of object properties sometimes one of those properties contains multiple entries in an array or object collection. In order to expand those multiple values into single rows we pipe the output to Select-Object -ExpandProperty.
Do you schedule DCPROMO activities for the weekend? After hours? Middle of the night? I remember those days. Often it was hard to get in the right frame of mind to think through all of the exact procedural steps during those late night change controls.
Today’s post will show you how to easily promote and demote a Windows Server 2012 domain controller remotely with a script. You don’t even need to logon to the target server.
Generally change controls have three plans:
You have all three of these scripts for DCPROMO in today’s post.
Do you remember SIDWALK? This resource kit utility was written back in the NT 4.0 days to assist with domain migrations. It used a mapping file to rewrite old SIDs with new SIDs across ACLs. That utility is a teenager now. It's time we rewrite it... in PowerShell. In part one of this series we will learn how to parse SIDs out of SDDL that we receive from Get-ACL.
Set your watch for January 1, 1601, Marty. Today we’re working with crazy dates in Active Directory PowerShell.
If you have ever tried to script out Active Directory reports that included date fields, then you have likely run into this challenge. There are “real” dates, and then “those” dates. You know… the ones that just look like a bunch of numbers. Today’s post shows you how to make sense of those crazy Int64 date fields.
TIP: Anyone who wants to write scripts for Active Directory will eventually run into the famous userAccountControl attribute. The good news is that in PowerShell we have two cmdlets that make this easy: Set-ADAccountControl and Search-ADAccount.
This post is the fifth in the "SID Walker, Texas Ranger" series on SID history remediation with PowerShell. Today we're wrapping up with a handy summary of each post in the series. We will also take the function library we've been using and upgrade it to a PowerShell module. Then we'll walk through the entire SID history remediation process using the provided cmdlets in this module.
I would like to thank everyone who has been using the Active Directory SIDHistory PowerShell module and sending me feedback. Your input helps guide future releases like the one I am publishing today.
I’ve been sitting on some updates for a while, because I prefer to release code that has been field-tested. I also wanted to time this release with the upcoming PowerShell Deep Dives book where I have a chapter discussing the origins of this module. The last update was version 1.4 in June of 2012. This is update 1.5 in July of 2013.
Summary of Changes
I am excited to announce the following key improvements in this release: