2 Setting Up a WebLogic Server Instance as a Windows Service

Use a Windows service to start Oracle WebLogic Server automatically when a Windows host starts. You can use the Windows Services console to start, stop, restart, and configure the service. By default, stopping the service terminates the server JVM.

To let in-flight work complete before the JVM stops, configure the graceful stop mode described in Enabling Graceful Shutdowns. A service has two distinct identities: the Windows account under which the service process runs and the WebLogic Server startup identity used to authenticate the server.

For each server instance that you set up as a Windows service, WebLogic Server creates a key in the Windows Registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. The registry entry contains such information as the name of the server and other startup arguments.

When you start the Windows host, the Microsoft Management Console uses the information in the Windows Registry key to invoke the weblogic.Server main class. The MMC cannot be configured to use Node Manager to start Managed Servers, therefore the Node Manager's monitoring and automatic restart features cannot be used for servers that run as a Windows service.

The following tasks set up and manage WebLogic Server instances that run as Windows services:

Setting Up a Windows Service: Main Steps

Windows services enable you to create long-running executable applications that run in the background without any user interface.

You can set up a Windows service by running a server-specific script that invokes the weblogic.Server main class by using the information in the Windows registry key. Before running the server-specific script, configure the required connections and stop mode for the Administration Server and Managed Servers.

To set up a Windows service:

  1. Create a script that sets values for server-specific variables and then calls a WebLogic Server master script. See Creating a Server-Specific Script.
  2. If you are installing a Managed Server as a Windows service, add a variable to the server specific script that specifies the location of the domain's Administration Server. See Configuring a Connection to the Administration Server.
  3. If you set up both an Administration Server and a Managed Server to run as Windows services on the same computer, modify the WebLogic Server master script so that the Managed Server starts only after the Administration Server Windows service reports STARTED. See Requiring Managed Servers to Start After Administration Servers.
  4. To request a graceful shutdown when Windows stops the service, set WLS_SERVICE_STOP_MODE=graceful and create the per-server stop configuration file. See Enabling Graceful Shutdowns.
  5. If you want to see the messages that a server instance prints to standard out and standard error (including stack traces and thread dumps), redirect standard out and standard error to a file. See Redirecting Standard Out and Standard Error to a File.
  6. If you have created additional Java classes that you want the WebLogic Server instance to invoke, add them to the server's classpath. See Adding Classes to the Classpath.
  7. Run the server-specific script. See Run the Server-Specific Script.
For more information, see the following sections:

Parent topic: Setting Up a WebLogic Server Instance as a Windows Service

Creating a Server-Specific Script

The script that you create must set the required variables DOMAIN_NAME, USERDOMAIN_HOME, and SERVER_NAME. It calls the domain's setDomainEnv.cmd before installSvc.cmd; setDomainEnv.cmd supplies WL_HOME, JAVA_HOME, and the domain environment. The master script invokes the wlsvcX64 utility, which adds a key to the Windows Registry.

Note:

You can specify a service description by setting SERVICE_DESCRIPTION before running installSvc.cmd, or by using the wlsvcX64 option -svcdescription:<user_specified_service_description>. For information about the utility, enter: 

"%WL_HOME%\server\bin\wlsvcX64.exe" -help

To see an example of a server-specific script, refer to Example 2-1.

Configure a server-specific boot identity file before installing the service. Do not put a clear-text WebLogic password in this script. WLS_USER and WLS_PW are deprecated compatibility inputs. See Boot Identity Files.

  1. In the domain home, create a text file with a .cmd extension.
  2. Begin the script with @echo off and setlocal, then set the required variables, each on a separate line.

    • DOMAIN_NAME is the name of your WebLogic Server domain.

    • USERDOMAIN_HOME is the absolute path of the domain home.

    • SERVER_NAME is the name of an existing server instance that you want to set up as a Windows service.

  3. Add any required optional inputs before calling setDomainEnv.cmd.

    • DOMAIN_PRODUCTION_MODE: Set to true for production mode or false for development mode. See Domain Mode and JDK in Creating WebLogic Domains Using the Configuration Wizard.

    • JAVA_OPTIONS: Java arguments to pass to the JVM, separated by spaces. For WebLogic Server options, see weblogic.Server Command-Line Reference in the Command Reference for Oracle WebLogic Server. The JVM that you use supports additional options, which are documented by the JVM vendor.

    • USER_MEM_ARGS: Heap-size options such as -Xms128m -Xmx512m. The -XmsNumberm argument establishes a minimum heap size in megabytes and -XmxNumberm sets a maximum heap size.

      Note:

      Set USER_MEM_ARGS in this server-specific script before calling setDomainEnv.cmd. setDomainEnv.cmd maps it to the effective MEM_ARGS; do not edit the shared commEnv.cmd for a single service.

    • MAX_CONNECT_RETRIES, HOST, and PORT: The number of status-check attempts, server IP address, and listening port used by the Windows service to determine whether the server has started. Specify these inputs together to wait for the server to start.

    • SERVICE_DESCRIPTION: A description of the Windows service.

    The installation scripts select the service VM for the certified JDK.

  4. Add the following required commands to the end of the script:
    call "%USERDOMAIN_HOME%\bin\setDomainEnv.cmd"
call "%WL_HOME%\server\bin\installSvc.cmd"
endlocal
  5. Save the file.

Parent topic: Setting Up a Windows Service: Main Steps

Configuring a Connection to the Administration Server

If you want to install a Managed Server as a Windows service, you must include a variable that specifies the location of the domain's Administration Server. On its first startup, the Managed Server must contact the Administration Server to retrieve its configuration data.

The Administration Server may itself run as a Windows service. It does not need to be running while you install the Managed Server service. On its first startup, the Managed Server must be able to reach the Administration Server at ADMIN_URL to obtain its domain configuration. On later startups, a Managed Server with Managed Server Independence mode enabled can use its locally cached configuration if the Administration Server is unavailable. See Starting a Managed Server When the Administration Server Is Unavailable.

To configure a connection to the Administration Server:

  1. In a text editor, open the server-specific script.
  2. In the text file, after setlocal and before the calls to setDomainEnv.cmd and installSvc.cmd, create the following command:
    set ADMIN_URL=protocol://listen-address:listen-port

    where:

    • protocol is a protocol accepted by the configured Administration Server channel, such as t3, t3s, http, or https. If the domain-wide administration port is enabled, use t3s or https and the configured administration port (9002 by default). For TLS, the Managed Server JVM must trust the Administration Server certificate, and the URL host name must satisfy certificate host-name verification.

    • listen-address is a listen address of the Administration Server

    • listen-port is a port of the Administration Server

      See Configuring Managed Server Connections to the Administration Server.

      For an example, refer to Example 2-1.

  3. Save your modifications to the server-specific script.

Configure a server-specific boot identity file before installing the service. See Boot Identity Files.

Example 2-1 Example Script for Setting Up a Managed Server as a Windows Service

@echo off
setlocal
set "DOMAIN_NAME=base_domain"
set "USERDOMAIN_HOME=C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain"
set "SERVER_NAME=ManagedServer"
set "ADMIN_URL=t3s://admin-host.example.com:9002"
set "DOMAIN_PRODUCTION_MODE=true"
set "USER_MEM_ARGS=-Xms128m -Xmx512m"
call "%USERDOMAIN_HOME%\bin\setDomainEnv.cmd"
call "%WL_HOME%\server\bin\installSvc.cmd"
endlocal

Note:

To use this example script to set up an Administration Server as a Windows service, remove the ADMIN_URL variable.

If you copy and paste examples, make sure that there are no trailing spaces in them.

The example uses the default secured-production administration port. Substitute the Administration Server's configured protocol, host name, and administration/listen port. If the administration port is enabled, use t3s or https and that port (9002 by default). The service JVM must trust the Administration Server certificate, and the URL host name must satisfy certificate host-name verification. See Using Secured Production Mode.

Parent topic: Setting Up a Windows Service: Main Steps

Requiring Managed Servers to Start After Administration Servers

If you set up both an Administration Server and a Managed Server to run as Windows services on the same computer, you can specify that the Managed Server starts only after the Administration Server Windows service reports STARTED.

  1. Create a backup copy of %WL_HOME%\server\bin\installSvc.cmd. If the Administration Server service is already installed, remove it before reinstalling it. See Removing a Server as a Windows Service.

  2. In the final wlsvcX64 invocation in installSvc.cmd, insert -delay:delay_milliseconds before -cmdline:%CMDLINE% when installing the Administration Server service. For a two-minute fixed delay, use -delay:120000. Install the service, then remove this temporary edit from the master script.

    -delay is a fixed delay before the service reports STARTED; it is not a WebLogic health check.

  3. Before installing the Managed Server service, insert -depend:"wlsvc domain-name_admin-server-name" before -cmdline:%CMDLINE%, using the exact Administration Server service name shown in Services. For example: -depend:"wlsvc myDomain_myAdminServer". Install the Managed Server service, then remove this temporary edit from the master script.

    The -depend option waits for the prerequisite Windows service to report STARTED before starting the dependent service. You can also add -delay:delay_milliseconds for the Managed Server service.

For information about the utility, enter:

"%WL_HOME%\server\bin\wlsvcX64.exe" -help

Parent topic: Setting Up a Windows Service: Main Steps

Enabling Graceful Shutdowns

If WLS_SERVICE_STOP_MODE is unset or set to kill, stopping the Windows service terminates the server JVM. Set the mode to graceful to use WebLogic Server's built-in graceful-stop class. The class authenticates with a WLST user configuration file and its associated key file; do not store a clear-text password in the service script or stop configuration file.

  1. Start WLST, connect online to the WebLogic Server that the stop route will use, and create a user configuration file and key file from the current connection. For example:
    wls:/offline> connect('stop-operator', 'password', 't3s://server-host.example.com:9002')
wls:/mydomain/serverConfig> storeUserConfig('C:/secure/wls-service-user.secure', 'C:/secure/wls-service-user.key')

    Use an account in the Operator or Administrator role. The sample password is a prompt placeholder; do not save it in a script or in this properties file. storeUserConfig is an online command and stores the identity from the current connection; its current configuration tree does not affect the output. Store both files in a directory readable only by the Windows service account and required administrators. See storeUserConfig in the WLST Command Reference.

  2. Create %USERDOMAIN_HOME%\config\windows-service\%SERVER_NAME%.properties. Use forward slashes in Windows paths because this is a Java properties file. For a service that connects directly to its own server runtime, use:
    route=local
url=t3s://server-host.example.com:9002
userConfigFile=C:/secure/wls-service-user.secure
userKeyFile=C:/secure/wls-service-user.key
timeoutSeconds=120
ignoreSessions=false
waitForAllSessions=false

    url, userConfigFile, and userKeyFile are required. route defaults to local. For route=local, url identifies the server being stopped. To route the request through the Administration Server, set route=admin and make url identify the Administration Server. Use the server's configured secure administration or SSL port; the example shows the default domain-wide administration port, 9002. The service JVM must trust the certificate presented at that URL, and the URL host name must satisfy certificate host-name verification. timeoutSeconds must be zero or greater. ignoreSessions and waitForAllSessions default to false. The optional serverName property, if present, must exactly match %SERVER_NAME%.

  3. In the server-specific install script, before the calls to setDomainEnv.cmd and installSvc.cmd, add:
    set "WLS_SERVICE_STOP_MODE=graceful"
  4. Run the server-specific install script.

    The master script verifies that the properties file exists and is readable, adds the built-in stop class and its module to the installed service, and leaves the default kill behavior unchanged for services that do not opt in.

  5. Use the server's Start/Stop settings or the optional properties above to choose the graceful-shutdown timeout and HTTP-session behavior. Test the stop operation before relying on it in production.

Existing custom stop classes remain supported. To use one, put the class on the service classpath and set both WLS_SERVICE_STOP_MODE=custom and WLS_SERVICE_CUSTOM_STOP_CLASS=fully.qualified.ClassName in the server-specific script. The class must provide public static void stop().

Parent topic: Setting Up a Windows Service: Main Steps

Redirecting Standard Out and Standard Error to a File

By default, when you install a WebLogic Server instance as a Windows service, you cannot see the messages that the server or its JVM print to standard out and standard error.

To view these messages, you must redirect standard out and standard error to a file:

  1. Create a backup copy of the WL_HOME\server\bin\installSvc.cmd master script.
  2. In a text editor, open the WL_HOME\server\bin\installSvc.cmd master script.
  3. In installSvc.cmd, the last command in the script invokes the wlsvc utility. At the end of the wlsvc command, append the following command option:
    -log:"pathname"

    where pathname is a fully qualified path and filename of the file that you want to store the server's standard out and standard error messages.

    The modified wlsvc command will resemble the following command: 

    "%WL_HOME%\server\bin\wlsvc" -install 
-svcname:"%DOMAIN_NAME%_%SERVER_NAME%" 
-log:"d:\Oracle\Middleware\user_projects\domains\myWLSdomain\myWLSserver-stdout.txt"
-javahome:"%JAVA_HOME%" -execdir:"%USERDOMAIN_HOME%" 
-extrapath:"%WL_HOME%\server\bin" -password:"%WLS_PW%" 
-cmdline:%CMDLINE%
  4. By default, every 24 hours the Windows service archives messages to a file named pathname-yyyy_mm_dd-hh_mm_ss. New messages collect in the file that you specified in the previous step.

    For information on changing the default behavior, see Changing the Default Rotation Criteria.

After you install the service and restart the Windows host, to view the messages that the server writes to standard out or standard error, do one of the following:

  • Make a copy of the file that you specified and view the copy. The Windows file system cannot write to files that are currently opened.

  • To view the messages as they are being printed to the file, open a command prompt and, using a DOS utility that supports the tail command, enter tail -f stdout-filename.

Parent topic: Setting Up a Windows Service: Main Steps

Changing the Default Rotation Criteria

By default, every 24 hours the Windows service archives messages to a file named pathname-yyyy_mm_dd-hh_mm_ss. New messages collect in the file that you specified when you set up the service.

You can change the time interval or you can set up rotation to occur based on the size of the message file instead of a time interval.

To change the default criteria at which the Windows service rotates message files:

  1. If the Windows service is running, shut it down.
  2. Edit the file you specified in the -log: pathname argument. If a file does not exist, create one.
    For example, to use the log file shown in Redirecting Standard Out and Standard Error to a File, create a file named 
    d:\Oracle\Middleware\user_projects\domains\myWLSdomain\myWLSserver-stdout.txt
  3. Do one of the following:

    • If you want the Windows service to rotate the message file at a specific time interval regardless of file size, add the following statements at the top of the file, each statement on a separate line (make sure to press the Enter or Return key after typing the last line):

      # ROTATION_TYPE = TIME
# TIME_START_DATE = date-in-required-format 
# TIME_INTERVAL_MINS = number-of-minutes

      where TIME_START_DATE specifies when the first rotation should take place. If the specified time has already passed, the first rotation occurs when the time interval specified in TIME_INTERVAL_MINS expires. You must use the following format to specify the start time: Month Day Year Hour:Minutes:Seconds

      where Month is the first 3 letters of a Gregorian-calendar month as written in English

      Day is the 2-digit day of the Gregorian-calendar month

      Year is the 4-digit year of the Gregorian calendar

      Hour:Minutes:Seconds expresses time in a 24-hour format

      TIME_INTERVAL_MINS specifies how frequently (in minutes) the Windows service rotates the file.

      Optionally, you can add the MAX_FILE_COUNT attribute to specify a rotation limit for the output files that are generated from WebLogic Server as a service. By default, MAX_FILE_COUNT=-1, meaning no limit on the number of files exists. Defining MAX_FILE_COUNT with a value greater than 0 sets a limit on the number of files to rotate.

      For example:

      # ROTATION_TYPE = TIME
# TIME_START_DATE = Jul 17 2003 05:25:30
# TIME_INTERVAL_MINS = 1440
# MAX_FILE_COUNT = 999

      When the time interval expires, the Windows service saves the file as pathname-yyyy_mm_dd-hh_mm_ss. It then creates a new file named pathname. This new file, which contains all of the headers that you specified originally, collects new standard out and standard error messages.

      If you specify # ROTATION_TYPE = TIME but do not include the other lines, the Windows service rotates the message file every 24 hours.

    • If you want the Windows service to rotate the message file after the file grows beyond a specified size, add the following statements at the top of the file, each statement on its own line (make sure to press the Enter or Return key after typing the last line):

      # ROTATION_TYPE = SIZE
# SIZE_KB = file-size-in-kilobytes  
# SIZE_TRIGGER_INTERVAL_MINS = polling-interval

      where SIZE_KB specifies the minimal file size (in kilobytes) that triggers the Windows service to move messages to a separate file.

      SIZE_TRIGGER_INTERVAL_MINS specifies (in minutes) how frequently the Windows service checks the file size. If you do not include this header, the Windows service checks the file size every 5 minutes.

      For example:

      # ROTATION_TYPE = SIZE
# SIZE_KB = 1024
# SIZE_TRIGGER_INTERVAL_MINS = 3

      When the Windows service checks the file size, if the file is at least the size you specify, it saves the file as pathname-yyyy_mm_dd-hh_mm_ss. It then creates a new file named pathname. This new file, which contains all of the headers that you specified originally, collects new standard out and standard error messages.

      If you specify # ROTATION_TYPE = SIZE but do not include the other lines, the Windows service checks the size of the message file every 5 minutes. If the file is at least 1 megabyte, it rotates the file.

To cause the WebLogic Server instance to print a thread dump to its standard-output destination, use the WLST threadDump command or open a command prompt and enter: 

"%WL_HOME%\server\bin\wlsvcX64.exe" -dump -svcname:"wlsvc domain-name_server-name"

Use the exact service name displayed in the Windows Services console. For example:

"D:\Oracle\Middleware\Oracle_Home\wlserver\server\bin\wlsvcX64.exe" -dump -svcname:"wlsvc mydomain_myserver"

Adding Classes to the Classpath

Add application libraries after the domain environment is established and before calling installSvc.cmd. For example: 

call "%USERDOMAIN_HOME%\bin\setDomainEnv.cmd"
set "CLASSPATH=C:\myLib\myJar.jar;%CLASSPATH%"
call "%WL_HOME%\server\bin\installSvc.cmd"

Note:

If the Windows service classpath is too long, put the complete classpath on the first line of a protected text file as one semicolon-separated line, for example C:\secure\service-classpath.txt. In the master installSvc.cmd, temporarily replace -classpath \"%CLASSPATH%\" in the service CMDLINE with -classpath @C:\secure\service-classpath.txt. Install the service, then restore the master script. This @file behavior is specific to the WebLogic Windows service wrapper's classpath parser; the wrapper reads only the first line.

Parent topic: Setting Up a Windows Service: Main Steps

Run the Server-Specific Script

Note:

To run the server-specific script, you must log in to the Windows computer with a user account that has privileges to modify the Windows registry.

If you install the Windows service in a production environment, Oracle recommends that you do not run the service under an operating-system user account that has administrator-level privileges. See Verifying the User Account Under Which the Service Runs.

To run the server-specific script:

  1. Open a command prompt and change to Administration Server's root directory, which is the directory that contains the server-specific script.
  2. Enter the name of the server-specific script.

    The command prompt runs the script as a batch file.

    If the script runs successfully, it creates a Windows service named wlsvc DOMAIN_NAME_SERVER_NAME and prints a line to standard out that is similar to the following:

    wlsvc mydomain_myserver installed.

    The Services console displays wlsvc mydomain_myserver. By default, standard out is the command prompt in which you run the server-specific batch file.

  3. If you modified the WL_HOME\server\bin\installSvc.cmd master script, consider undoing your modifications so the script can be used to set up other server instances.

Parent topic: Setting Up a Windows Service: Main Steps

Verifying the Setup

Use the wlsvcx64 -debug command to verify that the Windows service is configured correctly.

To verify that you successfully set up a WebLogic Server as a Windows service, do the following:

  1. Open a command window and enter the following command:
    set PATH=WL_HOME\server\bin;%PATH%
  2. Navigate to the directory immediately above your domain directory. For example, to verify the setup for ORACLE_HOME\user_projects\domains\mydomain, navigate to ORACLE_HOME\user_projects\domains.
  3. Enter: 
    wlsvcx64 -debug "yourServiceName"

    For example, wlsvcx64 -debug "mydomain_myserver".

    If your setup was successful, the wlsvcx64 -debug command starts your server. If the script returns an error similar to the following, make sure that you specified the correct service name: 

    Unable to open Registry Key ....... System\CurrentControlSet\Services\wlsvc example_examplesServer\Parameters

Parent topic: Setting Up a WebLogic Server Instance as a Windows Service

Verifying the User Account Under Which the Service Runs

In a production environment, WebLogic Server Windows services should run under a special operating-system user account that has limited access privileges. For example, the OS user should have access privileges only to Oracle files and to your domain files. This should be the only user account that has access to these files.

To ensure that the WebLogic Server instance runs under the special OS user account:

  1. Open Services in the Microsoft Management Console.

    For example, from the Windows XP desktop:

    1. Select the Start menu.

    2. On the Start menu, select Programs > Administrative Tools > Services.

  2. In the Services window, right click the WebLogic Server Windows service and select Properties.

  3. In the Properties window, select the Log On tab.

  4. Under Log on, select This account. Then enter the user name and password of the special OS user account.

  5. Click OK.

    Note:

    When accessing network drives, the Windows service must run under the same user name as the one who shared the network drive.

Parent topic: Verifying the Setup

Using the Services Window to Stop or Restart a Server Instance

Use the Microsoft Management Console Services window to stop and restart a server instance.

By default, if you use the Microsoft Management Console to stop a server instance, it kills the server's Java Virtual Machine (JVM). If you kill the JVM, the server immediately stops all processing. Any session data is lost. If you kill the JVM for an Administration Server while the server is writing to the config.xml file, you can corrupt the config.xml file. See Enabling Graceful Shutdowns.

To stop or restart a WebLogic Server instance that is installed as a Windows service:

  1. Select Start > Programs > Administrative Tools > Services.
  2. In the Services window, find the service that you created. By default, the service name starts with wlsvc.
  3. Right-click the service name and select commands from the menu.

Parent topic: Setting Up a WebLogic Server Instance as a Windows Service

Removing a Server as a Windows Service

You can remove a Windows service by using a script that causes the wlsvcX64 utility to remove the associated key from the Windows Registry.

It does not affect the server instance's configuration that is saved in the domain's configuration file. After removing the Windows service, you can restart the WebLogic server instance with start scripts or Node Manager.

The script sets DOMAIN_NAME and SERVER_NAME to identify the exact service named wlsvc DOMAIN_NAME_SERVER_NAME. Then the script calls a master uninstall script, WL_HOME\server\bin\uninstallSvc.cmd, where WL_HOME is the directory in which you installed WebLogic Server. The master script invokes the wlsvcX64 utility, which removes a key from the Windows Registry.

To see an example of a server-specific uninstaller script, refer to Example 2-2.

To create a script for removing a Windows service that runs a WebLogic Server instance:

  1. In the domain home, create a text file for the removal script. The domain configuration file is DOMAIN_HOME\config\config.xml.
  2. Add the following, required batch commands to the text file, each command on a separate line:

    • SETLOCAL

      This is a batch command that begins the localization of environment variables in a batch file.

    • set DOMAIN_NAME=domain-name

      where domain-name is the name of your WebLogic Server domain.

    • set SERVER_NAME=server-name

      where server-name is the name of an existing server instance that you want to remove as a Windows service.

    • call "WL_HOME\server\bin\uninstallSvc.cmd"

      where WL_HOME is the absolute path to the directory in which you installed WebLogic Server. This command calls the WebLogic Server master uninstall script.

    • ENDLOCAL

      This is a batch command that ends the localization of environment variables in a batch file.

  3. Save the text file with a .cmd extension. By default, the Windows command prompt associates the .cmd extension with batch files.
  4. Enter the name of the server-specific script.

    The command prompt runs the script as a batch file.

If the removal script runs successfully, it prints a line similar to the following to standard out:

wlsvc myWLSdomain_myWLSserver removed.

By default, standard out is the command prompt in which you run the batch file.

Example 2-2 Script to Remove a Windows Service

@echo off
setlocal
set "DOMAIN_NAME=myWLSdomain"
set "SERVER_NAME=myWLSserver"
call "D:\Oracle\Middleware\Oracle_Home\wlserver\server\bin\uninstallSvc.cmd"
endlocal

Parent topic: Setting Up a WebLogic Server Instance as a Windows Service

Changing the WebLogic Startup Identity or Windows Service Account

Change the WebLogic startup identity through the server-specific boot identity file, or change the Windows service account through the service Log On tab.

To change the WebLogic startup user name or password, update the server-specific boot identity file at SERVER_ROOT\security\boot.properties, where SERVER_ROOT is normally DOMAIN_HOME\servers\SERVER_NAME. Enter the valid username and password values. At the next successful server startup, WebLogic Server rewrites the values in encrypted form. Restrict permissions on the file and its containing directory to the Windows service account and required administrators. The identity must be valid in the server's security realm and authorized to start the server. See Boot Identity Files.

To change the Windows account under which the service process runs, use the service Log On tab as described in Verifying the User Account Under Which the Service Runs.

Note:

WLS_USER and WLS_PW are deprecated compatibility inputs. If an existing legacy service was installed with those values, remove and reinstall the service to change them, then remove the clear-text values from the script and migrate to a server-specific boot identity file. The legacy wrapper protects the registry value only with reversible obfuscation; do not describe it as secure encryption.

Parent topic: Setting Up a WebLogic Server Instance as a Windows Service