Updating firewall rules with netsh

I needed to adjust the scope of a built-in firewall rule in a couple of servers, restricting the remote IPs to a list of UVM subnets in CIDR notation. The netsh documentation describes the syntax for a list as comma-separated values (no spaces). But I kept getting errors with the command:

netsh advfirewall firewall set rule name="Windows Internet Naming Service (WINS) (NB-Name-UDP-In)" remoteip=",,"

Finally, I actually read the error message:

For ‘set’ commands, the ‘new’ keyword must be present and must not be the last argument provided.

And the related part of the usage text:

Values after the new keyword are updated in the rule.  If there are no values, or keyword new is missing, no changes are made.

One little three-letter keyword was all I needed:

netsh advfirewall firewall set rule name="Windows Internet Naming Service (WINS) (NB-Name-UDP-In)" new remoteip=",,"


Remote Desktop Gateway

In order to connect to the Remote Desktop service on centrally managed servers from off campus, as well as some more sensitive servers from on campus, you need to use the Remote Desktop Gateway feature.

For the current Remote Desktop Client on Windows, you can configure this option by going to the Advanced Options tab, and then click the Settings button.

Remote Desktop Gateway settings

On the RD Gateway Server Settings window that open, select the second option, Use these RD Gateway server settings. The server name is rdgateway.uvm.edu, and chose the Ask for password option.

Click OK, and you should be able to connect using the RD Gateway service. For more information about RD Gateway, see What is a Remote Desktop Gateway server?



Outlook 2013 at UVM

Please note: Microsoft Outlook is not (yet) an officially supported email client for UVM’s central mail services. However, I use it as my primary email client for UVM email. Its support of both touch and traditional Windows environments make it especially suited to modern Windows devices. The additional features of Outlook—Calendar, Contacts, ToDo—save to the local PC and aren’t connected to any server. 

Changes in Outlook 2013

The most significant change in the new version of Outlook is the support of touch-based interfaces. In Outlook 2010, using your finger to scroll a message resulted in selecting a swath of text, as though clicking and dragging with a mouse. Outlook 2013 addresses this, and adds specific support for touch interaction with adjusted menu spacing and a thumb-based button bar that works really well on Windows tablets.

Outlook 2013 - tablet mode

Outlook 2013 – special features available on touch devices include touch scrolling, and a button bar for the right thumb.

You’ll also notice a much cleaner design, where the faux 3D buttons and look have been simplified and flattened. I find myself selecting the dark gray color scheme to restore some visual variety and separation, though.

One change that’s a little irritating is that you can no longer specify the folder into which copies of your sent messages are received; they go into a folder called Sent Items. Instead, I’ve configured Pine, Webmail, and Thunderbird to use Sent Items, too.

I continue to find Outlook a user-friendly, feature-rich email client, and I’m glad to share these instructions with you. Let’s get started. Continue reading

Software updates user experience

As we transition from Windows Automatic Updates to the more capable System Center Configuration Manager (SCCM or ConfigMgr), the timing and the appearance of alerts and update-related content is changing as well. I think it may be confusing to non-technical users, so I thought I’d document the most common elements alerts and windows

This alert pops-up in the upper right corner of the screen on Windows 8 family systems.

This alert pops-up in the upper right corner of the screen on Windows 8 family systems.

Windows 7-style alert

Windows 7-style alert above the system tray in the lower-right corner.

Continue reading

Who’s logged into Server 2012?

I’m severely disappointed that Microsoft has removed from Server 2012 the tools required for managing and configuring Remote Desktop for Administration. On previous server editions, I’ve used the Remote Desktop Services Manager to troubleshoot colleagues and delegated administrators’ access issues. We’ve also had situations where the SSL certificate used to identify the server and to encrypt traffic has expired and needed some intervention.

Some discussion on Mark Minasi’s support forum indicates that some of this functionality is returning in Server 2012 R2. In the meantime, and until all our servers get upgraded, I’ll be using a combination of the Task Manager (which shows user sessions),

Displaying user logon sessions in Server 2012 Task manager

Displaying user logon sessions in Server 2012 Task manager

and Process Explorer, which can show the username and start time for process.

Mark Minasi’s talk: The Case for Powershell

With Mark’s permission, I’m mirroring the video of his recent web talk “The Case for PowerShell: Why You Should Learn-PowerShell So You Needn’t Leave-Industry.” Read more about it in his recent newletter.

He shared it via Skydrive, but there are some capacity constraints in place that have been blocking access. (Really, Microsoft‽‽ You’ve suspended Mark Minasi’s SkyDrive account‽)

Hopefully, folks can download it here, or watch it online:

The Case for PowerShell

Thanks, Mark, for your evangelism and expertise.

Adding VMware Tools to WinPE 4.0

I’m trying to augment the Bare Metal Recovery boot image provided by EMC as part of the NetWorker Client to support recovery in our VMware vSphere environment. The BMR .ISOs include a sources\boot.wim file that I should be able to modify.

I started with these somewhat date instructions in the VMware knowledgebase. I copied the contents of the .ISO file to a temporary directory on my PE Build system (Windows 8 guest). Using the Windows ADK, I mounted the sources\boot.wim file.

C:\Temp>dism /mount-image /imagefile:c:\temp\NW-MBR-ISO\sources\boot.wim /index:1 /mountdir:c:\temp\mount

I downloaded the latest VMware Tools, then used the /A switch (administrative install) on the setup file to extract the contents to a local folder. The driver files are contained within Program Files\VMware\VMware Tools\VMware\Drivers. I copied that directory to my working location, then added the drivers to the WIM files.

dism /image:c:\temp\mount /add-driver /driver:c:\temp\drivers /recurse

DISM reported success, so I committed the changes and umounted the WIM file.

dism /unmount-image /mountdir:c:\temp\mount /commit

The files I copied off of the EMC-provided ISO were not sufficient to create a new bootable image. So I used the CopyPE command to create a new base image, which included a file source for the PE image as well as the appropriate boot sector files. Since the image source files were identical to the file in the EMC disk image (because this is how they created the image), I just copied my customized boot.wim over the default boot.wim. Then I was able to use the makewinpemedia command to create a new .ISO image.

I’ve been able to boot the image, and it loaded the VMXNET3 like a champ. We’ll see how the Bare Metal Recover process goes. Thankfully, this is a test and not a crisis.

Renewing Tomcat SSL certificates

Following Greg’s advice, as well as the Tomcat docs here are the steps I’ve performed to update the SSL certificates used by two Tomcat instances:

  1. Backup the existing keystore file, just in case..
  2. Generate a new certificate, with new alias
    E:\Tomcat\conf> %java_home%\bin\keytool -genkey -keystore mytomcatserver.keystore -storepass ############ -alias tomcat2013 -keyalg RSA -keysize 2048  -dname "CN=mytomcatserver.uvm.edu, OU=Enterprise Technology Services, O=University of Vermont, L=Burlington, ST=VT, C=US" -validity 730
  3. Create a certificate signing request for that cert
    E:\Tomcat\conf> %java_home%\bin\keytool -certreq -keystore mytomcatserver.keystore -storepass ############ -keyalg RSA -alias tomcat2013 -file mytomcatserver.csr
  4. process the CSR with our CA

Now, there are two options for importing the certificate, and I’m not sure if there are implications for the difference:

  1. Import the rootCA cert first, then the intermediate CA, then the actual server
  2. Import the three certificates together as a chained cert. The order of the certificates in the certificate file appears significant; our signing authority provides the chained cert with the RootCA first, which hides the other certs from the Windows cert viewer, among other things.

To import the chained cert (ordered with the host cert, interm. cert, then rootCA cert):

E:\Tomcat\conf> %java_home%\bin\keytool -import -keystore mytomcatserver.keystore -storepass ############ -alias tomcat2013 -file mytomcatserver_uvm_edu.cer -trustcacerts

Now, we need to update the tomcat server.xml so that the keyalias attribute references our new certificate’s alias. Then, when the tomcat process is cycled, it should use the new cert.