Application services not migrated when upgrading from one Windows 10 build to another when path contain forward slashesPosted on February 14th, 2017 No comments
It seems that some applications (none mentioned and none forgotten) create services where the path to the service is written with forward slashes. The migration engine in Windows 10 does not recognize this as a valid path and therefore do not migrate those services and they are thereby missing after upgrade.
The following can be found in the setupact.log (located in C:\Windows\Panther) after upgrading Windows 10 to a new build:
2017-02-07 16:07:42, Info [0x08056f] MIG Start processing unit="Services"
2017-02-07 16:07:42, Warning MIG CAddSystemServicesExpander::ExtractImagePath: Failed to extract file path from APP_Service::ImagePath=["C:/Program files/Vendor/Product/APP_Service.exe"]
The solution is to make sure the application is installing the service with a path that contain backslashes instead of forward slashes.
Posted on February 8th, 2017 No comments
After filing this as a bug the first time in November 2015, as of February 6th 2017 the fix for searching for Internet shortcuts (LNK and URL files) placed in the start menu is here at last! Now when doing a search in all Windows 10 editions (1511, 1607 and the latest and upcoming Red Stone 2 build a.k.a. “Creators Update”) internet shortcuts (i.e. links to web applications) are returned in the search results as one would expect.
There are a few things to note though:
- The change is done by the Bing team and it is a server side update. This means the search components are updated in the background automatically, unless you are blocking silent updates.
- Only LNK and URL files that are placed in the start menu are returned in search. That is C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs or C:\ProgramData\Microsoft\Windows\Start Menu\Programs.
- You must make sure the GPO “Don’t search the web or display the web results in Search” is set to “Disabled” or “Not configured” (located in Computer Configuration\Administrative Templates\Windows Components\Search).
Thank you Microsoft!
Posted on December 9th, 2016 No comments
A cause of error 0x80070241 when upgrading a Windows 10 to Windows 10 build is that you may have the latest Windows ADK Insider Preview (build 14965) installed. The solution is to uninstall the Windows ADK Insider Preview and then perform the upgrade. The issue is caused by some interference with the DISM tool, and the setuperr.log points to problems mounting the WinRE.wim file. This occurred trying to upgrade from Windows 10 build 14971 with Windows ADK 14965 to Windows 10 build 14986.
Posted on December 9th, 2016 No comments
Having deployed many thousands of Windows 10 machines over the last year I must say that I am surprised by the large number of blue screens that have occurred and still occur on Windows 10. As always, hardware issues surface when deploying a new OS, but the vast majority of blue screens that occur are actually caused by bad drivers.
Things are shaping up and nowadays Windows 10 and its drivers are more stable then a year ago but still there are quite a few blue screens caused by primarily bad graphics drivers and not to mention WiFi drivers from the most prominent chipset maker in the business.
Therefore I have made some updates to this popular guide – troubleshoot and analyze blue screens of death – how to figure out what the infamous blue screen of death is caused by.
Updating drivers on an active basis is very much necessary in terms of deploying and managing Windows 10 if you want to keep blue screens away!
Microsoft changes search feature in Windows 10 v1511 using sneaky background delivery options – this is Microsoft “Searchgate”!Posted on August 12th, 2016 1 comment
So in Windows 10 1511 and 1607 I have an issue with searching for internet shortcuts as outlined in this blog post. For Windows 10 1607 things seemed to get worse. But, then I noticed in Windows 10 version 1511 as well that all of a sudden “Search my stuff” was gone although it had been there before! The investigation reveals some interesting stuff and magic things happening in the background!
SHORT SUMMARY: Microsoft is pushing Windows 10 1607 (Current Branch) search features to Windows 10 2015 LTSB and Windows 10 1511 (Current Branch for Business) silently and in the background without any announcements made.
Search in 1511 (as when Windows 10 entered Current Branch for Business and as long it has not been connected to the Internet):
1. I installed Windows 10 1511 (media updated in april 2016) in a VM – with no Internet connection. Note: system language is set to Sweden (Swedish) during install.
2. I logged in and noticed that “Search my stuff” was there.
3. I then thought I’d connect the machine to Windows Update to get the latest CU and see what happens after that. But before I knew it, “Search my stuff” vanished just after connecting the machine to the Internet. Now, things are getting interesting!
1. I installed Windows 10 1511 (media updated in april 2016) once again in a VM – with no internet and system language set to Sweden (Swedish).
2. I logged in and noticed that “Search my stuff” was there.
3. Checkpoint created in Hyper-V :)
4. Fired up good old Resource Monitor.
5. Connected the VM to Internet.
6. AS SOON AS I CLICKED THE WINDOWS FLAG IN WINDOWS – things started to happen in the background!
A process named BackgroundTransferHost.exe started to download new packages, including what seemed to be new and updated code for the Shell and Cortana!
7. When it finished downloading – Voílà – the search box in Windows 10 1511 looks very much a lot like in 1607 and yes, the option “Search my stuff” is gone.
This raises more than a few questions:
What else is changed using this background delivery manager? Can we expect the start menu in 1511 to look like 1607?
Is background delivery the reason why MS always writes “No new operating system features are being introduced in this update” on any CU:s released? I mean, “no new features are introduced in the CUs but we will gladly publish (new and) changed features unannounced using other delivery technologies than Windows Software Update packages (CUs)”. (https://support.microsoft.com/en-us/help/12387/windows-10-update-history )
I thought the whole idea of different builds (1507, 1511 and 1607) would mean no feature changes and especially no new feature changes which are completely unannounced or did I miss this announcement in feature change?
Is Windows 10 LTSB affected by this as well? UPDATE! Windows 10 2015 LTSB is affected by this as well which should be troublesome for Microsoft as Cortana is not supposed to be there and it is supposed to be feature locked.
Does this mean you can easily deploy a feature change/fix to my machine so that internet shortcuts are returned in the search results?
No further questions on this – I’m still shocked!!!
Posted on August 5th, 2016 1 comment
This is a follow up to the post “Internet shortcuts in the Start menu not returned in quick search in Windows 10“. The plot thickens quite a lot with Windows 10 v1607.
UPDATE February 8, 2017: The fix is out! Read more in this blog post: LNK files now searchable in Windows 10 search (Cortana / Start menu search)
UPDATE August 21, 2016: In a newly opened support case with Microsoft they have come to the conclusion that this is a code defect and will be fixed, for both LNK as well as URL files. Question is when it will be fixed, and (*irony*) if it will be distributed quickly in the background using the sneaky update method I wrote about in a recent blog post.
UPDATE August 12, 2016: It seems that Microsoft has also introduced this change in Windows 10 v1511! The option “Search my stuff” in the search box in the start menu and task bar is long gone! Read more about the sneaky update of the search feature in not only 1511 but also 10240 (CBB and LTSB).
It is no secret that web applications become more and more common for every day that passes and that has been the case for many years now. I know Microsoft wants and thinks that everyone is now turning all their Line of Business applications into modern apps but that’s just not the case just yet. This is a fact on how it looks in the real world. With that said, the problem here is that Internet shortcuts in the start menu that points to a URL is listed in the Start menu list of applications but they are not searchable in the Windows search feature.
Now things get interesting and at the same time worse! In Windows 10 v1511, you can search for an internet shortcut by typing its name and then choosing “Search my stuff”. In 1607, this option is gone. So without applying any workarounds the user must go back to find the web application by manually browsing through the long applications list in the start menu. So, with that we can tell all the users we for 10 years have tried to learn to use the search feature now to go looking for applications manually in the start menu. Well done Microsoft!
Lapse in logic? I and users expect that whatever application can be seen in the start menu (EXE, modern apps or web apps) is also found when doing a search! As described above, this is not the case in Windows 10 version 1607.
Yes, there are workarounds, but only crappy ones.
- You can exchange all LNK and URL:s and point them to iexplore.exe URL, i.e. “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 will this workaround be a good idea? This workaround kind of defeats the idea of 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 but this workaround points in the opposite direction to that.
- You can also instruct the users to open the web site in Internet Explorer 11 and choose “Add Site to Apps”. By doing that you get a shortcut with the extension .website which is listed in the Start menu AND apart from that also being indexed and searchable! Is it possible to create these .website files and distribute? Not quite, as these were invented for IE9 where users could pin websites to the Task Bar, and are intended to be pinned by the user, not programmatically. Also, .website files are always opened only in Internet Explorer regardless if you set the OS standard browser to Edge or some other browser.
To sum it up, am I the only one having customers with internet shortcuts in the start menu? The reason they are there is that I do not want users to have to distinguish if a Line of Business application they use for their daily work is a EXE file or a web application (or a modern app for that matter). I expect them all to be treated the same as well as existing in the same place. I expect that EXE applications are returned in the search results. I expect modern apps to be returned in the search results and I expect web applications (internet shortcuts) to be returned in the search results.
That is just simple logic in my world but who knows, I might be all crazy. I know 10000+ users that must think Microsoft are crazy when they are forcing users to go back to manually finding stuff instead of using search!
There is no solution so I appeal to Microsoft and specifically the Search team, that you repair the lapse in logic that exist in the current implementation in Windows search in Windows 10 1511 and 1607!
Posted on August 4th, 2016 No comments
In Windows 10 v1607 Anniversary Update there is a brand new UI for sharing your internet connecting and creating a mobile hotspot. The feature has been there in Windows before but has previously required administrative privileges to activate. Starting with Windows 10 v1607 this is exposed in the modern interface under Network > Mobile Hotspot and can be activated as a standard user, posing a security threat if you for instance have network security in place which can then be circumvented.
Using GPO, you can disable Mobile Hotspot in the UI by settings the GPO setting Prohibit use of Internet Connection sharing on your DNS domain network to Enabled. This settings is located under Computer configuration > (Policies) > Administrative templates > Network > Network Connections.
If you are using MDM, you can also configure this with this setting:
URI full path: ./Vendor/MSFT/Policy/Config/WiFi/AllowInternetSharing
Data type: Integer
0 – Do not allow Internet Sharing.
1 – Allow Internet Sharing (default)
Result when this setting is changed wither via GPO or MDM:
Posted on August 2nd, 2016 No comments
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).
Use the workaround described in the registry section workaround in https://support.microsoft.com/en-us/kb/3061518 to go back to the 512-bits settings.
Make necessary server configuration changes to support the better ciphers.
Posted on April 15th, 2016 1 comment
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.
Posted on April 14th, 2016 No comments
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!? :)