Analysis of Problem Areas

This section looks into some of the problems based on their functional areas and how to resolve them:

• Installation issues

• Initialization issues

• Browser issues

• Authentication issues

• Activity and job management issues

• Device import issues

• Configuration generation and deployment issues

• Database management issues

Installation Issues

Once Firewall MC is installed successfully, it is very important to verify that it is running correctly. This section discusses how to verify and troubleshoot the Firewall MC Installation problem.

Installation Verifications

After installing the Firewall MC, the first step is to verify the success of the installation. Following are two ways you can verify if the Firewall MC is installed successfully:

• Firing up Firewall MCLog in to the CiscoWorks Server desktop, and then selecting VPN/Security Management Solution > Management Center. Click on Firewalls in the Management Center folder. Answer Yes in the Security Alert window. The Firewall MC home page displays. Finally click on About to verify if the correct version of Firewall MC is running on your system.

• Checking Package OptionLog on the CiscoWorks Server desktop, then selecting Server Configuration > Administration > Package Options. Scroll through the list of package names to see the installed options. If the installation succeeded, you will see Management Center for Firewalls in the list of installed options. Select Management Center for Firewalls from the Package Name list, and then click Next. The Package Options page displays the build information for the installed version of Firewall MC.

Installation Troubleshooting

If Firewall MC Installation fails on the Windows platform, you need to analyze the log in the C:\ directory. This is where you can find the log in the format of C:\Ciscoworks_setupxxx.log (for example, C:\Ciscoworks_setup001.log) file. The file name with the highest number is the most recent log file. Following are some of the probable causes of Firewall MC Installation failure on Windows platform:

• CiscoWorks Common Services Installation is corrupt If the Common Services Installation is corrupted, the installation of Firewall MC will fail with one of the following messages:

  Unable to retrieve package name (pixmc) Unable to register Firewall MC Resource with CiscoWorks Common Services Client Registrar. Unable to initialize Firewall MC Configuration Manager database. 

  To resolve the problem, uninstall and reinstall CiscoWorks Common Services. Then install the Firewall MC. Additionally, if you have problem with CiscoWorks Common Services Installation corruption problem, you might receive one of the following messages:

  Unable to launch KRS database process. Unable to launch LM database process. 

  To resolve the problem, uninstall and re-install CiscoWorks Common Services. During the installation of Firewall MC, be sure to choose to initialize the database option of Firewall MC.

• The Firewall MC installation is corrupt Uninstall Firewall MC and reinstall it.

• Microsoft Terminal Services Issues You will receive the following message when terminal services are running at the time of installation:

  Unable to connect to the database. 

  There is a known problem when installing Common Services on a system that has Terminal Services enabled in Remote Administration mode. The workaround is to go to the Services Control Panel, and manually stop or disable Terminal Services before you install Common Services. After finishing your installation, you can then restart or re-enable the Terminal Services.

  However, there are existing problems with the Sybase SQL wherever a database is running as a service on a machine that has Terminal Services enabled using Application Server mode. These problems are outside the control of Cisco, and are documented at this URL:

  http://www.microsoft.com/windows2000/docs/W2kTSApCmpt.doc#_Toc475940238

  Under the Terminal Services Application Server Mode, there is an entry for Sybase SQL Anywhere on Page 16 which reads: "When SQL Anywhere is run as a service, compatibility problems with Terminal Services may result." To avoid such problems, you must run SQL Anywhere as a regular process. Sybase is currently working on a solution for this problem.

• VMS Interoperability Issues with Microsoft IIS Web Server VMS does not work well with IIS Web Server. IIS Web Server and VMS compete for port 443 during system startup. If IIS binds the port, then VMS will not work. It is recommended that you disable IIS to prevent port conflicts and other well-known IIS security problems.

• Firewall MC Interoperations with Other Applications Other software running on the system can affect Cisco Works performance and cause port conflicts. The VMS processes can be memory and I/O intensive, so it is recommended that you run VMS on a dedicated system. Table 19-1 lists the ports used by VMS that cannot be changed.

  Table 19-1. Ports Used By Different VMS Components

  Processes part of VMS	Port Numbers
  SSL port for Common Services web server	443
  Normal port for Common Services web server	1751
  Normal port for CMF web server	1741
  SSL port for CMF web server (only used if the desktop itself is in SSL mode)	1742
  JRun servlet engine	42343
  JRun administration	57860
  Cisco Works 2000 Daemon Manager	42340
  Tibco port for Common Services	10032
  Tomcat communications port to Apache web server	8007
  Tomcat communications port to Apache web server	8009

  
  

  Be sure that you do not run any application that is in conflict with the ports listed in Table 19-1. It is strongly recommended to remove any unnecessary service/application (IIS, HP Services, Compaq Services, and so on) that you do not need before installing Firewall MC.

Initialization Issues

After successful installation of Firewall MC, it takes approximately one minute for all the services to reach the state of having been started. Once all the services are started, there still may be processing going on by the individual applications, including Firewall MC, as they are being initialized as well. It should not be uncommon to see high CPU activity while services are starting up, and immediately after all services have reached the Started state. When you try to open up Firewall MC, you may receive the following message at that time:

The MC is not fully initialized yet. Please clicks refresh (F5) to try again in a few seconds. 

If you are unable to open Firewall MC even after waiting for a long time after the installation, work through the following steps to correct the problem:

Step 1.	View the Process Status. If you are unable to open up Firewall MC, go to Server Configuration > Administration > Process Management > Process Status from the CiscoWorks Server navigation tree. Be sure Apache, SqlCoreDB, Tomcat, daframework, and lm processes are running.
Step 2.	Restart the processes. To start the processes that are not running, go to Server Configuration > Administration > Process Management > Start Process page to start the processes. From the Start Process page, select System to start all processes, or select the specific process to start. You must be an administrator to CiscoWorks to be able to stop or start the processes.
Step 3.	Wait and view the Process Status again. After starting the Processes from the previous step wait for five minutes, and then check the status of the processes as described in Step 1.
Step 4.	Restart the processes using CLI. If any process is not running even after you restarted the process from CiscoWorks Desktop, you can restart the process directly from the command line of your CiscoWorks Server. Open the DOS prompt on the CiscoWorks server, and execute the following two commands: net stop crmdmgtd net start crmdmgtd Be sure that you do not start the crmdmgtd process after you stop it.
Step 5.	Check the Process Status again Wait for five minutes after starting the crmdmgtd process that is described in the previous step, and then follow Step 1 to check the status of the Processes again.

Browser Issues

You might experience browser-related problems while trying to access or use Firewall MC. Some of these issues are discussed in the list that follows:

• Desktop buttons do not work If the desktop buttons do not work, check whether Java and JavaScript are enabled. If not, enable Java and JavaScript.

• Browser cache settings For successful Firewall MC Operations, be sure the browser cache is not set to zero.

• Resizing browser window Do not resize the browser window while the desktop main page is loading.

• Disable popup blockers on browsers If you use a popup blocker utility on any client you use to access the Firewall MC server, popup windows used by Firewall MC are blocked. So, be sure to allow the popup for at least the Firewall MC Server.

• Open only one browser session from a single client Firewall MC supports only one browser session from a specific client PC. With Internet Explorer, even though you can create multiple browser sessions, it is strongly discouraged, because unpredictable results will occur.

• Internet Explorer hangs after trying to close a dialog box You may experience a browser hang session, if the sessions between the web client and the CiscoWorks Server are canceled after a user-defined period of inactivity. For example, if you restore the database, a dialog box displays stating that the restoration is complete. If you do not click OK before the session times out, the web client can hang and cannot be closed. To resolve this issue, press the Ctrl + Alt + Delete buttons at the same time. This will bring up Windows Security window. Click on the Task Manager tab and then Processes. Then select the iexplore.exe process from the Process list and click End Process.

• Other applications hijack Internet Explorer Windows for Firewall MC Internet Explorer provides an option that allows existing Internet Explorer browser instances to be used when a shortcut is selected or when a URL is entered in the Start > Run dialog box or at command prompt. You can change the default settings to prevent this level of reuse. Go to Tools > Internet Options > Advanced tab. Under Browsing, uncheck the "Reuse windows for launching shortcuts" checkbox.

• Logout Error Message Number 500 This message means that your session timed out and your Firewall MC window was left open. You must close all browser windows and then log in again to avoid this message. This error does not occur on a system on which Firewall MC is directly installed directly.

• Changed IP address but did not restart the services If you changed the IP address but you did not restart the services, you will receive the following message on the browser while you are trying to access Firewall MC:

  Error 404: Page not found Message 

  Stop and restart the services to avoid this message.

Authentication Issues

Authentication may take place among Firewall, Firewall MC, and Auto Update Servers in one of the following setups:

• Firewall MC authenticated by the Firewall during configuration import and deployment

• Firewall MC authenticated by the auto update server during configuration deployment

• Firewalls authenticated by the auto update server during configuration or image pulling

The sections that follow detail the points in the preceding list.

Firewall MC Authenticated by the Firewall During Configuration Import and Deployment

Before import or deployment of configuration, Firewall MC needs to authenticate with the firewalls. This authentication is performed either with AAA or with the enable password. When AAA is used, you must ensure that you provide both username and password on Firewall MC, by selecting Configuration > Device Settings > Firewall Device Administration > Firewall Device Contact Info on the Firewall MC.

If you run into a problem with authenticating Firewall MC with the firewalls, work through the following steps to correct the problem:

Step 1.	Check syslog on the firewall and see why the authentication is failing.
Step 2.	If AAA is used, analyze the log of the AAA server to find the cause of the authentication failure.
Step 3.	Change AAA authentication to enable password authentication to rule out the possibility of an AAA issue.
Step 4.	If the authentication problem occurs after you deployed the configuration, be sure to use current and future login credential options: - Changing Enable Password If you authenticate Firewall MC with the enable password of the firewall, and after the configuration import, you need to change the enable password, be sure to define the current and future password by selecting Configuration > Device Settings > Firewall Device Administration > Firewall Device Contact Info. Otherwise, Firewall MC will no longer be able to authenticate with the firewall after the configuration deployment. - Changing to AAA Authentication If you want to change the authentication method for Firewall MC from enable password to AAA-based authentication, be sure that the HTTP console setting is enabled and one AAA server is configured. To check the console setting in Firewall MC, select Configuration > Device Settings > Firewall Device Administration > AAA Admin Authentication. Next, set the AAA future username and future password settings. To set the future username and password, select Configuration > Device Settings > Firewall Device Administration > Firewall Device Contact Info.

Firewall MC Authenticated by the Auto Update Server During Configuration Deployment

Before Firewall MC can deploy to an AUS, Firewall MC must authenticate itself to the AUS with a username and password. You can either use CiscoWorks local user database or Cisco Secure Access Control Server (CS ACS) to authenticate the Firewall MC with the Auto Update Server. If CiscoWorks Common Services local database is used, the Username must be assigned the roles of system administrator or network administrator. On the other hand, if you need to use CS ACS for authentication, be sure Firewall MC roles are synchronized with the CS ACS server, and system administrator privilege is assigned for the user on the CS ACS Server.

On the Firewall MC, you need to provide the Auto Update Server contact information by going to Configuration > Device Settings > Auto Update Server > Device AUS Settings. The username and password entered here should be able to login to the CiscoWorks, bring up Auto Update Server and be able to perform administrative functions to the Auto Update server. Firewall MC communicates with the AUS using HTTPS regardless of whether the AUS is installed on the same or a different server.

Firewalls Authenticated by the Auto Update Server During Configuration or Image Pulling

Before Firewalls can contact AUS and pull the configuration or the image files from AUS, AUS will authenticate the firewalls. Hence, you must bootstrap the Firewall, which sets up the firewall with the minimum configuration needed. Example 19-1 shows the minimum configuration required on a PIX firewall to contact AUS.

Example 19-1. Minimum Configuration Required on the PIX Firewall for Contacting AUS

PIX# configure terminal PIX(config)# auto-update server https://username:password@<AUSServerAddress>:port/autoupdate/ AutoUpdateServlet PIX(config)# 

You can configure the AUS server settings on the Firewall MC by selecting Configuration > Device Settings > Auto Update Server > Server and Contact Information.

If the firewall has problems with pulling the configuration or the image from the AUS because of authentication issues, work through the following steps to correct the problem:

Step 1.	Revise the Firewall configuration. If AUS is failing firewall, this can be because of either a bad username or password defined on the firewall. Revise the firewall configuration and ensure that the username and password defined can successfully log in to CiscoWorks Common Services, and bring up the AUS GUI.
Step 2.	Verify the Login Role Privileges. If you are using CiscoWorks Common Services local user database for authentication, be sure that username has the administrative privilege. If CS ACS is used as the authentication module, you must revise the configuration on the CS ACS server to ensure that administrative privilege is configured for the user.

Activity and Job Management Issues

You must open an activity to start any task on the Firewall MC. Also you need to define a job to perform configuration deployment. While working with activity or job, you might encounter the following problems, which are discussed in the sections that follow:

• Unlocking an of an activity

• Stopping a job from being deployed

Unlocking of an Activity

If an activity is locked, and if you try to edit the activity, you will receive the following message:

Scope already locked by activity name 

To release an activity from the lock, you must either submit and approve the activity or undo the activity, which discards it from further use.

You could run into the locking up of an activity due to one or more of the following reasons:

• If you left an activity in the Edit_Open state (possibly due to a browser crash), the next time you log in, the Activity Management table displays the activity in the same state as before; however, the activity bar shows no activity opened (none) when you view the activity bar from the Devices or Configuration tabs. You must close the activity, and then reopen it to update the activity bar state.

• Another user has opened your activity and still has it open. The activity must be closed by the person who opened it or by an administrator before you can open the activity.

• Another user has opened your activity and has made changes to the activity that involves other devices. If you lack the needed privileges to modify the newly added devices, you no longer have access to your activity.

If you are unable to open an activity with the suggestions provided earlier, you may need to remove the activity from Firewall MC using the either of the following: Firewall MC GUI or Firewall MC Server CLI.

Using Firewall MC GUI

A pruning thread is run on demand or at midnight after a specified number of days to remove any terminal (approved or discarded) activities. Work through the following steps to remove the terminal activities from the Firewall MC using Firewall MC GUI:

Step 1.	Select Admin > Maintenance.
Step 2.	Perform one of the following tasks: - To purge all terminal activities, click Purge Now. All terminal activities are removed from the activities page. - To set a time for the Firewall MC to purge all terminal activities, enter the number of days in the field entitled Purge approved/discarded activities older than, and then click Apply.

Note

If you set the number of days to 0, then that night, any activity that is terminal and has its approved changes deployed will be deleted. All terminal activities that meet the requirements are removed from the activities page.

Using Firewall MC Server CLI

You can use a utility called purge-mc-tasks from a command prompt of the Firewall MC server to remove the terminal activities. It is strongly recommended to use this CLI utility as a last resort if you cannot close the activity and want to remove it from Firewall MC. Work through the following steps to perform the purging activity:

Step 1.	Stop service CiscoWorks Daemon Manager. Wait for all CiscoWorks services to stop.
Step 2.	Start the CiscoWorks KRS Database service. If you get a dialog about the service not starting in a timely manner, dismiss it, and watch the status of this service. Wait for it to change from Starting to Started.
Step 3.	Start the CiscoWorks Lock Manager service. Wait for the CPU to become idle.
Step 4.	Open a command prompt and type purge-mc-tasks (this should be on the path for an installed system). You should see output stating that tasks were purged or that no tasks were found.
Step 5.	Stop the CiscoWorks Lock Manager service.
Step 6.	Stop the CiscoWorks KRS Database service.
Step 7.	Start the CiscoWorks Daemon Manager. The system should be usable after all the services come up.

Stopping a Job from Being Deployed

If a job is being deployed, you can select the job in the Job Management table, and then click Cancel. If a job has completed deployment, you can select the job in the Job Management table, and then click Rollback. The rollback feature allows you to select the device(s) for which you want to roll back to the last previously deployed configuration file.

Device Import Issues

You can import the device (PIX or FWSM) configuration from either a CSV file or the live device. Work through the following steps if you cannot import a device configuration using either method:

Step 1.	Version information is missing on the CSV file. When you import the device configuration from a CSV file, you must ensure that you have the version information on the CSV file; otherwise, import will fail with the following message: No version found in the text The image version information should be at the beginning of the file with one of the following two syntaxes: ! A comment should be following an exclamation point :! PIX Version 6.n(n) Or PIX Version 6.n (n)
Step 2.	The required configuration is missing on the firewall. To import the firewall configuration directly from the device, you must ensure that firewalls are configured to communicate using HTTPS, and that Firewall MC is one of the listed addresses that are allowed to make an https connection to the firewall. If you have the proper configuration for Firewall MC to be able to connect, you will see the verification process illustrated in Example 19-2. Assume that the Firewall MC Server IP address is 10.1.1.100 and that it is sitting on the inside network. Example 19-2. Verifying and Correcting the Configuration Required on the PIX Firewall for Firewall MC To Be Able To Import The Configuration pixfirewall# show version Cisco PIX Firewall Version 6.2(4) ! Only showing the relevant information Compiled on Mon 28-Jun-04 15:05 by morlee Licensed Features: Failover: Enabled ! Make sure DES or 3DES feature is enabled for the PIX VPN-DES: Enabled VPN-3DES: Disabled Maximum Interfaces: 6 Cut-through Proxy: Enabled ! Removed the irrelevant portion of the output. Configuration last modified by enable_15 at 01:26:55.309 UTC Thu Jun 30 2005 pixfirewall# configure terminal ! Check to see if the http server is enabled and if so, is Firewall MC allowed? pixfirewall(config)# show http http server disabled ! As the http server is disable, you need to enable this server with the ! following command pixfirewall(config)# http server enable ! Then you need to allow the Firewall MC with the following command pixfirewall(config)# http 10.1.1.100 255.255.255.255 inside ! Verify the http configuration again pixfirewall(config)# show http http server enabled 10.1.1.100 255.255.255.255 inside ! If you still unable to connect, you may have certificate problem. Verify if ! the certificate is generated pixfirewall(config)# show ca mypubkey rsa % Key pair was generated at: 19:07:14 UTC Jun 16 2005 Key name: pixfirewall.rtp.cisco.com Usage: General Purpose Key Key Data: 30819f30 0d06092a 864886f7 0d010101 05000381 8d003081 89028181 00eb238b 6b2dde82 2c3b1b69 02844257 c175e53a e204510c b2e71689 392de546 ec5f0857 ebbcf8a3 116e5280 72fc3b26 13474501 ff49ba95 b8f37867 5de93a3e 9265745a 8897da68 e17db40b d453a525 36578df7 c91583d0 96f268d8 b3aa2246 2db82b8d 4dca775d da82314d d7256134 7250358a f37ecff0 e3090401 5375c8d7 db020301 0001 % Key pair was generated at: 01:26:21 UTC Jun 30 2005 Key name: pixfirewall.rtp.cisco.com.server Usage: Encryption Key Key Data: 307c300d 06092a86 4886f70d 01010105 00036b00 30680261 00ac5034 7d9092f9 fd4eaebe 124bb4d7 45a1c127 04733bfe 279b166f e90acaf0 bdaf462a c7876633 62618542 55cb224b 1644866c 40ebc906 80c1a0d2 cc2c1b74 c1b8e31e f974f7ee fc80c688 8ff7ab19 0250702a eacf1c37 cd4e1b4f 12a0b63b 1d020301 0001 pixfirewall(config)# ! If the mypubkey exists but, then may be the key is corrupt. You may want to ! remove the key. pixfirewall(config)# ca zeroize rsa pixfirewall(config)# show ca mypubkey rsa ! Regenerate the key with the following command. This example uses 512 as the ! key size as this activation key on the PIX supports only DES, not 3DES. You ! should choose this number based on your need. pixfirewall(config)# ca generate rsa key 512 . pixfirewall(config)# show ca mypubkey rsa % Key pair was generated at: 01:42:24 UTC Jun 30 2005 Key name: pixfirewall.rtp.cisco.com Usage: General Purpose Key Key Data: 305c300d 06092a86 4886f70d 01010105 00034b00 30480241 00c61618 84bfa964 bf5bd5ae a2116910 54f87e56 d4e213e9 c72e9f23 ffac73ac a811445b bda18805 25777c1f 7d52eb9c 425bbc20 5c6fa9da 0c7b7d76 93d16671 6f020301 0001 ! Finally save the key, otherwise a reboot will wipe out the key pixfirewall(config)# ca save all pixfirewall(config)#
Step 3.	There are communication problems using HTTPS. As the Firewall MC uses the HTTPS protocol to connect to the firewall to import the configuration, you must ensure that the firewall is configured to allow Firewall MC to connect to the firewall to pull the configuration as explained in the previous step. If HTTPS is blocked by a network device between the Firewall MC and the firewall, or if PIX is configured to allow the https connection from the Firewall MC server, you will receive the following message on the Firewall MC: Failed to contact host: x.x.x.x If there is a connection problem to the firewall, you can verify this with the following URLs from the Firewall MC Server browser to the firewall: https://<device-IP/exec/show%20ver https://<device-IP/exec/show%20run https://<device-IP/exec/show%20config https://<device-IP/config If any of these URLs work for you, then you do not have a connection problem using HTTPS to the firewall from the Firewall MC server. Otherwise, go through the previous step to make sure that you have the proper configuration on the firewall, and also revise the device configurations between Firewall MC and the firewall to ensure that one of the devices is not blocking the traffic.
Step 4.	There is an authentication failure. In this situation, the firewall can authenticate either with the AAA username and password or the enable password only. If you have the following command on the firewall and authentication fails, then the problem might be with the way the AAA server is configured. aaa authentication http console server_tag To eliminate the possibility that AAA is causing the problem, you can remove the AAA authentication for HTTP with the following command: no aaa authentication http console server_tag Open the browser on the server, and enter the following URL:https://<device ip> /exec/show version. and be sure that you can authenticate with the enable password. If enable password authentication works but AAA does not, be sure that the user defined on the AAA server has privilege 15 if the following command is turned on: aaa authorization command {LOCAL | TACACS_Server_TAG} If after checking everything, you still have problems generating the following message, then analyze the syslog on the firewall and the AAA server log. "Unable to talk to the server x.x.x.x. Please check the username and password".
Step 5.	Import fails with Interface error. If you have multiple interfaces up but do not have the IP address, the import will fail with the following message: *** Severe: Interface outside is not a valid interface The interfaces need IP addresses to become valid for Firewall MC.
Step 6.	You may import PIX configuration with unsupported commands. If you are running a version on PIX that is higher than what is supported by the Firewall MC, you will receive error messages when try to import the configuration from the Firewall. Follow either of the following methods to work around this problem: - Remove the commands for which you are getting errors. Import the configuration, and then insert the commands in the Ending Commands under Configuration > Device Settings > Config Additions > Ending Commands. Then push the configuration to the firewall. - Copy the entire Configuration from the PIX into a text file, and remove the commands you are having problems with from this text file. Insert the "removed" commands in the "Ending Commands" under Configuration > Device Settings > Config Additions > Ending Commands. Then push the configuration to the firewall.
Step 7.	Import is extremely slow. If network connectivity is very unreliable, an import or deploy may take a long time. If so, you should copy the configuration from the firewall as an interim solution and import the configuration from the CSV file. If you have the large configuration on the firewall, then a delay is to be expected.
Step 8.	Check if SSL communication is broken. If you still cannot import, get the output of the following debug command and contact Cisco Support for additional help. Be sure to collect the debug output when you attempt to connect to the Firewall MC. debug ssl cipher debug ssl device debug crypto ca Additionally, the syslog with the debug level turned on may be required.

Configuration Generation and Deployment Issues

If you cannot deploy the configuration from Firewall MC to the firewall, go through the troubleshooting steps under the "Device Import Issues" section of this chapter. Additionally, this section lists some of the issues that are specific to the deployment of Firewall configuration.

• Firewall MC is unable to push the configuration to the AUS

• Getting "Incomplete Auto Update Server contact info." Message when pushing the configuration to AUS

• Memory Issues with Firewall Services Module (FWSM) during deployment

The sections that follow present detailed discussions of these topics.

Firewall MC is Unable To Push the Configuration to the AUS

Firewall MC may be unable to push the configuration to the AUS for either or both of the following reasons:

• Username or Password is invalid If the username and password defined under Configuration > Device Settings > Auto Update Server > Server and Contact Information of Firewall MC, then Firewall MC will not be able to push the configuration to the AUS. Revise the configuration on both Firewall MC and the CiscoWorks Common Services local user database to make sure that the username and password match on both sides.

• Default Port is changed on the AUS By default the AUS listens on TCP/443 for Firewall MC. However, at the time of installation, if you change the default port, then make sure to use that port under Configuration > Device Settings > Auto Update Server > Server and Contact Information of Firewall MC.

Getting "Incomplete Auto Update Server contact info." Message when Pushing The Configuration to AUS

When you import a firewall that is configured for use with an Auto Update Server, the contact information for the Firewall MC to the Auto Update Server communication is overridden. Therefore, after import, you must provide the correct information on the Configuration > Device Settings > Auto Update Server > Server and Contact Information page before you try to deploy. The best way to work around this problem is to define the settings for this page at the group level, import AUS enabled devices into that group, and select the Inherit settings from the parent checkbox at the device level.

Memory Issues with Firewall Services Module (FWSM) during Deployment

By default Firewall Services Module (FWSM) keeps the old ACL and compiles at the same time with the new ACL, while the new ACL is added to the FWSM. This is to make sure that there is no traffic disruption at the time of ACL updates. However, this may result in Firewall MC not being able to successfully push ACLs to an FWSM device because of an out-of-memory failure. You can get around this problem by requesting that old ACLs be removed from the device before target ACLs are deployed by the Firewall MC by selecting Configuration > MC Settings > Management. Select the Clear ACLs before deployment (FWSM only) check box.

However, if the deployment fails, and the new ACL is not successfully deployed to the FWSM, traffic will be blocked. This may be less than desirable for specific network. Hence, make sure that you deselect the Clear ACLs before deployment (FWSM only) check box under Configuration > MC Settings > Management.

Database Management Issues

As the Firewall MC can coexist with other Management Centers on the same CiscoWorks Common Services server, the backup and restore operations are not exclusive to the Firewall MC itself. If you perform a backup or restore, the operation includes all CiscoWorks Common Services components running on the Server. This distinction is important to consider when restoring a component. All components on the CiscoWorks Server are restored using the last backed-up archive. Therefore, you should consider the strategies for scheduling Firewall MC Backups within the context of all components running on the CiscoWorks Server. It is important to realize that the backup and restore functions do not perform backup or restore on the users created on the CiscoWorks Common Services for login to the CiscoWorks desktop using browser.

The sections that follow discuss the following database activities in detail:

• Backing up and restoring database

• Scheduling checkpoint events for the database

• Compacting database for performance improvement

• Disaster recovery plan

Backing up and Restoring Databases

You should back up the database regularly so that you have a safe copy of the CiscoWorks Common Services database. You can back up the database on demand, at a specific time, or at scheduled intervals.

When you back up the database, the data for all client applications is backed up; you cannot specify a backup of a single client application. User account information is not backed up. You must use the CiscoWorks Server utilities to back up user account information.

Note

You can back up the data only to the server. You cannot back up the database to a client system, even if that client system is being used to connect to CiscoWorks Common Services and to initiate the backup. However, after you back up the database, it is recommended that you store the backup to a different computer to prevent data loss if hardware fails.

Database Backup Procedure

To back up the database, work through the steps that follow:

Step 1.	Select VPN/Security Management Solution > Administration > Common Services > Backup Database from the navigation tree. The Backup Database page displays.
Step 2.	Specify the path to the directory in which you want to store the backup.
Step 3.	To send an e-mail to a designated recipient each time the database is backed up, select the E-mail Notification check box and enter an e-mail address in the field.
Step 4.	To back up the database immediately, select the Immediate check box.
Step 5.	To back up the database at a specific date and time, deselect the Immediate check box, and define the Start Date, and Start Time.
Step 6.	To schedule a backup at regular intervals, enter a value in the Repeat After field, and select Days, Hours, or Minutes from the list. To limit the number of times the database backup occurs, enter a value in the Limit Occurrences field under Frequency.
Step 7.	To back up the database according to the settings you have made, click Finish.
Step 8.	Finally click OK to close the message.

Database Restore Procedure

You can restore the database from an existing backup. The backup contains data from all installed CiscoWorks Common Services client applications. Because user account information is not backed up, you cannot use restore to recover deleted accounts. Additionally, license information is not restored; the license in effect when the restore is performed remains in effect after the restore.

Caution

Restoring the database restores the data for all client applications; you cannot restore the data for a single client application. Therefore, restoring the database resets all client application data to the state it was in when you created the backup.

To restore a database, work through the steps that follow:

Step 1.	Select VPN/Security Management Solution > Administration > Common Services > Restore Database. The Restore Database page displays.
Step 2.	Specify the path to the directory where the backup is stored.
Step 3.	To send an e-mail to a designated recipient each time the database is restored, select the E-mail Notification check box and enter an e-mail address in the field.
Step 4.	Click Finish to save your settings. A message provides the status of the database restore. Note that if you restore using a backup file from an earlier version of Firewall MC and the database tables must be upgraded, the restore progress bar moves quickly to 25 percent and remains at 25 percent until the table upgrade is complete, Then, the progress bar moves quickly to 100 percent. The progress bar does not move during the table upgrade portion of the restore, which can take from several minutes to an hour, depending on the number of items that must be upgraded.
Step 5.	Click OK to close the message.
Step 6.	Select Server Configuration > Administration > Process Management > Stop Process. The Stop Process page displays. Select System in the stop column, and click Finish to start the process.
Step 7.	Select Server Configuration > Administration > Process Management > Start Process. The Start Process page displays. Select System in the start column. Click Finish.

Now you should have backup database restored to the system.

Scheduling Checkpoint Events for the Database

Checkpoint event is used to trigger the Firewall MC to write all information stored in the memory cache to data files on the hard drive. A log file tracks the changes made to the system. These changes signify information, such as configuration settings and audit records, which differ from the settings stored in the data files. If the server on which the database resides shuts down too early, when power fails, for example, the database uses the log file to recreate the state of the system before it was shut down. Checkpoints reduce the amount of time required to recreate this "last known good" state, because they reduce the size and number of changes in the log file. The database synchronizes its in-memory working data with the data stored on the hard drive when one of the following events occurs:

• The specified amount of time elapses.

• The size of the log file that is tracking the changes made since the last checkpoint exceeds the maximum specified file size value.

A disadvantage of checkpoints is that they use much of the system resources. Therefore, the number of audit records that can be recorded while a checkpoint is being performed is reduced. The smaller the difference between the in-memory data and the data files, the faster the server running the database can "recover" and resume normal activity. (Normal activity includes recording audit records and accepting changes to existing network policies.)

You can define a checkpoint rule to specify how frequently the database should write the information stored in its memory cache to the database files on the server hard drive. You can base checkpoint events on the size of the log file, the time of day, a set interval, or some combination of the three. You can also disable checkpoint events by disabling each type of checkpoint rule; however, we discourage this option.

Note

Database check pointing affects only the KRS database used by the Firewall MC.

Tip

If importing or generating large configurations in a client application takes a long time, increase your Checkpoint File Size value. It is likely that one or more checkpoint events are occurring during your import or generation.

Work through the steps that follow for configuring the checkpoints:

Step 1.	Select VPN/Security Management Solution > Administration > Management Center > Database Checkpoint. The Database Checkpoint Settings page displays.
Step 2.	Enter the maximum size (in megabytes) that the log file can reach before requiring a checkpoint in the Checkpoint File Size field. To disable the size checkpoint, enter 0 (zero).
Step 3.	From the Schedule At lists, select the hour and minutes when the checkpoint should occur. To disable the time-of-day checkpoint, select 00 (zero-zero) for both the hours and the minutes. The time is shown in 24-hour format.
Step 4.	In the Interval field, enter the interval, in hours, to specify how often to repeat the checkpoint.
Step 5.	Click Finish. A message provides the status of the configuration change.
Step 6.	Click OK to close the message.

Compacting a Database for Performance Improvement

Compacting the database eliminates space that is allocated for data that no longer exists in the database. Hence it decreases the amount of space required to retain existing CiscoWorks Common Services configuration data and can increase system performance and minimize startup time. Only the KRS database used by the Firewall MC is affected by this procedure.

You should compact the database at regular intervals to reclaim unused storage space. You can compact the database on demand or schedule the database to compact at a set time or at regular intervals. You cannot compact the database while backing up or restoring it.

Tip

Use the scheduling feature to schedule database compactions weekly or daily, depending on how often you update your configurations. You should schedule the compaction to occur when the system is not being used, such as late at night or early in the morning. Also make sure to schedule backup before scheduling database compactions.

Follow these steps to compact the database:

Step 1.	Close all instances of Firewall MC. Note that the CW2000 KRS database service is shut down while the database is being compacted and restarted when compaction is complete. If there are any instances of the Firewall MC being active when you compact the database, the connection to the database for those sessions will be terminated. You will need to close Firewall MC, and then log out and back in to the CiscoWorks Server before you can use Firewall MC.
Step 2.	From the CiscoWorks Server desktop, select VPN/Security Management Solution > Administration > Management Center > Compact Database. The Compact Database page displays.
Step 3.	To send an e-mail to a designated recipient each time the database is compacted, select the E-mail Notification check box and enter an e-mail address in the field.
Step 4.	To compact the database immediately, select the Immediate check box.
Step 5.	To schedule a specific date and time for the compaction, deselect the Immediate checkbox. Define the Start Date and Start Time list, and then click each displayed value to confirm.
Step 6.	To schedule compaction at regular intervals, enter a value in the Repeat After field, then select Days, Hours, or Minutes from the list. To limit the number of times the database is compacted, enter a value in the Limit Occurrences field.
Step 7.	Click Finish to save your settings.
Step 8.	Click OK to close the message.

Disaster Recovery Plan

To lessen the possibility of data loss and decrease the time required to recover from a catastrophic hardware failure on the system hosting Firewall MC, you can configure a rapid recovery server. A rapid recovery server is a secondary CiscoWorks Server running Firewall MC that subscribes to a database backup of the primary server. If the primary server fails, you can enable the secondary server as the new primary Firewall MC server.

Configuring the Recovery Server

Work through the steps that follow to configure the Recovery Server:

Step 1.	From the primary CiscoWorks Server, map a network drive to a local drive letter (for example, z:).
Step 2.	From the desktop of the primary CiscoWorks Server, select VPN/Security Management Solution > Administration > Common Services > Backup Database.
Step 3.	In the Backup Directory field, select the local drive letter that you mapped in Step 1.
Step 4.	Specify the backup interval that meets your needs.
Step 5.	From the secondary CiscoWorks Server, map a local drive letter to the same network share used in Step 1.
Step 6.	From the desktop of the secondary CiscoWorks Server, select VPN/Security Management Solution > Administration > Common Services > Restore Database.
Step 7.	In the Backed-up Archive field, select the local drive letter that you mapped in Step 5.
Step 8.	Authentication and Authorization with CiscoWorks Server Local DatabaseIf you are using the authentication and authorization services provided by your CiscoWorks Server, you must manually synchronize the account and authorization definitions between the primary and secondary CiscoWorks Servers.
Step 9.	Authentication and Authorization with Cisco Secure ACSIf you are using Cisco Secure ACS for authentication and authorization, this server acts as a shared authentication server for both Firewall MC servers. Therefore, you must verify that both the primary and secondary severs have the appropriate permissions in the PIX Device Group definition of the Cisco Secure ACS server.
Step 10.	AUS ServerBecause you can specify only a single AUS server as a target deployment location in Firewall MC, your AUS server also acts as a shared server for both Firewall MC servers. Therefore, you must configure your AUS Server to be independent of both Firewall MC servers.

Enabling the Recovery Server

If you experience a catastrophic hardware failure on the Primary Firewall MC server, go to the secondary server, assign the IP address and domain name to be same as primary Firewall MC server, and restore the last database backup performed by the primary CiscoWorks Server.

Note

The total data loss depends on length of time since the last backup (the backup interval) plus the time required restoring the data. In this sense, data loss refers to audit data that can be collected by other VMS components.