Powershell Desired State Configuration

Nicolas Prigent describes Powershell Desired State Configuration:

The management and maintenance of servers quickly becomes complex without standardisation. PowerShell allows us many ways of responding to different problems and occasionally bypassing certain restrictive techniques. The danger is that we end up with a plethora of scripts in order to manage a server, all more complicated than the other, and this works. We do much better with a standard way of automating a task

DSC gives us a declarative model for system configuration management. What that really means is that we can specify how we want a workstation or server (a ‘node’) to be configured and we leave it to PowerShell and the Windows Workflow engine to make it happen on those target ‘nodes’. We don’t have to specify how we want it to happen.

DSC is great for keeping servers and server configurations in sync.

Parameter Validation Using Pester

Rob Sewell is using Pester to write Powershell unit tests and wants to test the existence of a parameter:

Here is the start of the function. I validate the VMName parameter to ensure that there a VM with that  name does not already exist

Before Rob’s posts, I hadn’t seen Pester before, but if you write a lot of Powershell code, it looks like a nice testing framework.

Managing SQL Server Error Logs

Mike Fal shows us how to mange SQL Server error logs using Powershell:

Reading SQL Server error logs is pretty simple, but requires us to make use of the SMO objects and the .ReadErrorLog() method to get the data from the log. Let’s start by simply reading the SQL Server error log and see what the output looks like (I’ll be using the SQL Server provider for this)

The big benefit, as Mike points out, is that the log rows are considered objects, meaning you don’t need to try to parse out things like the log date.

Reusable Powershell Scripts

Laerte Junior has an article on writing re-usable Powershell scripts:

There are the rules that I use in my day-to-day work in PowerShell. They’ve worked well for me over the years, but I’m not saying that they are carved in stone.

  • Learn the languageYou need to treat PowerShell as a serious .NET language. Like C#, F# or VB, it is impossible to know what the language can do, such as its features or commands without understanding the language and its paradigms? You can cut and splice other people’s scripts but you must have a good feel for the way that the language works before you can proceed any further

  • Use The HelpFor PowerShell, the help system is the first thing you must reach for: it must be your best friend. The designers of the language intended it to be well-used.

  • Use the  PowerShell CommunityThe PowerShell community is unique, because it has people who have come from a wide range of IT backgrounds. They bring their experience and wisdom with them. They will know more than you.  The combination of skills multiplies the speed at which the language develops. Read their posts, download their script and learn from them.

  •  Keep It Simple

  • Do not use Aliases, except for deliberate obfuscation.

  •  Write with considerationDo not try to cram all your scripted process into one line.  In the Shared and Corporate environment other people will maintain your code and will not necessarily have the same PowerShell knowledge as you. Be kind in your code.

After reading his article, check out Carlos Perez, et al’s Powershell Best Practices and Style Guide.

Temporal Tables Via SMO

Cody Konior shows how to create temporal tables in SQL Server 2016 using Powershell and Server Management Objects:

Why would you want to do this? In my case I have a PowerShell function to accept an input object, convert it to a DataSet (a .NET representation of tables and the links between them), and bulk copy the data into SQL Server. However because the input objects can vary slightly with additional tables or additional columns I use the flexibility of SMO to create the tables and columns on the fly.

There’s a lot of power in programmatically defining objects.  I’m not sure that’s a good default scenario, but there are times in which it can come in handy.

Trust Relationship Failed

Chrissy LeMaire ran into a trust issue one one node of a cluster:

You know what’s scary as hell? When one node of an important cluster loses its trust relationship with the domain and you see the error “the trust relationship between this workstation and the primary domain failed”. That happened to me late last year with one of my SQL Server 2008 R2 nodes. The scary part was that I just didn’t know what to expect. The fix could be simple, or it could require a node rebuild.

Trust no one.

Powershell + SQL Server

Shawn Melton provides an introduction to various ways to interact with a SQL Server instance via Powershell:

The most commonly known cmdlet out of this module is, Invoke-Sqlcmd. This is generally thought of as a PS replacement for the old sqlcmd command-line utility, that to date is still available in currently supported versions of SQL Server. You utilize this cmdlet to execute any T-SQL query that you want against one or multiple instances. The advantage you get using Invoke-Sqlcmd over the command-line utility is the power of handling output in PS. The output from the cmdlet is created as a DataTable (System.Data.DataRow is the exact type).

This is a good overview of the different methods available.

Powershell Hashtables

Steve Jones shows us how to implement a hashtable in Powershell:

With that code, I could easily solve the puzzle. However I was struck by the various ways I work with the hash tables. I use braces, {}, to declare the table. I use brackets, [], to access elements and then parenthesis, (), when calling methods. All of that makes programming sense, but it’s something to keep in mind, especially as those three marks mean different things in Python.

Hashtables are easy to implement in Powershell and are extremely useful.

Powershell To Modify Team Foundation Version Control

Kevin Eckart makes use of TFS commands to maintain source:

In our environment, changes made in the Test branch have to travel through the Main branch and into the Release branch to be deployed into production. Sometimes changes need to move through quickly without regard to other changes, especially in an environment where there may be a single coder. Note: the following code will merge all checked in code regardless of who checked it in. Be careful in multi-coder environments.

This is your daily public service announcement saying that if you don’t have your database code in source control, you really should get your database code into source control.

Categories

August 2019
MTWTFSS
« Jul  
 1234
567891011
12131415161718
19202122232425
262728293031