“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

Netgear Switch 1Gbps port at 100Mbps, goes up and down several times before settling at 100Mbps

This article discusses a problem in which jacking cables on a switch cause two or more ports to drop in and out of a shutdown / no shutdown sequence. After a few moments of going up/down, one or both of the ports will settle at a low speed (e.g. 1Gbps port at 100Mbps).

After adding new cabling to a LAG group, I experienced an intermittent fault in which one (or occasionally both) of the new cables would drop down to 100Mbps. If I removed the relevant keystone modules from the patch panel, the problem would cease.

 

Troubleshooting 1Gbps port at 100Mbps

Firstly, you should test the cable ensuring that all 8 pairs are up and in the correct sequence. A network tester should be used to do this.

If you used a punch tool during the install. Use a watchmakers screwdriver or the flat headed probe/shim on your punch tool to ensure that each wire in each pair is correctly and firmly seated. Ensure that there are no arched cables across the termination pins.

The most likely cause of a fault like this is a patch panel short. On a keystone patch panel, the keystone modules sit very close together. If the exposed copper ends of one keystone module touch the copper of a neighbour, the electrical circuit will short.

Data intended for one network port will be (poorly) transmitted down another one, causing signal corruption. The switch will attempt to respond by disabling pairs until it can get a clean signal. In the case of a 1Gbps Ethernet connection, it will disable 4 pairs, rendering the port 100Mbps. If there is still a short, it will fail to 10Mbps or shutdown the port.

A simple check for an electrical short is to place something non conductive – for example paper or electrical insulation tape – between the two keystone modules.

Photo of patch panel
Insert something non-conductive between the two patch panel keystones to check for an electrical short

The switch port will not automatically recover from an electrical short. You must jack/un-jack or sh/no sh the port to force speed renegotiation to occur.

If the insulator corrects the problem use some clippers to better trim the excess copper from the keystone, or leave the insulation in place permanently.

Performance impact of 512byte vs 4K sector sizes

When you are designing your storage subsystem. On modern hardware, you will often be asked to choose between formatting using 512 byte or 4K (4096 byte) sectors. This article discusses whether there is any statistically observable performance difference between the two in a 512 vs. 4K performance test.

NB: Do not get confused between the EXT4 INODE size and the LUN sector size. The INODE size places a mathematical cap on the number of files that a file system can store, and by consequence how large the volume can be. The sector size relates to how the file system interacts with the physical underlying hardware.

QNAP Sector Size selection
Sector Size selection on QNAP QTS 4.3.6

Method

  • A QNAP TS-1277XU-RP with 8x WD Red Pro 7200 RPM WD6003FFBX-68MU3N0 drives running firmware 83.00A83 were installed with 8 drives in bays 5 – 12
  • Storage shelf firmware was updated to QTS version 4.3.6.0923, providing the latest platform enhancements
  • A Storage Pool comprising all 8 disks in RAID 6 was configured, ensuring redundancy
  • A 4GB volume was added allowing QNAP app installation so that the systme could finish installing
  • The disk shelf was rebooted after it had completed its own setup tasks
  • RAID sync was allowed to fully complete over the next 12 hours
  • Two identical 4096 GB iSCSI targets were created with identical configurations apart from one having 512 byte and the other 4k sector sizes
  • SSD caching was disabled on the storage shelf
  • 2x10Gbps Ethernet, dedicated iSCSI connections were made available through two Dell PowerConnect SAN switches. Each NIC on its own VLAN. 9k jumbo frames were enabled accross the fabric
  • A Windows Server 2016 hypervisor was connected to the iSCSI target and mounted the storage volume. iSCSI MPIO was enabled in Round Robin mode. Representing a typical hypervisor configuration
  • The two storage LUNs were formatted with 64K NTFS partitions (recommended for dedicated VHDX volumes)
  • A Windows 10 VM was migrated onto each of the targets and the test performed using Anvil’s Storage Utilities 1.1.0.20140101. The VM had no live network connections. The Super Fetch and Windows Update services were disabled, preventing undesirable disk I/O. The VM was not rebooted between tests, had no other running tasks and had been idling for 6 hours prior to the test
  • No other tasks, load or data were present on the storage array

 

512 vs. 4K Performace Results

The results of the two tests are shown below.

Anvil Storage Utilities Screenshot with 512bytes results
Anvil Storage Utilities Screenshot with 512bytes results

"Anvil

IOPS
512 byte 4K 4K Diff 4K Diff % +/-
Read Seq 4MB 417.45 403.3 -14.15 -3.51
4K 3001.56 3164.56 163 5.15
4K QD4 6021.45 6006.7 -14.75 -0.25
4K QD16 24228.16 24062.61 -165.55 -0.69
32K 2742.39 2807.47 65.08 2.32
128K 2628.86 2620.8 -8.06 -0.31
Write Seq 4MB 233.2 230.79 -2.41 -1.04
4K 2090.79 2165.45 74.66 3.45
4K QD4 5976.18 5983.65 7.47 0.12
4K QD16 8254.84 7874.67 -380.17 -4.83

 

Analysis and Recommendations

The results show that there is little difference between the two. Repeating the tests multiple times showed that the figures for both the 512 byte and 4K LUNs are within the margin of error of each other. A bias towards 512 byte was consistently present, but was not statistically significant.

The drives in the test disk array are 512e drives. 512e is an industry transition technology between pure 512 byte and pure 4K drives. 512e drives use physical 4K sectors on the platter, but that the firmware uses 512 byte logic. A firmware emulation layer converts between the two. This creates a performance penalty during write operations due to the computation and delay of the re-mapping operation. Neither sector size will prevent this from occurring.

My recommendations are

  • If all of your drives are legacy 512 byte drives, only use 512
  • Should you intend to mount the LUN with an operating system that does not support 4K sectors. Only use 512
  • In situations where you have 512e drives, you can use either. Unless you intend to clone the LUN onto 4K drives in the future, stick with 512 for maximum compatibility
  • Never create an array that mixes 512 and 4K disks. Ensure that you create storage pools and volumes accordingly
  • Where all of your drives are 4K, only use 4K