cancel
Showing results for 
Search instead for 
Did you mean: 

Re: Problem with ENS 10.6.1+November Update and Citrix XenApp 7.15

Jump to solution

@tzemva

I did not understand what MCafee process I should enter as badapp.exe ?

McAfee Employee tzemva
McAfee Employee
Report Inappropriate Content
Message 22 of 64

Re: Problem with ENS 10.6.1+November Update and Citrix XenApp 7.15

Jump to solution

Hi @xaba_sg,

"badapp.exe" is just an example...

I would recommend to exclude all ENS related processes:

This are McAfee Service Manager (MMS) managed processes from my test box:

PS C:\Program Files\Common Files\McAfee\SystemCore> .\mmsinfo.exe -enum
SERVICE_NAME:   mfeatp
SERVICE_STATUS  SERVICE_RUNNING

SERVICE_NAME:   mfecore
SERVICE_STATUS  SERVICE_RUNNING

SERVICE_NAME:   mfedxl
SERVICE_STATUS  SERVICE_RUNNING

SERVICE_NAME:   mfeensppl
SERVICE_STATUS  SERVICE_STOPPED

SERVICE_NAME:   mfeesp
SERVICE_STATUS  SERVICE_RUNNING

SERVICE_NAME:   mfefire
SERVICE_STATUS  SERVICE_RUNNING

SERVICE_NAME:   mfefw
SERVICE_STATUS  SERVICE_RUNNING

SERVICE_NAME:   mfehcs
SERVICE_STATUS  SERVICE_RUNNING

SERVICE_NAME:   mfemcp
SERVICE_STATUS  SERVICE_RUNNING

SERVICE_NAME:   mfetp
SERVICE_STATUS  SERVICE_RUNNING

SERVICE_NAME:   mfevtp
SERVICE_STATUS  SERVICE_RUNNING

So, based on Citrix article I would add:

For Windows 64-bit version
Keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook64
Value Name: ExcludedImageNames
Type: REG_SZ
Value: mfeatp.exe, mfecore.exe, mfedxl.exe, mfeesp.exe, mfevtp.exe, mfetp.exe, mfefw.exe, mfehcs.exe, mfefire.exe

Re: Problem with ENS 10.6.1+November Update and Citrix XenApp 7.15

Jump to solution

I know that "badapp.exe"....is just an example.

I will try...with your Mcafee list.

Citrix's answer:

 Firstly , this MCafee is not a Citrix Hook . so its not relevant to add the mcafee application in this.

 We normally disable the published application form the Citrix Hook .

 Here Mcafee is not the published application .

 

Re: Problem with ENS 10.6.1+November Update and Citrix XenApp 7.15

Jump to solution

With this settings:

For Windows 64-bit version

Keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook

Value Name: ExcludedImageNames
Type: REG_SZ
Value: mfeatp.exe, mfecore.exe, mfedxl.exe, mfeesp.exe, mfevtp.exe, mfetp.exe, mfefw.exe, mfehcs.exe, mfefire.exe

"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook64" this key is not present.

the issue has not occured. I will do more extensive tests tomorrow.

 

mr
Level 8
Report Inappropriate Content
Message 25 of 64

Re: Problem with ENS 10.6.1+November Update and Citrix XenApp 7.15

Jump to solution

Added listed registry keys to image.  Reboot.  No change.

McAfee 10.5 image - 30sec to desktop.

McAfee 10.6 image - 140sec to desktop.

mr
Level 8
Report Inappropriate Content
Message 26 of 64

Re: Problem with ENS 10.6.1+November Update and Citrix XenApp 7.15

Jump to solution

To wrap this up for anyone following along:

For us the registry entries mentioned above did nothing.  We had also tried the userprofilemanager.exe fix - setting it as a LOW Risk process with scanning disabled for low risk processes with no improvement.  However, in follow up with McAfee support, we tried the LOW Risk setting again and it suddenly worked.  I don't know if there was a DAT change or some strange event steps but is seems to be holding.  We did not use this setting under the prior McAfee patch/version - McAfee offered no explanation as to what change made it necessary.

Re: Problem with ENS 10.6.1+November Update and Citrix XenApp 7.15

Jump to solution

Thanks for the info.

I want to try to remove the registry keys (in the Test Environment), to see what happens.

On the production environment for the moment I maintain Viruscan 8.8 Patch 10.

McAfee Employee akatt
McAfee Employee
Report Inappropriate Content
Message 28 of 64

Re: Problem with ENS 10.6.1+November Update and Citrix XenApp 7.15

Jump to solution

@mr @xaba_sg

It is worth noting that we seem to be discussing two, possibly related, but different issues here.

1.  The ability for applications to "hook" McAfee processes, aka perform dll injection

2.  Configuring the On-Access Scanner to ignore disk activity of a given process, and thereby prevent scanning of everything that process performs (disk read/write).

@xaba_sg

Citrix allows for excluding certain applications from being "hooked" by their processes, but as I understand it, this is only for child processes of the Citrix application.  The core, or parent, processes cannot be configured to prevent their injection...the application would lose functionality.  Every so often, McAfee has to gather the certificates for these parent dll's used by Citrix, and then add them to the McAfee Trust Certificate store, in order for McAfee products to "trust" that the injected Citrix dll's are indeed legitimate dll's, allowing use in some way of McAfee processes, and also confirming that the dll injection is non-malicious (not Malware).  Note, that, dll injection into a McAfee process doesn't necessarily mean that either the McAfee application, nor the injecting application, may experience an issue; It is too difficult to project what might occur when allowing 3rd-party applications to inject into a McAfee process.  Generall, though, for Citrix it does not cause a product functionality loss for their software, nor McAfee software, when allowing the injection, but if we do not already trust the dll that is attempting injection, you could experience things such as McAfee software patch/upgrade/install failures (due to routine installer checks that occur during install).  If there are any unstrusted-by-McAfee dll's within your environment that you feel should be trusted by McAfee, or that might be causing an issue, we can start the review of those dll's through opening a support service request.  We will need the digitial certificate of the dll's which are injecting, to start the review process and determine whether or not we can sucessfully add them to the McAfee Trust Certificate Store.

@mr

The issue described has to do with logon performance.  One of the common items related to logon performance with Citrix, and McAfee software that performs scanning (VSE/ENS/MOVE), is due to the scanners monitoring the disk activity of UserProfileManager.exe.  In fact, some years back, we went ahead and added this process as a process exclusion within MOVE default policies (in ePO), as support would commonly help customers perform this process exclusion with MOVE, and all logon performance degredation would cease.  This isn't something we have done with product such as VSE/ENS, and as such we must manually configure it.  I would be curious to see all of the details regarding this specific support case, as there are a couple of aspects regarding the usage of "low-risk" that I find are misinterpreted, or perhaps just overlooked, commonly.  

In order to sucessfully use low-risk process polices (for what they are normally intended, aka a "process" exclusion) we must:

--Enable the feature to use Default, Low, and High-risk process policies (this is within the Default Processes policy for VSE, and within the On-Access Scan advanced options for ENS)
--Add the process name to the low-risk processes policy (example:  test.exe)
--Within the low-risk processes policy, disable scan on read and scan on write (NOTE:  for UserProfileManager.exe, we could probably just disable scan on read, as I believe most of the logon disk activity is read activity).

Personally, I commonly find that either item 1 was never enabled, but since ePO allows for modifying the low-risk settings without enabling the option, the low-risk settings never apply to the systems for which they are intended).  Or, I commonly find that the exe is added as a file exclusion within the Default Process Policy.  The latter, simply tells the product to ignore that single file on disk, whereas performing the "process exclusion" using low-risk, tells the scanners to ignore all disk read/write activity for the added processes.

Hopefully, this helps explain a bit more in detail.

 

Was my reply helpful?

If this information was helpful in any way, or answered your question, will you please select "Accept as Solution" in my reply, or give kudos as appropriate, so together we can help other members?




Highlighted
mr
Level 8
Report Inappropriate Content
Message 29 of 64

Re: Problem with ENS 10.6.1+November Update and Citrix XenApp 7.15

Jump to solution

akatt,

 

Certainly well described, thank you.

What I assume happened then is that 10.6.X enabled access from the hook process into the DLL as you've described.  If that were the case however, blocking the hook activity through the registry would have brought us back to normal without adding the high/low process rules.  And, it doesn't explain the situation where high/low intitially failed to resolve the issue.

If we can't define what led to our situation between 10.5.X and 10.6.X then we will have to be satisfied with the current resolution and hope there is nothing further that needs to be configured to prevent future occurance.

Thanks again.

Re: Problem with ENS 10.6.1+November Update and Citrix XenApp 7.15

Jump to solution

I tried to remove the changes made to the registry. But the problem remains.
Furthermore, after the various AmCore updates, it does not even work with the registry keys set.

I do not know if things can be related.


However, I am sending the logs again on the SR with the addition of the MER.

@akatt

How can we identify the DLL?

More McAfee Tools to Help You
  • Subscription Service Notification (SNS)
  • How-to: Endpoint Removal Tool
  • Support: Endpoint Security
  • eSupport: Policy Orchestrator