Nano Server Management

Where has the time gone? I looked up from my computer and the summer is nearly over! One of the things I’ve been tinkering with as of late with some of my “infrastructure as code” projects is Nano Server. Not only is Nano Server gearing up to be a great Hyper-V host and a cool place to start dabbling in containers, it’s also great server to use when testing deployment scripts because it’s small and deploys quickly. When all I want to do is spin up and tear down to test my templates, I love being able to use a Windows server with a smaller footprint.

With Nano server being “headless”, it only supports remote administration, so this has also lead me to check out all the newish ways we can manage servers remotely. You’ll need to take a few steps so you can remotely manage a Nano server deployed in Azure.

  1. Open NSG on Azure for the Nano Server – If you created a VM from the Azure Portal and accept all the defaults (which include an NSG), that NSG doesn’t open the ports for WinRM by default.  It only opens RDP.  The OS firewall is open to accept WinRM and PowerShell, but the NSG blocks it.  You need to edit the NSG to include TCP ports 5985 (http) and/or 5986 (https) for remote management.
  2.  Add Nano External IP Address as a Trusted Host – Since you’ll be connecting to your VM remotely over the public internet, you’ll need to add that IP address to your trusted host list on your workstation. You can do that via PowerShell or via CMD (just pick one).
    1. winrm set winrm/config/client @{ TrustedHosts="" }
    2. Set-Item WSMan:\localhost\Client\TrustedHosts ""

At this point you should be able to remotely connect to your Nano Server using PowerShell. On your workstation, run (replacing the IP address and username as appropriate):

$ip = ""
 $user = "$ip\sysadmin"
 Enter-PSSession -ComputerName $ip -Credential $user

You’ll be prompted for your password and then you’ll be given a remote PowerShell prompt to your Nano VM. But what if you want MORE than just a PowerShell prompt? What if you want access to event logs? Or some basic performance information? Or dare say, use “Computer Manager”??

You can use Server Manager tools from workstation or you can use the Azure Server Management Tools (and Gateway).

While your remotely connect to the server you want to manage, you may need to make a few other small changes, particularly if your servers aren’t domain joined or are on a different subnet than the machine you are connecting from. I recommend checking out this troubleshooting guide –

If you specify in Microsoft Azure the local administrator account to connect to the managed server, you have to configure this registry key on the managed server:
REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1

If you are connecting from a different subnet:
NETSH advfirewall firewall add rule name=”WinRM5985″ protocol=TCP dir=in localport=5985 action=allow

If you want to use Computer Manager and other common Server Manager tools:
Set-NetFirewallRule -DisplayGroup ‘Remote Event Log Management’ -Enabled True -PassThru |
select DisplayName, Enabled

Happy Remoting!

The Imperfect Lab: Letting Additional Administrators Remotely Connect to Servers

An age-old server administration best practice is to make sure that everyone who is administering servers on your network are doing it with their own “admin” credentials.

Up until this point, I’ve done all my remote Azure sessions (PS-Session) with the built-in administrator account.  This works fine if you are only person connecting remotely to a server. But what if you want to grant others administrative rights to your machine and they would also like to connect remotely?

Your first step would likely be to add them to the local administrators group. Since you’ve already turned on the “remote management” feature for yourself, you might expect this to work out of the box.

But you probably overlooked this little note in the “Configure Remote Management” box when you enabled remote management – “Local Administrator accounts other than the built-in admin may not have rights to manage this computer remotely, even if remote management is enabled.”

That would be your hint that some other force might be at work here.  Turns out that UAC is configured to filter out everyone except the built-in administrator for remote tasks.

A review of this TechNet information gives a little more detail:

“Local administrator accounts other than the built-in Administrator account may not have rights to manage a server remotely, even if remote management is enabled. The Remote User Account Control (UAC) LocalAccountTokenFilterPolicy registry setting must be configured to allow local accounts of the Administrators group other than the built-in administrator account to remotely manage the server.”

To open up UAC to include everyone in your local Admins group for remote access, you’ll need to make some registry changes.

Follow these steps to manually edit the registry:

  1. Click Start, type regedit in the Start Search box, and then click regedit.exe in the Programs list.
  2. Locate and then click the following registry subkey:
  3. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
  4. On the Edit menu, point to New, and then click DWORD Value.
  5. Type LocalAccountTokenFilterPolicy for the name of the DWORD, and then press ENTER.
  6. Right-click LocalAccountTokenFilterPolicy, and then click Modify.
  7. In the Value data box, type 1, and then click OK.
  8. Exit Registry Editor.

Now you will be able to remotely connect and administer your server using PowerShell with any account you’ve give Admin rights too for that particular server.  This would hold true for servers in Azure, as well as servers on your local network.

Special shout out to Bret Stateham for bringing this “remote admin road-bump” to my attention. Sometimes what looks like an “Azure” problem, is really a “Server” feature. 🙂

The Imperfect Lab: A Few VM Manageability Tweaks

Today in the Imperfect Lab I’m going to work on some clean up to improve the manageability of my new domain controllers. Since I have two of them, I want to take advantage of the Azure’s service level agreement.  The only way to ensure that Azure keeps at least one DC running at all times is to create an availability set, which will distribute the VMs within a set across different update and fault domains.

Some notes about Availability Sets – VMs must be in the same cloud service and you can have a maximum of 50 in each set. You will find that your machines are spread across 2 fault domains and upwards of 5 update domains.  Also, avoid creating a set with just one machine it, because once you create a set you won’t get notifications about maintenance regarding those update/fault areas. 

Since my machines have already been created I use the following PowerShell to update them with a set named “ADDC”.
Get-AzureVM -ServiceName “imperfectcore” -Name “dc-cloud1” |
    Set-AzureAvailabilitySet -AvailabilitySetName “ADDC” |
Get-AzureVM -ServiceName “imperfectcore” -Name “dc-cloud3” |
    Set-AzureAvailabilitySet -AvailabilitySetName “ADDC” |
If you want a quick gander at all the availability sets that exist in your subscription, run this:
(Get-AzureService).servicename | foreach {Get-AzureVM -ServiceName $_ } | select name,AvailabilitySetName
Since the GUI does hold a fond place in my heart, I do want the dashboard of Server Manager on one of the VMs to show the status of all the servers in the domain.  You’ll notice that if you log into the desktop of one of these newly created servers the “Remote Management” will be disabled.  This needs to be enabled to allow management from other services, so run “winrm quickconfig -q”against each server to turn that on.  You will have to start a PS-Session for each server for that.
Finally, since I expect to reduce the amount of times I’m logging into a machine directly, I’m going to take switch one of the DCs to Server Core and the other to the MinShell format.  These commands do take a while to complete and require a restart to complete the configuration, so don’t panic if you can’t connect to what looks like “running” VMs in Azure for a few minutes after reboot.
For Server Core (from a Machine running the Full GUI):
Remove-WindowsFeature -name User-Interfaces-Infra
Restart-Computer -Force
For MinShell (from a Machine running the Full GUI):
Remove-WindowsFeature -name Server-GUI-Shell
Restart-Computer -Force
With the MinShell installation I will still have access to the nice Server Manager dashboard when I want it and will be able to remotely manage the 2nd domain controller from it.  The list below will show the differences between each of the versions. (Click to make it bigger!)

The Quest for the Perfect Lab

There are a few old sysadmin jokes out there… one that often comes to mind for me these days is the one-liner about how the perfect network is one that no one is on.  But now that I have the luxury of being able to build just about any lab network I want (either in Azure or using Hyper-V) I find myself nearly paralyzed by wanting to build the “perfect” network/lab for my needs.

I start, I stop, I get sidetracked by a different project, I come back to my plan, only to realize I’ve forgotten where I left off (or forgotten where I wrote down that fancy admin password for that VM) and end up tearing it out and starting over again.  The end result is I’m getting no where fast.

I’ve got several MCSE exams in my future that I need to build some things for hands on for.  I have a little internal metric of how I need to improve my PowerShell a bit more.  I have work training items that sort of fit into all this and I keep striving for the perfect lab, the perfect naming system, the perfect password that I won’t forget… well, I guess my “perfectionist” is showing.

It’s a slow week here in the office with the Thanksgiving holiday approaching, so now is the perfect time to sit down with a pen and a paper and really figure out what I’m going to build and what I want to use it for.

Because there is something worse than a network that no one uses.  It’s that network I keep deleting.

Microsoft Top Support Issues: A Compilation

I know sometimes when I troubleshoot server issues, I feel like my issue is one of a kind. A special server snowflake. Though probably it isn’t.

Ever wonder what the most common support issues handled by Microsoft are?

Enjoy perusing the Top Support Solutions Blog! This might just save you some time when you are faced with that next head scratcher. Some of the product lines included (so far) are:

  • Exchange
  • Windows Server
  • Windows 8
  • Lync
  • System Center
  • SharePoint
  • SQL Server

Tips on AD replication. Update lists. DNS optimization. Client activation. STOP Errors. ActiveSync FAQ.  Outlook Anywhere.

There is even a Quick Start for upgrading Domain Controllers in domains with servers older than Server 2008.

This is the repository of tidbits that you are looking for. I started this blog as a place I could collect handy information for myself. I can now sleep peacefully at night knowing there’s something even better.

Go forth and troubleshoot!

Home Tech Support: What happen to my picture thumbnails?

You know you have to do it.  Your parents, your sister, grandpop… they all ask for help with their computers when you are around.  So here’s a quick one I got during my family vacation last week – The thumbnail view of a folder my father kept pictures in wasn’t showing the photos anymore.

Somehow the setting for “Always show icons, never thumbnails” was selected in the Folder Options settings, under the View tab. 

I’m guessing an application change it, though I wouldn’t be totally surprised to find out he was mucking around in there.

Another reason thumbnails might not show up is if the hard drive is mostly full.  Windows will stop generating thumbnails to save space.  That was the first thing I checked, but wasn’t the issue in this case.

Sysadmin Appreciation Day Coming!

Don’t forget that Sysadmin Appreciation Day is on Friday, July 26th!  If you are a sysadmin, this might be a great time to take advantage of a floating holiday you’ve been saving. 

If you AREN’T a sysadmin you might want to take a look around for your nearest helpdesk support person, the guy who last fixed your misbehaving keyboard, the person who helped you solve that problem with your voicemail, the gal who configured your mobile phone with corporate email, or the guy who restored that file you were looking for from last week’s backup.

If you need ideas for how to celebrate or appreciate your neighborhood sysadmin, visit