Sabian0309 Tracker

Re: Vmware Intergrated Printing, fslogix and small printout.

Sabian0309 — Thu, 20 Jan 2022 17:00:28 GMT

Hello,

We load all printer drivers on our parent image, and honestly its a bit of a pain. Occasionally Microsoft updates cause us to have to reload the printers again (mostly issues with xerox and dymo drivers). We persist the printers and default by using DEM. Its not perfect but it seems to work pretty well. When we moved to fslogix we cut a lot of our DEM out, but we still have it for a few odd jobs.

Oddly the small print issue just disappeared. I did go through and alter service and registry permissions to allow the end user to stop and restart the spooler and horizon printer service via an powershell script converted to an exe as a stop gap... but a few months ago the issue just stopped happening.

Vmware Intergrated Printing, fslogix and small printout.

Sabian0309 — Fri, 21 May 2021 14:48:56 GMT

Hello,

I'm hoping someone else has seen this issue... as its one of those things that is slowly eroding my sanity. Ever since we moved to using vmware integrated printing and fslogix a strange issue seems to happen intermittently when some of our users print. When the user goes to print, despite the properties on the printer, the default paper size is 4.xX"3.x so the end result is a tiny printout on normal paper. The current workaround is to remove the printer and add it back, which will print normally for that session and at times for multiple sessions. However eventually after login they go to print and go back to a small paper size. This does not seem to effect all users, however the users that have the issue seem to have it fairly consistently. It also is not isolated to a specific program, and users who have this issue do not have a common appvol or anything of that nature.

We are still using DEM to keep user printer settings (mainly for default printer), however I do have some test users which are excluded from those DEM settings that still have the issue. Printers are installed and not being pushed in via GPO or DEM.

All printers are running from a 2016 print server, the issue does not happen outside of the VM and never happened back in the days of thin print.

The issue can happen with redirected printers as well, not just printers that are assigned to the VM.

I've played with the policy for "Disable Printer Property Persistence" without any success as well.

Horizon version 2012 (agent 8.1.0)

Appvol 4.2.0.48

fslogix 2.9.7654.46150

(Profile and office containers, single user search roaming)

DEM 10.1.0.959

Anyone have any idea on what could be causing this, or how to prevent it? I'm at the grasping at straws phase.

Thank you.

Re: App Volumes 4.0 performance

Sabian0309 — Tue, 28 Jan 2020 19:55:47 GMT

I ended up here looking to see if anyone else was seeing poor performance with AppVolumes 4.

I just rolled a test server for it and created a brand new application with 3 small apps (Putty/winscp/notepad++), and it has taken the login time up a good bit.

I'm going to start digging into it, but right now it seems significantly slower. Though i do like some aspects of the UI .

Re: App Readiness going crazy after upgrade to 2.16+

Sabian0309 — Thu, 08 Aug 2019 17:26:08 GMT

When i asked (as i really didn't want to go through and modify a ton of apps), i was told it was cumulative. I'm still asking if this will be patched... as its a hokey work around, but slightly less so than killing off services .

Re: App Readiness going crazy after upgrade to 2.16+

Sabian0309 — Thu, 08 Aug 2019 17:19:35 GMT

Alrighty, i got some traction with my SR on this issue. While it isn't perfect, there is a bit of a work around that vmware has provided.

What they suggested:

Edit the Snapvol.cfg by creating a blank app stack and attach the app stack to user or machines to verify
- Or Try updating an existing App Stack with the below config

exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx

include_registry=\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Applications

exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx

exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppReadiness

This does appear to work. You don't have to do it to every appstack, from my understanding as long as this change has been made to one of the app stacks being applied it will be applied to all. In my testing this has resolved the issue, hopefully they can update their template.

Re: App Readiness going crazy after upgrade to 2.16+

Sabian0309 — Wed, 31 Jul 2019 19:13:50 GMT

To resolve the issue I disabled the app readiness service. Which did the trick, but then if someone tried to click the cog off the start menu nothing would happen. Somehow having that service disabled broke the settings metro app. We found that if you right-clicked and selected personalize it would work for the session (probably a bit different as you're using linked clones). However that wasn't a great work around for a lot of our users, so we implemented redeploying the appx package for it.

Re: App Readiness going crazy after upgrade to 2.16+

Sabian0309 — Wed, 31 Jul 2019 17:11:59 GMT

We are running 1803 instant clones. We tried using the 2.17 agent and it didn't resolve the issue. I guess we could of rolled back to 2.15 however we created an executable of a ps1 script to add windows.immersivecontrolpanel appx package at login through UEM which resolved the settings not launching.

Sorry you're having the issue as well, but I'm glad I'm not the only one :smileysilly:.

Re: Vmware Horizon Default Printer keeps changing.

Sabian0309 — Wed, 31 Jul 2019 13:46:14 GMT

Glad it worked for you

App Readiness going crazy after upgrade to 2.16+

Sabian0309 — Tue, 30 Jul 2019 13:55:43 GMT

I have an open support case, but i thought i'd ask if anyone else has seen this issue.

Over a weekend we updated our appvolume server from 2.14 to 2.16. The following monday our VDI cluster was screaming. The cause was the app readiness service crawling the appvolume's non-stop using 25-40% cpu constantly.

I tested it with old appvols as well as newly created. Even tried the 2.17 agent with no change in behavior. Anyone else notice their cpu usage spike after going with 2.16+?

Re: Vmware Horizon Default Printer keeps changing.

Sabian0309 — Tue, 30 Jul 2019 13:51:25 GMT

I fought with this for a while to. I still occasionally have issues with it, and to be honest i've been frying bigger fish and haven't been able to check into the stragglers.

So, when you have a user logout, do you see their default printer set at the bottom of the registry file that got exported (pending they set it correctly before logout)?

If you did, then i have a hacky work around for you. We are going to import the printer settings again after user login. The thought behind this is that an appstack or other process is coming along after the original printer import and changing the default.

In your UEM configuration share, create 2 .bat files.

Make one called "launcher.bat". Inside of it you want to have the following:

START /MIN CMD.EXE /C "\\yourserver\UEM Configuration\printer.bat"

Then you want to create printer.bat containing:

@echo off

timeout 3 /nobreak

"C:\Program Files\Immidio\Flex Profiles\Flexengine.exe" -i "\\yourserver\UEM Configuration\general\Windows Settings\User Printer Configs.INI" -r "\\yourserver\UEM Profiles\%username%\archives\Windows Settings\User Printer Configs.zip"

Now in UEM under user environment select shortcuts. Create a new one that looks like this:

The user will see a cmd window launch shortly after login, but it will re-import their printer settings after everything has settled down. You can play with the timeout in the printer batch file, but 3 seconds seems to work well.

---------------------------------------------------------------------------------------------------------

Was it helpful? Let us know by completing this short survey here.

Re: UEM hanging/delaying randomly.

Sabian0309 — Mon, 24 Jun 2019 19:45:00 GMT

This is awesome. I have tested this in my testing pool and will be rolling this out over the next week. So far it seems to be doing the trick. Your rock sir.

Re: UEM hanging/delaying randomly.

Sabian0309 — Fri, 26 Apr 2019 12:31:45 GMT

I'm going to guess that is the default setting, as that is how my share is setup as well. I've altered it to not allow any caching and will see if this has any effect.

Thank you .

Re: UEM hanging/delaying randomly.

Sabian0309 — Tue, 23 Apr 2019 15:32:19 GMT

This last weekend i had an outage window where i tweaked the oplockbreakwait setting (and attempted to disable oplocking via powershell), however it did not alter the behavior. I know with SMB2+ many of the configurations within lanmanserver\parameters are no longer valid, so that may be the case.

I'll still poke around some more and see what i can figure out .

Re: UEM hanging/delaying randomly.

Sabian0309 — Tue, 23 Apr 2019 15:21:02 GMT

UEMdev,

Does UEM do anything funny with exports where it would lock the configuration files as its processing? As seen in the previous post, the ini file has an oplock where a break is requested. I've captured earlier in the process, and see a fsctl_request_batch_oplock on the file that causes the delay from another session, guessing from an export of another user as shortly afterwards i see a similarly labeled .tmp then .zip being written:

Reading up on the batch uplock, it appears this is requested from the application

Re: UEM hanging/delaying randomly.

Sabian0309 — Tue, 23 Apr 2019 14:45:00 GMT

I'm still lurking on this . So i just sent this on the case i am working on with this issue:

I’m open to suggestions, it does appear to be oplock related.

To recap, things that were done to the file server:

Set-SmbServerConfiguration -EnableLeasing $false

Set-SmbServerConfiguration -EnableOplocks $false

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Name : OplockBreakWait

Type : REG_DWORD

Value : 10

However, this I see this on the file server when an issue happens:

Then 19 seconds later:

This matches the delay in the logs

2019-04-23 09:37:06.491 [DEBUG] Read 13 entries from profile archive (size: 66625536; compressed: 8536205; took 493 ms; largest file: 31457280 bytes; slowest import took 185 ms)

2019-04-23 09:37:25.428 [INFO ] Importing profile archive 'Internet Explorer.zip' (\\jfv-vm-fs2\UEM Profiles\XXXX\archives\Windows Settings\Internet Explorer.zip)

Now a normal session where this delay is not experienced(no oplock break request):

Re: UEM hanging/delaying randomly.

Sabian0309 — Thu, 21 Mar 2019 15:22:12 GMT

Well, i think that this point that the conversation is dead. I've gone as far as catching the slow down and suspending the VM to send over suspended memory files and have been told that I would need to contact Microsoft. VMware is stating that it is an infrastructure issue, but cannot provide any method to prove it aside from contacting an outside vendor. My manager doesn't want to waste the money opening a support case with Microsoft for something that happens part of the time.

Sorry guys, i was hoping i could find the smoking gun. I'll still poke at this issue in my spare time and if i ever come up with something i'll post it on here. I guess this would be the reason why all other cases with this issue are closed as "Client stopped responding". Guess we all have the same infrastructure issue.

Re: UEM hanging/delaying randomly.

Sabian0309 — Mon, 28 Jan 2019 18:34:29 GMT

Sadly no. I've watched our file server without any issue. Procmon doesn't have any spikes in anything relevant. I actually made a script that ran on a VM copying 100 little ini files to the uem share, read a few, then copy them back to the VM locally and delete. I let that run for almost 4 hours without any delay being produced.

I'm open to suggestions on trying to replicate the issue outside of UEM.

Re: UEM hanging/delaying randomly.

Sabian0309 — Thu, 24 Jan 2019 14:24:52 GMT

I've uploaded a zip to the SR with an example of a delay and what looks to be regular. Thank you sir.

Re: UEM hanging/delaying randomly.

Sabian0309 — Thu, 24 Jan 2019 13:53:20 GMT

Ray,

I do not see any firewall events within our svservice.log, we also have the firewall disabled on our master and appvolumes parent images and do not have a cvfirewall.cfg I do see the same empty space, however it happens here:

(flexengine)

2019-01-24 08:36:06.106 [INFO ] Importing profile archive 'Mozilla Firefox.zip' (\\jfv-vm-fs2\UEM Profiles\bbombatch\archives\Applications\Mozilla Firefox.zip)
2019-01-24 08:36:06.700 [DEBUG] Read 252 entries from profile archive (size: 24769993; compressed: 7937162; took 586 ms; largest file: 6180184 bytes; slowest import took 51 ms)
2019-01-24 08:36:25.622 [INFO ] No profile archive to import for config file '\\jfv-vm-fs2\UEM Configuration\general\Applications\MP2.INI'
2019-01-24 08:36:25.638 [INFO ] Config file '\\jfv-vm-fs2\UEM Configuration\general\Applications\Notepad.INI' added to DirectFlex cache

(svservice)

[2019-01-24 13:36:02.731 UTC] [svservice:P1252:T2420] All volumes finished processing
[2019-01-24 13:36:02.731 UTC] [svservice:P1252:T2420] User has not configured for checking of VM persistence
[2019-01-24 13:36:02.731 UTC] [svservice:P1252:T4548] User has not configured for checking of Windows Update Service status
[2019-01-24 13:36:29.017 UTC] [svservice:P1252:T3176] OnStartShell called (Session ID 1, Handle 0000017143319C00, Params 0000003FDD0FE518, Context 0000000000000000)
[2019-01-24 13:36:29.017 UTC] [svservice:P1252:T3176] OnStartShell: APOLLO\XXXXXXXX (NameSamCompatible)

I've actually ran through and did some benchmark testing of logins to try and support this is a UEM related issue and not appvol or esxi. I did 29 logins with just horizon, horizon+uem, horizon+uem+appvol and horizon+appvol. The only place i see large inconsistencies are with UEM involved:

Agent	UEM	UEM+APP Vol	App vol
12	38	49	26
13	17	27	25
14	18	30	26
14	19	36	33
14	19	49	23
14	23	51	22
14	31	50	26
14	33	53	25
14	35	37	24
14	36	33	25
14	37	44	22
14	37	47	26
14	38	31	22
14	38	52	24
14	41	30	30
14	41	34	25
15	19	31	24
15	23	30	24
15	38	29	25
15	38	47	24
15	49	29	25
16	35	41	26
16	40	30	23
16	41	29	26
17	17	39	23
17	20	50	25
17	36	53	25
14	36	36	24
15	38	46	28

But regardless i appreciate the information

Re: UEM hanging/delaying randomly.

Sabian0309 — Wed, 23 Jan 2019 19:01:33 GMT

Running a direct flex refresh did not show any issue after 500+ runs (i make a simple bat file to run it 50 times then checked the log).

If i do a full refresh (flexengine.exe -r) I see times varying between 19 seconds and 30+, and can do a procmon while this happens. Anything specific to look for?