To recover the objects, rules and users: 1) First, the files you will need from the management servers $FWDIR/conf/: fwauth.ndb lcrulebases_5_0.fws rulebases_5_0.fws fgrulebases_5_0.fws slprulebases_5_0.fws Objects_5_0.C 2) Create a new SmartCenter. This can be done in a virtual machine or in a physical machine, just be sure that yours has the same hostname as the one you are trying to salvage. Install the same OS and version of our software that the downed management is using. Go through cpconfig at the end of the install. Add an administrator and GUI clients, but do not reboot! Instead, navigate to $FWDIR/conf/ and put the files there, overwriting the ones that already exist. Now, you can reboot. 3) When the system comes back up, you should be able to log in, but the policy will be in a somewhat inconsistent state. Note: If the rulebase doesn't load after launching SmartDashboard take the following steps: cpstop Move the $FWDIR/conf/applications.C* files and $FWDIR/conf/CPMILinksMgr.db* files in order to clear cached info from previous Dashboard logins cpstart We will need to reset SIC and the internal CA. On a command line, run the command 'fwm sic_reset'. If it throws an error about "There are IKE Certificates that were generated by the internal Certificate Authority.", there are two ways to fix it. The most reliable is to go through the procedure listed in sk10451 - Manually removing the Internal CA Certificate from a FireWall Module object. In short, this is what you will need to do: Go through the objects_5_0.C and look for any of the following line (it will show up for each firewall and for most hosts): certificates ( Delete everything inside the parentheses such that the line looks like this: certificates () You can also delete the certificates in the Dashboard by removing the firewalls from their VPN communities, unchecking "VPN" in the Products section, then hitting "OK". Be sure to write down the communities in which the firewall is a member. 4) Once you've zapped all of the certificates, run 'fwm sic_reset'. Run cpconfig again and regenerate the internal CA. When it's done, it will give you a new fingerprint. This doesn't matter to us. Be sure that your administrator and GUI client settings have remained. Try to log in. You should be able to, though the Dashboard will warn you about a new fingerprint on the CA. You should be allowed to see the rulebase on your next login. For further information refer to sk22405 - Connecting to a SmartCenter Server with the SmartDashboard Client fails with the error: "Connection cannot be initiated. Please make sure server is up and running.". 5) Verify that all of the rules and objects are there. Add the VPN certificates back and get everything back into the original state of the policy. Generate an upgrade_export from that SmartCenter. Import it on the rebuilt SmartCenter and go through the same procedure of resetting the internal CA (this way, we don't have their private key), administrators and GUI clients. They will need to recreate all of their VPN certificates as well, which is probably the most time-consuming part of the whole process. 6) Have the customer update IPS. This is to resolve an issue that is an unbelievably huge pain to fix after you hit it. After going through this procedure with one of my customers, he reestablished SIC and pushed policy, but the policy threw about 45 errors about undefined functions and wouldn't compile. At this point, his enforcement was running on the default, drop everything policy, so it became a Critical issue. 7) If you encounter this, have the customer install SmartDashboard on a new machine and connect it both to the management and to the Internet through some other means (my customer used a dial-up account). Log in to the SmartCenter with the Dashboard, then update SmartDefense. While it may seem backwards, SmartDefense updates actually use the Dashboard's Internet connection and not the SmartCenter's. 8) Next, they will need to reestablish SIC with each gateway and push policy to them. This will bring VPNs down, so plan the order with extreme care. Remind the customer that when you reset SIC on a gateway, it goes back to enforcing the default policy. This has bitten me a couple of times when my customers were doing the procedure remotely and accidentally locked themselves out.