There was a post on the Ivanti forums that I started reviewing in October (https://community.ivanti.com/thread/60703). This post was about the Edge icon on the taskbar reappearing each time.
From my past experience, this was an easy fix, you needed to add the “StartMenuInit” value as a managed item in personalization. The “StartMenuInit” value acts much like “Active Setup” and runs at first logon to customize the users profile by adding the browser (based on your OS) to the start menu as well as the taskbar.
It also adds Windows Media Player or Server Manager shortcuts depending on your OS. For the customer in this forum post, the fix was easy, capture “StartMenuInit” to prevent this from happening at every logon. The customer responded that this recommendation broke the start menu.
I’ve never used the XML method mentioned in the thread above to capture the start menu. Historically, personalization worked fine, using my baseline templates and the built-in functionality… so managing the start menu via PowerShell didn’t make sense to me. “XML Method Reference”: James Rankin first talked about this method on his blog over 3 years ago: https://www.htguk.com/getting-to-grips-with-windows-81-25/
I decided to give the “XML method” a try and found out that it is also controlled by “StartMenuInit” value and is designed to run once per user. This being the case, you can capture “StartMenuInit” and prevent IE or Edge from re-pinning over and over or you can personalize your start menu via the XML method but not both.
During this testing, I tried reverting back to my “old tried and true” templates that have always worked. Basically, my template is an out of the box configuration with “StartMenuInit” and the “UserSignedIn” values added. What I found was that on the second logon the start menu was completely broken. I was able to reproduce these results on every recent build of Windows 10 (1607, 1703, 1709). I was “stumped”… why is this issue occurring all of a sudden?
Come to find out this is a new undocumented “feature” in FR3. This new functionality handles the start menu using the XML method that isn’t documented in any release note that I could find.
This little-hidden gem was found in the out of box templates on my personalization server. See the image below:
When the layoutmodification.xml file is included it breaks the functionality in my template. Since I cannot update the out of box settings I had to create a new custom setting and replace it.
Now I had my start menu working again on Win10 1607 and properly managing the taskbar personalization by capturing “StartMenuInit.”
I was fired up until I started testing this fix on other Win10 builds. On Windows 10 1709 the implementation with FR3 was rather simple. In 1709 Microsoft stopped using the “TileDataLayer” and completely replaced it with the “CloudStore” registry key.
After some success with Windows 10 1709 and the updated Windows Setting Group I moved on to testing Windows 10 1703. This turned out to be a “mess”. I began to suspect that Ivanti development must be doing something in the code with 1703 and the TileDataLayer that does not make sense to me.
Much like the new XML method, that I mentioned earlier, it isn’t documented in the release notes.
When testing Windows 10 1703, At logoff, the copy of the TileDataLayer folder fails. Not only does it fail with some completely weird reason but the path is completely wrong and is referencing my temp folder, as shown in the highlighted output below:
After witnessing these results the issue is becoming apparent. In my opinion it appears that FR3 has had some major overhauls, which are causing a lot of issues. I decided to test FR2 on the exact same machine. FR2 was able to copy the entire folder without any issues. This led me to the conclusion that the issue cannot be the endpoint OS but the version of Environment Manager that is not allowing the “TileDataLayer” folder to be copied out on 1703.
So rollback to FR2? Not exactly…. See there is a known issue in FR2 with the “CloudStore” key. https://community.ivanti.com/docs/DOC-48236 This article written in Ivanti’s own words proves that all that was needed was the “CloudStore” key.
The issue in the article DOC-48236 has been resolved in FR3. While FR3 fixes one (or many) issue(s) it appears to also unintentionally broke some features that worked before. I cannot rollout FR3 due to the “TileDataLayer issue” in Win10 1703 and the workaround in the article is inconsistent due to it using the desktop created trigger.
It seems to me that if the issue with the CloudStore key was resolved in FR3, which it has, and development didn’t add changes with the “XML Method” and “TileDataLayer” functionality we would be in good shape. The start menu and taskbar functionality would be working if the “out of the box” templates were modified to use the proper includes (referenced above).
At the present time I am being told that this issue would need to be addressed as a feature request. Since we know the issue exists and have at least one possible solution to fix the issue, I need some support from the community to get this feature request prioritized.