Microsoft products – consolidated table of end of life dates

Microsoft product end of support dates are sometimes not easy to find and its not getting any better with the “current branch” releases and cloud solutions being governed by the Modern lifecycle policy.

The Modern lifecycle policy page further links to 3 product catagories, O365, Cloud platform and Dynamics. Unfortunately, its not clear (at least to me) how this helps with products such as SCCM current branch (be it 1606, 1702, 1706, 1710 or 1802) – however this information is available at another location

Likewise with the “traditional” products, most end of life information is available here – but to say that the information is difficult to search through is an understatement.

It also sometimes lacks detail, for example, there is no metion of the differing support for Windows 8.1 without update 1 and with update 1.

We have a number of clients that take the approach that while a server is running, to leave it there – and while I may personally not like this approach (i prefer to roll through the OS upgrades as they come out) – they have a valid approach and end of life information is important for them.

Keep in mind that everything listed below is end of extended support, not mainstream support – and i have taken some liberties (e.g. assumed that windows 8.1 is 8.1 with update 1)

Windows 10 dates have been sourced from the product lifecycle page, however this blog entry states than an additional 6 months has been granted to displayed Windows 10 versions.

If you find the below useful – cool. If i’ve got something wrong, or missed something that is key (in your opinion), please leave a comment.

 

ProductEnd of life date (end of extended support)
Windows 2003 SP2July 14, 2015
Windows 2008July 12, 2011
Windows 2008 R2 SP1Jan 14, 2020
Windows 2012Oct 10, 2023
Windows 2012 R2Oct 10, 2023
Windows 2016Jan 11, 2027
Windows XP SP3Jan 11, 2011
Windows Vista SP2April 4, 2017
Windows 7 SP1Jan 14, 2020
Windows 8Jan 12, 2016
Windows 8.1 with update 1Jan 10, 2023
Windows 10 RTM (1507)May 9, 2017
Windows 10 1511Oct 10, 2017 (End of support)
April 10, 2018 (additional servicing for enterprise and education)
Windows 10 1607April 10, 2018 (End of support)
Oct 9, 2018 (additional servicing for enterprise and education)
Windows 10 1703Oct 9, 2018 (end of support)
April 9, 2018 (additional servicing for enterprise and education)
Windows 10 1709April 9, 2019 (End of support)
Oct 8, 2019 (additional servicing for enterprise and education)
Office 2007Oct 10, 2017
Office 2010 SP2Oct 13, 2020
Office 2013April 11, 2023
Office 2016Oct 14, 2025
Lync 2010April 13, 2021
Lync 2013April 11, 2023
Skype for Business 2015April 11, 2023
Exchange 2010 SP3Jan 14, 2020
Exchange 2013 SP1April 11, 2023
Exchange 2016Oct 14, 2025
Forefront TMGJuly 12, 2011
Sharepoint 2010July 10, 2012
Sharepoint 2013 SP1April 11, 2023
Sharepoint 2016July 14, 2026
SCCM 2012 SP2July 12, 2022
SCCM 2012 R2 SP1July 12, 2022
SCCM 1606July 22, 2017
SCCM 1610Nov 18, 2017
SCCM 1702March 27, 2018
SCCM 1706July 31, 2018
SCCM 1710May 20, 2019
SCCM 1802Sept 22, 2019
SCVMM 2012 SP1July 12, 2022
SCVMM 2016Jan 11, 2027
SCOM 2012 SP1July 12, 2022
SCOM 2012 R2July 12, 2022
SCOM 2016Jan 11, 2027
SCORCH 2012 SP1July 12, 2022
SCORCH 2012 R2July 12, 2022
SCORCH 2016Jan 11, 2027
SCSM 2016Jan 11, 2027

Microsoft Surface Laptops and SCCM OS Deployment

So you’ve just picked up your shiny new Microsoft Surface Laptop and want to put your current Windows 10 Enterprise SOE on it. Of course you have it all set up in SCCM (right?), so you figure you’ll kick off a build and be up and running in a half hour or so.

Granted, the Surface Laptop isn’t marketed as an Enterprise device and comes with Windows 10 S pre-installed, but you can do a simple in-place upgrade to Windows 10 Pro. So obviously it should be capable of running any of the Windows 10 OS’s (which it is).

Unfortunately it’s not quite so simple to get them to build through SCCM. Below are the three issues I experienced when trying to build one via SCCM (and was silly enough to think it’d be straight plug and play!):

  • PXE doesn’t work. I’ve got a couple of USB to Ethernet adapter that works fine with PXE on other devices – but they simply don’t work with the Surface Laptop. Updated the firmware on the laptop to the latest (as Surface Pro’s had similar issues with old firmware), and still had the same issue. Whether this is unique to the Surface Laptop I have, or all of them – I’m not sure (as I’ve only got the one so far).
  • The keyboard doesn’t work in WinPE. Touchpad mouse works fine – so you can kick off the task sequence – you just can’t use the keyboard at all. Fine if your task sequence is fully automated, but if you need to enter a computer name or troubleshoot issues, you’re going to need to import some drivers.
  • SecureBoot. Once I’d decided to use a bootable USB to kick off the task sequence, it started running through fine. Rebooted into Windows Setup, then proceeded to complain about the “Microsoft-Windows-Deployment” component of the Specialize pass in the Unattend.xml. Long story short, it’s caused by SecureBoot (more on this further down).

So lets break this down into how to fix each.

PXE: Simply put, I haven’t been able to fix this. Updated firmware, used different PXE capable USB to Ethernet devices. As above, I’m not sure if this is just the one I have, or all of them – or even if it’ll be fixed in newer firmwares. At this stage, it looks like the only option is SCCM boot media. Since the Surface Laptop only has a single USB port, you’ll either need to use a USB/Ethernet combo (like one of these – not sure if they’re PXE capable or not, haven’t tested), or you’ll need to use an external USB hub. Note: you can initiate PXE from full power off by pressing Volume Down + Power. If you want to USB boot, you need to go into the UEFI setup by pressing Volume Up + Power. On the boot settings page, you can swipe left on any of the boot options to initiate a ‘boot now to selected device’.

SecureBoot/Unattend.xml: This one is a little more tricky. Essentially if you look at the setupact.log file, you’ll see something along the lines of “[SETUPGC.exe] Hit an error (hr = 0x800711c7) while running [cmd / c net user Administrator /active:yes]“. 0x800711c7 translates to “Your organization used Device Guard to block this app”. According to this Microsoft article, it’s due to the Code Integrity policy in UEFI being cleared as part of the OS upgrade (from Windows 10 S to something else). Since Windows 10 S won’t let you launch certain executables, it blocks them during the OS Deployment as well. Supposedly fixed by a reboot – but by then you’ve broken your OS deployment. The obvious fix is to disable SecureBoot, then re-enable it after the task sequence completes. I’m not really a fan of this approach, and I’m not sure how you’d automate it (even if you could).

During my research, I found a reference to someone suggesting that applying the Surface Laptop drivers during the OS Deployment actually fixes the issue. I’m not 100% sure if this is the case – as I disabled SecureBoot, rebooted and re-enabled SecureBoot before testing out this process – but doing so afterwards did actually work (with SecureBoot enabled). Since I’ve only got the one device so far, I’ll update this blog once I’ve tested on others. I’ve put some instructions further below on how to import the drivers into SCCM (as they’re provided in MSI format now, and you’ll need them to apply before Windows Setup).

Keyboard during WinPE: Essentially, you need 5 drivers imported into the boot image for the keyboard to work (as detailed by James in this technet blog) Below is an image of the drivers required in the boot image:

Adding Surface Laptop Drivers to SCCM

Surface drivers all now come in MSI format – which is good for normal deployments, but doesn’t really help you for OS Deployments (assuming you want to apply the drivers prior to Windows Setup). After downloading the latest Surface Laptop drivers from Microsoft, you can use the following example command to extract them (which goes from around 300MB to a whopping 1.3GB):

msiexec.exe /a C:\Temp\SurfaceLaptop_Win10_15063_1802008_1.msi targetdir=C:\Temp\Extract /qn

From there you can import the “Drivers” sub-folder into SCCM as per usual. If you plan on applying them as a proper ‘Driver Package’ during the OS Deployment, you’ll need to import them into their own driver package, distribute it to the relevant Distribution Points, then add it to the task sequence. You can use the following WMI query to filter it to just Surface Laptops:

SELECT * FROM Win32_ComputerSystem WHERE Model LIKE “%Surface Laptop%”

Obviously you can now also add the keyboard drivers to the required boot image!

Azure AD Connect – Permissions Issues

I’ve had various versions of AD Sync/Azure AD Connect running in my development environment over the years, and have used a number of different service accounts when testing out different configurations or new features. Needless to say, the permissions for my Sync account were probably a bit of a mess.

Recently, I wanted to try out group writeback. It’s been a preview feature of Azure AD Connect for quite a while now – it allows you to synchronise Exchange Online groups back to your AD environment so that on premise users can send and receive emails from these groups.

Launched the AADConnect configuration, enabled Group Writeback, then kicked off a sync. Of course, I start getting ‘Access Denied’ errors for each of the Exchange Online groups – couldn’t be that easy!

Generally speaking, you need to also run one of the “Initialize-<something>Writeback” commands. When I went looking for the appropriate commands (as I don’t remember these things off the top of my head!), I came across an interesting TechNet Blog article: Advanced AAD Connect Permissions Configuration – it’s pretty much a comprehensive script that handles all the relevant permissions (including locating the configured sync account and sync OUs).

Gave it a whirl, entered credentials as required, and what do you know – permissions all now good!

Microsoft Surface Pro With 4G in Australia, and the people rejoiced!

It’s been a loooooong time coming, but it’s almost here!

A number of our clients provide Surface Pro’s for their staff, and for what seems a very long time, have been complaining about the lack of a Surface with LTE. It seems like such a simple thing, yet Microsoft haven’t released it in Australia. IT departments have gone out and purchased a number of other devices to try and meet the requirements, some have been successful, others sooo very not so, but all have added complexity or diversity to the number of devices that these departments have had to provide and support.

But the wait looks to be over, the Surface Pro with 4G is set to launch in April. You can pre-order specific hardware configurations now from the Microsoft Store, Harvey Norman and JB Hi-Fi.

Microsoft Surface Pro With 4G: Australian specifications

Microsoft Surface Pro With 4G
OS Windows 10 Pro
Dimensions (mm) 292.10 x 201.42 x 8.5 mm
Weight From 768g
Storage Solid state drive (SSD) options: 128GB, 256GB, 512GB, or 1TB
Display Screen: 12.3” PixelSense Display, Resolution: 2736 x 1824 (267 PPI), Aspect Ratio: 3:2, Touch: 10 point multi-touch
Battery life Up to 13.5 hours video playback
Processor Intel 7th Gen Core m3, i5, or i7
Graphics Intel HD Graphics 615 (m3), Intel HD Graphics 620 (i5), Intel Iris Plus Graphics 640 (i7)
Security TPM chip for enterprise security, Enterprise-grade protection with Windows Hello face sign-in
Memory 4GB, 8GB, or 16GB RAM
Wireless Wi-Fi: 802.11ac Wi-Fi wireless networking, IEEE 802.11 a/b/g/n compatible, Bluetooth Wireless 4.1 technology, LTE Advanced (optional)
Ports Full-size USB 3.0, microSDXC card reader, Surface Connect, 3.5mm Headset jack, Mini DisplayPort, Cover port
Cameras, video, and audio Windows Hello face authentication camera (front-facing), 5.0MP front-facing camera with 1080p Skype HD video, 8.0MP rear-facing autofocus camera with 1080p Full HD video, Dual microphones, 1.6W Stereo speakers with Dolby Audio Premium
Sensors Ambient light sensor, Accelerometer, Gyroscope
Warranty 12 months limited hardware warranty

Now all I need is a compatible external battery, I have been less than impressed with the support of the current 3rd party battery that was purchased.

https://arstechnica.com

https://www.lifehacker.com.au

Reducing your Risks

As I’m sure you’re all aware, there was another vulnerability advertised to the general public over the Christmas new year period, and if you’ve been following the details, the patches to fix this specific vulnerability have been recalled. The advice from Intel and other vendors currently is, “don’t deploy the patch as it can cause system instability and in some circumstances cause data loss or corruption”. Good stuff!

Update: Intel releases Spectre fix for Skylake CPUs only

Protecting against vulnerabilities like this and many other security threats is a multi-layered approach, if you’ve got these layers of protection in place, then the risk of your computers being impacted by any of these vulnerabilities is greatly reduced.

Removing Admin rights
First and foremost, to protect your network and computers, you should be granting user’s with sufficient rights to do their job, nothing more. In our opinion, users very rarely need Administrative rights over a computer. Users in an Enterprise environment shouldn’t be installing software as they please, not only does this prevent system changes from being made, intentionally or otherwise, it also allows the IT department to maintain control of your software licensing.

One issue we tend to face when suggesting or implementing the removal of Admin rights, tend to be those joyful applications that sing out in protest. Most of these well written applications may simply require write access to the local machine registry hive, or write access to the application install location. You can use tools such as ‘Process Monitor’, system instability can in some circumstances cause data loss or corruption troubleshoot these applications and then granting the users write access to the require locations. This is far more secure than granting blanket Admin rights of the entire computer, or computer fleet!

Application Whitelisting
Not all vulnerabilities or malicious code require administrative access, a user accidentally running a crypto locker application will cause more than enough headaches when all the network shares they have access to become encrypted. This is where Application whitelisting comes in. Using Group Policies AppLocker we can ensure that only authorised applications (e.g. programs, software libraries, scripts and installers) can be executed. The default rules you can create with AppLocker, allow applications installed in the ‘Program Files’ and Windows directories to run without hindrance. You can then extend these rules to allow additional applications to run as needed for your environment, and as you’ve removed Admin rights from your users, they wont have write access to these locations.

Blocking Attachments
By far the most common distribution of malware I’ve experienced has been via E-mail attachments. I’m sure, like me, you’ve lost count of the number of times you’ve told friends, family, users, don’t open emails or attachments you don’t know, but let’s face it, that’s a losing battle, especially when one of these people get infected, and then start sending out emails unknowing to their address list containing a malicious payload. Most malware I’ve seen attached to emails has been either
an executable or script directly attached to an email, or in a zip file attachment, there are very few reasons a standard user would be sending these types of attachments via email, I’d even argue that IT users should also be using alternative methods for transferring these files. It may simply be a case of changing the script file extension to txt, which then at least requires the users interaction before it will run. In the enterprise environment, I strongly suggest setting up rules in your email system to block or quarantine any email with an executable attachment (including scripts) or any zip file attachments that include executable files.

If you’d like any assistance or guidance in implementing any of these measures in your environment, feel free to contact us, we’d be happy to help.

Meltdown and Spectre patches available

Hi all,

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”.

You can find more detail on these Vulnerabilities  here – https://meltdownattack.com/

Advice for Microsoft client OS’s is here – https://support.microsoft.com/en-us/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in . The page still indicates to “contact your vendor” for microcode updates – which isnt going to overly helpful for standard end-users.

Advice for Microsoft server OS’s is here – https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution. There is additional work required over and above the patch for Remote Desktop and Hyper-V servers. Additionally, Windows server 2008 and 2012 are not yet patched, only Server 2008 R2/2012 R2/2016/1709 – read into that what you will.

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.

Project Honolulu

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.

Server 2016 LTSC vs Server 1709 Semi-Annual

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.

 

Preparing to update for Intel® Management Engine Critical Firmware Update (Intel SA-00086)

Intel released a security advisory yesterday (22/11/2017) advising of vulnerabilities with their management engine firmware – which can he found here

The reason why this is concerning for corporate customers is that basically every PC, Server and laptop that you have, most likely will be exposed, as the vast majority of corporate level hardware contains this hardware.

Intel has provided a detection tool available at https://downloadcenter.intel.com/download/27150. Contained within is a couple of applications, the GUI version will probably be handy for those orgs with only a handful of makes and models – where-as the command line tool will be more useful for larger organisations to run and centralise results via tools such as SCCM.

 

The original page contains links for various vendors update, the downside is that there doesnt seem to be many patches as yet, as per this page (at the time of writing, all Dell entries are marked as “TBD”, where-as Lenovo lists a target date of 24/11/2017)

 

So, what can you do while waiting for the patches to be released?

  • Test your systems using the provided tool to see if they are vulnerable. Testing at least one of each make/model will give you a good idea what you will need to target
  • Setup SCCM collections ready to go, which would entail
    • A collection for each make and model (I imagine many places would have this already)
    • A series of collections which each include one/make model and the criteria “AMT Agent – Flash is NOT equal to <insert version number of patched FW – once released>” – This will enable you quickly identify machines which need to be targeted with the update
    • (Please note the above is an assumption, some vendors may patch this via a BIOS update, in which case, the BIOS version may be the identifier instead)

 

Please post a comment if there are any questions – and ill update thios post once the patches are released – if there are any gotcha’s we run into.

KB4038777 fails on some Windows 2008 R2 servers

Recently, we had an issue where KB4038777 was failing to install on some Windows 2008 R2 servers, but was fine on others.

Sometimes, this indicates that the “maximum run time” on a patch has been set ludicrously low (generally 10 minutes) on a specific patch – and the servers that it is failing on, are those that don’t perform so well – and therefore time out.

In this case, the patch was failing with the following line in the CBS.log

Failed to find file: x86_microsoft-windows-directwrite_31bf3856ad364e35_7.1.7601.23688_none_c657164201eacd8d\DWrite.dll [HRESULT = 0x80070002 – ERROR_FILE_NOT_FOUND]

We tried a number of things to “fix” this, including comparing file versions of Dwrite.dll, cleaning out the softwaredistribution cache, disabling AV etc – to no avail.

After a few hours, we found that installing the “desktop experience” feature (which requires a reboot), then running a disk cleanup (including windows updates) on the server then allowed us to install this update.

Its not an ideal “solution” – and quite frankly – all Windows 2008 R2 server should be in the process of being decommissioned… but aside from that, it seems that admins have the option of

a) installing desktop experience, rebooting, then running a disk cleanup

b) waiting for next months rollup – which may not have the same issue.