SMBv1 Solutions


It’s been weeks since the #WannaCry #WannaCrypt exploited thousands of computers across the internet. If you have been regularly patching your systems you would have been covered by the March 2017 update. The vulnerability used the legacy protocol SMB version 1 to propagate across the network once a machine was infected. Security experts and even Microsoft have been calling for the disabling and or removal of the SMBv1 protocol from Windows environments for quite some time.

A Little History

Introduced with Windows XP, the SMBv1 protocol has been installed and enabled by default on all Windows operating systems for backwards compatibility. SMB version 2 was introduced with Windows Vista/Windows Server 2008 adding additional security and performance. SMB version 3 was introduced with Windows 8/Windows Server 2012 adding even more performance and availability options.

But First…

Disabling SMBv1 across an enterprise is no small feat. There’s a process to follow, and there’s research that needs to be done ahead of time. There are basically three hang-ups that can keep you from disabling SMBv1 across the board:

  • Windows XP and Windows Server 2003 boxes still hanging around the network. You REALLY need to get rid of them.
  • Linux servers, appliances, or devices that share or access data over SMBv1. Check with your vendors on supporting SMB 2.
  • Network scanners or multi-function printers that scan to file servers using SMBv1. See if they can be reconfigured or updated to support SMB 2.

Do the work to identify these gotchas so that you can know where you can and can’t proceed with disabling the legacy protocol.


Note that when disabling the SMBv1 protocol you need to disable both the server-side (I’m sharing files with you) and client-side (you’re sharing files with me) of the protocol.

Get It Done!

You route to disabling SMBv1 depends on the tools at your disposal.

1. Batch files and psexec


2. Group Policy



I wrote a PowerShell tool to gather the SMB protocols that are enable/disabled on a Windows computer called Get-SmbStatus. You can use this tool for discovery before and/or after you make your changes.


You can pick up the PowerShell function Get-SmbStatus at the Technet Script Repository.

Using PowerShell with SCCM Pending Updates

SCCM Pending Updates
SCCM Pending Updates

We’ve been deploying Microsoft updates with System Center Configuration Manager for a few months now. Each month we get a little better at the process and trust the system more. After approving each month’s patches, I kept finding myself logging into my servers to see if they had pending updates ready to be deployed at the next maintenance window. Logging into each server doesn’t scale, so I needed to find a way to automate the process using PowerShell.

After using a search engine I was able to find the correct WMI class that I could use to query for SCCM client software updates.

Once I had the proper namespace and class, I wrapped a function around it to get the information I need along with a simplified summary output.

Full Output (Default)

Summary Output

If I find that the computer I’m working on still doesn’t have the updates that I approved, I give it a good kick with the following three client actions from the same CMClient module :

Try it out for yourself.


PowerShell and SCCM Client Actions

SCCM Client Actions
SCCM Client Actions

If you work with System Center Configuration Manager (SCCM) you will be familiar with the number client actions that you can execute. Some of these actions are used more often than others, and learning what each of them do is for another blog post.

In our quest to roll out automated patching with SCCM we found that we often needed to run these various actions to get the SCCM client to check back in for new policy and check for pending updates. After logging into a handful of computers to open the Configuration Manger client applet from Control Panel to perform a Machine Policy Retrieval and Evaluation Cycle, I had to stop myself and find a faster way.

“What if I could use PowerShell to do this for me?”

I started like I normally do trying to find a SCCM client module with built-in cmdlets, but that path led to futility. Thankfully I found @adbertram wrote a PowerShell module that could execute the proper WMI method for the client actions. I immediately downloaded the code and started to try it out. I found one problem: the functions only accepted a single computer name at a time. I asked Adam about it. He told me to go ahead and update the code, and do a pull request on Git. I said I’d be glad to, pretending I knew how to do any of that Git stuff. After updating the code and performing my first Git pull request, we now have a SCCM client module for invoking client actions on multiple computers.

Let me show you a few examples:

Check out the CMClient module on Github and the PowerShell gallery (Install-Module CMClient).

Send your positive feedback to me and your bugs and complaints to Adam.



Windows UpdateI’ve been working on a project to roll out automated patching to the servers in our environment. We have been using a combination of group policy and WSUS, which is a great solution, but it doesn’t allow for multiple maintenance windows. Since we are primarily a Windows shop we chose to use System Center Configuration Manger (SCCM) as our solution. If you’ve worked with SCCM you know that “it’s a full time job.” So over the last few months we’ve been carving off some servers from our WSUS and moving them to SCCM for patching. During the changeover we needed to verify if the server was  actually talking to SCCM instead of our existing WSUS infrastructure. For the first few servers I logged on and launched regedit.exe to look at the policy key HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate. After doing this two (too many) times I realized this wasn’t going to scale. I put together a PowerShell script to read the registry keys we needed from one or more remote servers.

Introducing Get-WindowsUpdatePolicy

Now with a quick command I can see what WSUS server a computer is configured to use. Try it out, and let me know if you find it to be useful.

More Lessons Learned from Hyper-V Replica

In my previous post on lessons learned from Hyper-V Replica, I introduced the features of Hyper-V Replica introduced in Windows Server 2012 and improved in Windows Server 2012 R2. We saw that while Hyper-V Replica is a great feature, like all other technologies, it requires a workflow along with monitoring and troubleshooting procedures. In this post, I will discuss the workflow of implementing replication on an individual VM.

If there’s one thing that we can all agree on, it is that we should organize our VM configuration and virtual hard disk files in an orderly way (OCD FTW). If there’s one thing we can’t all agree on is how do that. The default way which Microsoft organizes Hyper-V VM’s is by placing the configuration file within one folder and placing the virtual hard disks within a separate folder.



Having the configuration files and VHD(X) files in separate locations doesn’t seem very tidy to me. I have opted to create a single folder to hold both configuration files and VHD files, naming the folder with the name of the VM. I then named the associated VHD files with the server name and drive letter as appropriate.

hypervreplica003hypervreplica004This organization makes it easier to locate all the files associated with a VM for administration, migration, backups, and other duties to which you might be called.

Tip: If you’re creating a VM from the GUI check the “Store the virtual machine in a different local” box and specify the folder, then all your configuration and VHD files will be stored in that one folder with the folder named as the VM name.


We spent all this time organizing our VM files into orderly folders, so the assumption would be that when you enable replication for the VM your orderliness will be mirrored to the replica host. Well you know what assuming does…Here’s what really happens.

When establishing initial replication the replica server creates separate folders for configuration and VHD files using GUID‘s as the folder names.


I’m sure there was good reasoning behind this decision but for those of us with CDO (that’s OCD in alphabetical order) we like to keep things organized.  Fortunately a simple storage migration on the replica server will get us back to OCD nirvana ensuring everything is in its place.

When first establishing replication for a VM allow the Hyper-V server to create the replica folders where it wants, but do not initiate replication immediately. Instead set the replication for a future time. hypervreplica007Then create a folder with the name of your choosing and perform a storage migration of the placeholder files. hypervreplica008Then initiate the replication. hypervreplica009hypervreplica010Now your replica VM files will be nice and tidy.

Now that we now have an understanding of the Hyper-V files and folder structure for both primary and replica VM’s, we can implement processes and procedures for deploying Hyper-V VM replicas. With this knowledge we can develop PowerShell scripts to automate these processes to free up your engineers and administrators for other duties.

Hyper-V and Mounted DVD Drives


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.