Disk Inventory with PowerShell

Hard Drive
Hard Drive

Almost every time I write a PowerShell script, tool, or module it is to scratch an itch that I have. The Get-DiskInventory script is not new to me, but I have recently published because I saw others needed the same type of tool.

Get-DiskInventory gets a list of disk (really volumes) on a local or remote computer and displays their drive letter, name, free space, capacity, used space, and % free. While new operating systems have Get-Volume, sometimes you need a tool to work with those “legacy” operating systems such as Windows Server 2008 R2.

Get-DiskInventory leverages Get-WmiObject to gather the necessary information and is compatible across all versions of Windows client and server.

Examples:

Get your copy now from the TechNet Script repository.

PowerShell Tip: Get-Clipboard

Often times I find myself working with lists of computers (servers) where I need to get some information from the servers (i.e. uptime, OS version, etc.), or I need to run a command against them. I typically gather the computer names into a list in Excel for data manipulation, then I save the list of computer names into a text file to use from PowerShell. Now with PowerShell 5 I have the ability to work with data from the clipboard. I can select the list of computer names, copy it to the clipboard, and from PowerShell convert the text list in my clipboard to an array of objects that I can feed into other commands (i.e. Get-ADComputer, Get-CimInstance, etc.).

list of Servers
Excel list copied to clipboard.

We selected the list of server names from Excel and copied them to the clipboard (Ctrl +C). Now we need to get the contents of the clipboard into PowerShell.

Notice the -match operator? When copying a list from Excel to the clipboard, Excel adds an additional carriage return. The regular expression ‘\S’ means match any non-white space characters.  By using the -match operator with this regular expression we are suppressing the extra carriage return (and any other empty lines).

Now let’s look at the results.

Now we can run some commands against our list like Get-Uptime.

 

Password Expiration Notification with PowerShell

Your password is expiringYou may have seen this message if you work from a PC connected to a domain. Windows is letting you know that your password is expiring soon, and you should change it. This is an extremely helpful feature provided you are using a Windows PC connected to your domain as your primary device. But what if you’re using a Mac, or a mobile device (i.e. phone, tablet), or if you have vendor AD accounts whose devices are not joined to your domain? I have received too many tickets from vendors not being able to successfully authenticate to the VPN due to their password expiring. Some VPN clients don’t allow the user to reset their password after their password has expired resulting in a password reset service ticket. If only there was a way to notify users before their password expires regardless of the device they’re using.

Introducing Send-ADUserPasswordExpirationNotification

I wrote a PowerShell module (MrAADAdministration) to send email notifications to Active Directory users whose passwords are expiring within a set number of days. The function Send-ADUserPasswordExpirationNotification by default gets all users whose passwords are expiring within 10 days and sends the user a friendly email to remind them to change their password.

Requirements and Features

The user must have an email address populated in their AD account. You can filter usernames by pattern and/or scope your search base via distinguished name. If you’d like to notify the users earlier than the default ten days, you can just set the NotificationStartDay parameter. Let’s look at how you’d implement this for your own domain.

Get-Started

Download the module from the PowerShell Gallery.

After you have installed the module, you may wish to customize the email notification message to include your service desk contact information. You can also modify the default parameter values for the from, to, and SMTP addresses.

After you have customized the message you’re ready to send your first test notification.

Example:

Assuming everything works you should receive two emails. One email will be the notification email informing you of your password expiring. The other email will be the detailed report of all evaluated user accounts and if they were sent a notification.

Once you have tweaked your default parameter values and notification message you’re ready to schedule the script to run via Task Scheduler on a daily or weekly basis.

We’ve been using this process for over a year now, and it’s helped cut down on many of the tickets for password resets.

But wait, there’s more..

There is more in the MrAADAdministration module, but we’ll save that for another day.

Azure Cage Match: ASM vs. ARM

Ken vs Ryu

This year I embarked upon a journey into the world of the cloud, specifically Microsoft’s IaaS offering in their Azure public cloud. I’ve learned a lot, and I have oh so much more to learn. Over the next few posts I wanted to share the highlights and pain points that may help the next person.

Last time we met Azure IaaS, but it was a rather superficial introduction. We didn’t dive right into IaaS, because we discovered we had to answer a few key questions before deploying an infrastructure in Azure. When I began to stand up the new environment using Azure IaaS I was hit with an unexpected question. Which deployment model should I use?

Biggest question: Classic or Resource Manager

This question was unexpected because I didn’t even know there was more than one option, nor which one was the “right” choice for me. What I realized was that there are two different Azures, two different portals, two different architectures, resulting in twice the confusion, and twice the learning curve. I was at a crossroad. Do I stand up our environment in the classic environment or the new resource manager environment? I needed to research and compare each offering to determine which one was the best fit for us.

Azure Service Manager (known as ASM) is Microsoft’s first generation of cloud architecture. In the service manager model everything revolves around the cloud service. This is suitable for running your apps on IaaS VM’s, but not conducive to running real infrastructure roles. The networking in the ASM model provides only basic features, and the administrative model is a flat all our nothing approach. You’re an administrator or nothing, with no delegation of administration possible.

Microsoft’s second generation cloud architecture is known as Azure Resource Manager or ARM. Built from the ground up with role-based access control (RBAC) and a common deployment model, all your cloud assets are collected into resource groups. Azure Resource Manager has completely revamped networking which allows flexible virtual networks to be created. All current development efforts of Microsoft are being poured into the ARM architecture thus leaving ASM a legacy platform.

We deployed our first pilot in Azure Service Manager (“classic”) because at the time we found more documentation, blogs, and training online for ASM. However we quickly found some limitations that would eventually back us into a corner. When we began deploying a pilot in the Azure Resource Manager we discovered a lack of feature and functionality parity between the two portals. There were actions that existed in classic portal which didn’t yet exist in the new portal. Many of the actions and management changes required us to break out PowerShell. While I’m no stranger to PowerShell managing Azure through PowerShell was yet another learning curve. On top of that there are separate Azure PowerShell modules for each portal.

Despite the initial barriers to getting started with the new Azure Portal (ARM), the advice given to me from our consultant (and the general consensus of the Azure blogs and Twitter) was to push forward with the Azure Resource Manager architecture. We took this advice and began our deployment in Azure Resource Manager.

The Nugget of Wisdom

The rapid pace of development of Azure necessitates an always learning attitude from the whole team including development and operations. The evergreen model of change also means that not all features are fully baked when they are made available. Finally a strong knowledge of PowerShell is absolutely necessary when working with Azure as many features and settings are not available through the portal and can only be done through PowerShell.

Next time we’ll look at building out a virtual network.

It’s Patch Tuesday: Do you know where your patches are?

Now with with 10% real code.
Patch Rollups: Now with with 10% real code.

Starting tomorrow, October 11, Microsoft will change the way they deploy updates (and consequently so will you). Each month they will provide a single update containing all the security patches for that month and will be distributed via SCCM and WSUS only. In addition, they will publish a security plus fixes “quality” rollup update containing all of the current and previous months’ security updates as well as all previous non-security fixes. Both of them will be classified as security updates. Microsoft doesn’t really want us to approve both, but if you do it will (probably) work. IT professionals need to make a decision as to approve the security-only update or rollup or both. I typically deploy both security and critical updates where “critical” is the classification of update not the severity.

Critical Updates Classification from WSUS
Critical Updates Classification from WSUS

The critical update classification typically means a non-security fix. I’m trying to find out if the security plus fixes rollup means these critical updates that I normally approve. If that is the case then I will probably just go with the rollup update, especially since this is what Microsoft is recommending. Note that we will continue to have separate Internet Explorer and .NET framework rollups, as well as Office updates. Also bear in mind that this new process may provide “different” results for compliance tools (i.e. Nessus) since these two updates contain the same security updates and may report differently depending on the order in which they were installed if both were approved.

Thanks Mary Jo Foley for bringing this back to my attention.

Read More:

https://blogs.technet.microsoft.com/windowsitpro/2016/05/17/simplifying-updates-for-windows-7-and-8-1/

https://blogs.technet.microsoft.com/windowsitpro/2016/08/15/further-simplifying-servicing-model-for-windows-7-and-windows-8-1

https://blogs.technet.microsoft.com/enterprisemobility/2016/10/07/configuration-manager-and-simplified-windows-servicing-on-down-level-operating-systems/?utm_content=buffer410e6&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

Updated Certificate Health PowerShell Module

Working with SSL TLS certificates is becoming more and more a necessary skill for an IT professional. We should be working towards securing most if not all traffic. The bad guys are not trying to get in, they’re probably already in (assume breach). Hopefully you have good practices in place for protecting your private keys and for renewing your certificates. Speaking of which, how do you know when it’s time to renew your certificate? Hopefully your certificate provider sends you an email when it’s getting time to renew. However you may have installed a certificate on two or more servers or devices. You need a mechanism to find the expiring certificates in your environment. This week I updated the Certificate Health PowerShell module to add the ability to check certificates on remote Windows computers as well as creating an exclusion list. You can also use the Certificate Health PowerShell module to check your key size and algorithm (sha1 is no longer safe).

You can get the latest version of the module from TechNet or install straight from PowerShell.

 

Automate Snipping Tool with Autohotkey

Snipping Tool

Taking screenshots is necessary in the life of an IT worker. Every day we run into error messages that require investigation and resolution. I often find when I run into an issue that chances are I will run into the issue again (and usually a day or two after I completely forgot how I fixed it). That’s why I use screen shots in combination with OneNote to document what I do on a daily basis to fix recurring problems that my brain has forgot about. (PowerTip: OneNote can index text inside of screenshots.) Screenshots should also be used for documenting processes, installations, and changes. Although there are many spectacular screenshot tools out there, I’ve always tried to build my workflow around in-the-box apps when they are sufficient. For my screen shots I use the built-in Snipping Tool which has been around since Windows Vista. However when launching the Snipping Tool you have to switch to the app and then tell it to start a capture. In my never-ending quest for efficiency I want to find ways to keep my hands on my keyboard and use the mouse less and less. I needed a way to use Launchy to not only launch Snipping Tool, but to start the capture. I found and modified an Autohotkey script to help me accomplish my goal. Now I can press Alt+Space, type “snipit” and immediately begin my screenshot selection.

snipit.ahk

 

 

Detailed Cluster Shared Volume Information

Cluster Shared Volume DiagramIf you’re running Hyper-V clusters and/or Scale-out File Servers (SoFS) you may have the need to get a quick report of the Cluster Shared Volumes (CSV’s). However with the built-in cmdlet Get-ClusterSharedVolume you only get basic information. I wrote a function called Get-ClusterSharedVolumeUsage to gather additional useful information including Path, Size, FreeSpace, UsedSpace, and PercentFree.

Example:

Get-ClusterSharedVolumeUsage

10 Immutable Laws of Security and JEA

Sleeping Security GuardI came across a list of the ten immutable laws of security on Twitter last week written by Scott Culp back in November 2000, and I found it both profound and amusing. I found the list profound because the laws truly are still the same and still apply. I found the list amusing because of the mitigations and examples provided show us how far we have come (most of us kicking and screaming). For example it talks about setting your antivirus to update silently once a week using “push” methodology.  I’m reminded of the difficulty managing antivirus products used to be. Antivirus vendors have been challenged with providing robust manageability while building additional protection mechanisms to the point where we just call it endpoint protection nowadays. I’m sure years from now we will look back and laugh at how we are currently managing our ever-growing, always-connected, disparate collection of devices (i.e. Internet of Things).  Even the name Internet of Things may sound like the Information Superhighway or Cyberspace in just a few years from now.

One of the ways PowerShell can help us take our security to the next level is the Just Enough Administration. The goal of JEA is to move away from granting users administrative access to servers by giving them PowerShell constrained endpoints to allow them to do the jobs and tasks required with the minimum amount of privilege necessary. The JEA toolkit is still in development, but here’s to hoping it becomes the standard of granting access in the near future (more).

10 Immutable Laws of Security:
Law #1: Nobody believes anything bad can happen to them, until it does
Law #2: Security only works if the secure way also happens to be the easy way
Law #3: If you don’t keep up with security fixes, your network won’t be yours for long
Law #4: It doesn’t do much good to install security fixes on a computer that was never secured to begin with
Law #5: Eternal vigilance is the price of security
Law #6: There really is someone out there trying to guess your passwords
Law #7: The most secure network is a well-administered one
Law #8: The difficulty of defending a network is directly proportional to its complexity
Law #9: Security isn’t about risk avoidance; it’s about risk management
Law #10: Technology is not a panacea

Source

Certificate Keys: Size Matters

Keys

When issuing SSL certificates you can specify the key size (or length). The larger the key size the more secure the certificate, however higher key sizes also increase CPU load for encryption/decryption. When issuing certificates for your web servers the current recommendation is to use at least 2048 or higher.  Certificates with key sizes less than 2048 (i.e. 1024 or 512) are considered vulnerable and should be replaced as soon as possible. Check your SSL certificates key sizes to ensure they are using an securable key size.

 

PowerShell Certificate Health Module