Tech through the eyes of a Young Professional

Category Archives: Windows

Recently I presenting at the Indianapolis PowerShell User Group and talked about Desired State Configuration. The presentation was 100% demonstrations, and I decided it would be a good idea to provide all of the PowerShell commands/instructions I used to build my lab environment for the presentation.

Note: Please note that these instructions were written using multiple Experimental DSC Resources, Microsoft and I myself provide no guarantee that these will work in a production environment. I strongly encourage that you use test environments that do not matter until you feel comfortable with DSC.

Pre-requisites

Licensed/Trial Media for Windows Server 2012 R2

An installed/updated Sys prepped VM Parent Disk

Stored at D:\Templates\Server2012R2.vhdx

a Virtual Switch within Hyper-V Configured as a Private, named “Private Network”

Now before we dive into the scripting component of this blog post I want you to know that this is not 100% automated. You will have some manual steps here and there, it is possible to 100% automate – but that will require significantly more effort. Please continue reading for instructions on this demonstration.

Recently I worked with a client to validate that if a user account were to be disabled that it wasn’t going to break any of their currently running applications. You can be bit by an accidental miss-configuration where an end-users account is running a Windows Service or possibly at a lower level in a specific application such as SQL Server jobs. Luckily with the Power of PowerShell we can conquered the Windows Services! It is also possible to create a SQL Query, or even PowerShell scripts to query SQL, but we will not be covering that in this article.

Checking Windows Services:

The biggest concern I had was the Windows Services, it is easy enough for a junior admin to install SQL and specify their own account as the Service Account. THIS IS BAD! However with some simple PowerShell we can perform a visual inspection, or with some minor adjustments we could look for a service running with a specific user.

In the above example we are using a parenthetical command along with the Get-CimInstance Cmdlet. The command that is executed first is the Get-ADComputer, this will required the ActiveDirectory module is available on your computer system. It uses the filter parameter to look for any computer that is running Windows Server (any version). It then passes those values to the Get-CimInstance which performs an initial WQL Query, which doesn’t allow and statements. Therefore we have to pipe it’s returned values to a where statement which will continue filtering for us. At the very end it provides me the service name, the user account running it, and the computer this service is on.

I was able to run this against the clients environment and within a few minutes we new that it was safe to disable the account.

This evening I’ve decided to add additional functionality to the GriffinMonitor Module. I noticed that I am filling up my storage on my lab server fairly quickly. With that in mind I knew I needed to know once I am about to max it out. I’ve decided to write a fairly simple alert for remaining disk space per volume. Before we dive into how to use the cmdlet and the code itself please reference the previous blog post on Monitoring Storage Pool Health – GriffinMonitor Module.

Using Alert-GMLowDiskSpace:

This cmdlet is very similar to the Alert-GMUnhealthyStoragePool as it has 3 mandatory parameters. There is a 4th parameter that is optional so you can specify the threshold at which it alerts. As I mentioned in the previous blog post at some point I intend to add additional functionality for TLS or SSL secured SMTP servers along with the ability to pass authentication. That functionality is still not there, but it is still on my to-do list.

Update Instructions:

Open C:\Users\<username>\Documents\WindowsPowerShell\Modules\GriffinMonitor with the PowerShell ISE or your favorite text editing document

Replace the code with the above script

Create a Scheduled Job for the new PowerShell cmdlet

Scheduling the Job for Alert-GMLowDiskSpace

1

2

3

#The below PowerShell commands will schedule the cmdlet to run every 30 minutes using the SMTPServer xxx.xxx.xxx.xxx, emailing to joe@example.com and coming from noreply@example.com - Make sure you update the parameter values.

Installation Instructions:

Navigate to C:\Users\<username>\Documents\WindowsPowerShell\Modules\GriffinMonitor

(Note: If the directory doesn’t exists you must create it.)

Save the above code in a file named GriffinMonitor.psm1 under the above directory

Create a Scheduled Job using PowerShell

Scheduling the Job for Alert-GMLowDiskSpace

PowerShell

1

2

3

#The below PowerShell commands will schedule the cmdlet to run every 30 minutes using the SMTPServer xxx.xxx.xxx.xxx, emailing to joe@example.com and coming from noreply@example.com - Make sure you update the parameter values.

The Windows Management Framework 5.0 Preview was released in early April, and an update to it was posted during Microsoft TechEd in May. Some major things are changing with PowerShell; the main one being that new versions of PowerShell are not going to be tied to major OS releases. PowerShell will be released as it is ready, and then added into the OS for the latest version.

Two of the major changes with PowerShell v5.0 include two new modules; the OneGet Module and the PowerShellGet Module. In this blog post we are going to explore some of the basics for these modules. If you would like to play with the Windows Management Framework 5.0, if can be downloaded from the Microsoft Download Center. Please note that this is preview code and should not be used in production. You are using this at your own risk and I strongly encourage testing it on the VM until the final code is released.

Please note that this is just a very quick overview of the modules and we will dive into more depth on them in upcoming blog posts.

There have been times in the past (more than I like to remember) where I’ve had a hard drive fail, a raid 5 fail, and eventually I am sure I’ll have a Storage Pool fail at some point with my lab environment. The best way to avoid this is by introducing active and heavy monitoring. In my work world I am very good and forward thinking when it comes to this; however no matter how many times it happens in my home environment I still fail at maintaining the system.

When Server 2012 was released with the introduction of Storage Pools I had just lost my RAID 5, I decided it was the right time to implement Storage Pools as my primary storage at home. It uses parity which is basically a software raid, and I was able to use cheap consumer drives along with USB drives (YAY! more space since I was out of it inside of the server.)

I’ve been running Storage Pools for over a year, knowing one major issue with my setup. I have absolutely no monitoring in place, and if I were to have a drive fail it could be weeks… maybe months before I realize an issue exists. I recently went through updating my home lab from Server 2012 to 2012 R2 and decided I needed to stop fooling around with my data and get some monitoring in place.

Well the first issue came along… how am I going to monitor my Storage Pool? Sadly there is no easy alerting of an unhealthy Storage Pool built in… I’m sure there are third party tools, but do I really want to go through the hassle of setting that up for just my Storage Pool? The good news is that PowerShell has some fantastic cmdlet’s available for working with storage.

When I started building my monitoring solution I initially thought… a simple script on a scheduled task will get the job done. As I built it out, I decided that I needed to go further than I have in the past, I needed to build a cmdlet, then once I finished that I thought why stop there? Why not built my first module? This module currently only contains a single PowerShell cmdlet, but as time goes on I hope to build out many more that I can continue to use in my environment at home. Below is the entire source of the psm1 file that is stored in my Modules directory along with installation instructions and directions on how to use the cmdlet.

Using Alert-GMUnhealthyStoragePool:

This is a fairly straightforward cmdlet, only 3 mandatory parameters and it works. There are quite a few restrictions surrounding the SMTP Server including it cannot use TLS or SSL (Currently) and it doesn’t accept Authentication. These will be added in the future but for the first iteration of it I was going for quick and dirty for a lab environment.

'Subject'="The Storage Pool $($pool.FriendlyName) is currently $($pool.HealthStatus) on $env:computername";

'Body'=($physicalDisks|Out-String);

'BodyAsHtml'=$true}

Send-MailMessage@mailMessageParams

}

}

}

Installation Instructions:

Navigate to C:\Users\<username>\Documents\WindowsPowerShell\Modules\GriffinMonitor

(Note: If the directory doesn’t exists you must create it.)

Save the above code in a file named GriffinMonitor.psm1 under the above directory

Create a Scheduled Job using PowerShell

Scheduling the Job

PowerShell

1

2

3

#The below PowerShell commands will schedule the cmdlet to run every 30 minutes using the SMTPServer xxx.xxx.xxx.xxx, emailing to joe@example.com and coming from noreply@example.com - Make sure you update the parameter values.