Windows Server

PowerShell remoting – source vs destination

Powershell remoting, the ability to remotley manage and influence devices is a key part of PowerShell. By default PowerShell remoting is enabled on servers and one of the lazy “security” features you can use is to only allow connections from specified networks.

In a domain network this is very easy to do, all you need is a small group policy that sets the networks. There is one thing you need to note, that is not really documented.

The Group Policy

The group policy is a regular computer policy setting found under “Computer\Policies\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service” and the actual poliy item is named “Allow remote server management through WinRM”

When you enable this policy you can enter networks the server will consider trusted.  So lets say you have your server on the network 192.168.1.0, that would mean you set the filder to 192.168.1.1-.192.168.1.254.

The issue

What you need to consider is the following. Say you have servers on two seperate networks and one is considered management network, lets say it uses 172.16.1.0/24. This means you now specify the management network as approved. But the servers you are accessing is on your primary server network 192.168.1.0/24. You have to specifiy both source and destination networks for this to work as this also controls the actual listners and if you only specify the 172.16.1.0/24 network the listners on the servers on network 192.168.1.0/24 will not be enabled.

The solution

For the scenario above make sure to specify both networks in your GPO. So the filter will be set to 192.168.1.1-192.168.1.254,172.16.1.1-172.16.1.254

winrm

/Peter

Advertisements

Strange Case of the failed Remote Desktop Gateway

I have been having a kind of a strange issue for a longe while and finally got around to troubleshooting and figuring out why so here is a breakdown of the strange case of the failed remote desktop gateway connection.

The setup is as follow, using diffrent machines Windows 10, 8.1 and 7 to connect to diffrent remote desktop gateway solutions and for some reason the connection failed with wrong username and password to a couple of the RDGWs.

So after som digging and alot of help from my good friend over at isloation.se we found the issue and how to check if you are also running into this issue.

The check

On the RDGW check under incomming connections/monitoring and if the connections display as RPC-HTTP. This is the clue that something is not all right.

rdgw1

The cause

So over the years the has been alot of fixes and version of the RDP client for each version of Windows. In the later release support was introduced for RDP over HTTP with UDP as a performance booster. However due to bugs and other things happening there have been posts and information about setting a registry value to make RDP work again. The value is called RDGClientTransport. It is a DWORD and you set it to 1 to get everyting working again.

However what this does is force the RDP client to fall back to RPC-HTTP connections instead of HTTP/UDP. This in turn can cause connection issues if you have modern solutions.

The solution

Depsite several blogs and forum posts saying this the value should be 1 you really should change the default value of 0.

So here is the full path to set the value.

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\RDPClientTransport

As you probably noted it is a current user setting and since I am very lazy. Most of my configuration is done through either Configuration Manager or GPO so in this case it was a GPO setting the value to 1 for all my users. Hence the problem was only on my devices and not my coworkers devices.

rdgw2

/Peter

Techdays 2017 Pre-Conf Slides

Me and Jörgen Nilsson (@ccmexec) did a pre-conf together at Techdays in sweden. And after much slacking here are now the slide deck from that pre-conf.

Here is the link to download the slidedeck!
https://1drv.ms/b/s!ArAh2CEqOjRkk-8ZDAVJ1vRqi8Glxg

Techday2017

/Peter

System Center ConfigMgr 1702

Here we go again. New version of ConfigMgr! This time around it brings a bunch of new cool features and improvements. It also brings along the end of the 2008 era for site servers and SQL servers.

This is all good news but it requires some planning and managinig before an upgrade can be done if you are still running Windows Server 2008 or SQL server 2008.

For a complete list of what’s new and removed check out the official documentation here.

https://docs.microsoft.com/en-us/sccm/core/plan-design/changes/whats-new-in-version-1702

 

Happy deploying!

/Peter

Keeping Track of PowerShell versions

In today enterprises many are faced with the challenge of managing both Windows 7, 8, 8.1 and 10. This means that most have a multitude of PowerShell versions out there which in turn does not ease the management tasks faced.

If you are running ConfigMgr 2012 or later you have access to one of my favorite features called Compliance Settings. Use this feature you can easily keep track of your environments different settings and measure compliance. One of the things I like to measure is the current running PowerShell version. I do this for two reasons. Number one, I want to now that my systems are running the version set out as a baseline. Number two is that if they are not running the correct version I get an easy way of finding them all and hence an easy way of correcting it.

So the tasks including creating a Configuration Item, linking it to a Configuration Baseline, deploying said baseline to a collection of workstations and creating a collection of devices that are not running the correct version.

Step 1 – Creating the Configuration Item

In your ConfigMgr console find the Assets and Compliance workspace and then under Compliance Settings you will find Configuration Items.

Create a new one and give it a name, I will be using “PowerShell Version”. Make sure that Settings for device managed with ConfigMgr Client is set to “Windows Desktops and Servers (custom)”.

In the next pane select the appropriate Operating Systems that this can be run on. Hint, Windows XP does not support PowerShell.

On the settings pane, hit New and in the configuration set a Name, again “PowerShell version” works just fine. Set the Setting type to “Script” and the datatype to Integer. Hit the “Add Script” button for Discovery script and paste in the following script and then hit OK.

[int]$Version = $PSVersionTable.PSVersion.Major
return $Version

On the Compliance Rules pane hit New and give the Rule a name. I’m calling it BaselineVersion. Hit the browse button and select your Current CI and the Version setting we just created. The rule type should be set to Value and in the comply part set the value returned must “Equal” and then set your desired baseline version. 4 will give you an OK on Windows 8.1 and Windows 10 and 5 will only give you an OK on Windows 10 (this assumes you have not previously upgraded your WMF versions). Hit OK and then Next.

Review your setting on the summary pane and hit next when ready to create the Configuration Item

Step 2 – Creating a Configuration Baseline

Head over to the Configuration Baselines workspace and create a new baseline. Please note this can both be included in previously created baselines but I prefer a separate for this so I can later use the non compliance feature. Give the Baseline a name, “PowerShell”. Hit Add, Select Configuration Item and select your previously created CI.

Step 3 – Deploying the Baseline

This should feel very normal to most of you since it’s the same procedure as deploying any application or client setting. Right click your baseline and select deploy. The wizard will not look like the usual deployment wizards but all you have to do is select a collection to deploy to. I recommend avoiding deploying it to the built-in collections and instead do two deployments if you want to monitor both servers and clients. Before you hit OK change the Schedule to suite your response times. Default is 7 days which in a small environment can be forever but in a large environment it just around the corner.

Step 4 – Creating the non compliant collection

The last step is to create that all needed collection which you can deploy the new Windows Management Framework too. select your newly created baseline, look for a tab named Deployments a the bottom of the console. In this view you can see the collection the baseline has been deployed to.

Now right click the collection, select “Create New Collection” and then select “Non-Compliant”. Follow the new Collection wizard and not that the rule for membership is premade.

noncompliance

Last notes

Now all that remains is waiting for the devices to report back status and then end up in the Non-Compliant collection so you can remedy them.

For your Windows 7 machines please note that if you have not previously upgraded Windows Management Framework you will need to install both WMF4 and WMF5. WMF4 is a prerequisite for WMF4 and both require a reboot to complete. This might be a good time for a small custom task sequence.

 

/Peter

ConfigMgr–Disk Space Compliance

One of the least utilized features in ConfigMgr is compliance items and baselines. For some reason most of my customers tend to forget that a small part of monitoring on the client side will go a long way towards reducing the amount of tickets to your helpdesk.

One of things you might wish to measure is free space left of on the OS drive. This is easily done with a small compliance item. This post will show you how and you can then expand this to do self cleaning and other features as well if you so wish.

Start with creating a Compliance Item by going to the Asset and Compliance Node, Compliance Settings and Configuration Items. Right click, Create Configuration Item and give it a suitable name. Click Next when ready.

Create

Select the Operating systems that this can run on. Make sure to deselect the older OSes which do not support PowerShell and click next when done.

OS

In the settings pane click new to create a new setting to monitor. Give it a name I use FreeSpace and then set Setting type to Script and Data type to Integer.

Setting

Click Add Script and add the script to get the frees pace percentage of the C drive. Click OK and next to get to the Compliance Rules pane.

Script

The Script

$FreeSpace = (Get-Volume -DriveLetter C).SizeRemaining/(Get-Volume -DriveLetter C).size
[int]$Size = [math]::Round($FreeSpace,2)*100
return $Size

Click New to add a new rule, give the Rule a name and select the setting you just created. For rule type set it to Value and set the following values:
The value returned by the script: Less than
The following values: <percent you wish to monitor> (I use 80)
Noncompliance severity for reports: Warning

Compliance

Now the Configuration Item is done, just click next twice to save everything and create the CI.

For this to actually work a Baseline needs to be created. So head over to the Asset and Compliance workspace and the Compliance settings node and find Compliance Baselines. Right click and create a new baseline.

Give the baseline a name, click Add and select Configuration Item.

Baseline

You get a list of all your CIs and just select the one you just created and click Add and OK.

CIs

Now you have a baseline you can deploy to a collection.

This can of course be expanded with things like non compliant collections, reports, remediation scripts and so on. You can also add other checks and verifications to the same baseline and monitor things like BitLocker encryption status.

WS2016 Beyond Unsupported

Update 2016-10-01: Currently MAK keys won’t work with activation. Expect Microsoft to release a new Eval media to correct this.

Update 2016-10-09: I previously had mentioned you can upgrade index 1 and 3 using the methods described below but Core editions cannot be modified this way and I have update the post to reflect that.

Windows Server 2016 Eval media has been released and while we wait for VL media there is a small cheat you can use if you want to play around with the licensing modes. Please do note that this is not in any way a supported way to do it and far from recommended.

Method 1 – An already running server with WS 2016 installed

This is the easier way and can be done on any running Windows Server 2016 except for domain controllers.

First you need to get the KMS keys from Microsoft TechNet KMS key appendix A found here https://technet.microsoft.com/en-us/library/jj612867(v=ws.11).aspx. There are different keys for both Standard and Datacenter so make sure pick the correct one.

Next start an elevated command prompt and run one of the following commands depending on if you upgrading to Standard or Datacenter

For Standard:
Dism /online /Set-Edition:ServerStandard /Productkey:<key for Standard from appendix A> /AcceptEULA /Norestart

SrvStd

For Datacenter:
Dism /online /Set-Edition:ServerDatacenter /Productkey:<key for Datacenter from appendix A> /AcceptEULA /Norestart

SrvDC

Wait while it completes and then reboot the server and your done. When the server is done rebooting you will have either a Standard edition or Datacenter Edition server.

Method 2 – Changing the media and enable in-place upgrade

This is a bit more complex and requires some installation steps before it works. The first thing needed is the newest Dism tools 10.0.14939 found in the ADK for Windows 10 1607. That can be found here https://developer.microsoft.com/sv-se/windows/hardware/windows-assessment-deployment-kit

Download the setup for ADK and run the installation. The only component needed for this is the Deployment Tools. Wait for the installation to finish and then reboot the machine to make sure all dlls are registered.

adk

Download the Eval media from the TechNet Evaluation Center https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2016

Copy the contents of the ISO to a folder on your management machine in this example I will use C:\ISO but you can use any folder, just make sure to correct all paths in each command.

Iso

Create a folder for mounting the wim file (C:\Mount) and start an elevated command prompt.

Change the directory to your newly installed dism tools usually here C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM then run the following commands and press enter after each (there will be some wait in between each)

dism.exe /Mount-Wim /WimFile:C:\ISO\Sources\Install.wim /index:2 /MountDir:C:\Mount

dism.exe /Image:C:\Mount /Set-Edition:ServerStandard /ProductKey:WC2BQ-8NRM3-FDDYY-2BFGV-KHKQY /AcceptEula /Norestart

dism.exe /UnMount-image /MountDir:C:\Mount /Commit

dism.exe /Mount-Wim /WimFile:C:\ISO\Sources\Install.wim /index:4 /MountDir:C:\Mount

dism.exe /Image:C:\Mount /Set-Edition:ServerDatacenter /ProductKey:CB7KF-BWN84-R7R2Y-793K2-8XDDG /AcceptEula /Norestart

dism.exe /UnMount-image /MountDir:C:\Mount /Commit

If you look closely you will notice I change the index number and the product key to update all 4 scenarios, Server Standard Core, Server Standard GUI, Datacenter Core and Datacenter GUI

Now the last step is the one you have to solve yourself and that is to create a bootable ISO from these files.

 

As a last note: DO NOT under any circumstances use this in production. I highly doubt this is a supported or even recommended way from Microsoft but can help you in your testing with licenses.

Happy deploying!

/Peter