> Installation Guide > Completing Post-Installation

Installation Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Completing Post-Installation

This chapter describes the tasks you may have to complete after installing WebLogic Network Gatekeeper and configuring the WebLogic Server domain for use with it. These include

 

Complete Post-Install Tasks

You may not need to do all of the following tasks depending on the type of installation with which you are working.

Create JMS Servers for Any Additional NT Servers

If you have added any Network Tier servers to the initial two provided by the domain template, you must edit the configuration to add support for the EDR Service. Each server in the Network Tier requires its own JMS server in order for the EDR Service to work correctly.

For the following task, you must start the Administrative Server in your WebLogic Network Gatekeeper installation so that you can use the Management Console to make the necessary adjustments. Unless you are setting up an all in one domain, you will also need to start at least one Network Tier server (this prevents a null pointer error in initializing the Console). For more information on using the Console, please see the System Administration Guide, a separate document in this set. The following is an overview only:

  1. Start WebLogic Network Gatekeeper on the Administrative Server.

    2. In a command prompt window, go to the domain\bin directory. In the default installation, this would be <beahome>\user_projects\domains\wlng-domain\bin. Run the startWebLogic script.

    The Administrative Server will load.

  2. Watch the command prompt window as the server loads. Wait until the prompt indicates that the server is in state RUNNING.
  3. Start a Network Tier server.

    4. In a separate command prompt window, go to the domain\bin directory. See step 1 above. Enter the following:

    startManagedWebLogic networknode0-0 t3://adminhost:7001

    replacing the first parameter with the name of the NT server and the second with the URL of the Administration Server.

Note: You can also log into the NT server, and run the startManagedWebLogic script from there.
  1. Watch the command prompt window as the NT server loads. Wait until the prompt indicates that the server is in state RUNNING.
  2. Once both servers are in state RUNNING, bring up the Administrative Console.

    3. In your browser, enter the following address: http://<hostname>:<port>/console, where <hostname> is the Administrative Server and port is the ListenAddress assigned during Domain Configuration. The default value is 7001.

  3. Login using your login credentials.

    4. If this is the first time you have logged in, you should use username: weblogic; password weblogic. There are instructions in the System Administration Guide on changing these values once your system is fully configured.

  4. Before you can make any changes using the Console, you must click Lock & Edit in the Change Center on the left side of the window.

(In the example below, assume that the additional server WLNG_NT3 was created.)

In the Management Console:

  1. Select Home > Services > Messaging >JMS Servers > New
  2. In the Name text box, enter the name of the JMS Server. In our example, this would be JMSServer-NT3
  3. In the Target dropdown menu, select the appropriate server. In our example, this would be WLNG_NT3
  4. Click Finish
  5. Click Activate Changes

Install Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files, if desired

WebLogic Network Gatekeeper 4.0 does not require the JCE files, but you can install them if you wish to use JCE providers. For more information, please see the Using the nCipher JCE Provider with WebLogic Server section in Securing WebLogic Server.

Install and configure the necessary SIP integration software

If your installation is using SIP connectivity, there are Network Gatekeeper files that must be installed in your WebLogic SIP Server.

  1. If necessary, install the SIP Server using the supplied installer, either into its own domain or into the same domain as the Network Gatekeeper Network Tier, but in a different cluster. For more information on installing the SIP Server, see Installing BEA WebLogic SIP Server
    2. Note: If the SIP Server is in a separate domain, trust must be configured between the two domains. You must do this on both sides. Because WLSS runs on version 9.2 of WebLogic Server and Gatekeeper runs on version 10.0, you need to follow the instructions per the server you are configuring. For version 10.0 information can be found in Enable trust between domains in the WLS Administration Console Online Help For version 9.2, instructions can be found in Enable trust between domains in that version. You will need to restart after you have completed.
  2. Locate the three files you need to install on your SIP server. They are stored in the wlss directory of your domain directory. In the default installation this is <bea_home>\user_projects\domains\wlng-domain\wlss\.
  3. Copy the first file, wlng-integration-management.jar, to <beahome>\user_projects\domains\<sip-domain>\lib\
  4. Copy the second file, wlng-integration-console-ext.war, to <beahome>\user_projects\domains\<sip-domain>\console-ext\
  5. Create a custom resource description file and place it in <beahome>\user_projects\domains\<sip-domain>\config\custom\. Listing 8-1 below is a sample of what you must create, although the contents will in each case be installation specific, and not all elements may exist in all files. All of these values can be changed using the Console Extension during the Network Gatekeeper configuration process. The possible elements for the file are as follows:
    • wlng-jndi-url: The WLNG Network Tier JNDI lookup URL
    • wlng-jndi-username: The WLNG Network Tier JNDI lookup username
    • wlng-jndi-password: The WLNG Network Tier JNDI lookup password
    • call-notification-plugin-name: The WLNG Network Tier call notification plugin RMI home interface JNDI name (you should not change the name shown in the sample unless you are developing a custom traffic path).
    • call-direction-plugin-name: The WLNG Network Tier call direction plugin RMI home interface JNDI name (you should not change the name shown in the sample unless you are developing a custom traffic path).
    • third-party-call-manager: The class name for the third party call manager component (you should not change the name ushown in the sample unless you are customizing the third party call control implementation at the WLSS)
    • third-party-call-servlet: The SIP servlet name for the third party call control (you should not change the name shown in the sample unless you are customizing the third party call control implementation at the WLSS)
    • third-party-call-controller-uri: The controller SIP URI that is used to establish the third party call. By default, the value is "None", where no controller URI is used to establish the call. If this field is set to a URI other than "None", the call appears to the callee as if it comes from the controller URI rather than from the caller’s URI.
    • presence-sip-subscribe-expiry-seconds: Specifies a suggested lifetime for a subscription.
      • Note: This value might not be accepted by the Presence Server. In that case the Presence Server sets the expiry value it has chosen, which is the value that will be used, in the first NOTIFY sent to the WLSS plugin.
    • presence-sip-subscribe-target-address: The address to which the subscribe messages are sent, which can be the presence server itself or a proxy. The value is a sip:URI.
      • Listing 8-1 Sample custom resource description file 
      <?xml version='1.0' encoding='UTF-8'?>
       <xt-resource xmlns="http://www.bea.com/wlcp/wlng/wlng-integration"   xmlns:sec="http://www.bea.com/ns/weblogic/90/security"   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   xmlns:wls="http://www.bea.com/ns/weblogic/90/security/wls">
        <wlng-jndi-url>t3://hostname:7001</wlng-jndi-url>
        <wlng-jndi-username>weblogic</wlng-jndi-username>
        <wlng-jndi-password>weblogic</wlng-jndi-password>
       <call-notification-plugin-name>com.bea.wlcp.wlng.plugin.callnotification
         .ejb.CallNotificationPluginEJBHome</call-notification-plugin-name>
       <call-direction-plugin-name>com.bea.wlcp.wlng.plugin.callnotification
          .ejb.CallDirectionPluginEJBHome</call-direction-plugin-name>
       <third-party-call-manager>com.bea.wlcp.integration.tpc.impl.
          ThirdPartyCallManagerImpl</third-party-call-manager>
        <third-party-call-servlet>third-party</third-party-call-servlet>
        <third-party-call-controller-uri>sip:myname@localhost</third-party-call
          -controller-uri>
       <presence-sip-subscribe-expiry-seconds>60</presence-sip-subscribe-expiry-seconds>
       <presence-sip-subscribe-target-address>sip:172.23.81.52:5060</presence-sip-subscribe-target-address>
       </xt-resource>
  6. The third provided file, wlss-int.ear, should be deployed as a J2EE application in the SIP server.
  7. Edit the <beahome>\user_projects\domains\<sip-domain>\config\config.xml file. You must add the following stanza:
    8. Listing 8-2 Custom resource stanza for config.xml 
    <custom-resource>
      <name>wlng-integration</name>
      <target>SIPCluster</target>
      <descriptor-file-name>custom/wlng-integration.xml
        </descriptor-file-name>
      <resource-class>
        com.bea.wlcp.integration.management.descriptor.resource.XTResource
      </resource-class>
      <descriptor-bean-class>
        com.bea.wlcp.integration.management.descriptor.bean.XTResourceBean
      </descriptor-bean-class>
    </custom-resource>
  8. Change the target element to point to the server name or cluster name on which your WebLogic SIP Server is installed. Change the descriptor-file-name element to point to the custom resource description file you created in step 5) above.
  9. Update the WLSS system classpath with a Gatekeeper specific security module, wlng-security.jar. There are multiple ways to do this, but one way would be:
    1. Copy the security module, found in <bea_home>\user_projects\domains\wlng-domain\wlss\wlng-security.jar to the SIP server, <WLSS_HOME>\sipserver31\server\lib\wlss\wlng-security.jar.
    2. Update the commEnv.cmd(sh) script, found in <bea_home>\sipserver31\common\bin\commEnv.cmd(sh)to include the security module:

      3. set WEBLOGIC_CLASSPATH=%PATCH_CLASSPATH%;%JAVA_HOME%\lib\tools.jar;%WL_HOME%\server\lib\weblogic_sp.jar;%WL_HOME%\server\lib\weblogic.jar;%SIP_CLASSPATH%;%WL_HOME%\server\lib\webservices.jar;%SIP_CLASSPATH%;%WL_HOME%\server\lib\wlss\wlng-security.jar

Once these files are installed and configured, a WLNG Integration console extension will show up in the Domain Structure left navigation box when you run the WebLogic Server Administration Console on the SIP installation. Any further changes and modifications you may need to do can be done using this tool. For more information on these changes, see the “Configuring WebLogic SIP Server Integration” in the System Administrator’s Guide, another document in this set.

Run Migration Scripts, if upgrading

Some aspects of the way Network Gatekeeper stores information in the database have changed with this release. If you are upgrading from a 3.0 installation, you must run a set of migration scripts to upgrade your current data to 3.0 formats.

Note: Backing up your database before running these scripts is recommended.

The scripts include:

Note: These scripts are located in the migration.zip file, which is found in <bea_home>/wlng400/common/templates/scripts.

Database Migration

WARNING: Run this script before doing either of the other two migrations.

To run the script:

  1. Create a migration directory under the scripts directory.
  2. Unzip the migration.zip file into the migration directory.
  3. Copy the jar file containing the driver for your database (ojdbc14.jar for Oracle, mysql.jar for MySQL) into the lib directory that is extracted when you unzip the migration file. In the default installation this would be <bea_home>/wlng400/common/templates/scripts/migration/lib.
  4. Make sure the environment variables JAVA_HOME and ORACLE_HOME (for ORACLE DB) or MYSQL_HOME (for MySQL) are set properly.
  5. Run the script with the required parameters, as follows (replace CAPS with appropriate values):
    6. db_migration.sh <DB TYPE [oracle | mysql]> <DB HOST> <DB NAME | ORACLE SERVICE NAME> <DB USERID> <PASSWORD>

PRM Data Migration

PRM data must also be migrated. You can choose to migrate a single Service Provider, Application, or Application Instance account, or to migrate them as a group by type.

  1. The script is part of the set in the migration.zip file that you unzipped in the first task.
  2. The driver jar file must be in the lib directory just as it was in the first task.
  3. Run the script with the required parameters, as follows:
    • To migrate all SP accounts:
      • runPrmMigration.sh <DB type [oracle/mysql]> <DB HOST> <DB PORT ><DB NAME/Oracle Service Name> <DB USERID> <PASSWORD> sp %
    • To migrate a single SP account using the SPID:
      • runPrmMigration.sh <DB type [oracle/mysql]> <DB HOST> <DB PORT ><DB NAME/Oracle Service Name> <DB USERID> <PASSWORD> sp [SPID]
    • To migrate all APP accounts:
      • runPrmMigration.sh <DB type [oracle/mysql]> <DB HOST> <DB PORT ><DB NAME/Oracle Service Name> <DB USERID> <PASSWORD> app %
    • To migrate a single APP account using the APPID:
      • runPrmMigration.sh <DB type [oracle/mysql]> <DB HOST> <DB PORT ><DB NAME/Oracle Service Name> <DB USERID> <PASSWORD> app [APPID]
    • To migrate all APP Instances:
      • runPrmMigration.sh <DB type [oracle/mysql]> <DB HOST> <DB PORT ><DB NAME/Oracle Service Name> <DB USERID> <PASSWORD> appInst %
    • To migrate a single APP Instance using the appInstanceId:
      • runPrmMigration.sh <DB type [oracle/mysql]> <DB HOST> <DB PORT ><DB NAME/Oracle Service Name> <DB USERID> <PASSWORD> appInst [appInstanceId]

Administrative and PRM User Migration

Administrative and PRM users must also be migrated.

  1. The script is part of the set in the migration.zip file that you unzipped in the first task.
  2. The driver jar file must be in the lib directory just as it was in the first task.
  3. Run the script with the required parameters, as follows:
    • To migrate all PRM users:
      • runPrmMigration.sh <DB type [oracle/mysql]> <DB HOST> <DB PORT ><DB NAME/Oracle Service Name> <DB USERID> <PASSWORD> prmuser %
    • To migrate Administrative users:
      • runMgmtUserMigration.sh <DB type [oracle/mysql]> <DB HOST> <DB PORT ><DB NAME/Oracle Service Name> <DB USERID> <PASSWORD>

 

Configure Network Gatekeeper

Once you have installed the software, configured the domain, and completed any necessary post-installation steps, you can proceed to configuring Network Gatekeeper itself. The specifics for doing these tasks are presented in the System Administrator’s Guide and Managing Accounts and SLAs, but the following list gives you a general outline of the initial tasks you must perform:

 

For Further Information

To learn more about installing WebLogic Server products in general, and about the installer program in particular in regard to WebLogic Server, see the WLS Installation Guide.


  Back to Top       Previous  Next