Goatee PFE

Blog of Microsoft Premier Field Engineer Ashley McGlone featuring PowerShell scripts for Active Directory.

Goatee PFE

  • The GoateePFE Active Directory PowerShell Link Fest

    Over the years on this blog I have created a number of short links to my most popular posts. I thought it might be handy to post a greatest hits list of these short links for easy reference and sharing. Enjoy!

  • PowerShell Summit North America 2014

    I know this post is a little late, but I wanted to offer some helpful information that I picked up at the PowerShell Summit last month.  This post is packed with links to keep you surfing high-value PowerShell content for days.

  • Career Tip: The Power of a Niche

    Have you reached a plateau in your career?  Need a new challenge?  Trapped at one company?  Then build your own niche.  Differentiate yourself.

  • Three Steps to Migrate Group Policy Between Active Directory Domains or Forests Using 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.

  • Oh Snap! Active Directory Attribute Recovery With PowerShell

    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.

  • PowerShell to Find Where Your Active Directory Groups Are Used On File Shares

    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:

    • “I have no idea where it is used.”
    • “The last admin told me to never delete that group.”
    • “That is how the leprechauns get access.”
    • All of the above.

    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.

  • Using PowerShell to Find Stale and Duplicate Active Directory Groups

    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.”

    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.

  • PowerShell Saturday 007 Charlotte: From Cmdlets to Scripts to PowerShell Hero

    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.

  • Use PowerShell to Find Windows XP Computers Still Alive in Your Active Directory 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.

  • Back To The Future: Working with date data types in Active Directory PowerShell

    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.

  • DogFoodCon 2013: From Cmdlets to Scripts to PowerShell Hero: An essential session on the scripting process

    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

    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.

  • PowerShell Saturday 005 Atlanta: It's Time To Part With Blankie: Moving from command line tools to PowerShell for Active Directory

    Atlanta-bound I am drafting this post from the airplane as I make my way to Atlanta, Georgia USA for PowerShell Saturday 005 . I am looking forward to spending the weekend with folks who share my passion for PowerShell. I’ll get to reconnect...
  • PowerShell Active Directory Schema Report

    Last year I published a script on the Hey Scripting Guy blog to review the AD schema. This comes in handy when you want a report on the history of schema changes in your forest and the related OIDs. The script lives on the TechNet Script Gallery, and...
  • PowerShell Get-WinEvent XML Madness: Getting details from event logs

    Announcements

    Before we jump into today’s script here are some current events:

    • This blog post celebrates three years of PowerShell blogging on TechNet as GoateePFE.  It has been a great ride, and I am far from done.  See the most popular posts here.  Thank you for making this blog successful.
    • The PowerShell Deep Dives book is out now.  I contributed a chapter on Active Directory token bloat taken from my SID history blog series.  This book has a ton of great chapters by a ton of great people. All the proceeds go to Save The Children.  Buy your copy today.
    • If you haven’t had a chance to watch the Microsoft Virtual Academy recordings Getting Started with PowerShell 3.0 Jump Start and Advanced Tools & Scripting with PowerShell 3.0 Jump Start then you need to put them on your list.  Jeffrey Snover and Jason Helmick do a fantastic job of covering everything you need to know to get started with PowerShell.  Make time for this over several lunches or knock it out in a couple training days.  These videos will seriously boost your career.  You could even gather the family around with a bowl of popcorn.
    • PowerShell Saturday 005 is coming up October 26th in Atlanta, Georgia.  My session is titled It’s Time To Part With Blankie: Moving from command line tools to PowerShell for Active Directory.  If you’re in the area stop by for a good time with several PowerShell celebrities.  I’m looking forward to Ed Wilson’s session PowerShell Workflows for Mere Mortals.

    Now for today’s topic…

    XML vs. IT Pro

    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).

    Events:  The good, the bad, and the ugly

    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. 

  • Active Directory PowerShell SIDHistory Module Update 1.5

    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:

    • SID history updates in ACLs can be added instead of replaced.
    • Create SID map files for security translation without needing SID history.
    • Track down old domains after their trusts have been removed.
    • Get error logging for file server paths that fail the ACL scan.
    • Automate SID history data collection across many servers and shares.
  • Microsoft PFE Ashley McGlone Speaking for MSPSUG Virtual User Group on Tuesday, July 9th at 8:30pm CDT

    Update: Watch the one hour meeting recording on the page below. This is a video tutorial on the Active Directory PowerShell SID history module. If you follow #PowerShell on Twitter you’ve seen Mike F. Robbins . He is a superstar in the PowerShell...
  • How To Use The 2012 Active Directory PowerShell Cmdlets From Windows 7

    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.

    • Are Windows 8 and Windows Server 2012 compatible with my existing AD PowerShell scripts?
    • Can I use the Windows 8 RSAT AD module against 2008 R2 or 2003 DCs?
    • Can I use the Windows 7 RSAT AD module against 2012 DCs?

    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.

  • Dude, where’s my GPO? Using PowerShell to find all of your Group Policy links.

    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.

  • Touch-Free PowerShell DCPROMO in Windows Server 2012

    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:

    • Implementation
    • Validation
    • Back-Out

    You have all three of these scripts for DCPROMO in today’s post.

  • Active Directory OU Permissions Report: Free PowerShell Script Download

    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.

  • How to do PowerShell on your phone

    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.

  • Called Out: From 2012 to 2013

    Departing from the usual scripting today's post is a reflection on 2012 and a look ahead at goals for 2013.  The overall theme today is the Heroes To Mentors vision we have embraced within Microsoft PFE.

  • Free Download: CMD to PowerShell Guide for AD

    New Years Resolution

    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.

    It's time to part with "blankie".

    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.

  • TIP: 2 Ways userAccountControl Is Easier In AD PowerShell

    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.

  • AD PowerShell Password Reset Shortcut for Helpdesk

    Introduction

    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.

    Monday Morning on “The Desk”

    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.