For many of you that switched off over the xmas break (like me), you may have missed that there are now patches (released Jan 3rd 2018) for the creatviely (almost bond movie like) named vulnerabilities of “meltdown” and “spectre”.
The register has a good article (as they do most of time) cutting through the intel PR bullshit. Importantly, there has been various reports of performance impacts after installing these patches – but it is still too early to tell exactly how large/important those perfomrance impacts are.
There are links to many vendor advisories (which in turn have links to updates) @ https://meltdownattack.com/ – which is quite useful.
The patches and additional mitigations are fairly easy to implement if you have patching/management infrastructure in place – but if your company needs any assistance, we’re happy to help too.
With the recent release of Server 1709 (and the fact that it’s Server Core only), Microsoft have also recently released a preview of a new server management product. This product is currently code-named ‘Project Honolulu’, and is a light-weight web-based management console for Windows Server. Details of the original preview release can be found here.
In the past, when you wanted to manage remote servers (and especially Server Core instances), you either had to:
RDP in to configure it
Enable WinRM and use remote powershell
Enable WinRM and use a remote Server Manager instance from Server 2012 R2 or Server 2016
Depending on what you were trying to achieve, you also may have had to use remote consoles like Computer Management, Event Viewer, Storage Management, Certificate Management, Firewall Management – none of which are built in to Server Manager, but can be launched from there.
Based on initial impressions of Project Honolulu, it looks like Microsoft is trying to improve that experience, and it looks like they’re actually moving in the right direction.
As you can see from the above image, they’ve actually rolled a bunch of the above tools into a single interface – and the really surprising part, is that it’s actually fast. Not like Server Manager where sometimes it can take quite a while to refresh or load.
Obviously it’s not a complete product yet, and there’s a bunch of stuff in Server Manager that it would be nice to see in Honolulu – mostly around dashboards, additional tool sets (Active Directory tools, for example), and additional functionality in the existing tools.
Some of the things I found quite good with Honolulu:
The speed of loading remote information (event logs, services, etc)
The ability to remotely import a certificate PFX file without having to resort to painful powershell commands and scripts!
Set basic IP config on a remote server
Remote process monitor (graphical – not tasklist.exe!)
Remote storage management without setting up additional firewall rules
Virtual Machine dashboards/management. I haven’t had too much of a play with this so I’d say there’s stuff missing, but what’s there is actually quite good.
Remote Windows Update management (for those of you not using SCCM/WSUS to automate update installation)
Things it can’t do yet, but I’m hoping they add in:
Dashboards for overall status of servers
Search function for Registry viewing/editing
More settings for Services (eg: Logon details)
Editing of certificate private key permissions
Additional remote tools – such as Active Directory Users and Computers, DHCP, DNS, Remote Access Management, IIS, etc
If you’re interested in trying out Project Honolulu, it can be downloaded here. Installation instructions can be found here. To be honest, it’s a super simple setup – whether that changes in the future is yet to be seen!.
Note: remote management via Honolulu does require Windows Management Framework 5.0, so you’ll need to install that on non-2016 servers.
In September 2016, Microsoft released Server 2016. A couple months ago, they then released Server 1709. You’d be forgiven for thinking that Server 1709 is an upgrade to 2016 – because it’s actually not.
Much like Windows 10, Microsoft have gone down the path of having multiple ‘Channels’ with the Server products. Essentially:
Server 2016 is the server equivalent of Windows 10 LTSB (Long Term Servicing Branch)
Server 1709 is the server equivalent of Windows 10 CBB (Current Branch for Business)
Instead of using LTSB and CBB, the server OS’s are ‘Channels’ – so LTSC (Long Term Servicing Channel) and SAC (Semi-Annual Channel).
So what are the main differences?
Server 2016
Available in Standard, Datacenter and Essential editions
Available as Server Core, or Server with a GUI
5 year mainstream support, 5 year extended support
New release expected every 2-3 years
Server 1709
Available in Standard or Datacenter (no Essential edition)
Only available as Server Core
18 months mainstream support, no extended (much like Windows 10 CB and CBB)
Releases semi-annual
So why would you go with 1709 over Server 2016? In general, it depends on your use-case scenario. The largest improvements for 1709 are around Containers and Nano Containers (with Nano Server being deprecated), along with some Hyper-V. Obviously you’re going to be restricted to Server Core, but that’s not as big of a deal these days when you’re talking about built-in roles (due to significant improvements in remote management for Server 2016). In general, you’re only going to be considering 1709 (or any SAC release) in the following scenarios:
You’re looking to build a new Server Core server and you don’t mind upgrading it every 12-18 months
There’s specific features available in 1709 that aren’t available in 2016
For a full list of updated features in 1709, here’s the full list. There’s also a new management interface on the way, currently named ‘Project Honolulu’ – this may help with some of the Server Core management concerns.
A couple of gotchas:
If you’re using Automatic Virtual Machine Activation (AVMA) on Datacenter Hyper-V hosts, it doesn’t seem to work with Server 1709 – at this stage I’m unable to find official information about this, so it seems that you’ll need to use Manual Activation Keys (MAK) in the mean-time (or…ongoing).
You can’t upgrade from Server 2016 to Server 1709 (even if it’s 2016 Core) – much like you can’t upgrade from Windows 10 LTSB to CBB.
As per the link above, SMB 1 will no longer be installed by default in Win 10 1710 (which, given the release date, I’m guess that’s what it will be called among techs, rather than the exceedingly shitty “fall creators update” name – because calling two different versions “creators update” is logical) or the next version of Server 2016 (whatever that ends up being called).
Considering the recent-ish SMB1 targeted attacks, this isn’t surprising – and is a good move in my opinion. Issue is of course, the companies likely to hit by SMB1 (or other old-school attacks) are likely to not be up to date with their patching and even less likely to be up to date with OS versions – so it wont help secure the more vulnerable networks out there….
Updated on : 11/08/2016 (Windows 10 KMS patch compatibility)
Relevant to: KMS – all versions
KMS seems to be one of those things that is sometimes quite poorly understood – and many existing blog articles or pieces of documentation seem to gloss over important details (IMO). So, below is my attempt.
Concepts
MAK – Multiple Activation Key
This type of key is intended to be used on multiple computers, but must be entered manually, via VAMT or in an SCCM task sequence. The activation process occurs once per machine either directly over the internet, via a MAK proxy or via telephone.
The MAK activation method is best suited for
Small organisations with 25 or less computers
Organisations who have certain machines which are not domain joined and/or do not connect to the business network regularly
KMS – Key Management Server(s)
A Key management server is a service which provides activation on behalf of clients. The KMS server is activated once, and in turn, clients will auto-locate and activate against the KMS service. (more about the details a bit later)
KMS Key – Key Management Server Key
This type of key is intended to be used on a Key Management Server to provide activation for clients and has a couple of important factors:
KMS requires what is called an “activation threshold”, which basically means that until you have more than 25 Windows 7/8/8.1 activations or more than 5 Windows Server 2008 R2/2012/2012 R2 activations, the KMS server is not active
To remain active, KMS clients must contact the KMS server once every 180 days. If it does not, the client will start showing activation messages.
Volume licensing
I would imagine that if you are reading this blog you are familiar with what volume licensing is. KMS and MAK are both used for volume licensing customers, you cannot activate retail or OEM operating system installs using these methods.
Decisions to be made prior to install
KMS or MAK
Many organisations we deal with use both.
If a machine is off the network for long periods of time or is not domain joined, use a MAK. (Please note that non-domain joined machines can still use a KMS, but usually there is a reason they are not domain joined, which may also mean they cannot access the KMS!)
For all the domain-joined, generally on the network machines, use KMS.
In short, go with the “highest” version of server you have available and it can then activate everything “below” it.
For example:
If you utilise the Server 2012 R2 standard key (KMS B), it can act as an activation server for 2008R2/2012/2012R2 standard and Win7/8/8.1, but it cannot activate datacentre editions.
If you utilise the Server 2012 R2 datacentre key (KMS C), it can activate other datacentre editions as well as all 2008R2/2012/2012R2 standard/datacentre and Win7/8/8.1.
“But I only want to license Windows 7 machines!” the response frequently comes back.
A KMS key will also license all products that are “lower” in the tree, so using a server 2012 R2 standard KMS key will allow you to license all windows 7 machines (as well as windows 8/8.1 and server 2008R2/2012/2012 R2)
“So why do I have a Windows 7 KMS key then?” is the next question
This is because it is an option to install a KMS on Windows 7, simple as that. This is something we would generally advise against, as most organisations that use a KMS would use it for their servers and workstations.
Choosing a KMS server – OS Version
Using the newest operating system in your environment generally means that you will not need to download additional updates or patches, so simply for that reason, we would recommend using the newest OS version you have available.
Choosing a KMS server – Server load & placement
The KMS role is a very low-load role and we have never had any issues co-locating it with other roles. One common pairing is placing the KMS role on the SCCM primary site server (for organisations of up to 5000 PC’s)
For larger organisations, we see various approaches. Some have dedicated KMS servers, some co-locate on other services.
This section is here because often people ask what the load is like and can be co-located with other roles. The short answer is, very low load service and it be co-located with anything that doesn’t need TCP 1688.
KMS publishing and load balancing
KMS, by default listens on port TCP 1688 and will (by default) publish a DNS SRV record to allow domain-joined clients to locate the KMS service. The record created is called _vlmcs
Windows 7/2008 R2 and above volume license operating systems automatically look for this DNS record.
SRV records have a weight and priority associated with them, and this, by its nature, allows multiple KMS’ to be published and administrators to use them in a round-robin scenario (same priority) or in a fault-tolerance scenario (different priorities)
It is possible to disable publishing for a KMS service, but this is not something we have ever done – and we are not quite sure of a scenario where this would be helpful (but this doesn’t meant there isn’t one!)
Patching KMS to support Windows 10
In order to support Windows 10, you will need to patch your 2008R2, 2012 or 2012R2 KMS server as per
These steps remain the same whether you are installing on Windows 2008 R2, 2012 or 2012 R2.
Decide which server will host your KMS. We recommend utilising the latest server version you have access to and the highest “edition” (at the time of writing, this is Server 2012 R2 Datacentre)
Logon to the server and open an elevated command prompt (this process will fail if you do not elevate the command prompt!)
C:
Cd windows\system32
Cscript slmgr.vbs /ipk <your product key, with the dashes>
Cscript slmgr.vbs /ato
You now have a KMS server
To verify the install and look at the number of currently activated machines
Cscript slmgr.vbs /dlv
To install the Office KMS host (we will use 2013 in this example, however it is very similar to the 2010 process)
Download the KMS host update from the links above
Run the install
Enter your product key when prompted
To verify the install and look at the number of currently activated machines
Cscript slmgr.vbs /dlv all
Look for the appropriate office 15 (or 14) section
Common questions
Question: I want to move my KMS server, how do I move the activation database etc.?
Answer: There is no activation database or anything that needs to be moved. Simply create a new KMS, install the KMS key and activate. Then decommission the “old” KMS by running slmgr.vbs –upk (uninstall product key) and then either delete the “old” _vlmcs record from DNS, or use slmgr.vbs -cdns
Question: If my KMS client is off the network for more than 180 days, what do I do ?
Answer: Simply re-attach it to the network, it will find the KMS server and renew its activation. If the client will regularly be off the network for more than 180 days, it would be wise to consider using a MAK for this client.
Question: The SRV record has not registered in DNS.
Answer: Sometimes a restart of the KMS service is required. Net Stop sppsvc then net start sppsvc
Sometimes, if an existing record already exists from a previous KMS, you may need to grant permissions over the DNS record, but frankly, its easier just to delete it and restart the KMS service (command above)
Common mistakes
Mistake: Using a KMS key on a number of client machines, either because the difference between MAK and KMS wasn’t clear, or my licensing person gave me the wrong key.
This can be quite easily fixed by changing the key on the affected clients :
Part 1 – identifying affected clients
Open DNS admin, and navigate to <your domain>\_tcp
Take note of all the _vlmcs records – these are all the KMS hosts on your network
Delete the additional _vlmcs records from your DNS
Mistake: Deploying MAK keys in a task sequence, when you actually want to use a KMS.
If you want to use KMS, simply leave the product key section in your task sequence blank.
To “fix” existing clients, you will need to identify the machines with a MAK and install the default KMS key. The VAMT can be used to help identify and update these machines.
Mistake: Using the windows 10 KMS key on a server results in Error 0xC004F015
Recently we had a client who diligently updated their 2012 R2 DC’s to U1 as part of their normal patching cycle – and found afterwards that their 2003 servers were experiencing some “odd” behaviour.
After having a look, sure enough, networking was fine, RPC was fine, all services were fine, but when trying to connect to netlogon, the error: “The specified network name is no longer available” was thrown.
Our experience of the issue was slightly different – in that it did not occur when the 2012 R2 DC’s were first upgraded, only when U1 was applied, in addition, the 2003 clients could connect to the file server which was running 2012 R2 (not u1) without any issues, but had trouble to any file shares on 2012 R2 u1 servers. It is also worth noting that all of these servers had been upgraded from 2008 R2/2012 – none were fresh builds.
The registry change documented in the article worked and all was good with the world. In this instance, the client only had a small number of servers still running 2003 – and this has given them a bit of a hurry up to sort out the apps on these servers.
*edit 24/11/2015 * – The original article seems to have become unavailable… so the changes are:
Install the feature “SMB 1.0/CIFS file sharing support”
