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.
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.
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.
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.
This post describes the exact steps to use the Active Directory PowerShell cmdlets in your 2003 environment today.
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.
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.
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.
Today I have the privilege of speaking at the second-ever PowerShell Saturday event. As a Microsoft Premier Field Engineer I get to meet many customers and help them with their Active Directory and PowerShell needs. I’ve taken some of that experience and wrapped it into a presentation called Active Directory PowerShell Notes From The Field.
The session includes these four topics:
These notes from the field come from scripting that I've done to assist customers with real-world needs. The purpose of the session is to demonstrate the power of PowerShell for automating Active Directory solutions for every-day scenarios AND to inspire you to learn PowerShell. To help with the learning part I have included several resources here for your reading pleasure.
Attached to the bottom of this post you will find a file containing the DNS sample code and a PDF of the PowerPoint presentation.
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.
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.
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.
My last post on getting started with Active Directory was so popular that I thought I would do one for getting started with Group Policy. Once again this link list will satisfy everyone from beginner to advanced. I know there are many other third party resources and books, but I want to surface some Microsoft white papers and articles that may not always be obvious. Enjoy!
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.
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?
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.
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.
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.
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.
Today we are diving into PowerShell remoting to understand five different methods for commanding our army of minions. We will also examine the protocols and requirements under the hood so we know exactly what we are getting. The information below comes from some testing in my home lab where I captured network traces of each remoting technology to see the ports, protocols, and protections employed between two Windows Server 2008 R2 member servers.