Joe W
-
Posts
66 -
Joined
-
Last visited
Content Type
Forums
Articles
Labs
Videos
TechZone
Citrix Community Articles
Events
Profiles
Posts posted by Joe W
-
-
I also would like to know what others are setting the RAM buffer size to. I have read that 4096Mb is recommended for Desktops, but that seems quite low, as users can easily burn through that in a couple of hours. I guess what I need to know is how the buffer works and if I am having issues with the cache drive filling up should I increase this or should I be increasing the overall memory on the host vm?
-
Just wondering what the average cache drive size is for users? We are running Windows 2016 Desktop servers, averaging around 11-12 users per box and are running into frequent instances where the cache drive is filling up and the box crashes, needing to be rebooted. Not ideal in the middle of a workday to say the least. Our cache drives are 20 Gb and we are using "Cache in device RAM, with overflow to Hard Disk. Each vm is configured with 24Gb of RAM.
It would appear that the bulk of the writes to the disk are being done my Edge and Chrome caching, which to my knowledge cannnot/should not be disabled.
-
Hey Alan,
That's a negative. Still occurs 3-4 times a day on any number of Desktop servers. It doesn't seem to affect performance-- at least people aren't complaining lol. More of an annoyance as our WhatsUp Gold monitor sends out multiple emails alerting us of the high CPU condition.
-
Still no joy unfortunately. I turned off resource monitoring and while I am not seeing the WMI Provider Host consuimg high CPU at this time, I do still have an issue with the Spooler service. I observed something strange in the C:\Windows\system32\spool folder. Every few seonds the folder would populate with .cab files and folders with a GUID string as the name. Then they would disappear. I compared this to a machine which was not experiencing high CPU and did not see this behavior. A quick google search led me to a bad printer driver again. But how to determine which one is causing the issue? Users are not reporting any issues with printing at all.
-
We did not. A lot of these are thin clients (some Linux-based) and not on the domain either.
-
Here is the issue:
We began deploying new XenApp clients using the fqdn of the server hosting the Storefront site. But now we want to change it to something a little friendler e.g. citrix.mydomain.com. We don't want to go back and reconfigure all the clients we have previously deployed so how can we use another hostname and point it to the existing Storefront site. I have already generated the self-signed cert w/ a SAN of citrix.mydomain.com and it seems to work through the browser. However configuring Receiver to use the new url does not work. I imagine becuase it is returning the metadata of the site configured with the fqdn and it doesn't like that.
-
All of our high WMI cpu instances are always coupled with the Windows spooler service (both on Windows 2008 R2/XA7.6 & Windows 2016/XA7.15).
I have yet to find a cause... or a solution.
-
My bad. I am running two farms concurrently 7.6 (on Windows 2008 R2) and 7.15 (on Windows 2016). Both farms experience the same exact problem which is what makes it so confounding.
I will review those links and see if there is anything I missed. In the meantime, I will disable the CPU Usage monitoring on the 7.6 farm and will monitor the effects.
-
So I guess this policy setting isn't available in version 7.6 of Xen App. Seems like 7.12 is when they added it. Instead I see a setting for CPU monitoring.
I guess my question is: what specifically triggers the WMI service to spike?
-
Oh wow. OK. Worth a shot. I've tried everything else.
Thanks!
-
Where would I look to find/configure CItrix monitoring? I guess you do see CPU/memory stats in Director. I didn't think of that.
-
Yeah, we originally thought it was our monitoring (What's Up Gold) that was casuing the issue, but we switched to monitoring CPU, memory, etc. from the VMWare side rather than Windows thinking this would solve the problem but it did not.
-
I have been battling this problem for years now and really need to find a solution. We have a 7.15 farm hosting provisioned Windows 2016 desktops running on esx 6.5 hosts. Each vm averages about 7-8 users a day. Every day at least one or multiple servers experiences an issue where something is causing the WMI Profiver Host service and the Spooler service to consume large quantities of CPU for extended periods of time-- sometimes for hours. If you end one service the other will drop off too only to resume occupying the CPU again moments later. I have tried everything from resetting the WMI metrics to installing all new printer drivers . There has to be someone out there who has seen this behavior before?
-
12 hours ago, Sjoerd Van den Nieuwenhof said:
Hi Alex,
We saw that same behavior with another customer and stopped using the shadowing feature and then they didn't had that issue.
I will test this at a customer to disable shadowing.
If Citrix finds anything hopefully this solves our problem.
We just had a crash: users got shadowed at 8:07, server crashed 15 minutes later. at 8:08 all logging stopped. (logging was redirected to WCD).
I just found this forum post: https://discussions.citrix.com/topic/408153-remote-assistance-crashes-local-and-remote-session-when-it-ends/
Maybe this would solve our issue.
Thanks for the update.
regards.
Sjoerd
Strange. We've never had any issues with shadowing in any version going all the way back to XenApp 5.0. It just goes to show that there isn't any one, single solution to this issue. At least not that we've discovered yet.
-
Hi Sjoerd,
Thanks for posting. Please let us know the outcome of your case(s).
We just recently upgraded our Provisioning to 1912 CU1 and since have not experienced the issue. I'm not saying that it is resolved but just wanted to document it here.
-
-
Hi Carl,
Thanks for the reply.
That folder is there, but I don't recall installing it and I certainly am not using it. Can I uninstall it by re-running the VDA setup?
-
-
We have had the same issue since upgrading to 7.6 to 7.15. Our Desktop and Published Application servers reboot nightly and randomly some will never re-register and become "zombified" for lack of a better word.
Currently running PVS 7.18 with no change. Was contemplating upgrading to the latest issue (2009) but ran into an issue with the Target Device upgrade (https://discussions.citrix.com/topic/411194-citrix-provisioning-target-device-x64-200900-does-not-support-personal-vdisk/)
Was then considering going to 1912 CU1 but it sounds like the person above is still having the same problem. I can't believe this hasn't been fixed over so many versions and CUs. This was never an issue in 7.6.
I also have another thread going but no responses: https://discussions.citrix.com/topic/410736-target-devices-becoming-unresponsive-vmware/
-
I'm trying to upgrade my Provisioning Services Target Device (Windows 2016 Server) from 7.15 CU1 to the latest version (2009) and receive the following error: "Citrix Provisioning Target Device x64 2009.0.0 does not support Personal vDisk."
As far as I am aware, I am not using a Personal vDisk. This is a Windows 2016 vdisk that serves up Desktops to a XenApp Delivery Group. I have the vdisk in Private mode and trying to perform an in-place upgrade per official Citrix documentation.
-
For the record, I'm not using Personal vDisks. This is a standard vDisk in Private mode, trying to perform an in-place upgrade.
-
I am getting an error message that "Citrix Provisioning Target Device x64 2009.0.0 does not support Personal vDisk."
-
Are there any prerequisites for upgrading Provisioning 7.15 LTSR (7.18.0.106 to be exact) to the latest version, 2009?
-
OK, here is the link to my thread if you want to follow it: https://discussions.citrix.com/topic/410736-target-devices-becoming-unresponsive-vmware/
Fwiw, we don't have any antivirus or security software installed other than Defender, and are still experiencing the issue.
No device license warning
in Provisioning Server Compatibility
Posted
We just started having this issue after the PVS server rebooted the other night from Windows updates. Already tried all the recommended fixes to no avail.