Dennis Parker
-
Posts
173 -
Joined
-
Last visited
-
Days Won
3
Content Type
Forums
Articles
Labs
Videos
TechZone
Citrix Community Articles
Events
Profiles
Posts posted by Dennis Parker
-
-
Seen this, or something very similar at least, for a very long time, but don't remember exactly what version it started with...
We had to disable resource monitoring to clear it up.
Citrix Policy - "Enable Resource Monitoring" = Disabled
Lose some metrics like CPU and Memory to Director, but we have other tools to monitor these. -
7 minutes ago, Jeff Riechers1709152667 said:
Try it out in Desktops if you can. That will load different parts of the authentication process and will allow it to be narrowed down to Citrix's engine, or Office's engine.
Do you see any info in the Okta logs when this problem shows up?
There are other forums that I monitor that have complained about it in RDP sessions as well, so I'm fairly confident that it is an Office on TS issue. Been working on this for probably 6 months or more.
I also doubt Microsoft would release anything like the article if they thought there was even a chance it was just a Citrix thing. ? -
Just now, Jeff Riechers1709152667 said:
Does it happen only on published applications? Or does it happen on Desktops as well.
Can't answer that. We only use published applications.
-
3 minutes ago, Glenn Dowling1709151535 said:
Assuming this was meant for me. ?
VDA is 2203 LTSR CU3, and it gets Windows Updates on a monthly basis. It seemed to start right after Microsoft 365 was updated in mid-October.
The other registry values were added to the VDA's weeks ago. I thought I had mentioned that in my initial post.
It launches, but when it gets redirected for authentication through our Okta portal, that's when the fun begins.
Profile Management = UPM
Assumed it was meant for me. ?
It has been getting progressively worse for us. We are an MSP and it seems like it hit tenant by tenant, not specifically with any version of Office. -
3 minutes ago, Jeff Riechers1709152667 said:
Did you do the rest of the items in that post? The updated VDA, and windows updates?
So is it not even launching? Or hanging on the auth process.
Also what are you using for your profile management? UPM or FSLogix?
Yes to all of the things.
Outlook launches, but hangs on Authentication when the token expires.
Can create a new Outlook profile to work around for a while, but that's certainly not sustainable.
We use Citrix UPM, but the PM tech is not the issue at all here. It's something with Microsoft. MS Engineers are working on the issue. We provided tons of logs to them. -
We are now seeing crashing with SDXHelper since doing the fix above. We are looking at a workaround for that right now.
-
Shellbridge does nothing for this in our environment.
A co-worker wrote a login script that deletes the Experiments keys, recreates them and denies access to them as a workaround.
It requires SetACL.exe: https://helgeklein.com/setacl/
Attached a .txt file that contains the ACLs we use with SetACL.exe.
put in a .cmd file:
@ECHO OFF reg delete HKCU\Software\Microsoft\Office\16.0\Common\Experiment /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs /f reg add HKCU\Software\Microsoft\Office\16.0\Common\Experiment /ve /f reg add HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs /ve /f reg add HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs /ve /f "%~dp0\SetACL.exe" -on hkcu\Software\Microsoft\Office\16.0\Common\Experiment -ot reg -actn restore -bckp "%~dp0\ExperimentACL.txt" -silent reg delete HKCU\Software\Microsoft\Office\16.0\Common\Experiment\excel /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\Experiment\outlook /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\Experiment\sdxhelper /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\Experiment\word /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs\ApplicationUpgradeCandidate /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs\Ecs /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs\ExternalFeatureOverrides /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs\FirstSession /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs\FirstSessionUpgradeCandidate /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs\SDXInfo /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs\all /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs\excel /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs\outlook /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs\Overrides /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs\sdxhelper /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs\unknown_app /f reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs\word /f
-
2203 CU2 and now 1912 CU7 both force the OST back to the default location.
For 2203 CU2 open a support case an reference CVADHELP-21974.
I don't have anything specific to reference for 1912 other than my case # where they provided a private hotfix on Thursday. Case #: 81803606 -
I believe you also need to roam: AppData\Local\Microsoft\OneAuth if I recall correctly. I have it in my roaming settings and am pretty sure it came with Teams. Also recommended, if you use the Teams features in Outlook:
AppData\Local\Microsoft\TeamsMeetingAddin
AppData\Local\Microsoft\TeamsPresenceAddin -
Well, there was a hotfix for it. Upgrade to CU3 fixes it. Finding the RDP user account that causes the issue and stop them from logging in to the server is an option.
-
I would think you are looking for more issues with trying to rename the new SQL server. Just restoring to a new SQL server and pointing the Delivery Controllers to the new DB is the safer bet, in my opinion. It's pretty painless, have done it a few times.
-
This sounds very similar to an issue I ran into a few weeks back. A user changed their password and then were not able to launch applications, but I can't remember for sure if the page just did a refresh or what exactly, but it seems like that was the symptom. Anyway, the user put a space as the last character of the new password. Changing the password without the space at the end resolved the issue.
-
Haven't seen the issue on 2012 personally, but on 2016 clearing credentials from credential manager would usually clear it up. Upgrading Office to newer releases stopped it from happening as well, when they stopped using credential manager to store Outlook credentials.
-
Just now, Kasper Johansen1709159522 said:
Beat you with a few seconds ?
Yeah, I saw the notification just as I clicked Submit. ?
-
You don't mention what OS you are working on here, but the most common solution seen is to add this to a PowerShell login script:
if (-not (Get-AppxPackage Microsoft.AAD.BrokerPlugin)) { Add-AppxPackage -Register "$env:windir\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown } Get-AppxPackage Microsoft.AAD.BrokerPlugin
-
Don't know why this starts happening, but we have discovered that if you do a full "Reset Citrix Workspace" it clears up for a while, but it usually will return eventually.
Interested to see if others have ideas. -
You didn't mention CU version and patches...but maybe this?
https://support.citrix.com/article/CTX322615or maybe this...
https://support.citrix.com/article/CTX215872https://discussions.citrix.com/topic/396857-logon-duration-data-missing-in-citrix-director/
-
2
-
-
You did say 7.15 in the initial post about this, so I thought that's what we were talking about, but neither here nor there.
I can't tell you specifically anything that causes the WMI spike, but I can direct you to a few discussions about the issue that helped me find my issues:
https://discussions.citrix.com/topic/400135-xenapp-715-cu2-wmiprvseexe-high-cpu/
https://discussions.citrix.com/topic/395518-wmiprvse-high-cpu-utilization/#comment-2010908
https://github.com/prometheus-community/windows_exporter/issues/89 -
Yeah, those stats in Director aren't gathered. I set the "Enable resource monitoring" policy to Prohibited in Citrix policies.
-
Look at Citrix monitoring as well. It isn't the monitoring itself that caused our issue either. It was a WMI "rebuild" process triggered by the monitoring processes. And it seems there are several WMI calls can trigger this rebuild.
-
We had WMI High CPU issues for quite some time. There are threads about it here in the forums somewhere still I'm sure. We ended up disabling a feature in our monitoring system (I can't recall the exact WMI calls it was doing and what we disabled, but this wasn't CPU as we still do CPU monitoring with the monitoring system) and Citrix CPU monitoring that were both causing WMI rebuilds at a regular interval due to what others have deemed to be a bug, but Microsoft hasn't changed/fixed as far as I have seen.
This may not be related to your specific case since we didn't have the same issues with the Print Spooler service you are seeing in that case.
We did have some printer billing software packages that also generated high WMI CPU as they were doing their function and had to get fixes from the different vendors (at least two different vendors have caused this sort of issue for us, as well as one VOIP phone system), but again, not the Spooler service that you also are seeing.
This can get difficult to troubleshoot as there are potentially many different causes that end up with the same symptom in the end and any one of them alone will cause it and disabling the one thing won't fix the issue. Breaking a "rule" of troubleshooting, only make one change at a time to see if things are fixed. -
There are many reasons that can have issues and some really depend on your authorization configuration as well. Not knowing enough about the configuration, just going to throw out some things for you to search/test and see if they fit your environment.
- disableadalatopwamoverride
- shared licensing
- check add-ins installed. (Test with some add-ins disabled)
- Personal account using same email as federated work account
-
I'd say it depends on what you are trying to accomplish exactly.
I have used Application Groups to force users to log in to specific servers and if their primary is unavailable, fail back to any available server. This could be expanded to use pools of servers for user 1 and a different pool of servers for user 2 so they will never be logged into the same server but have multiple servers available to log in with.
-
Seen this after an upgrade where the old version wasn't completely/properly removed. A full VDACleanup Utility removal and VDA reinstall fixed the issue.
Seen this when our Group Policies aren't properly being applied to the VDA. I think this is because we set SeamLessFlags to 0x104 by policy for display issues (there aren't any other policy settings I can see that would really relate to this that I can see).
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI SeamlessFlags DWORD 0x104Have seen this inconsistently with EDT connections where disabling EDT on the client end solved the issue.
StoreFront Store Web URL Stopped working after upgrading from LTSR 2203 CU 1 to LTSR 2203 CU4
in XenApp 7.x
Posted
https://support.citrix.com/article/CTX584143/user-enumeration-or-launch-failures-after-upgrading-citrix-storefront-to-ltsr-2203-cu4
Probably want to check with Citrix support.