Removing phantom “ms-resource:AppName/Text” apps from the Start Menu

This article discusses a method of eliminating phantom “ms-resource:AppName/Text” entries on the Windows 10 Start Menu. You may see these after upgrading Windows 10 to version 1903 in an “other” group at the bottom of the Start Menu.

 

What are “ms-resource:AppName/Text” entries?

A database is used to store information on user-available ModernApps and its contents merged with traditional apps (.lnk files) when the start menu is opened by a user.

The “ms-resource:AppName/Text” reveals a corrupt/orphaned entry in the database. As part of this, lookups are performed to C:\Users\<username>\AppData\Local\Packages and/or C:\Windows\SystemApps to load the app’s manifest.xml file. The manifest file is used to query for the Icon, life tile instructions and the multilingual label used on the start menu.

If the database record exists, but the application itself no longer does – due to a crash during uninstall or the user being offline when an administrator removed the app. “ms-resource:AppName/Text” will appear until such time that Windows validates the contents of the database. This usually during the next update to the “Start Menu” app itself, or an OS upgrade.

 

Ensure App Uninstallation

A common reason for this occurring is:

  1. The user has never run the app to install it into their user profile
  2. The app is removed from AppxProvisionedPackages in C:\Windows\SystemApps by an administrator. This prevents self-repair
  3. The app is removed from ‘All Users’ on the system, however the database entry remains in one or more local user profiles

If there are remnants of the app in Get-AppxPackage or Get-AppxPackage -AllUsers, you must remove the entries first. This is because the entry will be re-written to the Start Menu database after it is reset.

Once the app has been removed from the local user account, ‘all users’ and the provisioned apps repository. You can reset the database.

 

Reset the Start Menu database

There are several ways to do this. This fix runs in the local user context and uses a “bludgeoning” approach to solving the problem.

Paste the following code into a PowerShell window. It will error, it will not be pretty but it will remove the phantom entry – provided that you have genuinely uninstalled the app.

Stop-process -Name 'explorer'; Remove-Item "$env:LocalAppData\Packages\$($(Get-AppxPackage | ?{$_.name -like '*startmenue*'}).PackageFamilyName)\TempState\" -Recurse -Force -Confirm:$false; Stop-process -Name 'explorer'; Remove-Item "$env:LocalAppData\Packages\$($(Get-AppxPackage | ?{$_.name -like '*startmenue*'}).PackageFamilyName)\TempState\" -Recurse -Force -Confirm:$false; Stop-process -Name 'explorer'; Remove-Item "$env:LocalAppData\Packages\$($(Get-AppxPackage | ?{$_.name -like '*startmenue*'}).PackageFamilyName)\TempState\" -Recurse -Force -Confirm:$false; Stop-process -Name 'explorer'; Remove-Item "$env:LocalAppData\Packages\$($(Get-AppxPackage | ?{$_.name -like '*startmenue*'}).PackageFamilyName)\TempState\" -Recurse -Force -Confirm:$false; Start-Process 'c:\windows\explorer.exe';

If you are paying attention, yes, the above is repeating itself several times. This is intentional.

 

What does it do?

Very simply the above PowerShell sample:

  1. Crashes the Windows Shell (Windows Explorer)
  2. Looks up the version number of the Windows 10 Start Menu app (“Microsoft.Windows.StartMenuExperienceHost”)
  3. Uses the version number to construct the path to the location of the Start Menu database
  4. Deletes the database
  5. Return to 1
  6. Repeat…
  7. Start Windows Explorer

The code repetition prevents explorer.exe from being auto-recovered by the WinLogon watchdog. If explorer.exe is running, it will fail to delete the database. By repeatedly running, it will eventually brute-force explorer.exe closed, perform the deletion and restart explorer.exe on its own.

Explorer.exe re-scans the local system/user to inventory apps when it starts and a new database created without the phantom app.

“TsManager.exe – Entry Point Not Found” error during MDT task sequence

This article discusses an error that you may receive performing a MDT Windows Client Upgrade Task Sequence. The error message “TsManager.exe – Entry Point Not Found” may halt, but not end your Task Sequence process or, my cause it to fail prematurely part-way through the task sequence.

Error Message Screenstor of TsManager.exe - Entry Point Not Found

TsManager.exe - Entry Point Not Found
The procedure entry point MDMIsExternallyManaged could not be located in the dynamic link library C:\WINDOWS\CCM\lsutilities.dll

Note: The above error is for “LSUtilities.dll” not “iSUtilities.dll”

The name of the entry point stated in the error may differ depending on

  1. The stage in the MDT Task Sequence where the error occurs
  2. The version of the SCCM Client installed on the computer. The above error is from SCCM Client version 5.00.8790.1025 (SCCM 1902 Update 1) at the end of the Post-Processing phase of the Task Sequence

 

More Info

“TsManager.exe – Entry Point Not Found” is caused by a mismatch between the MDT integration with SCCM and the SCCM Client LSUtilities.dll – which provides Location Services for the SCCM Client.

Microsoft have made the assumption that if you are using the SCCM client and MDT, that MDT has been integrated into SCCM. If you are running a stand-alone MDT LTI build process, you may encounter this problem. The issues occur because MDT integration modifies MDT to work with the task sequence and the SCCM client. Without the integration, the SCCM client’s MDT hooks still fire, but cannot function due to MDT not having been upgraded.

 

Check the Client Version

Ensure that the SCCM Client version you are deploying is an approximate match to the version to the one in General Availability at the time the MDT build was released.

For example, MDT version 8456 was released 25th January 2019. By using the SystemCentreDudes SCCM Client Version list, you can see that the active release of SCCM in January 2019 would have been SCCM 1810. Consequently you should ensure that the SCCM Client version deployed on the system/via the MDT Task Sequence is is a SCCM 1810 release.

This means that you should avoid using the SCCM 1902 client with a stand-alone MDT 8456 build server.

Ensuring client version parity will not prevent all Entry Point errors, however it will minimise the possible range of errors that can be encountered by the Client/MDT. SCCM will self-update the client to the current version as part of its client servicing activities post-install.

View: SystemCentreDudes “SCCM Version Numbers and Cumulative Update List”

 

Preventing an irrecoverable failure of the task sequence

You must uninstall the SCCM client from the workstation before the operating system upgrade commences. You can automate this as part of your task sequence. The only requirement is for it to have been uninstalled before the first reboot of the system by MDT.

  1. Open the “Task Sequence” tab in the properties of you Task Sequence
  2. In the “Preparation” section, after “Validate” add a new “Run Command Line”
  3. Name the task:
    Uninstall SCCM Client
  4. Enter the Command Line:
    cmd.exe /c ""C:\Windows\ccmsetup\ccmsetup.exe" /uninstall & RD /S /Q "C:\Windows\ccmsetup" & RD /S /Q "C:\Windows\CCM""

The first part of the command shuts down all SCCM client services and performs the uninstall:

"C:\Windows\ccmsetup\ccmsetup.exe" /uninstall

The second part of the command deletes the “C:\Windows\CCM” folder, ensuring that LSUtilities.dll cannot be present during the imaging process.

Note: Deleting this folder will delete all historic log data associated with the client.

 

Reinstall the SCCM Client

To reverse the removal and restore the SCCM client, you must introduce its re-installation later in the task sequence. To reinstall the SCCM Client add the SCCM client setup as a new application in the Applications section of your Deployment Share. The following example is for the SCCM 1902 client.

MDT Application Definition for SCCM ClientMDT Application SCCM Client Install Command

Note: Do not select “Reboot the computer after installing this application”. Doing so will force the SCCM client to interact with MDT.

An example of the install command would be:

ccmsetup.exe /service /mp:<management point FQDN> /forceinstall SMSSITECODE=<site code> DNSSUFFIX=<domain suffix> FSP=<server> SMSMP=<server FQDN>

Return to the Task Sequence tab in the properties of the task sequence.

Create an “Install Application” task as late as possible in the “Post-Processing” section of the Task Sequence. Select a single application and browse for the newly created SCCM Client package.

Note: Avoid running additional tasks after the reinstallation of the client as you increase the risk of experiencing an associated fault once the system has restarted.

Windows 10 Search not working after performing an in-place upgrade

This article discusses a fix for the Windows Search bar / Cortana not working after an in-place Windows 10 upgrade.

The Problem

Upgraded Windows 10 to find Windows Search Not Working? The symptoms may include:

  1. Clicking on the search bar in the task bar does not launch the search user interface pop-up
  2. Opening the Start menu and immediately typing does not launch the search user interface
  3. When you click on the search bar in the task bar, Cortana momentarily appears on the ‘Apps’ tab in Task Manager and then exists
  4. Clicking on the search bar causes SearchUI.exe to launch on the Details tab in Task Manager and then immediately exit
  5. The search bar on the taskbar flickers, flashes on and off or even vanishes completely; leaving a display artefact.
  6. The Events Viewer > Application log records the following event under Event ID 1000:
Faulting application name: SearchUI.exe, version 10.0.18362.1, time stamp: 0x5c90179d
Faulting module name: SearchUI.exe, version 10.0.18362.1, time stamp: 0x5c90179d
Exception code: 0xc000027b
Fault offset: 0x000000000015bf3e
Faulting process ID: 0xb50
Faulting application start time: 0x01d5229682a57780
Faulting application path: C:\Windows\SystemApps\Microsoft.Windows.Cortana_cw5n1h2txyewy\SearchUI.exe

In my case, the upgrade was from Windows 10 1703 to Windows 10 1903 and the user account was a Roaming profile (local profiles were all fine).

Am I the only person who is beyond fed-up with this nonsense? I digress…

Yes, no doubt you are equally frustrated with seeing Microsoft supports unhelpful and generic “run DISM’s Restore Health command followed by running SFC.exe /ScanNow[1]. Microsoft Product Support are just ignoring the problem and trying to encourage people for format the system by means of finding a zero-effort fix. This attitude helps no one.

The Windows shell is a mess. The Windows Modern App paradigm – while improved on 2015 – is still not in a fit state to be able to replace Win32. With these kinds of issues, is it any wonder that even in 2019 no one is writing Modern Apps? Microsoft themselves were forced to acknowledge this. Microsoft’s one success to encourage the use of Modern Apps has been to create a Win32 wrapper. Allowing Win32 programs to be released via the Windows Store. It says it all doesn’t it?

The Fix

As the search bar works fine for local users, the issue had to be profile, not system level (for anyone paying attention this rules out SFC /ScanNow and DISM).

Event Viewer tells us the application version involved as being “Microsoft.Windows.Cortana_cw5n1h2txyewy”. For a test user this happens to map within their profile to:

C:\Users\<username>\AppData\Local\Packages\Microsoft.Windows.Cortana_cw5n1h2txyewy

I then proceeded to delete data from within the directory until search worked. The culprit was the contents of the Settings folder. Clearly between version 1703 and 1903, Microsoft have changed a lot here. There has not been any settings migration through Windows Store auto-update as “Cortana” (Windows Search) is only upgraded during feature updates.

 

Automating the Fix

If you are experiencing the same problem. I have put together the following PowerShell scripts to solve the issue on both a per-user and per-system basis. The script does the following

  1. Searches for all Settings folders present beneath any version of Cortana on the system
  2. Attempts to kill the SearchUI process, if present
  3. Deletes the contents of the Settings folder and the Settings folder itself

The SearchUI process/deleted data will be restored the next time the search bar is clicked.

 

For the currently logged on user

$settings = dir $env:UserProfile\AppData\Local\Packages\Microsoft.Windows.Cortana*\Settings
$settings | % {Stop-Process -Name 'SearchUI' -Force; Remove-Item $_.FullName -Recurse -Force}

 

For a named user profile

$profile = ‘joe.bloggs’

$settings = dir C:\Users\$profile\AppData\Local\Packages\Microsoft.Windows.Cortana*\Settings
$settings | % {Stop-Process -Name 'SearchUI' -Force; Remove-Item $_.FullName -Recurse -Force}

 

For all users on the system

$settings = dir C:\Users\*\AppData\Local\Packages\Microsoft.Windows.Cortana*\Settings
$settings | % {Stop-Process -Name 'SearchUI' -Force; Remove-Item $_.FullName -Recurse -Force}

 

Things to note

Working search bars will have file locks on the Setting folder. If you do not wish to see file lock errors messages use:

Remove-Item $_.FullName -Recurse -Force -ErrorAction SilentlyContinue.

 

Deployment Options

Your options for deployment of the script(s) are:

  1. Inject the script into a HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce entry for the system
  2. Inject the script into a HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce entry for the user
  3. Process the script as part of a logon script
  4. Use SCCM to deploy the script as a SCCM Package to the system/user
  5. Fire the script as a one-off/recurring Task Scheduler script via Group Policy
  6. Execute the script at the end of your MDT upgrade task sequence

Create a Slipstreamed Hyper-V Server 2019 installation image with working Remote Desktop for Administration

If you have been following the saga of the non-working Hyper-V Server 2019 release from November. You may be aware that the most prominent issue – that of Remote Desktop Services for Administration not working – has now been resolved in the February 2019 patch release cycle.

This article outlines how to create updated media for Hyper-V Server 2019 using the original installation medium and patch it into a working state.

Note from the author

Please note that if you intend to use Hyper-V Server in a production environment, you should wait for Microsoft to re-issue the office ISO. Once it is released, it will be made available in the Microsoft Server Evaluation Centre.

View: Microsoft Evaluation Centre

Pre-requisites

You will need access to a Windows 10, Windows Server 2016 or Windows Server 2019 system in order to update the installer.

Obtain and install the Windows ADK 1809 (or later) selecting the Deployment Tools option (providing you with an updated version of DISM)
Download: Windows Assessment & Deployment Kit (ADK)

Retrieve the original Hyper-V Server 2019 ISO
Download: Hyper-V Server 2019 (1809)

Download following updates from the Microsoft Update Catalogue
Note: This is correct as of early March 2019. It is suggested that you apply newer cumulative and servicing updates as they are released in the future.

  1. KB4470788
  2. KB4482887
  3. KB4483452

View: Microsoft Update Catalogue

[Optional] If you wish to apply any language regionalisation (e.g. EN-GB), source the CAB file(s) for the language features that you require. For example:
Microsoft-Windows-Server-LanguagePack-Package~31bf3856ad364e35~amd64~en-GB~10.0.17763.1.cab

Updating the Installation Image

To update the installation image:

  1. Create a folder on C:\ called ‘Mount’
  2. Add a second folder on C:\ called ‘hvs’
  3. In the hvs folder, create a subfolder called ‘Updates’
  4. Extract the entire contents of the ISO from the Hyper-V Server 2019 ISO into C:\hvs
  5. Place the three MSU files from the Microsoft Update Catalogue into the C:\hvs\Updates folder
  6. [Optionally] Place the CAB file for the language pack into the C:\hvs folder and for convenience rename it ‘lp.cab’
  7. Open an elevated Command Prompt
  8. Issue:
    cd /d "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64"
    To navigate into the working folder for the updated version of DISM.exe
  9. Issue:
    dism.exe /mount-image /ImageFile:"C:\hvs\Sources\install.wim" /Index:1 /MountDir:"C:\Mount"
    To unpack the installation image into the C:\Mount folder
    Note: Do not navigate into this folder with CMD, PowerShell or Windows Explorer. If you leave a handle open against this folder when you try to re-pack the install.wim, it will fail.
  10. Once the mounting is complete, patch the installation by issuing:
    dism.exe /Image:"C:\Mount" /Add-Package /PackagePath:"C:\hvs\Updates"
  11. [Optional] Apply the language pack by issuing (change en-GB to your language as applicable):
    dism.exe /Image:"C:\Mount" /ScratchDir:"C:\Windows\Temp" /Add-Package /PackagePath:"C:\hvs\lp.cab"
    dism.exe /Image:"C:\Mount" /Set-SKUIntlDefaults:en-GB
    If you intend to use ImageX, DISM or WDS to deploy this image, you can skip the following command. If you intend to create a new bootable ISO or UFD, issue:
    dism.exe /image:"C:\Mount" /gen-langini /distribution:"C:\hvs"
    This will create a new Lang.ini file which must be included in the ISO/UFD media (but is not required for other deployment methods)
  12. Dismount and re-package the install.wim file by issuing:
    dism.exe /unmount-image /MountDir:"C:\Mount" /Commit
  13. Once DISM has processed the installation image, the new Install.wim file can be found at:
    C:\hvs\Sources\install.wim
  14. At this point you will have a working installation image which you can use to create a new ISO, UFD or install via WDS. You should delete the Updates folder and [optional] lp.cab from C:\hvs before creating a new ISO or bootable UFD.

If it goes wrong at any point, issue the following command to abort the process and go back and try again:
dism.exe /unmount-image /MountDir:"C:\Mount" /Discard

Delete the C:\Mount and C:\hvs folders once you have finished creating you new deployment media.

Final Word

If you follow the above, you will have not only a fixed RDP experience, but also a current patched version of Hyper-V Server. Eliminating a little time spent waiting for Windows Update to run.

If you are going to enable RDP for Administration. As ever, do not forget to enable the firewall rule in PowerShell. SConfig.cmd does not do this for you!

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"