Pipe output to the clipboard using clip.exe

Quick one today, a very simple trick I learned a few days ago: if you need to copy and paste your output from the console, instead of using the markup tools built in to cmd.exe, you can simply pass your output directly to the clipboard.  No big trick needed for this; just pipe the output to clip.exe and it will be put on the clipboard, ready to be pasted wherever you need.  It's built in to the OS, so you don't need to download and install anything.

Let's say I have a list of user account I've grabbed from Active Directory and saved to the variable $users, and I need to send that list in an email.  I could enter "$users" by itself on the command line, then select and hit enter to copy.  Then I would paste the list...and find I need to strip out all of the white space this creates. It's not hard, but it can be inconvenient sometimes, especially if it's a long list.

Instead, I could just run "$users | clip.exe" and get the same effect, only without jumping through hoops, without the chance of over or under selecting, and without selecting a bunch of extra white space.

It's really that easy.  Just add " | clip.exe" to the end and it will throw the screen output into the clipboard directly instead of on to the screen, and then you can paste it normally.

Listing Forwarders for all domain DNS Servers

Anyone who's managed Active Directory long enough can tell you that one of the most (if not the most) important thing to a healthy AD is healthy DNS.  While forwarders won't likely be a huge cause for AD problems, it's still nice to make sure your servers are configured in a consistent manner, and since forwarders can be set per DNS server, you'd have to log in to each and every one to verify the settings on it.  Fortunately, PowerShell can help (but only if you're running Windows 8/Server 2012 or newer; don't worry, though, the target servers can be 2008 R2, though it does have to be Microsoft DNS (sorry, BIND users!)).

Note that if you supply the name of your domain, you should get back a list of IPs of all of your AD/DNS servers.  If this is not the case, then you likely have bigger issues with DNS to resolve first.  If you for some reason separate your AD and DNS servers, then you may have to do something else to get the list of servers.  Also note that my idea of having all forwarders be the same is not necessarily a one-size-fits-all; there are times and places when having them be different for some servers makes sense.  Even still, being able to quickly and easily document these settings could be a huge time saver, especially if you have a large environment.

Forwarders aren't the only thing you can get with Get-DNSServer; you can see just about any setting on the server with that.  I recommend firing it off by itself against a single DNS server to see what all it gives you, and you could easily modify this snippet to document just about any setting in there that you want.

EDIT 5-18-2015: I've modified the part of the script that gets the name servers and makes it actually capture the name servers and not just assume that the A records for the domain will be a full list of name servers.

Protecting all OUs from accidental deletion

If you've run the Best Practice Analyzer (or BPA) for Active Directory Domain Services (ADDS), you may get the following warning: "All OUs in this domain should be protected from accidental deletion".  Depending on the size of your domain, going through all OUs to check that could sit on your list of things you want to do somewhere between "Mindbogglingly boring and waste of time" and "SHOOT ME NOW!".  Thankfully, this, too, can be done through PowerShell:

Here's where I tell you that this makes changes to your AD environment, and while there should be no ill consequences for this one, do take proper precautions; before running it, you should also just run the first two lines by themselves (minus the last pipe) to see what you'd be changing.

Other than that, this is another really simple, fairly self-explanatory snippet.

Copy Group Policy links from one OU to another

Testing Group Policies can be a chore if you have a lot of them, especially if you need to link a long list of GPOs to one OU that are linked to another OU.  You could do this via the Group Policy Management console, but that can be time consuming, and you could wind up linking the wrong GPO or missing one if you're not careful.  So, let's script it, instead!

You will need to have the AD RSAT tools installed, and have the GroupPolicy module.  I've only tested this on Windows 8.1 with PowerShell V4, so your mileage may very (and, as this is one I've marked as "Dangerous", you absolutely should test this before using it in production, and be VERY careful: linking GPOs in the wrong place could have very bad adverse effects).

I highly recommend playing around with the output stored in $gpos; as you can see, what you want is nested fairly deeply ($gpos.gpos.gpo[*].LinksTo.SOMName).

Note that the SourceOU is the name of the OU itself, while DestinationOU is the full LDAP name.

I do very much recommend playing around with this on a test environment before going to town in production.

EDIT (2019-01-22): I didn’t spell this out, but this method will only work if the source OU name is unique on your domain. ColdPower in the comments below mentions an alternative way to get the GP links that will work with the full DN of the source OU, and will work a lot faster (especially if you have a lot of GPOs and GP links)

Someone else commented how this doesn’t copy additional properties like enabled state, permissions, etc. I didn’t approve it as the comment was rather rude and I’m not into that, so I’ll just respond up here instead. That is true, and it’s something to consider if your GP links are more complicated. I’ll again reiterate that I do very much recommend trying this on a test environment before using it in production. That includes finding and dealing with cases where the copy won’t be perfect. I didn’t share this as a heavily tested and battle tried method that should work in all circumstances. I don’t have one of those as my need for this sort of thing is very occasional and if I run into a few minor extra tweaks I need to make after, it’ll still be faster than accounting for it in the script at this point for me. I may come back and revisit this at some point in the future, if I feel up to it, and make it a much more comprehensive solution.