The start of my tech blog

  |   Source

I have been wanting to start my own blog for some time now and have never gotten round to it. A few years back I was going to start one based around my interests in home theatre's, but the hobby nature of this never made me want to do it enough. This time however the idea was to start a blog originally based around PowerShell and the knowledge I've gained using it for a few years, but this could turn out to be on anything and everything.

At my workplace I have found that I am spending a lot of time writing my own PowerShell scripts, from scratch or based off someone else's scripts, to fit the needs of my work requirements. This is obviously what most people do, but hopefully some of the content I have created can help others who might have a similar need.

I'm not too sure where to start, so lets start with a small outline of my role and provide a glimpse into the scripts and Modules I've created in PowerShell. I'm yet to upload these into github, most will require 'cleansing' first.

My official job title is Technical Specialist. Essentially I’m the primary technical resource for a small government department. I handle all things ‘powered’, from our desktops, application deployment scripts, printer configurations through to handling our SAN, basic network/VLAN requirements, Hyper-V Clusters, Disaster Recovery, Backup, AD, Group Policy, file servers, application servers, the build process involved with those and everything else in between! Over the past year or two I have really started to concentrate on utilising PowerShell to ‘automate everything!’, and surprisingly I am really enjoying it.

PowerShell Modules and Functions

In my work I have found the simplest way of accessing my scripts is to turn them into Functions within Modules. This way, I can simply provide a menu item in PowerShell ISE to import those Modules for easy use. Some of the Modules I have written are:

General Functions

This was originally written to handle desktop application deployments by providing standard functions like retrieving installed applications, creating folder trees, adding and removing files, folders and registry items through to installing and invoking executables. The main reason for these functions was to provide reusable code that included built in logging in a standard format. Hyper-V Functions

This includes a range of simple functions, such as to provide an overview of our Hyper-V Replica Health, CSV capacity status, through to a custom script to balance our virtual machine load across nodes in the cluster, and to larger scripts we use to deploy all server virtual machines that includes the automated builds with specific environmental software configurations, SQL servers and custom vendor application server environments. Yes, some of this could be handled via SCVMM and templates, however due to my workplaces size (and workload), deploying SCVMM just never happened. WSUS

This was to provide simpler handling of finding and approving WSUS updates while having the ability to ‘exclude’ updates without having to worry about those going forwards. This has turned out to be a far simpler way to not only identify those updates our systems require, but also approve them for a ‘test’ WSUS group and them merging those approvals into our ‘production’ WSUS group.

Desired State Configuration (DSC):

Since discovering DSC when it came up in one of the technical sites I’m following, I had to look further into it. Now, I am using DSC to handle specific server build requirements in a far more controlled way than a simple script. While we are a small ‘shop’ and do not have large web farms or anything of that nature (which to me is one of the primary reasons DSC was initially built for), I’m able to use a mix of scripting and DSC to give me a build process that is reusable and provides an expected outcome, over and over again.

A few of the custom DSC Resources I’ve written are:

  • cLegacyFirewall

Essentially a rewrite of Microsoft’s xNetworking ‘MSFT_xFirewall’ Resource, but using a custom PowerShell wrapper to control and use the netsh command to handle the Firewall changes. This allows me to use DSC to configure firewall rules against Windows Server 2008 R2 systems.

  • cLegacyFirewallGroup

Same as above, but to control firewall group rules (such as “Remote Desktop”, “Remote Event Log Management”, etc)

  • cDCOMPermissions

A DSC controlled way to set specific DCOM ‘Machine Access’, ‘Machine Launch’, ‘Default Access’ and ‘Default Launch’ permissions using a PowerShell wrapper for dcomperm.exe.

  • cIPv6NicBinding

To enable/disable an IPv6 binding on network interfaces

  • cEnableNetworkDTCAccess, cDisableNetworkDTCAccess

As the names suggest, enabling and disabling Network DTC Access.

Hopefully this shows some insight into my work with PowerShell, and I plan on following this post up in the future with some in depth detail on these PowerShell scripts. Unless I have input from someone about a topic they’d like, I’ll probably start with my cLegacyFirewall DSC Resource as it also covers how I have 'wrapped' netsh.exe with PowerShell, a process I'm finding to be more and more useful.