Install Trellix Agent on RHEL 9.8

Install Trellix Agent on a RHEL 9.8 VM and verify its ePO check-in.

Introduction

30 Second Summary

A server can appear healthy while the security team has no way to manage it. That silence becomes a rollout risk when the same gap spreads across more machines.

In this project, you will install Trellix Agent 5.8.6 on one approved RHEL 9.8 pilot VM in VMware vSphere. You will prove secure reachability to your existing Trellix ePolicy Orchestrator environment before using one successful check-in as the gate for a controlled wider rollout.

What You'll Build

Your final demo is a check-in that makes the pilot VM appear in ePO with the expected agent version plus a recent communication time.

By the end of this project, you'll have:

A pilot VM where the running Trellix Agent service gives you a local health check before any broader rollout.
A proven secure route to the approved management endpoint. You can show that DNS resolves the name. You can also show that outbound TCP 443 completes a TLS handshake with the expected certificate.
A managed ePO record that displays the expected agent version. Its recent communication time proves the pilot can phone home.
Secret Mission: Prepare a nonproduction vSphere template that gives each test clone a unique Trellix Agent identity. Prove the source VM plus clone appear as separate ePO records.

Are there any prerequisites?

You need access to the existing ePO environment plus one approved persistent RHEL 9.8 pilot VM in vSphere. Step 1 checks your privileges, endpoint FQDN, installer, System Tree access, plus change and rollback records before installation.

Before We Start

This checkpoint commits the project to one approved persistent nonproduction RHEL 9.8 VM in VMware vSphere, so the wider server fleet stays untouched. Your scope record names the pilot, its safety rationale, the approved change record, and the rollback owner before any Trellix Agent or ePO changes begin.

Gather the Trusted Inputs

A trusted installer is like a key cut for one lock. Your Trellix ePolicy Orchestrator On-Premises control plane must match the agent package before it reaches the pilot.

You'll confirm the existing control plane. You'll also prove every required access route before staging the environment-generated installer.

In this step, get ready to:

Record the approved ePO endpoint details.
Confirm every administration path for the pilot.
Stage the environment-generated installer without running it.

Confirm the control plane

The installer gets its management destination from your ePO environment. A fully qualified domain name (FQDN) identifies the approved endpoint without relying on a guessed short name or IP address.

Ask your ePO administrator to confirm the exact ePO On-Premises update.
Record the exact update here: your exact ePO On-Premises version.
Compare the recorded update with 5.10.0 Update 13.
Stop this deployment if the update is older than 5.10.0 Update 13.
Record the endpoint type here: ePO manager or Agent Handler.
Record the approved endpoint FQDN here: your approved ePO or Agent Handler FQDN.
Confirm the recorded FQDN with the environment owner.

Why does the update gate matter?

Trellix Agent versions 5.8.0 through 5.8.6 require ePO 5.10.0 Update 13 or later. This gate keeps the pilot inside the supported management range.

Confirm access and rollback

The VMware vSphere Client gives you the console path to the pilot. The Red Hat Enterprise Linux terminal proves you can reach the host selected for deployment.

Sign in to the VMware vSphere Client with your approved account.
Locate the pilot VM named in the approved change record.
Match the selected VM to the persistent nonproduction pilot recorded earlier.
Open the pilot VM console.
Confirm your assigned account has root or sudo privileges.

The pilot console is now available for the release check at the end of this step.

Sign in to ePO with your approved account.
Open the System Tree to confirm your account can view managed systems.
Return to the approved change record from earlier.
Confirm the recorded change owner remains responsible for the pilot.
Confirm the recorded rollback owner remains authorized to remove or reinstall the agent.

Stage the approved installer

An environment-generated Smart Installer carries the connection details for one ePO environment. Keeping the script inside the approved internal transfer path protects that destination boundary.

Request TrellixSmartInstall.sh from the approved ePO administrator.
Receive the script through the approved internal transfer path.
Stage the script inside the approved internal location for this pilot.
Confirm the filename is exactly TrellixSmartInstall.sh.
Confirm with the ePO administrator that the repository targets Trellix Agent 5.8.6 package build 5.8.6.185.
Reject any installer copied from a public mirror.
Reject any installer generated by a different ePO environment.
Leave the staged script unexecuted.

Why use the environment-generated installer?

The approved ePO administrator supplies a script tied to your management environment. This gives the pilot the correct destination when installation happens later.

A public mirror or script from another environment breaks that chain of trust.

Trusted Inputs Checkpoint

The approved persistent nonproduction RHEL 9.8 VM remains the only pilot. Its authorized change and rollback owners remain recorded.

The approved ePO administrator supplied TrellixSmartInstall.sh. The script remains unexecuted in the approved internal location.

ePO On-Premises is 5.10.0 Update 13 or later. The approved endpoint type and FQDN are recorded.

System Tree access is confirmed. The repository targets Trellix Agent 5.8.6 package build 5.8.6.185.

Return to the pilot VM console from earlier.

Before you run the check, which release do you expect the approved pilot to report?

Confirm the approved release by running this command:

cat /etc/redhat-release

What does this check?

The cat command prints the operating-system release information stored in /etc/redhat-release. This gives you visible evidence that the selected console belongs to the approved pilot.

You'll see the terminal identify the approved pilot as RHEL 9.8.

Seeing a different release?

Stop before installation if the terminal identifies another release.
Ask the platform owner to restore the approved pilot scope.

If the VM details do not match the change record, help me verify the correct RHEL pilot before installing Trellix Agent.

The trusted inputs are now locked down. Next, you'll prove the pilot can reach the approved ePO endpoint securely.

Prove the Secure Path

Your approved VMware vSphere pilot is ready. The deployment inputs in ePO are also confirmed.

The next risk is making changes to a Red Hat Enterprise Linux host whose identity or security state is unclear. You'll record the pilot's baseline before any installation begins.

DNS locates the approved endpoint. TCP port 443 carries the connection.

TLS version 1.2 checks the server certificate. ePO still needs more than a reachable network path to recognize the pilot as managed.

In this step, get ready to:

Record the pilot's operating-system identity and security posture.
Clear the local storage and software-state checks.
Prove secure reachability to the approved ePO endpoint.

Record the pilot baseline

The pilot's future ePO record depends on the identity reported by the host. Its current security posture also becomes the baseline for troubleshooting.

Collect the release, kernel, FIPS mode, SELinux mode, and hostname by running each command below one at a time:

cat /etc/redhat-release
uname -r
fips-mode-setup --check
getenforce
hostnamectl status --static

What do these checks prove?

The /etc/redhat-release file identifies the installed RHEL release.
The uname command reports the running Red Hat kernel.
The fips-mode-setup command reports the current FIPS state.
The getenforce command reports whether SELinux is enforcing, permissive, or disabled.
The hostnamectl command reports the static hostname that identifies this pilot.

You should see Red Hat Enterprise Linux 9.8 in the release result. The kernel may retain an upstream-looking 5.14 base because Red Hat backports changes into its kernel packages.

Record the release result here: your RHEL release.
Record the running kernel here: your running Red Hat kernel.
Record the FIPS result here: your current FIPS mode.
Record the SELinux result here: your current SELinux mode.
Record the static hostname here: your pilot hostname.

Missing a baseline result?

Confirm that you are using the RHEL terminal from earlier.
Record any unavailable check as a preflight gap.
Ask the Linux owner to verify the missing system tool before continuing.

Share the unavailable command and its terminal output when you ask for help with the pilot baseline.

Confirm local readiness

The Trellix Agent stores working data under /var. A full filesystem can prevent later agent-server communication.

Check the pilot's filesystem capacity by running:

df -h

What does this check prove?

The df command reports filesystem usage in readable units. Use the filesystem row that covers /var.

If /var has no separate row, use the row mounted on /.

Locate the filesystem that contains /var.
Record its free-space status here: your /var free-space status.

The relevant filesystem must have available capacity. A full filesystem is a stop condition.

Check the pilot against your approved software inventory for an existing Trellix Agent package or service.
Inspect /opt/McAfee/agent/bin/ through your organization's approved host-inspection process.
Confirm that no unknown or partially removed Trellix Agent is present.
Stop the preflight if the software state is unclear.
Escalate the inventory evidence to the change owner.

Is the host state unclear?

Preserve the inventory evidence before anyone removes or reinstalls software. The rollback owner needs that evidence to choose the approved recovery path.

Use the observed package, service, or directory details when you ask for help identifying a partial Trellix Agent installation.

Prove DNS and TLS reachability

The pilot must use approved internal name resolution before it contacts the management endpoint. The resolver configuration shows which DNS servers the host consults.

Display the pilot's resolver configuration by running:

cat /etc/resolv.conf

What does this configuration show?

The /etc/resolv.conf file displays the configured DNS search entries. It also displays each nameserver entry.

These entries identify the resolvers that handle the approved endpoint name. They must match your organization's internal DNS configuration.

Compare the listed resolver addresses with the approved internal DNS servers.
Record the matching servers here: approved internal DNS servers.

Do the DNS servers look wrong?

Stop before testing the management endpoint.
Send the resolver configuration to the Linux or network owner.
Keep the current network settings unchanged during the escalation.

Include the expected internal resolver addresses when you ask for help with the pilot's DNS configuration.

Before you test, ask yourself whether secure reachability alone creates a current managed record in ePO.

Replace <EPO_FQDN> with the approved ePO manager or Agent Handler FQDN from earlier.
Test the TLS 1.2 route on TCP 443 by running:

openssl s_client -connect <EPO_FQDN>:443 -tls1_2

What does this connection test prove?

The -connect option directs the test to your approved management endpoint.
The :443 value tests the outbound agent-server communication port.
The -tls1_2 option requires a TLS 1.2 negotiation.
A completed handshake proves that DNS resolution and the secure network path are working.

Compare the displayed server certificate with the expected certificate for the approved endpoint.
Press Ctrl+C after reviewing the handshake.

You'll see a TLS handshake and a server certificate when the path is working. The certificate should identify the approved ePO manager or Agent Handler.

Handshake missing or certificate unexpected?

Stop if the endpoint name does not resolve.
Stop if the connection times out.
Escalate if a firewall or proxy presents a substituted certificate.
Keep certificate checking and the current security controls enabled.

Share the redacted connection output when you ask for help with the TLS path.

Return to the ePO System Tree from earlier.
Search for the pilot using your pilot hostname.
Confirm that the pilot has no current Last communicated value.
Stop if a different VM appears under the pilot hostname.
Escalate any current or conflicting record to the ePO administrator.

The secure route works while the pilot remains unmanaged in ePO. That shortfall is the intended result of this preflight.

You have now separated network readiness from endpoint management. The pilot's identity, security posture, storage state, DNS configuration, and TLS path are recorded.

The pilot has a proven secure path without weakening any host or network control. Next, you'll use the approved installer to give the VM its Trellix Agent identity.

Install the Trellix Agent

Your pilot has already reached its approved management endpoint over the secure route you proved. The open network road is ready for an endpoint agent.

Installing Trellix Agent gives the VM its trusted management identity. Its local service supplies the radio that the management server can hear after check-in.

In this step, get ready to:

Confirm the approved installer is staged on the designated pilot.
Run the environment-generated Smart Installer with elevated privileges.
Verify local agent health after installation.

Recheck the installer boundary

An environment-generated installer belongs to one management environment. The approved staging boundary keeps that installer on the designated pilot.

Switch back to the VMware vSphere Client console for the approved pilot.
Compare the VM name shown in the console with your pilot deployment scope record.
Return to the pilot's Red Hat Enterprise Linux terminal from earlier.
Return to the approved staging location that contains TrellixSmartInstall.sh.
Confirm the filename is exactly TrellixSmartInstall.sh.
Review the installer handoff record to confirm it came from the approved ePO administrator.
Keep the installer inside its approved staging location.

The matching pilot name keeps the target clear. The approved handoff confirms the installer belongs to this ePO environment.

Run the official Smart Installer commands

The approved Smart Installer uses the package target from your existing Trellix ePolicy Orchestrator (ePO) deployment inputs. That target is Trellix Agent 5.8.6 package build 5.8.6.185.

Elevated privileges make this the point where the VM changes. Your approved pilot plus named rollback owner keep the change controlled.

Give TrellixSmartInstall.sh execute permission by running the first command below.
Install the agent with administrator rights by running the second command below.

sudo chmod +x TrellixSmartInstall.sh
sudo ./TrellixSmartInstall.sh

What do these commands do?

The first command makes the approved Linux installer executable.
The second command runs the installer with the administrator rights required to install Trellix Agent.
The Smart Installer uses the configuration generated by your existing ePO environment.

Wait for the installer process to return control to the terminal.
Review the terminal output for a completed installation.

The installer has now applied the approved agent package to this pilot. The next check proves that its local service started successfully.

Installation did not complete?

Preserve /tmp/McAfeeSmartInstall.log for the authorized rollback owner.
Stop before retrying the installer with different switches.
Keep the installer inside the same approved security zone.

Ask for help to diagnose a failed Trellix Smart Installer run.

Confirm local agent health

A running service proves that the agent started locally. Managed status requires the server-side check-in in the next step.

Before you check, do you expect the service to be stopped or running after a successful installation?

Check the Trellix Agent service by running this command:

/etc/init.d/ma status

What does this command show?

This command queries the Trellix Agent service on Linux. A healthy installation reports the service as running with a process ID.

You should see the Trellix Agent service reported as running. The status also includes a process ID.

Inspect the agent installation directory at /opt/McAfee/Agent/bin in the existing RHEL terminal.
Leave the recorded SELinux mode unchanged.
Leave the recorded FIPS mode unchanged.
Keep the host firewall settings unchanged.

You should find /opt/McAfee/Agent/bin present on the pilot. This completes the local installation check.

Service not running?

Confirm the Smart Installer process completed before you ran the service check.
Review /tmp/McAfeeSmartInstall.log for installation details.
Stop the rollout before changing any security control.

Ask for help to diagnose a Trellix Agent service that is not running.

You kept the deployment inside one approved pilot, where the agent is now running locally. Next, you'll trigger its first communication with ePO.

Trigger and Verify Check-In

Your pilot now has a running Trellix Agent service. That confirms the endpoint process has power.

The remaining proof lives in ePO. A recent server-side record shows that the VM can send properties through the secure path.

In this step, you'll trigger one agent-server communication. You'll verify the resulting record before capturing the evidence.

In this step, get ready to:

Trigger one property collection from the pilot.
Verify the pilot's managed-system record in ePO.
Capture the final check-in evidence in the existing change record.

Trigger one agent-server communication

An agent-server communication asks the agent to collect its current properties. Those properties give ePO the data for the managed record.

Before you run the check, do you expect a running local service to be enough for the pilot to appear as recently managed in ePO?

Trigger the pilot's property collection by running this command:

/opt/McAfee/agent/bin/cmdagent -p

What does this command do?

The cmdagent command collects the pilot's current properties when you use the -p switch.
The agent sends those properties to ePO through the established secure path.
Running one switch at a time keeps the communication result clear.

Wait for the terminal prompt to return before running another cmdagent action.

Once the terminal prompt returns, the property collection has finished. The server-side record is the next proof.

Good. The pilot has completed the local property-send action.

Check-In Command Not Finishing?

Recheck the running agent service from the earlier installation step.
Reconfirm the approved DNS path without changing its configuration.
Reconfirm the approved TLS path without weakening certificate checks.
Stop repeated communication attempts until the local issue is understood.

Help me troubleshoot a Trellix Agent property collection that does not finish.

Verify the server-side record

The local command proves the request ran on the VM. The System Tree proves ePO received enough information to recognize the pilot.

Return to the ePO System Tree from earlier.
Search for the pilot using its approved hostname or FQDN.
Select the matching system record.
Refresh the System Tree view.
Confirm the displayed hostname matches the approved pilot.
Confirm the Last communicated value is recent.
Confirm the reported agent version is 5.8.6.
Compare the record with the approved pilot to confirm it is new or correctly matched.

You should see the pilot under its approved hostname or FQDN. Its agent version should be 5.8.6.

The Last communicated value should be recent. That is the core proof that ePO can identify the pilot as a managed system.

Pilot Missing or Stale in ePO?

Refresh the System Tree after the property collection finishes.
Check the search against the pilot's exact approved hostname or FQDN.
Review the matching /var/McAfee/agent/logs/masvc_<machine_name>.log for communication details.
Stop before reinstalling the agent or changing security controls.

Help me investigate a missing or stale ePO pilot record.

Recheck the endpoint and capture evidence

Server-side check-in is strongest when paired with a final local health check. The existing change record connects the running service to the ePO evidence.

Before you run the final local check, do you expect the service to still report a running process after check-in?

Recheck the pilot's local service health by running this command:

/etc/init.d/ma status

What does this status prove?

The status check reports whether Trellix Agent is running or stopped.
A running state with a process ID confirms the local service remains healthy after check-in.
The ePO record provides the separate proof that communication reached the management system.

You should still see the Trellix Agent service reported as running with a process ID.

Service No Longer Running?

Stop the rollout if the status no longer shows a running process.
Review the matching /var/McAfee/agent/logs/masvc_<machine_name>.log for follow-up details.
Preserve the current FIPS mode during the investigation.
Preserve the current SELinux mode during the investigation.

Help me investigate a Trellix Agent service that stopped after check-in.

Record the final hostname in the existing change record.
Record agent version 5.8.6 in the existing change record.
Record the recent Last communicated value in the existing change record.
Attach the ePO System Tree screenshot to the existing change ticket.
Attach the running-service evidence to the existing change ticket.
Note /var/McAfee/agent/logs/masvc_<machine_name>.log as the follow-up log location.
Review the completed change-ticket evidence.

Your completed evidence should show the approved hostname. It should also show agent version 5.8.6.

A recent Last communicated value should be included. The running-service output should be attached to the same change ticket.

You've closed the loop between local service health and ePO management. Next up, you'll turn these checks into a red-green troubleshooting card for a controlled rollout.

Build the Rollout Checklist

Your pilot is now reporting to ePO as a managed system. That success gives you a trusted baseline for the next small batch of RHEL 9.8 VMs.

A red-green checklist turns DNS, firewall, disk, TLS, certificate, build, or identity problems into clear stop decisions. This prevents one unsafe condition from spreading across the rollout.

In this step, get ready to:

Define the red conditions that stop deployment.
Match each red condition with a safe response path.
Create a green gate for the next small rollout batch.

Create the red checks

A red check is an observable condition that stops deployment. Each red check names a specific failure that needs investigation.

Add a Red checks section to the rollout card in your approved change record.
Copy the failure conditions below into that section:

Red Checks for the Rollout

DNS red: The approved ePO manager or Agent Handler FQDN does not resolve through internal DNS.
Network red: TCP 443 cannot reach the approved ePO manager or Agent Handler.
TLS red: A proxy or firewall presents a substituted certificate instead of the expected server certificate.
Host red applies when /var is full. It also applies when the service is stopped. The installed Trellix Agent build must be 5.8.6 package build 5.8.6.185. The agent identity must be clear before deployment continues.

Attach one safe response to each red check

A useful stop sign also identifies the team or remediation path that can clear it. This keeps a failed check from turning into an unsafe workaround.

Add a Safe response section beside the red checks in your rollout card.
Pair every red condition with the matching response below:

Safe Response Paths

DNS red routes to the AD DNS or network team.
Network red routes to the firewall team with the exact source VM. Include the approved destination FQDN. Specify the outbound TCP 443 path.
TLS red requires an approved inspection bypass for agent-server traffic. TLS settings stay unchanged.
Host red routes full /var capacity to approved space cleanup. A stopped service routes to service investigation. A wrong build routes to a fresh installer from the same ePO environment. An unclear identity routes to the approved removal or reinstall process.

Define the green rollout gate

A green gate is the minimum evidence required before another VM receives the agent. Every condition must pass at the same time.

Add a Green rollout gate section to your rollout card.
Copy these gates into that section:

RHEL 9.8 is confirmed.
The running Red Hat kernel is recorded.
The FIPS mode matches the recorded preflight state. The SELinux mode also remains unchanged.
Free space remains available on /var.
TLS 1.2 reaches the approved FQDN over TCP 443 with the expected certificate.
Trellix Agent 5.8.6 is running.
The ePO record has a recent Last communicated value.
Inbound TCP 8081 remains closed unless Agent Wake-Up is explicitly approved.

How the Rollout Decision Works

Every box must stay green before the next small batch begins. One red result changes the decision to stop until the approved response clears it.

Set the rollout decision to Go only when every green gate passes.
Limit the next rollout to a small batch after the gate passes.

Before you test the finished card, do you expect the pilot to reach a green rollout decision or stop on a red condition?

Trigger a fresh agent-server communication from the pilot terminal by running this command:

/opt/McAfee/agent/bin/cmdagent -p

What Does This Command Prove?

This asks Trellix Agent to collect the pilot's current properties and send them to ePO. A successful run tests the same communication route that your rollout card marks green.

You'll see the command finish after the pilot sends its current properties.

Did the Communication Fail?

Stop the rollout when the command does not finish successfully.
Review the matching /var/McAfee/agent/logs/masvc_<machine_name>.log file for follow-up details.
Keep FIPS mode, SELinux mode, TLS settings, and the host firewall unchanged during troubleshooting.

Ask for help interpreting the communication failure with help me map this Trellix Agent check-in failure to the correct red check.

Confirm that the local service remains healthy by running this command:

/etc/init.d/ma status

What Does This Status Check Prove?

This reads the local Trellix Agent service state. A running result proves the pilot still has a healthy agent process after communication.

You'll see the Trellix Agent service reported as running with a process ID.

Is the Service Stopped?

Mark the host check red when the service is stopped.
Use the approved service investigation path before another rollout attempt.
Avoid changing FIPS mode, SELinux mode, or the host firewall to force a green result.

Ask for help planning the safe investigation with help me troubleshoot a stopped Trellix Agent service on the pilot.

Return to the ePO System Tree from earlier.
Refresh the System Tree view.
Search for the pilot by its approved hostname or FQDN.
Confirm that Last communicated updated after the command.
Confirm that the reported agent version remains 5.8.6.

That is the rollout gate proven. Your card now leads from a red condition to a safe response while preserving every security control.

Secret mission

Make a Test Template Clone-Safe

A VM template can accidentally give every clone the same Trellix Agent identity. In this mission, you will prepare one nonproduction vSphere template so a test clone generates its own agent GUID and appears as a separate ePO system record.

Clean Up Your Resources

Your verified pilot and clone-safe test assets add no incremental cost because they use existing Trellix, Red Hat, and VMware licenses. Choose whether to keep them, pause the nonproduction VMs, or remove test resources through your approved change process.

Resources you used:

Trellix Agent 5.8.6 package build 5.8.6.185 running on the approved persistent nonproduction RHEL 9.8 pilot VM.
Managed pilot system record in the ePO System Tree with a recent Last communicated value.
Environment-generated TrellixSmartInstall.sh retained in the approved internal staging location.
Nonproduction vSphere test template prepared for unique agent identities.
One nonproduction vSphere test clone with a unique hostname.
Separate ePO System Tree record for the test clone.

Keep everything running

No action is needed. Choose this option while the pilot remains useful for the controlled rollout.

Leave the validated pilot managed in ePO for the next rollout batch.
Retain the red-green troubleshooting card as the rollout gate.
Protect TrellixSmartInstall.sh in its approved internal staging location.
Keep the nonproduction test template only while the clone-safe workflow remains approved.
Keep the nonproduction test clone only while it supports testing.
Keep each retained VM matched to its own ePO System Tree record.

Pause - I'll come back to this later

Pausing frees vSphere capacity while preserving the installation. The matching ePO record remains available for an approved return.

Ask the change owner to approve pausing the nonproduction pilot or test clone.
Power off only the approved nonproduction VM through your established vSphere process.
Leave the Trellix Agent installation unchanged while the VM is paused.
Leave the matching ePO System Tree record unchanged while the VM is paused.
Record the pause in the existing change record.
Continue troubleshooting any failed agent validation instead of using power-off as the fix.

Delete - I don't want to use this again

Deletion is final for these nonproduction resources. The approved change record keeps the cleanup inside the authorized boundary.

Pilot cleanup:

Obtain approval from the change owner before removing the pilot agent.
Have the authorized owner remove Trellix Agent from the pilot through the approved Trellix change process.
Have the ePO administrator remove the pilot managed-system record through the approved ePO change process.
Confirm the pilot no longer appears in the ePO System Tree.
Remove every staged copy of TrellixSmartInstall.sh when internal policy requires cleanup.
Confirm the approved internal staging location no longer contains the installer.

Secret Mission cleanup:

Delete the nonproduction test clone through your approved vSphere deletion process if it is no longer required.
Confirm the test clone no longer appears in the vSphere inventory.
Have the ePO administrator remove the clone managed-system record through the approved ePO change process.
Confirm the clone record no longer appears in the ePO System Tree.
Delete the nonproduction test template through your approved vSphere deletion process if it is no longer required.
Confirm the test template no longer appears in the vSphere inventory.

Nice Work!

Excellent work! Your approved Red Hat Enterprise Linux 9.8 pilot now reports to your existing Trellix ePolicy Orchestrator environment as a managed endpoint.

You've learned how to:

Install Trellix Agent 5.8.6 package build 5.8.6.185 on the RHEL 9.8 pilot with unchanged FIPS and SELinux modes.
Prove agent-server communication by confirming the expected agent version plus a recent Last communicated value in the ePO System Tree.
Use a red-green rollout gate to stop wider deployment whenever a network, host, agent build, or identity check is red.
Secret Mission: Prepared a nonproduction VMware vSphere template that gives each clone a unique Trellix Agent GUID.

Ready to quiz yourself?