The Support Authority
Running WebSphere Application Server as a Windows service
This content is part # of # in the series: The Support Authority
This content is part of the series:The Support Authority
Stay tuned for additional content in this series.
In each column, The Support Authority discusses resources, tools, and other elements of IBM® Technical Support that are available for WebSphere® products, plus techniques and new ideas that can further enhance your IBM support experience.
Leveraging Windows services
A Windows service can be run in the security context of a local user account, a domain user account, or the LocalSystem account. To help decide which account to use, an administrator will install the service with the minimum set of permissions required to perform the service operations, will typically create a domain user account for the service, and grant that account the specific access rights and privileges required by the service at run time.
There can be many reasons you might want to do this. Windows services typically live on each local machine and can be controlled by a local user or a domain user. In some cases, it can be beneficial to set up the service to run as a domain user. For example, if multiple machines are set up to run IBM WebSphere Application Server as a service, a domain user account can be set up to control all those services. If a password ever needs to be changed, it can be modified in just the domain controller for that user. If local system users were to run the services, the password would need to be changed in every machine instead of just once for the user in the domain controller. When the password changes for a user that is running a Windows service, the only way to get the service to work again is to update the service and repeat all the steps.
The task of setting up WebSphere Application Server to run, as a Windows service under a domain user account, can be complicated. This article explains the general information you need to accomplish this setup in Windows Server 2003. You will learn how to create the Windows service using the WASServiceCmd utility and how to change the service to log on as the domain user account.
For the purpose of this article, it is assumed that the local machine is already part of the domain. Be aware that once the machine is added to the domain, the group for Domain Admins is added by default on the local machine, shown in Figure 1.
We’ll refer to two different users located in the Active Directory of the domain controller:
- alainadmin: A domain administrator in the domain controller, shown in Figure 2.
- alainuser: A domain user with basic user rights, not an administrator in the domain controller. This is the user for which the setup is being run, shown in Figure 3.
Figure 1. Domain Admins group gets added by default when machine is added to domain
Figure 2. Shows alainadmin is a member of Domain Admins group
Figure 3. Shows alainuser is a member of Domain Users group
Specific rights are required by the operating system to be able to run the domain user. To set up and run this function on a Microsoft Windows operating system, the user must belong to the administrator group and have these advanced user rights:
- Act as part of the operating system.
- Log on as a service.
To demonstrate, let’s step through the procedure:
- Log on to the local machine with a user that has Domain Administrator rights (alainadmin).
- Add the domain user to the Administrators group of the local machine (alainuser), shown in Figure 4:
- Right click My computer and select Manage. In the directory tree,
navigate to Under Local Users and Groups > Groups.
Figure 4. Shows path to get to Administrators Group in Windows 2003
- To add the user to the Administrators group, double click Administrators, then select Add.
- Click Advanced. If prompted for username and password, use the credentials for the domain administrator in the domain controller (alainadmin).
- Click Find Now. The users from the domain will display.
Add your domain user to the group of Administrators (Figure 5),
then click OK and Apply.
Figure 5. Shows alainuser getting added to the Administrators group of the local machine
- Right click My computer and select Manage. In the directory tree, navigate to Under Local Users and Groups > Groups.
- Add the two required user rights assignments:
- Click the Windows Start button and navigate to Settings > Control Panel > Administrative tools > Local Security Policy.
- Select User Rights Assignment in the left window (if
not already selected) and then double-click Act as part of the operating system (Figure 6).
Figure 6. Security setting: Act as part of the operating system
- Click Add User or Group. Select the user and click OK to add the user to the policy (Figure 7).
Figure 7. Add the local user alainuser to the security policy
- Repeat the previous step to the user to the Log on as a service policy (Figure 8).
Figure 8. Local security settings
- Log off Domain Admin (alainadmin) and log in as the Domain user (alainuser).
- Run the WASServiceCmd utility to create the service. Earlier this year, The Support Authority presented the WASService command. You can download the utility from the Using WASServiceCmd to create Windows services for WebSphere Application Servers Technote. Follow the instructions to unzip the tool to the WebSphere_root/AppServer/bin directory. WASServiceCmd.exe is a front end for WASService.exe, which is shipped with WebSphere Application Server. The creation of a service takes many parameters and this utility will help minimize any human errors that can occur during service creation.
- Change the service to log on as the domain user. Click the Windows Start button and navigate to Settings > Control Panel > Administrative tools > Services.
- Locate the service that was created. Double-click the service, select
the Log on tab, and change the Log on as selection
Figure 9. Shows the Domain user alainuser becoming Log on as
The service should now be working with the domain user alainuser. Shown in Figure 9, the log on values show
AUSTINL2\alainuser. This shows that the service is now being controlled by a domain user account.
This article described how the domain administrator for Windows Server 2003 can set up a user that lives in the domain controller, and has the bare minimum user rights, but runs the service on the local machine for WebSphere Application Server. This consists of the domain administrator logging in to the local machine and providing the correct rights for the domain user to run the Windows service.
- Information Center: WASService command
- Using WASServiceCmd to create Windows services for WebSphere Application Servers
- The Support Authority: Take the confusion (and errors) out of creating Windows services for WebSphere Application Server
- Video: An imated demonstration of the WASServiceCmd tool (Flash)
- Guidelines for Selecting a Service Logon Account
- The Support Authority: If you need help with WebSphere products, there are many ways to get it