Windows administrator’s PowerShell script kit
August 28, 2016
The Windows GUI is the traditional way to perform administrative tasks, but scripting offers faster and more versatile methods that can help further your technical skills. This download includes 21 publicly available PowerShell scripts, along with a document explaining each one, to help you up your scripting game and administer your AD environment more efficiently.
From the download:
To assist Windows administrators with repetitive or mundane tasks, Microsoft developed a scripting language called PowerShell many years ago. Built upon the .NET framework, PowerShell lets you run the same tasks as the GUI, but with better controls and the capability of scheduling tasks or performing automation-related functions. It can also provide customized information and find things more rapidly than hunting through the GUI.
The power of scripting can work for both good and bad, of course. An improperly written or executed script can wreak havoc, perhaps by deleting ALL users from a domain instead of just one. It’s also a bad idea to code passwords into a script or any other confidential data, which if leaked, might harm your company’s reputation or environment.
To introduce you to PowerShell–or further your existing knowledge base–we have collected 21 PowerShell scripts for common AD tasks, like creating accounts, checking for account lockouts, and finding domain administrators.
The scripts provided with this document are not original–most were made public by their authors, to whom full credit at the top of each script file is given where applicable (some scripts were the result of simple trial and error by our staff). The purpose of this guide is to showcase the scripts and explain how they can be valuable to you. If you like the scripts, we highly recommend you check out the corresponding author webpages (if applicable) for other content that may be of use.
These scripts are safe to run and modify so long as you are confident in your understanding of how the changes will work. A test Active Directory domain is always a good idea and can be set up in a virtual environment, separate from your production environment.