EDIT: As Randall has mentioned below, it looks like Apache has retracted their mitigation suggestion of adding the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable. Therefore, this won't be an effective (at least not fully) technique to mitigate risk. From Apache as of this evening:
Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.
The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.
The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar.
Original: I can post screen shots if you'd like, but I think this video covers the workflow pretty well. Just ensure to restart the ArcGIS Enterprise (Server/Portal/Data Store) Services under Services on each server following the creation of the variable (this video shows them restarting other services at the end). This assumes you are running ArcGIS Enterprise on a Windows Server.
https://www.youtube.com/watch?v=CoUi4Hk6P3Y&t=0s
