Regular Change Windows

I am a proponent of change management (CM). I value the function, even if I sometimes despise the bureaucracy found in typical implementations.

At $work, we follow fairly well established CM process. It’s not perfect and it has bureaucratic elements but it’s well understood and mostly respected. Regular thinking about process improvement has led to critique of the individual elements of the process. Deadlines. Approvals. Communication plans. Success criteria. Change windows.

Let’s talk about change windows. We have a “regular” change window that happens once a month on a particular weekend. This was an IT decision. We decided on a particular schedule and called it the “regular” change window and asked everyone to schedule their changes within that window unless they had justification and approval from management for doing otherwise. The problem is, by the numbers, it is hardly our “regular” change window.

The Numbers

In 2014, just over 89% of our changes were performed outside of the “regular” change window. The trend for 2015 remain nearly identical.

Those numbers mean that we’re (re)negotiating change windows with stakeholders 9 out of 10 times. We’re creating justifications and requiring “off-cycle” approvals 9 out of 10 times. Talk about overhead!

The key to this process failure and resulting overhead is that we haven’t tied change windows to the actual business. We didn’t engage stakeholders to determine when is a good time to make changes for the business. However, in our complex environment doing so isn’t straight forward. We have a multitude of different clients, stakeholders and services. Boundaries often overlap.

Reducing the Friction

We can consider focusing in on major services, identifying stakeholders and establishing regular change windows on a per-service basis. This probably makes sense for the major services but what about the smaller, less visible services? What about services with a single stakeholder? How do we document each change window? How do we enforce changes to a particular service within that service’s specific change window? I don’t know…. but my short-term recommendation is to simply ditch the idea of regular change windows unless we can do them right. Why are we bothering with rubber stamp approvals for scheduling on 90% of changes when we’re going to talk about schedule in CAB anyways? What are we gaining from this?


Read More

Lync/Skype for Business Message Limit

Maximum frustration alert!

Lync (Skype for Business) has a maximum message size limit for instant messages:

This message is too long.

The limit cannot be configured and has a bizarre maximum of 800 characters for the first message and 8000 characters for subsequent messages to the same recipient. What? Why? How? Confusion and frustration ensues.

I actually enjoy using Lync but this one unresolvable minor irritation is spoiling the entire experience every time I want to share text with my colleagues.

Read More

World’s Worst POODLE Scanner for HTTPS

Behold, the world’s worst POODLE scanner for HTTPS services:

for subnet in $subnets; do
echo -e "########## SCANNING $subnet ##########\n"
https_servers=`nmap -sS -P0 -n -p 443 -oG - $subnet | grep open | awk '{print $2}'`
echo "TCP/443 found open on:"
echo -e "$https_servers\n"
echo "Scanning for SSLv3..."
for https_srv in $https_servers; do
echo -n | openssl s_client -connect $https_srv:443 -ssl3 &> /dev/null
if [ $? -eq 0 ]; then
echo "SSLv3 ENABLED on $https_srv:443"
echo -e "\nCOMPLETED SCAN FOR $subnet\n"

All it really does is tell you if SSL 3.0 is enabled on port TCP/443 when given a list of IP addresses and/or subnets to scan.

The above code depends on several things:

  1. bash or bash-like shell
  2. nmap, running with root privileges
  3. openssl command line utility
  4. awk and grep

Define the variable $subnet with a space-delimited nmap-compatible list of IP and/or subnet addresses.

The code can be easily modified to check for SSLv3 presence on other services/ports but I didn’t build that into the functionality because this is, after all, the world’s worst POODLE scanner.

Quick? Check. Dirty? Check. Yep, it’s a hack.

Read More

PowerShell 10961B Training – Top 5 Take Aways

I recently attended the Microsoft 10961B PowerShell training course. In the spirit of sharing, here are my top five take aways for those new to PowerShell:

Take Away 1: Learning and using PowerShell is all about command and knowledge discovery.

Three cmdlets that help us learn about PowerShell concepts, lookup commands and inspect objects:

  1. Get-Help – Read help information for topics and commands
  2. Get-Command – Find commands based on partial names / concepts
  3. Get-Member – Discover object properties and methods

There are approximately 24 “core” cmdlets that a seasoned PowerShell user will want to memorize. The rest can be discovered on-demand. No need for memorizing thousands of commands.

Take Away 2: Most day-to-day tasks are generally performed on the command line, not by running complex scripts.

Scripting is powerful and useful but it probably makes sense to focus on using PowerShell as a shell first and transitioning to scripting once we want to do more advanced things.

The Microsoft terminal for hosting cmd.exe and powershell.exe is… not so great. Alternative terminal programs to host the PowerShell engine are available. I prefer ConEmu. Install it locally or on a terminal server “jumpbox” and use PS Remoting!

Take Away 3: Everything is an object.

Output of cmdlets are objects that can be fed into other cmdlets to form powerful pipelines of processing. Unlike traditional UNIX/Linux shells, PowerShell commands return objects, not text. While text parsing can be used in PowerShell, most use cases do not require it as there is often a simpler, more direct way of accomplishing the same thing using object properties or methods.

Take Away 4: Remoting is powerful!

Enabled by default on Server 2012 and newer. Uses a single port. Secure. Allows for one-to-one or one-to-many management of remote systems. PS Remoting is a great alternative to logging into remote servers with RDP to perform manual GUI tasks.

It’s almost like SSH in UNIX/Linux, but flavoured for Microsoft Windows.

Take Away 5: PowerShell is the current and future best practice for managing Microsoft Windows.

With the release of Windows 8 / Server 2012 (PS 3.0 and newer), Microsoft has provided over 1500 cmdlets to manage their flagship operating systems. It is clear that PowerShell is how Microsoft intends to move management of Windows forward from here on out.


Start learning PowerShell today to stay current with modern practices for management and administration of Microsoft products!

Read More

RDP Inception and Password Changes

A common pain point that seems to come up regularly among technical folks is how to change a Windows account password over an RDP connection.

The correct answer is Control+Alt+End, right? Of course.

However, this doesn’t work as you might expect when you’re lost in RDP “Inception“. RDP inception is when you’re multiple levels deep with RDP connections, such as would be common when using one or more “jump boxes” or intermediate systems.

Example: Local Device->RDP1->RDP2->RDP3

When you’re lost in RDP inception, the Control+Alt+End command is sent to the very first RDP session you are connected to. In our example above, that would be RDP1. So what about changing your password on RDP2, RDP3 or any other systems beyond RDP1? The On-Screen Keyboard (osk.exe) is your new friend. Using osk.exe to bring up the Control+Alt+Del menu is not necessarily intuitive, though.

The Method

  1. Launch osk.exe in the RDP session for which you want to change your password.
  2. Hold down Control+Alt on your physical keyboard connected to your local device.
  3. Click “Del” using the On-Screen Keyboard running in the RDP session for which you want to change your password.

The Control+Alt+Del menu will now appear within the desired RDP session, allowing you to change your password.

Note: The “Desktop Experience” feature appears to be required for osk.exe to launch on Windows Server 2012 and perhaps also 2008 (untested).

Read More