Category: Powershell

Jeffery Hicks shares several tips on creating fancy HTML reports using Powershell:

Usage is pretty straightforward. You specify one or more computers and off you go. There is a default value for the resulting HTML file, but you’ll likely want to specify your own.   Because the function is generating custom HTML on the fly, I also provided options for you to provide pre and post content HTML material, just as you might with ConvertTo-HTML. I also give you an option to specify a graphics file which is display like a logo at the top of the report. The graphics file will be embedded in the HTML file. The CSS is also embedded in the HTML making the entire file completely self-contained.

The one knock I have is the gradient color scheme:  people with Protanopia or Deuteranopia will have trouble reading the free space indicator, as the colors blur into one another.  Otherwise, this looks great.

Fred Weinmann argues for the value in learning modules over built-it-yourself solutions for expanding knowledge:

When you start with a new technology, you don’t start on a green field. You’ve got lots of luggage you carry around with you (previous experience) and a perception where you want to go (project conditions, goals). However the technology you interact with may not be limited to just that.

Using, consuming and discovering tools written for a technology by someone who has been busy in that particular field for years can guide you in your own comprehension of the technology.

For example, if you were to shift to Database Administration of MSSQL servers, there is this community module called “dbatools” which covers most of the tools you will need (seriously, we spent lots of time on it to make that true). Now, no module can replace your own mastery of the topic. You will need to know how backup and restore works. How to design a new database and how to troubleshoot inefficient queries.

No tool can save you from needing to understand the concepts and the procedures.

However by looking up the commands, what they do and how they do it, you can benefit from the experience from some seriously senior dbas. For free.

The key point here is that going completely your own path may result in a bad solution, in piled up technological debt which you didn’t see coming because you didn’t have the context yet, because you tried to map new information into your previous context, whether that fit or not.

Click through for the full argument.  I’d go a step further:  these modules are capital.  They are the sum of knowledge built up over time and eschewing this so you can traverse the same ground and try to solve the same problems is a waste of time (unless you can do it better).  Build from what is there and use that precious time you have solving other problems.

Patrick Flynn wants you to improve dbatools:

As part of dbatools participation in this event we are encouraging contributors to assist “the road towards 1.0” by improving the examples available in the comment-based help, which power the new docs site at docs.dbatools.io.

The activity is available to anyone who wants to help and does not require any expertise in PowerShell. Any of the following actions are desirable:

•  Fix typos in examples
•  Fix obvious errors in examples
•  Add examples to illustrate use of all possible parameters
•  Add examples to illustrate use of pipeline support
•  Add examples to illustrate combining multiple dbatools commands.
•  Add examples that illustrate use of dbatools commands in new or interesting ways.

We are a looking for a max of 6-8 examples per command.

Patrick also shows you how easy it is to edit the documentation, so check that out and get contributing.

Chrissy LeMaire notes a slew of dbatools updates:

And don’t forget, you can use Invoke-DbatoolsRenameHelper to rename commands in your scripts.

There is a slew of new functionality, but this little two-line mention is probably the best of the bunch.  Of course somebody was going to go and automate the renaming of cmdlet as a cmdlet.

Emin Atac reviews a couple of 64- versus 32-bit Powershell oddities:

• • Context

My colleagues send an message with a link that points to a script located on a shared drive to help our users reinstall their software.
Our users just click on the link in their Outlook and got a message saying:
\\servername.fqdn\share\softwarename\install.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.

• • Issue

Users use Outlook that is a 32-bit process. If they click on link that points to a script, it will spawn a 32-bit console and run a 32-bit powershell.exe child process.
It appears that the ExecutionPolicy isn’t defined in the 32-bit PowerShell and set to its default value: “Restricted” although it’s defined in the 64-bit Powershell.

Read on for the solution to this issue as well as a second, similar issue.