Use PowerShell to Create a New Active Directory Forest on Windows 2019 Server Core Installation (no-GUI)

You have a fresh installation of Windows Server 2019 that was installed using the default installation type of server core installation (no-GUI). This server will be the first domain controller in a brand new Active Directory forest. You’ve completed the following configuration prior to attempting to turn this server into a domain controller: Install all the available Windows Updates Set the time zone Set the computer name Set a static IP address Log into the server and launch PowerShell by typing powershell.

What’s the Recommended Editor for PowerShell Scripts?

You’ve probably heard, as I have, that Visual Studio Code (VSCode) is the latest whiz-bang editor that you should be using for PowerShell (and I am for development of PowerShell code on my primary workstation). One word of caution though is to make sure to put things into perspective and not be so quick to shun people away from using the PowerShell Integrated Scripting Environment (ISE), depending on how they’re using it.

Managing the Hyper-V Default Switch in Windows 10 version 1709 and higher with PowerShell

Windows 10 version 1709 introduced a default Hyper-V virtual switch which is installed when the Hyper-V role is added. As you can see in the following example, by default on Windows 10, the default virtual switch does not exist because the Hyper-V role hasn’t been added. Get-NetAdapter Now that the Hyper-V role has been added, you can see that a new network adapter named “vEthernet (Default Switch)” exists. Get-NetAdapter | Format-Table -AutoSize While you wouldn’t think this would be a problem, I’ve seen some latency problems on the host operating system once this default switch is added.

PowerShell Script Module Design: Building Tools to Automate the Process

As I previously mentioned a little over a month ago in my blog article PowerShell Script Module Design Philosophy, I’m transitioning my module build process to a non-monolithic design in development and a monolithic design for production to take advantage of the best of both worlds. Be sure to read the previously referenced blog article for more details on the subject. My goal is to write a reusable tool to retrieve the necessary information from a non-monolithic script module that’s necessary to create a monolithic version of the same module.

Learn about the PowerShell Abstract Syntax Tree (AST) – Part 3

This blog article is the third in a series of learning about the PowerShell Abstract Syntax Tree (AST). Be sure to read the other two if you haven’t already. Learning about the PowerShell Abstract Syntax Tree (AST) Learn about the PowerShell Abstract Syntax Tree (AST) – Part 2 Learn about the PowerShell Abstract Syntax Tree (AST) – Part 3 In this blog article, I’ll be specifically focusing on finding the AST recursively.

Learn about the PowerShell Abstract Syntax Tree (AST) – Part 2

In my previous blog article a few weeks ago on Learning about the PowerShell Abstract Syntax Tree (AST), I mentioned there was an easier way to retrieve the AST so that you didn’t have to cast everything to a script block. There are two .NET static methods, ParseFile and ParseInput, that are part of the Parser Class in the System.Management.Automation.Language namespace which can be used to retrieve the AST. First, I’ll store the content of one of my functions in a variable.

Use PowerShell to Monitor IIS Websites and Application Pools

I recently received a request to write a script for monitoring IIS websites and their application pools on a specific Windows 2012 R2 server and start them if they were stopped. This is something I created fairly quickly and thought I would share. I always try to centralize any scripts I write and have them run on a job server instead of the actual server they’re querying. That way I don’t have multiple versions of the same script floating around on different servers.

Use PowerShell to Install the Remote Server Administration Tools (RSAT) on Windows 10 version 1809

My computer recently updated to Windows 10 version 1809 and as with all previous major updates of Windows 10, this wipes out the Remote Server Administration Tools (RSAT). However, unlike previous versions, Microsoft has now made RSAT available via Features on Demand and while you’re supposed to be able to install them from the GUI, they never showed up as being an option for me. That’s not really a problem though since they can now be installed via PowerShell.

Learning about the PowerShell Abstract Syntax Tree (AST)

This week, I’ll continue where I left off in my previous blog article PowerShell Script Module Design Philosophy. Moving forward, the development versions of my PowerShell script modules will use a non-monolithic design where each function is dot-sourced from the PSM1 file. When I move them to production, I’ll convert them to using a monolithic design where all functions reside in the PSM1 file. In development, each PS1 file uses a Requires statement which specifies the requirements from a PowerShell version and required modules standpoint.

PowerShell Script Module Design Philosophy

Years ago, when I first learned how to create PowerShell script modules, I built them with all the functions in one huge monolithic PSM1 file. I like the monolithic script module design from a performance and security standpoint along with the ease of signing fewer files if you’re taking advantage of code signing to digitally sign your scripts and modules (there are fewer files to sign). What I don’t like is that collaborating with others using one huge file is a merge conflict waiting for a place to happen and if someone only wants one of my functions instead of the entire module, they’re out of luck unless they want to copy and paste it.

PowerShell Script Module Design: Don’t Use Asterisks (*) in your Module Manifest

Using asterisks (*) in your module manifest is a bad idea no matter how you look at it. First, your module will be slower because it will have to figure out what to export. More importantly, if you use a “#Requires -Modules” statement in your functions and they’re in separate PS1 files, all of the specified module’s commands will show as being part of your module. I’ll pick up where I left off in one of my previous blog articles PowerShell Script Module Design: Plaster Template for Creating Modules.

Indentation and Formatting Style for PowerShell Code

My preferred indentation style when writing PowerShell code is Stroustrup style because I don’t like my code to cuddle (there’s no cuddled else in Stroustrup style). I occasionally hear from others that they don’t like this style because it doesn’t work from the PowerShell console. if ($plasterParams.Git) { $ModulePath = "$($plasterParams.DestinationPath)\$($plasterParams.GitRepoName)\$($plasterParams.Name)" } else { $ModulePath = "$($plasterParams.DestinationPath)\$($plasterParams.Name)" } While it doesn’t work by default, there’s a trick to making that style work from the PowerShell console.

PowerShell Script Module Design: Plaster Template for Creating Modules

I recently began updating my PowerShell script module build process. Updating my Plaster template was one of the first things I needed to do. If you haven’t already read my blog article about Using Plaster to create a PowerShell Script Module template, I’d recommend beginning there as this blog article assumes you already have a basic understanding of how to use Plaster. All of the information from my previous Plaster template is still there with the exception of the required PowerShell version as I plan to obtain that information and update it a different way.

PowerShell Script Module Design: Public/Private versus Functions/Internal folders for Functions

There’s been a lot of debate about script module design as of lately and instead of tweeting something out asking for responses, I thought I would post it here via a blog article. Back when I first started creating PowerShell script modules, I placed all of my functions in the PSM1 file and later started placing each function in a separate PS1 file that was dot-sourced from the PSM1 file.

Determine the Day of the Week in 11 Days from Now with PowerShell

A couple of days ago, one of my kids asked me “What day of the week will it be in 11 days from now?”. My response was “I’m not sure, but I can tell you how to figure out the answer for yourself”. Open up PowerShell, wrap Get-Date in parentheses, place a dot or period afterwards, followed by AddDays, then 11 in another set of parentheses, and finally another dot or period followed by DayOfWeek.

Determine if a Mailbox is On-Premises or in Office 365 with PowerShell

One of the companies that I support is currently in the process of migrating from an on-premises Exchange Server environment to Office 365. They’re currently running in hybrid mode. While it seems like wanting to know what mailboxes still exist onsite versus which ones are in the cloud would be an all too common task, there doesn’t seem to be an easy way to get that information with PowerShell. You would think that you’d be able to run a PowerShell command and it would return the results.