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.
If 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.
Get-ClusterSharedVolumeUsage -ClusterName prodcluster05
Name : vol001
Path : C:\ClusterStorage\vol001
Size : 4096
FreeSpace : 4010
UsedSpace : 86
PercentFree : 98
OwnerNode : hyperv16
State : Online
Name : vol002
Path : C:\ClusterStorage\vol002
Size : 1536
FreeSpace : 486
UsedSpace : 1049
PercentFree : 32
OwnerNode : hyperv14
State : Online
I 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
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
FileName : Microsoft.PowerShell.Security\Certificate::LocalMachine\My\27AC9369FA
Subject : CN=Go Daddy Secure Certificate Authority - G2,
OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.",
L=Scottsdale, S=Arizona, C=US
SignatureAlgorithm : sha256RSA
NotBefore : 5/3/2011 3:00:00 AM
NotAfter : 5/3/2031 3:00:00 AM
Days : 5672
Thumbprint : 27AC9369FAF25207BB2627CEFACCBE4EF9C319B8
ValidityPeriodStatus : OK
ValidityPeriodStatusMessage : Certificate expires in 5672 days.
AlgorithmStatus : OK
AlgorithmStatusMessage : Certificate uses valid algorithm sha256RSA.
KeySize : 2048
KeySizeStatus : OK
KeySizeStatusMessage : Certificate key size 2048 is greater than or equal to 2048.
From time to time there is a need to mount an ISO to a Hyper-V virtual machine to install an operating system or SQL or other software. Unfortunately not everyone remembers to dismount the ISO from Hyper-V after they completed their task. This can cause errors when live migrating the VM to another host if the ISO is not located in a cluster shared volume. Either way it’s a good habit to keep those DVD drives unmounted if they are not in use. I wrote a script to connect to System Center Virtual Machine Manager to find any VM’s with mounted DVD drives and created a report. The script can also optionally send the report to the address of your choosing. I set it up to run once a week to nag remind our team to clean up after ourselves.
When an SSL certificate is issued it uses a cryptographic hash algorithm (read: hard math) to ensure your private information stays private. There are a number of hash algorithms, also known as signature algorithms, used in certificates in the past and present. Security researchers and scientists are constantly evolving the algorithms as the bad guys are always trying to break the encryption in the never-ending arm’s race of cryptography. When an algorithm is known to shown to be weak and vulnerable to cracking, it is deprecated. The mainstream browsers begin to warn and eventually not accept certificates using these vulnerable algorithms. Currently certificates using the MD5 algorithm are no longer considered secure, and now SHA1 certificates are being deprecated. All your new certificates should be signed using the SHA256 or higher which should now be the default on your Windows systems.
You can check your certificate’s algorithm health using the PowerShell Certificate Health Module.
Get-CertificateHealth -Path cert:\LocalMachine\My
Every business needs SSL certificates for encrypting their traffic. Typically we see SSL certificates being used for encrypting our http web traffic, but certificates are also used for securing LDAP (Active Directory), SMTP, IMAP, POP3, and so many more protocols. Certificates can also be using for authentication on your domain or on the web. When you purchase a certificate you typically choose to pay for the certificate to be valid for a year or more. After the certificate is processed, you install it and then your work is done. Except one year or so from now something breaks, and you realized that your certificate has expired.
Keep an eye on your certificates with the PowerShell Certificate Health Module.