Anyone else have problems with November patches kb5032189?

[Chris Carter1709157035]

Environment:

ELM/ALA version 2309 (latest at the time)

vSphere 7.0.3.01700

 

After applying the November 2023 security patch KB5032189 the start menu pinned icons were not showing up. We do use the startlayer.xml and a group policy to pin those apps. Through my testing I found that I can add version my October patched layer but as soon as I installed patches the KB5032189 and finalize the layer, if i publish that OS layer (only) directly to vSphere the Windows Search service is hung on 'Starting'. Has anyone else experience this or have any advice? I do have a ticket open but I thought i would try here too.

Thanks in advance!

[Björn Schläfli]

I was interested in the way how Jean disabled it. Set the DWORD Enabled to 0, use the Exclude List or set the gpo setting to disabled.

FSLogix Profile Exclude List doesn't help in my case. The desktop still stuck at the black screen.

I suspect a possible connection with dll hooking. But the earlier mentioned support article doesn't help either (CTX585692).

[Björn Schläfli]

The one with Windows Search service was a good one Steven. Same here. Service has the status starting and type automatic. After a few seconds the type switches to disabled. If I stop the Searchindexer.exe the desktop is loaded successfully.

[Jean Soslashrensen]

We have an Exclude AD group for users who shouldn't use FSLogix. The group is configured in a FSLogix registry key. 

[Tobias Scheller]

I think i found a workaround for us. We also have the black screen problem at user logon.

 

Our Environment:

App Layering ELM 23.12.0.1001

Hypervisor: XenServer 8.2 CU1

VDA OS: Windows 10 21H2 PVS provisioned target devices

fslogix

 

I disabled the windows search service in the platform layer. After publishing the PVS Images and user logon the black screen is gone and the windows search service is still enabled and running.

[Jean Soslashrensen]

1 hour ago, Steven Mudde said:

What we see is that the Windows Search service is hanging on status Starting. We also see this behavior on physical machines where no VDA or other citrix components are installed. On machines where FSLogix is not installed we also do not see this behavior. Latest FSLogix version does not seem to resolve the issue unfortunately. We have a case open with MS, but are not making any progress yet. We are still in the process of collecting logs.

 

After a reboot the search service usually works again. On our vDisk this is now a standard procedure during image finalization, this prevents the issue most of the time. But of course this isn't a solution.

Hi Steven, what exactly do you do in your finalization steps to work around this issue? Thanks ?

[Steven Mudde]

51 minutes ago, Jean Soslashrensen said:

Hi Steven, what exactly do you do in your finalization steps to work around this issue? Thanks ?

We just give the machine a extra reboot when in private mode. First time when we logon the search service is stuck on starteing and start-menu is not working correctly. The we reboot and logon again, service is now started and start-menu is working. Then we do our sysprep/seal actions and shutdown the machine. After this set the image to standard image and are good to go. We purely use Citrix PVS instead of layers btw

[Björn Schläfli]

I don't use AppLayering.

 

I just tested around with windows search service. The service is running in the golden machine. In the pvs targets the service comes up with start pending. If I kill the Searchindexer.exe, the service starts and Searchindexer.exe is reloaded. After that a user can logon to the desktop smoothly.

Thanks to Steven for pointing out the cause.

 

Now I try to figure out why the search service stuck at start pending state.

[Björn Schläfli]

I've done a lot of tests with no success.

- replaced searchindexer.exe

- used a clean new golden machine with only pvs target device software

- Procmon recorded while booting, but didn't found anything helpful

- As I used a clean image API hooking is completely out of focus 

- compared windows search regkeys working / non-working

- It works in the golden machine, but the first boot of a vdisk of it shows the windows update startpending status. After a reboot more it is working.

 

I'll open a case next week.

[KFI Service]

Does someone have any news on this issue?

[Chris Bondy1709160344]

I am seeing the exact same issue.  WIndows 10 22h2, vmware, newest vmware tools, PVS.  We are using the newest version of App Layering 23.12.0.1001 with newest machine tools in image.  Published image has Windows Search Service stuck in Starting state.  breaks Teams login, indexing, start menu search, etc.  Putting the image in private mode and rebooting, then resealing image fixes the issue.  September OS layer does not have the issue.  I have tried updating the OS layer straight from Sept to Jan patches with no change.  I got this from Citrix support today:  "As for the issue occurring with the search service failing, I spoke with internal app layering resources and was advised the Windows Search service failing was reported back in App Layering version 2309 and is a known issue. Based on the information provided, the issue was introduced after having Microsoft KB032189 applied to the OS layer the search service stops working. A patch was made for the 2309 version of App Layering. Also, the latest App Layering version 2312 was released before the patch was available so a patch was made for that version as well."  I'm waiting on a link to the ELM patch to test.  I do not have the KB listed but hoping the ELM patch fixes the issue.

[KFI Service]

We have this is also in PVS images without the use of App Layering...

[Steven Mudde]

Is there anyone seeing the issue without FSLogix? We only see it on systems with FSLogix installed (even for users that are not  FSLogix enabled)

 

we have a case open at MS, but no progress is being made. Would be helpfull if everyone experiencing the issue opens a case, so this gets more traction at MS.

[Björn Schläfli]

I tested it with an image on which nothing other than the PVS target device software was installed. So no fslogix. It's a clear Microsoft problem. The problem always occurs when a virtual disk (pvs, app layering or other) is used. I spoke to someone yesterday who reproduced the problem with a virtual disk without Citrix or fslogix. For me it's clearly because the Windows Search service doesn't start. Of course, FSLogix has a big problem with this because it needs this service.

 

Workaround: boot the image in private mode, boot again, seal the image.

[Steven Mudde]

We see the issue also on physical machines where there are no Citrix components installed, nothing like app layering etc. The only virtual disk there is the FSLogix Disk

[Björn Schläfli]

Good news.

A colleague informed me yesterday that the problem no longer occurs with patch KB5034203. I immediately tested this patch in our test environment and no longer found any problems. There is nothing mentioned about black screen or windows search in the fixed issues list, but Microsoft seems to have fixed it again.

Patch KB5034203

 

Try it out and give feedback, please

[Steven Mudde]

2 hours ago, Björn Schläfli said:

Good news.

A colleague informed me yesterday that the problem no longer occurs with patch KB5034203. I immediately tested this patch in our test environment and no longer found any problems. There is nothing mentioned about black screen or windows search in the fixed issues list, but Microsoft seems to have fixed it again.

Patch KB5034203

 

Try it out and give feedback, please

Thanks for this info! We are going to test with this update and let you know the results ?

[Julian Mooren1709156280]

1 hour ago, Steven Mudde said:

Thanks for this info! We are going to test with this update and let you know the results ?

Hello everybody, a customer and myself did a lot of testing's regarding this issue the last weeks and still have an open support case at Microsoft.

As Bjoern posted, my client has been able to identify, that the issue is gone with the latest preview KB5034203.

We provided the MS Support a broken virtual disk, which is being analyzed by a support engineer.

Unfortunately the support quality is really bad, but I keep asking and asking for a identification of the root cause. I want to prevent that this is happening again with a CU in the future.

There is nothing mentioned in the changelog which is a bummer. If you want to raise the pressure on MS here is our support case ID #2401040030004010

 

Julian

 

 

[Chris Bondy1709160344]

 I patched the App Layering appliance to 23.12.1.1002 and added kb5034203 to the OS layer.  After this, I do not see the Windows Start service error.  Not sure if it was the one or the other or the combination of both that resolved the issue.

[Steven Mudde]

On 1/25/2024 at 11:53 AM, Julian Mooren1709156280 said:

Hello everybody, a customer and myself did a lot of testing's regarding this issue the last weeks and still have an open support case at Microsoft.

As Bjoern posted, my client has been able to identify, that the issue is gone with the latest preview KB5034203.

We provided the MS Support a broken virtual disk, which is being analyzed by a support engineer.

Unfortunately the support quality is really bad, but I keep asking and asking for a identification of the root cause. I want to prevent that this is happening again with a CU in the future.

There is nothing mentioned in the changelog which is a bummer. If you want to raise the pressure on MS here is our support case ID #2401040030004010

 

Julian

 

 

Hi Julian,

 

We did some test with KB5034203 and indeed this seems to resolve the issue. When starting with a new/empty FSLogix disk we do see some eventlogs about corrupt search index at first logoff, but after that everything seems to work OK. No more corrupt search index messages after the first logoff and no hanging search service.

 

We have passed your case ID to our support engineer, hopefully they can combine the cases and find the cause of it. Our support case ID is #2312210060003102

 

[Björn Schläfli]

My Microsoft case id: 2402060030007022