For some reason the last couple of engagements there has been discussions on what its means to run supported hardware for your devices and why that is imported. For me this has always been a no brainer, I refuse to be last person to solve everything. This applied to everything I do, if there is an issue I don’t want to be that last stop, the one everyone expects to magically fix everything. This is especially true for devices so I always make sure the devices that we run are supported.
Now in the old days of Windows 7 this was not a big issue. The same device that was supported 5 years ago was usually still supported later on as well and since the same OS was run all was the same. With Windows 10 its a different story. And before you start screaming about “<insert brand name> should fix this” or “I will switch to <insert other brand name>” you need to consider why this is happening and what the consequences of a change actually are.
So if we look at why, well its pretty simple and as a lot of other things it basically boils down to money. Intel/AMD wants to make more money, they way they do that is to sell more CPUs. To sell more CPUs to enterprise customers (who don’t just change CPUs) they need to speed up how often they release new versions of the CPUs. This together with the fact that newer CPUs are more secure and faster by design means the Microsoft also have to step up and release new versions of the OS more often (exactly how often is a different discussion). But this all means that the vendors have to supply new models with the new CPUs more often and since they don’t want to support a million different models (cost money to support) they move the support cycles.
The other side of this is that even if you where to change to different vendor, odds are they are doing the same thing and you would still have all of your old models laying around and you would still have to deal with them. With all of what that entails both regarding support and firmware updates.
So if we establish that we cannot solve the issue by moving to another vendor the solution is then to have a lifecycle process to make sure old hardware is replace in a timely fashion. This will beside the point of making sure you are supported also make it easier to stay compliant with patching, firmware updates and so as you will get better control on the actual devices running in the your organization.
So there are three links that you should keep track of (since I am assuming you are running one of the big vendors). The list is without any preference and available to help you find the information.
Now two things remain, set the data type to boolean and as compliance set to “True”.
All set to measure this. Of course a simple script or package can now be used to force the setting of this, just remeber that its only supported on Windows 10 1703 and later and will require a reboot before taking effect.
Update 2018-09-07: Michael Niehaus was kind enough to supply some additional information on this subject. So to clarify this post and the information from MS. The currently available versions of Windows 10 Enterprise and Education will have 30 months of support and future releases starting with 1809 and 1903 will have 30 and 18 months of support.
Niehaus has also stated that Microsoft is still commited to deliver innovation and new features for every single Windows 10 release.
So its happend again, the lifecycle supportstatment surrounding Windows 10 has been changed. Some say for the better, but it remains to be seen. The change only applies to Enterprise and Education SKUs and only to the september relase of every year. So if you are on 1703 nothing has changed but if you are on 1607 or 1709 there has been some changes.
The new change is that Enterprise and Education now get 30months of support. There is also a small note to be made about a statment of the lifecycle facts page stating
“…you’ll need to install the latest feature update to help keep your device secure and have it remain supported by Microsoft.”
Which would mean that unless you apply the latest CU every month you are not really supported. How this will be “enforced” remains to be seen.
One last thing to note, up until now Microsoft have only been testing upgrading the previous version to the lastest version of Windows 10, example when 1709 was released the only path that was tested was 1703->1709. With the new support statement you might have an urge to skip versions. However unless Microsoft changes their test protcoll and actually tests jumps like 1607->1709 it might still be worth going with every version, altho not as quickly as before.
When you upgrade to Windows 10 or between diffrent Windows 10 versions there are genearlly several things you wish to do. This can include removing “bad” applications or install drivers. Among some common things that needs to be taken care of is diffrent pre-requisites and language packs. This posts covers some things you can improve in your Windows 10 upgrade sequence.
The small things first. As more and more users are working from a laptop a common problem is that someone intiates the sequence when the users has 10% battery left. Now the predicatable outcome is broken upgrade and rollback. To prevent this we can enable a small check to verify if the machine is running on battery power and if so exit the sequence quickly all while we leave a log trace for admins to track.
Create a package with source files but no program. Then add a Run PowerShell Step in the begning of your sequence. Use the new package that has been created and set the script name to Get-xTSRunningOnBattery.ps1. Set the execution policy to ByPass.
That will take care of machines running on battery. Next common issue is that machines not connected to the wired network won’t reconnect to the network after a restart. To assist with this we can make sure that the upgrade does not run if its not a wired connection.
Create a package with source files and no program then add another Run PowerShell Step in the beginning of your sequence. Use the new package that has been created and set the script name to Get-xTSEthernetConnection.ps1. Set the execution policy to ByPass.
Now we create another package with source files but without any program and add a final Run PowerShell Step to our upgrade sequence. This time at the very end of the sequence. Make sure to use your new package, set the script name to Disable-xTSLanguagePackTask.ps1 and set the execution policy to ByPass.
Now you should be all set to upgrace your machines.
So NIC has come to and end and I was fortunate enought to be selected as a presenter for not one but two session. My first session was about whats changed in Windows 10 in the 2 years since its first release and how to keep up with the changes. The second session was a co-presented session with @nickolajA from SCconfigMgr.com about using community tools during OSD in ConfigMgr and MDT.
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.
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.
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.
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.