Other WUI Features
The WUI has a couple of other features that aren’t obvious if you’re just logged in to a single ESA with the admin account. The WUI takes on a different appearance if you’re logged in with other credentials or if you log into an ESA that’s part of an active CM cluster.
Variable WUI Appearance
Up to this point, all the figures and descriptions have described the UI as it looks to a super user logged in using the admin account. What about other user roles? Administrator, Operator, and Read-Only Operator have a couple of minor differences, but essentially, see the same WUI that I discussed in this chapter.
Guest users see a radical change from the administrative interface. Figure 4-12 shows the view of a guest user login.
Figure 4-12. WUI Appearance for a Guest User
As you can see, the WUI contains only the Monitor menu, plus the Options, Help, and Support menus, and even these menus are limited in the options that they provide. A Helpdesk user will see a similar interface, but the Message Tracking menu item will be exposed.
The ESA uses an explicit configuration change model that requires a commit before changes become effective. In the CLI, you would issue the commit command to make your changes to the running configuration. In the WUI, the No Changes Pending button in the upper right of every page changes to a yellow Commit Changes button whenever there are pending configuration changes. You must click this button to get to the Uncommitted Changes confirmation page, and then click Commit Changes after adding an optional comment.
Somewhat counter-intuitively, you can clear your current pending configuration changes by clicking the Commit Changes button, and then clicking Abandon Changes on the Uncommitted Changes page.
The comment that you enter here is entirely optional, but I strongly recommend that you get into the habit of commenting your changes. These comments are recorded along with a timestamp and username in the system logs on the ESA:
Tue Jul 5 10:31:13 2011 Info: PID 1085: User admin commit changes: deleted @ cisco.com from the HAT exception table
Because the comments space is limited, another practice is strongly recommended: making your changes granular. That is, if you have multiple changes to make, make the changes individually or in related groups, and commit as often as you can. This allows the comments to be relevant to the precise change that you’re making. For example, if you have to add a domain to the RAT, set up a new LDAP server profile for redundancy, and modify the text resource for email disclaimers, you should do them individually and commit after each change. For changes that are related, like adding a domain to the RAT and the corresponding entry to SMTPRoutes, it’s better to commit the changes all at once. Granular commits also make it easier for you to remember what you’ve changed in your session, because the ESA provides no easy way to review the changes you’ve made before you commit them.
With AsyncOS 7.5, a new Configuration History log records your configuration changes and saves a copy of the configuration file when you commit. It is extremely valuable in the event of a mistaken configuration change. This log subscription is not enabled by default and, therefore, must be created by an administrator.