Some web apps might not work after installing the June (or July) 2016 Cumulative Update for Windows 10.
After installing June (KB3163018) or July (KB3172985) cumulative updates for Windows 10 a specific web app was broken, when browsing to it in Internet Explorer 11 or Edge lead to ”The page can’t be displayed”.
Looking at the System log in Event Log showed Schannel errors:
A fatal alert was generated and sent to the remote endpoint. This may result in the termination of the connection. The TLS protocol defined fatal error code 40. The Windows SChannel error state is 808.
Doing a network trace showed that the web app server negotiated the TLSCipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA.
Windows as of update https://support.microsoft.com/en-us/kb/3061518 no longer support ciphers with 512-bits. Note that this KB was released in May 2016 but not anywhere stated to affect Windows 10. Nothing related to these changes points to Windows 10, but as we can conclude, these changes are introduced with June 2016 CU for Windows 10 (and thereby carried forward to July CU and any other CU to come).
This issue is quite annoying but as it seems shortcuts to URLs placed in the Start menu is not being returned in the quick search in Windows 10, i.e. press the Windows button and type the name of a Start menu item pointing to a URL. You have to click “Search my stuff” for it to be displayed.
A few customers have a bunch of MSI packages containing shortcuts pointing to URLs which are published in the start menu in Windows 7 and in there being easily findable in the search feature in the start menu. When moving to Windows 10, the user logic comes to a halt when shortcuts in the start menu is not being returned in the quick search.
Steps to reproduce
In File Explorer, go to C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs.
Right click anywhere in the empty space and choose New > Shortcut.
Enter a URL, for instance http://www.microsoft.com, then click Next.
Name the shortcut “TEST URL” and click Finish.
Wait a few seconds and then try to search for it by pressing the Windows key and start typing “test”. It will find nothing which is what one is expecting in this scenario.
Clicking “My stuff” will show the shortcut, and it is also listed in the root of the start menu under All apps. Also, creating a shortcut the same way but to an EXE instead, using the above steps will return it in the search results instantly.
The Microsoft search and indexing team thinks that returning internet shortcuts placed in the start menu means too much “noise” to the users. My opinion is that whatever is found under Start > All apps would also be returned when just pressing the Windows button and starting to type.
Well there are a few workarounds but none are actually appealing nor logical.
GPO Preferences. Yeah you could distribute the Internet shortcuts with GPO Preferences.
Repackage the MSI packages (or by scripting) and point shortcuts to “iexplore.exe http://www.microsoft.com”. This is what Microsoft recommends. Hmm, well is that a good solution? So when the customer wants to switch their standard browser that will this workaround be a good idea? What happened to defining standard programs and URLs open in the browser defined as the standard program? I try to make my customers Windows client environments less complex and more standardized…
To sum it up, the chances of Microsoft actually fixing this problem is very much zero percent chance as I interpret the communication we had with various Microsoft people in this issue.
Anyone who has worked with smart card and Windows clients have probably seen that on rare occasions users can pull their smart card from the smart card reader and the machine will not be locked although it should be locked instantly. As this typically only occur very rarely it is extremely hard to troubleshoot. However, things are coming together with a cause that makes sense and also shed some light on this elusive problem.
A smart card is enforced to be used to login to machines in Windows 7 or Windows 10. GPO settings declare that when the smart card is removed from the smart card reader, the machine will be locked.
When the user removes the smart card from the smart card reader, the machine is not locked (rarely). Most of the times the machine is locked but occasionally the machine is not locked and the user can continue to work inside Windows with the card in their hands.
The Smart Card Removal Policy service has been restarted and when it restarts, the session to keep control over when the smart card is pulled from the card reader is lost and therefore the machine is not locked. The cause of Smart Card Removal Policy service being restarted is when new Windows patches are released and installed on the machines, specifically many of the latest Cumulative Updates for Windows 10 causes the problem. The issue is more rarely seen in Windows 7, likely due to the changes in updating/patching strategy in Windows 7 vs Windows 10 which differs quite a lot.
None by Microsoft as this is by design (bad design I might add). A solution is to use a third party smart card tool that provides its own service to lock the machines.
The restart of this service does not trigger any events in the Event Viewer so we cannot trigger on anything. By design the machine should be locked whenever the Smart Card Removal Policy service is restarted but that does not happen. Could there be problems with that design? Probably, otherwise I suppose it would work that way already Microsoft!? :)
Just a quick note to myself as well as maybe helping others out. If you open a PDF file in Microsoft Edge (Windows 10 RTM version or latest Insider Build 10547) and try to print the PDF file only one or two pages come out from the printer, over and over again.
For example if you print a 15 page PDF file, the first page of the PDF file comes out over and over again, or the first two pages over and over again.
Solution: Open the PDF files using Adobe Reader and print without problems.
One of the things you can and should do before moving to Windows 10 is to deploy Internet Explorer 11 on your existing machines. But if you think that means you are safe in terms of then moving to Microsoft Edge and be running with all the latest and greatest of web standard, you’d better think again. Why?
Well ever since Internet Explorer 8 the setting “Display intranet sites in Compatibility View” has been enabled. Really what that means is that although you have moved to IE11 the chances are very likely that all your LOB web apps and all intranet based sites have been running in IE7 mode the last 10 years or so, at least after moving to IE8. That’s not very good to be honest.
The solution to really be future-safe is to make sure to unset that setting to actually run all your sites in IE11 mode. This can of course be done using Group Policies by setting the policy “Turn on the Internet Explorer 7 Standard Mode” policy. However when doing that expect things to break so I strongly advise you do some thorough testing Before deploying that setting to your entire organization.
Most books written about Microsoft products are very focused on one single product. A book about Windows Server covers all you need about the server OS itself. A book about System Center Configuration Manager covers everything you need to know about ConfigMgr in its bubble and a book about a Windows client covers everything you need to know about the client itself.
Consider the following scenario: A user has a Windows client running UE-V (User Experience Virtualization) and IE 11 and everything in regards to Enterprise Mode in Internet Explorer 11 is working fine. The user then gets a new machine or logs into another machine let it be a client or for instance Remote Desktop session and then Enterprise Mode in IE11 does not work at all. The URL:s defined in the Enterprise Mode XML ruleset file are not applied when the user browse a web application defined for Enterprise Mode.
The problem is a consequence of UE-V roaming the Enterprise Mode registry key HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\Enterprise Mode where it lists CurrentVersion with the current version of the XML file that is being used. So basically that means that Enterprise Mode think it has already applied the current ruleset although it has not.
Solution / Workaround
The workaround to prevent this scenario from happening is to exclude that registry key from being roamed. In the MicrosoftInternetExplorer2013.xml file scroll down to <Application> <Name>Internet Explorer 11</Name> and add an additional exclusion to the other exclusions already listed under <Registry>:
For users that are already affected by the problem one must delete the registry key mentioned above and make sure that it is not synced back from the IE package in the SettingsPackages location (MicrosoftInternetExplorer.Version11 package).
To demonstrate how Windows is being optimized over time (i.e. from Windows 7 x86/x64 to Windows 8.1 x64) I have made a very fundamental performance benchmarking of the Windows memory consumption. The benchmarking has been done in a virtualized environment. Before measuring the below numbers the clean installation of Windows has been left idle for 5 minutes, then had a reboot. This was been repeated three times after which the below numbers were gathered:
The conclusion is that Windows 8.1 in its x64 edition is basically consuming as much memory as the 32-bit version of Windows 7 and running smoother with fewer processes running. Windows 7 64-bit is consuming some 100 megabytes+ compared to Windows 7 32-bit.
Many thanks to all of you who attended my session yesterday. So here is a summary of the key takeaways from my session “Preparing for Windows 10” at TechDays Sweden 2014 November 19th. Consider this an action list in what you can do todayto prepare yourself form Windows 10.
Yeah, it is so boooooring, but still a golden opportunity to make your client environment more standardized and less complex. Make sure to remove GPOs and GPO settings that are not necessary, remove or replace scripts, applications or components that are not needed. Also, if you have a Premier support agreement with Microsoft, do use the RAP as a Service for Windows Desktop to let Microsoft do an analysis of your environment and suggesting remediation.
App compat when moving from Windows 7 to Windows 8.1 or 10 is practically 99%+ success in terms of regular Win32 based applications. Still actual testing of applications needs to be done for business critical applications.
New way of doing inventory in Windows 10
There are new WMI classes in Windows 10 that can be used to collect software inventory. The information can be displayed using PowerShell. Also, there is a feature that inventories what framework or runtime an application is dependent on, for instance which version of .NET Framework or Visual C++ Runtime and it can even see if there are dependencies for OpenSSL. Imagine having these feature in place when the HeartBleed bug appeared earlier this year.
Display all installed applications on a Windows 10 machine:
What I forgot to mention in yesterday’s session was that these feature are being back ported to previous Windows versions, as that is where you’d typically want to run the inventory, but much of the feature regarding this new way of doing inventory is still work in progress.
Applications in a mobile world
With Windows 8.1 and Windows 10 and the new types of devices that make users more mobile gives other challenges. It is one thing that the OS and devices are great at supporting a mobile work scenario, but without apps that also adhere to this environment you will have challenges. Make sure that the technology to deliver the user experience is evaluated, upgrade the user interfaces where necessary or port them (or parts of them) to modern apps.
In terms of moving to Windows 8.1 or Windows 10 you will face the most application compatibility challenges with IE11 and web apps. After the summer Microsoft announced that from January 2016 only the latest version of IE will be supported on the currently supported OS’s.
Are you running your intranet sites in IE7 mode?
Regardless if you run IE8, IE9, IE10 or IE11 you are very likely to (without knowing it) running all or many your internal web apps in IE7 mode, due to this nasty little settings still being default in Windows 10 and IE in Windows 10.
That is the setting that you will find by going go Tools menu and then Compatibility View settings. The setting which I strongly recommend to uncheck (set it via Group Policies) is called “Display intranet sites in Compatibility View”. I have seen this setting causing problems with web apps because modern web apps and systems stop supporting IE7 and thereby not working in IE11.
Deploy Internet Explorer 11 today!
Well, deploy IE11 today and start working with compatibility testing your web apps!
IE11 Enterprise Mode
Enterprise Mode in IE11 is a compatibility mode that runs web apps in IE8 mode to make them work on IE11. With the November 2014 CU update for IE11 you will be able to not only set web apps to run in IE8 mode but also any document mode such as IE10, IE9, IE7 or even IE5.
For those of you already running IE11 – inventory tool!
Not long ago Microsoft released a little tool that will inventory all the web sites a user visits to provide means to get a grip on web app compatibility. The inventory is activated on specific clients (or all if that is OK in terms of integrity etc) and is collected via WMI to for instance System Center Configuration Manager. There are pre-made reports that can be used. More on Enterprise Site Discovery Toolkit for Internet Explorer 11.
Taming the user interface for Windows 8.1 enterprise users
A good thing to prepare for Windows 10 is to deploy Windows 8.1. Some time ago I wrote a blog post on how to customize the user interface in Windows 8.1 to make it work as expected and make it easier for the end users. Read the blog post Taming the user interface for Windows 8.1 enterprise users.
Install Windows 10 Technical Preview
Of course you can and should install Windows 10 Technical Preview for a number of reasons. Test applications, test in-place upgrade and last but not least, provide Microsoft with feedback either using the built in Windows Feedback app or via UserVoice. This is a unique opportunity to still influence how and what Windows 10 will be!
Windows 8.1 and Windows 10 have a security feature that is dependent on that a machine is installed in UEFI mode, that is Secure Boot. UEFI replaces the 30 year old BIOS that has “always” been around. Note that Microsoft talks very much about in-place-upgrades from previous versions to Windows 10. However, as switching to UEFI demands that you reinstall your OS you will not be able to get the full benefit of Windows 8.1 or Windows 10 if you are running your machines in legacy boot mode.
Figure out if your machines are running in UEFI and if not, make sure that you have an infrastructure that supports it and that you switch to UEFI mode in your client machines BIOSs’.
The easiest way to determine if you are running in UEFI mode is to run msinfo32.exe (only in Windows 8/8.1 and Windows 10). There is a new line that clearly displays that.
If running Windows 7 (or later) you can determine if running in UEFI mode by starting diskmgmt.msc and note if you have an EFI system partition. If you do, you are running in UEFI mode.
If you have Configuration Manager you can look at the pre-made report Hardware – Disk > Disk information for a specific computer – Partitions to see if you have machines that either are running in Legacy/BIOS mode which will have partitions named “Installable File System” or UEFI machines that will have GPT partitions and in particular a GPT System partition.
If you haven’t already done so look into Azure AD and what is has to offer. The cloud connections in Windows 10 will be significant!
There are quite a few things you can do to prepare yourself for Windows 10 so that you are ready when Windows 10 is released sometime next year. Happy Windows 10’ing!
I’ve encountered quite an interesting issue when deploying a custom iOS (IPA) app using System Center Configuration Manager and Intune. The problem is that the deployment status for the app never reports as “Success” and is hung at “In progress”. As it turns out there is a mismatch in the version info that exist within the IPA file and the plist file that is included when deploying the IPA.
The CFBundleVersion listed within the IPA in the file info.plist
must match the bundle-version found in the plist file that is used when creating the app deployment in Configuration Manager.
If these values do not match the status will never be reported as successful in the ConfigMgr console. After the September 2014 maintenance window for Intune I also suspect that this version mismatch is causing the app to be re-deployed over and over again, however this has yet to be confirmed.
Note: You can easily check the content of info.plist within the IPA by renaming the IPA to ZIP and extract its contents. Use a plist viewer of your choice (there are several free for trial) to check the CFBundleVersion.