ENS 10.5 / TIE SRV 22.214.171.124 > OK to Update DXL from 126.96.36.1995 to 188.8.131.52 on all clients?
Is it ok to update the DXL from 184.108.40.2065 to 220.127.116.11. Or even if its a must if you RUN END 10.5. All is working but
we want to keep things up to date.
We have seen posting where people had problems regarding the TIE Server IF they updated DXL components in the past DIFFERENT
then the version which where mentioned in the TIE release notes or software sets on the Download pages.
since TIE and DXL is available we always used different versions or we never installed the DXL Service on the TIE Server. We are always using dedicated DXL Broker appliances in corporate Environments.
We only have one customer which uses the DXL Service on the TIE Server.
Separating DXL Brokers and TIE Servers is also recommended by McAfee.
We also noticed no Problems with different DXL Client Versions on the endpoint, ATD and MWG in one Environment.
If you're running DXL brokers on your TIE servers, the DXL broker gets updated as part of the TIE server update. You're not meant to use the DXL broker package on a TIE server. I can't remember where I read that in the documentation, but can probably dig out the reference if you need it.
I can't answer if the newer DXL client would communicate with the older DXL broker version; I wasn't game to try. 😛 I'm hoping they update the TIE package soon to include the new DXL broker, so I can upgrade them. Like you, I like to stay on top of my security product upgrades.
@Thorsten_Schranz, where did you read that McAfee recommends separating DXL & TIE? I just implemented TIE in my environment and don't remember reading that anywhere, nor did our McAfee reps tell me that when I discussed how to deploy TIE with them. I have TIE & DXL both together on a pair of servers inside our corporate network, and just a DXL broker in the DMZ to service clients outside the network. I'd be interested in reading what they had to say about separating them.
we discussed this at several meetings and doings.
There are many settings for TIE/EPO/ATD/MWG/Endpoint which are not documented. I do not know why, but this is real life.
Finally, in most cases we got the information using dedicated DXL broker appliances in bigger customer environments. I think it depends on the amount of request and connections when many DXL messages are sent. In some cases we saw 4000 and more requests/second on DXL brokers. From our experience this works fine.
If you have any other information or another question, please let me know.
"If you're running DXL
brokers on your TIE servers, the DXL broker gets updated as part of the TIE
server update. You're not meant to use the DXL broker package on a TIE
> Thats how i had it in
MIND somewhere in a BEST Practice or even in the Release Notes.
@Troja, I even think you once mentioned that to me once that we should not update DXL outisde a TIE release. I was hoping you answer again so thank you. (Gruss nach Wien)
I would from my side never have the idea to update the DXL Part which runs on the TIE-Server if something
does not work. However there must be a reason maybe because of performance.
In the future i think these points have to be more cleared out by MCAFEE. They did release in short times
around 5-6 Patches (Security) for the EPO itself and also the other products.
I think anything that is not "Drive by Infection" or "Ransomware" > Real Attacks.
They currently try starting to attack the TIE Servers which block them. That seems a good sign However you need to fast patch things now. And with all the PRODUCTS on one EPO Server this is beginning
to be a Negative sign. You will have to check DLP, TIE, MAR and all Before you install such an
important patch i think.
For the scaling of the TIE / DXL Server i think most samples showed all functions on one server. I did see
a real new Youtube Movie where they showed TIE and MAR Server installation and
did not even DXL Broker in one word.
I have to day that on the EPO side this seems also not too good documented for architects. Like Splitting
different roles on different EPO Server (ONE DLP, ONE TIE etc.)
Just because of the RISK of upgrading or migration.
I just turned of SIEM to SPLUNK because i did not want to have another product on the EPO server again.