Configure Failover Failed Error 87 The Parameter Is Incorrect

[Gabelo Camphire]

Goodday forum. I have two 2012 R2 servers hosting our DHCP environment. One primary site and another DR(secondary site). These are in a failover state for the scopes. Over time perhaps some things got out of sync from primary to secondary probably due to human error. But now I have one scope on the the secondary that does not exist on the primary. I've asked around and some people say export the dhcp scopes from the primary and import on the secondary. These people say this will not overwrite anything but I'm not so sure about that. I can't delete the scope as it is in use and it will not allow me to try and sync with the error 87.

I see the error when I try and configure failover. Once I choose the partner server and choose the relationship name. which is dhcp1-dhcp2 and we are using 50/50 %. Once I click finish i receive the error attached.

For the above error message, it failed to add scopes on partner server when you configure DHCP failover. In your case, we might need to trace process monitor to find which process is preventing DHCP failover to add scopes on partner server.

However, analysis of log is beyond our forum support level and due to forum security policy, we have no such channel to collect user log information. So we recommend you open a case with MS Professional tech support service, they will help you open a phone or email case to Microsoft, so that you would get a technical support on a one-to-one basis while ensuring private information.

Initially I thought the failover scope should be the same as the regular scope, so I set everything up the same on the second DHCP, but obviously that was incorrect. Then I used a different name and different range, but it still showed the same error. I can't find anything to explain what I should have setup.

I've built a new AD domain and I've got 2 dhcp servers (2016 & 2019) that have been setup in a Failover partnership. I've tested it and it's working correctly. I decided to RENAME both of these servers to more meaningful names. Dhcp is still working correctly. However, when I look at the ipv4 properties under Failover, the partner servers still list the old server names. I want this fixed. When attempting to Deconfigure Failover(from the scope) it fails. Here's the exact message that is displayed, "Check status of the failover relationship....Failed. The dhcp service is not running on the target computer. Deconfigure failover failed. Error 1722. The dhcp Server service is not running on the target computer."I've monkeyed around with dns cnames and other stuff to no avail. I know that i can remove the dhcp roles from both servers and add them back again to fix the problem. But, I would think that there must be another way to fix this issue. Thank you in advance for your help!

I modified "Floating Connection" timeouts parameter to 30 sec (default is 0) in Platform Settings and I deployed the new config from FMC to FTD. For some reason, the deployment failed. So, I set back the the "Floating Connection" timeouts parameter to default and push the config again. Now the deployment failed again. I rebooted both Active/Standby FTDs. But I still get the same error..."Deployment failed. Please modify the description of your Access Policy, save the policy, and attempt the deploy again. If problem persists after retrying, contact Cisco TAC." I can get only generic error messages and I don't know where to start troubleshooting. I wish FMC has a feature like Juniper or PAN such as commit check or validate the config and tell where is a wrong config.....

I don't want to be side tracked here but... In traditional ASA (Active/Standby), we will configure ASA active device and sync the config to ASA standby device. However, in FMC, it seems each commands such as 'timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02' are executed on both Active and Standby separately. Or I could be reading this syslog output wrong....

I opened a Cisco TAC case. Cisco support gave me the link (a bug) and we tried the workaround (rename Access Policy description/name and redeploy it) but it didn't fix my problem. I submitted Troubleshoot files of FTD and FMC to Cisco TAC. I really want to know where the deployment is failing....

It took 4 days...but finally I got an experienced FTD/FMC TAC engineer and pointed me to the right direction. FTD/FMC has a troubleshooting tool called "pigtail deploy" (in linux mode) to show all deployment related debug logs in one session. I recommend to redirect a console output to a text file since they have a lot of outputs. Then, you need to find key word "ERROR:" to spot what FTD is complaining about.

I've had some Cisco staff recommend to avoid Flexconfig if you don't really need those few features only available via it. It's a bit of a kludge to expose features they haven't quite gotten into the UI (or API) just yet. Unfortunately there are a number of things important to many customers that can only be configured that way. Catch 22.

Each node in a Failover Manager cluster has a properties file (by default, named efm.properties) that contains the properties of the individual node on which it resides. The Failover Manager installer creates a file template for the properties file named efm.properties.in in the /etc/edb/efm-4. directory.

By default, Failover Manager expects the cluster properties file to be named efm.properties. If you name the properties file something other than efm.properties, modify the service script or unit file to instruct Failover Manager to use a different name.

The property files are owned by root. The Failover Manager service script expects to find the files in the /etc/edb/efm-4. directory. If you move the property file to another location, you must create a symbolic link that specifies the new location.

You can use the properties listed in the cluster properties file to specify connection properties and behaviors for your Failover Manager cluster. Modifications to property settings are applied when Failover Manager starts. If you modify a property value, you must restart Failover Manager to apply the changes.

Property values are case sensitive. While Postgres uses quoted strings in parameter values, Failover Manager doesn't allow quoted strings in property values. For example, while you might specify an IP address in a Postgres configuration parameter as:

Use the db.service.owner property to specify the name of the operating system user that owns the cluster that is being managed by Failover Manager. This property isn't required on a dedicated witness node.

Use the same service control mechanism (pg_ctl, service, or systemctl) each time you start or stop the database service. If you use the pg_ctl program to control the service, specify the location of the pg_ctl program in the db.bin property.

Use the db.data.dir property to specify the location where a standby.signal or recovery.conf file will be created. This property is required on primary and standby nodes. It isn't required on a dedicated witness node.

Use the db.config.dir property to specify the location of database configuration files if they aren't stored in the same directory as the recovery.conf or standby.signal file. This is the value specified by the config_file parameter directory of your EDB Postgres Advanced Server or PostgreSQL installation. This value is used as the location of the EDB Postgres Advanced Server data directory when stopping, starting, or restarting the database.

If you set the value of jdbc.sslmode to verify-ca and you want to use Java trust store for certificate validation, you need to set the following value. This line can be added anywhere in the cluster properties file:

Use the notification.level property to specify the minimum severity level at which Failover Manager sends user notifications or when a notification script is called. For a complete list of notifications, see Notifications.

Use the script.notification property to specify the path to a user-supplied script that acts as a notification service. The script is passed a message subject and a message body. The script is invoked each time Failover Manager generates a user notification.

The EDB Postgres Advanced Server pg_is_in_recovery() function is a Boolean function that reports the recovery state of a database. The function returns true if the database is in recovery or false if the database isn't in recovery. When an agent starts, it connects to the local database and invokes the pg_is_in_recovery() function.

For example, given the default values of these properties, a check of the local database happens once every 10 seconds. If an attempt to contact the local database doesn't come back positive within 60 seconds, Failover Manager makes a final attempt to contact the database. If a response isn't received within 10 seconds, Failover Manager declares database failure and notifies the administrator listed in the user.email property. These properties aren't required on a dedicated witness node.

Use the remote.timeout property to limit how many seconds an agent waits for a response from a remote agent or database. Agents only send messages to each other during cluster events. Examples include:

Use the enable.stop.cluster property to enable or disable the stop-cluster command. The command is a convenience in some environments but can cause issues when unintentionally invoked. In Eager Failover mode, the command results in stopping EDB Postgres Advanced Server without failover.

Use the stop.isolated.primary property to instruct Failover Manager to shut down the database if a primary agent detects that it's isolated. When true (the default), Failover Manager stops the database before invoking the script specified in the script.primary.isolated property.

Use the stop.failed.primary property to instruct Failover Manager to attempt to shut down a primary database if it can't reach the database. If true, Failover Manager runs the script specified in the script.db.failure property after attempting to shut down the database.

3a8082e126