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.
This post describes the exact steps to use the Active Directory PowerShell cmdlets in your 2003 environment today.
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.
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.
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.
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.
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?
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.
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.
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.
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.
Tired of copying and pasting scripts from the internet? Want to write your own scripts? Become the go-to scripter on your team. This session will break down the scripting process into logical steps you can follow. Learn how to wrap cmdlets into scripts into functions into modules that you can reuse and share with your team.
Even Spiderman would envy this web action. Today we're going to walk through setting up a portable PowerShell v3 Web Access demo. Using this demo guide you can explore PowerShell from any web-capable device: your phone, your tablet, or your Raspberry Pi. The links in this post will guide you to all of the key documentation to build your own PowerShell Web Access lab.
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:
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.
Hi folks. It's your friendly, neighborhood PFE again. In order to avoid the long lines to buy a treadmill the first week of January I thought I would save you some time and give you an easier New Years Resolution… Learn PowerShell.
For years many of us have relied on trusty command line utilities like PING, IPCONFIG, and REPADMIN. Some of us are still hanging on to those instead of embracing the brave new world of PowerShell.
In an effort to assist with the transition and to introduce some of the cool new cmdlets in PowerShell v3 I have created a free reference guide showing how the old meets the new. For example, instead of PING try the PowerShell cmdlet Test-Connection, instead of NSLOOKUP use Resolve-DNSName, instead of GPUPDATE use Invoke-GPUpdate.
The guide attached at the bottom of this blog post contains four packed pages of PowerShell pleasure for your perusing.
After speaking about SID history and token size at PowerShell Saturday last month an attendee approached me with a common concern. I was so excited to code the answer that I did it in the airport on the way home.
Joe User has been with the company for 23 years and has accumulated more group memberships than the entire desktop support team. Joe has rotated through five different departments during his career and managed to survive all of the layoffs. As a result he has access to every share in the company. Even worse his access token is so big that it won’t fit through the door.
We would love to clean up his group memberships, but we have no way of knowing when he was added to all these groups. If we could see the dates he joined those groups it would give us a clue about removing just the older group memberships. Without this information his token will continue to bloat.
Time for some AD PowerShell v3 goodness!
PS - I'm also going to give you a handy chart showing PowerShell equivalents for REPADMIN in AD PowerShell v3.
Now most people don't plan to spend their entire career on the help desk. It is a starting point for bigger things in IT. PowerShell can be your career LAUNCH PAD. Seriously. PowerShell skills will differentiate you from your peers and slingshot you to the front of the pack.
What if you could get all of the data you needed to close a ticket in seconds?
Give a man a script; feed him for a Get-Date. Teach a man to script; feed him for a New-TimeSpan.
Lao Tzu, 4th century BC
Lao Tzu, 4th century BC
Tired of copying and pasting scripts from the internet? Want to write your own scripts? Become the go-to scripter on your team. This post will break down the scripting process into logical steps you can follow. Learn how to wrap cmdlets into scripts into functions into modules that you can reuse and share with your team.
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.
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.
Many companies have upgraded bandwidth without updating AD replication topology. Today's post features PowerShell one-liners to report on your AD site links and then tweak them for high performance.