Before You Begin

Before implementing Responder, there are several things to consider. Be sure to review the Responder Read Me file for complete system requirements.

Responder Tables: Create the Responder and Archive tables in your geodatabase by following the steps outlined in the Implementation Scripts sections for Oracle or SQLServer.
Hardware/Servers: Responder may be hosted on multiple servers or on a single server. We recommends three individual servers to optimize Responder's performance. This means a separate server for each component: Responder services, web, and geodatabase. All routers/switches between the Responder server and the client machines must support IP multicasting in order for Responder events (e.g., refresh) to be available. Each component has its own requirements.
- Responder Server: This server hosts the various Responder Services (e.g., Data Services, Prediction Services, Archive Services). The Responder services may also be hosted separately on individual servers as well as on a single Responder server. The Configuration section of this online help describes how the Responder services must be configured.
- Web Server: The web server requires IIS and hosts the web-based Call Entry browser. Configuring this server is also covered in the Configuration section.
- Database Server: The database server hosts the database used to view incidents in ArcMap. You may use data replicated from your production geodatabase, or implement a geodatabase copy or versioning strategy. This database must be maintained to remain concurrent with the production geodatabase. It is recommended that you determine how this data will be maintained before implementing Responder.
- Client Machines: The Configuration section of this online help describes how client machines must be configured to use Responder.
Multicasting: All routers and switches must support multicasting. The multicast group number must be unique from other groups, and match between the Responder services config files for all Responder services (Data Services, Prediction Services, Archive Services). The multicast group number is available in the Responder services config files (e.g., Miner.Responder.DataServices.exe.config).

Multicast groups are restricted to class C network IP addresses (in the range 224.0.0.0 to 239.0.0.0). Responder uses scope-relative multicast addresses (in the range 239.0.0.0 to 239.255.255.255). This means that the group is for local use within a domain (it does not need to be globally unique and packets are not passed beyond the domain boundary).

External references:

RFC3171 defines specific ranges of IP multicast addresses

RFC2365 describes scope-relative multicast addresses
Configure Feeder Manager: Feeder Manager is required for Responder to work properly. The Configuring ArcFM Solution online help contains procedures for configuring Feeder Manager.
Load Points: When an outage occurs, a load point is placed to indicate customers without power. Load points are defined as the lowest point modeled on the network. Before implementing Responder, it is important to determine on what features load points can be placed (usually transformers or service points). Devices assigned as load points are indicated by the FDRMGRLOADPOINT model name (see Assign Model Names). This feature class also requires a Phase Designation field with the PHASEDESIGNATION field model name assigned.

You may use both service points and transformers as load points. For example, to assign load points to service points in an urban setting. But in a rural setting, you may have customers assigned directly to a transformer. In this case, assign the FDRMGRLOADPOINT model name to the Service Point feature class and to a Yes/No field (e.g., Load Point field) on the Transformer feature class. You may need to create a Load Point field to which the FDRMGRLOADPOINT field model name is assigned. If you are creating a new Load Point field, ensure it is a Yes/No field. Do NOT assign the model name to the Transformer feature class. When the field is set to Yes, the transformer will be treated as a load point.

After assigning model names it is necessary to initialize trace weights using the Initialize Electric Trace Weights tool in ArcCatalog.
Associate Customers: Ensure customers are associated with the devices on which load points may be placed (e.g., service points, transformers).
Responder Customer Tables: The Responder customer tables must be populated with customer information from the CIS. Before implementing Responder, it is important to decide how these tables will be populated. Once populated, it is important to determine what method will be used to update the data and how often. Below are examples of methods that utilities have used to populate the Responder customer tables with CIS information.
- SQLServer: The data that ties the customer to the service point is stored in the GIS rather than the CIS, and the GIS customer data is versioned. On a weekly basis, the GIS customer data is updated to match the data for a particular LOCATIONID in the CIS. This creates a new version in the GIS. The customer data in this new version is exported to a file that may be read by SQL Server Data Transformation Services (DTS). DTS replaces the Responder customer data with the updated data.
- Oracle: Another possible method is to utilize an Oracle view to the customer data that resides in the CIS. A migration/interface matrix is required to define which fields in the CIS map to the fields in the Responder Customer table and how. This method also requires a method to interface the CIS to Responder to allow the information to be updated regularly.
- Oracle: Use View Table Queries to identify and remove customers without active account numbers, update the connect status field for existing customers with the active CIS customer’s connect status, and append any non-existing customers from the CIS data. These tasks are executed nightly by a Microsoft Access macro through the Microsoft Schedule Task tool.
Create Responder Services User: While installing Responder Server, you were prompted to enter a user name and password for a domain user. This is the login used when executing Responder Services (e.g., Data Services, Prediction Services, Archive Services). This user should exist on your domain before starting the Responder Server configuration.
Citrix Users: Responder takes advantage of ArcFM Solution functionality that makes Responder Explorer semi-transparent before highlighting a feature in ArcMap. This functionality does not work well with Citrix configured for 256 color-depth. Modifying the color-depth of the Citrix connection properties to 16-bit or 24-bit color corrects the problem.
Clustering: You may choose to cluster your Responder servers and Message Router in order to provide failover support. This configuration is optional.
Database Connections: We recommend using direct connections to the database. Refer to Esri's ArcGIS for Desktop help for information about setting up direct connections.