Return to Newsletter Contents...

Enterprise Services and User Accounts

by: Joe Roberts, Principal Consultant, BECP, SLE, MCP

When Business Objects Enterprise XI installs services the default configuration for “Log On As” is “System Account”. This default configuration creates a great deal of confusion and will even render some features of the platform unable to execute successfully. In this article we will examine the “Log On As” feature, explain your options and hopefully, take the mystery out of this important task.

The problem with servers

Most of us are used to working interactively, that means we log on to our workstations and work. The operative word here is “log on”. Windows interacts with resources on our networks (file shares, printers, databases, etc.) on that basis. We are providing the operating system with a default identity; the users we logged on as. When we try to access network resources, that identity is passed to the resource as authentication. If that identity fails we are often prompted to supply credentials that would allow us access. This is the context with which most of us are familiar.

Now consider the server. It sits in the server room often without a keyboard or monitor even connected to it. It is constantly working without anyone logged into to it or even directly aware what it’s doing. That’s its job!

So what does the server do when it needs to access a network resource? It uses the identity of service defined by the “Log On As” parameter to authenticate. When a particular process executing within a service needs access to network resources, it passes the user name and password defined there to the network resource. This serves the same purpose any your user name and password does when you log on to your workstation.

Local System accounts vs. Network User accounts

As I told you earlier Business Objects Enterprise, by default, installs all service account to use a Local System account for log on. This is because Enterprise does not necessarily need to access network resources to do its job. A Local System is a built in account on the local server that can be used for just this purpose. The difference between a Local System account and a Network User account is that a Local System account does not have access to network resources under any circumstances. It can access most any resource on the local machine just not resources on other servers.

If you need to do that you will need to create a domain user account and start the services with that domain user account. That user account must also be given the proper access to the resources.

Starting a service with a network user account

To access resources on another server you must first create a new domain user. Typically you will want to create an account specifically designed to use as a service account. Regular user accounts have password restrictions like requiring regular changes to that password. That could be problematic with a service account since each password change would require that you stop all service and change the password or network access will fail because it will be trying to use an expired password.

Once the account has been created go to the Central Configuration Manager on the Business Objects server.

Select the service you want to startup using a user account. Stop the services and double click on it to open the properties page. In this example we are using the Crystal Reports Job Server.

Uncheck “System Account” and type in the user name, password and then confirm the password for the account you just created. Remember to preface it with your domain name.

Click “OK” to close the properties sheet and re-start the service.

To complete the process there are a few more requirements.

1.   The user account MUST be a member of the Administrators group on the local machine

2.   The user account will also have to be granted the following permissions using the Local Policy Editor (found in the User Rights Assignment area of the Local Policies in the Administrative Tools applet on the server)

a.   Act as part of the operating system

b.   Log on as a service

c.   Log on as a batch job

d.   Replace a process level token

Once this is complete you services is ready to access network resources. Don’t forget that the user account must be granted access to that resource for the process to work.

When should I use a user account for start up

The simple answer is “When the service needs access to local resources”, but how do you know when that is? A network resource can be defined as a:

• Shared network folder

• A database that requires network (Active Directory or LDAP) authentication

• Network Printers

That means anytime you want to output a file to the network (Unmanaged Disk), Print a report directly to a printer, store your report files (Repository files) on a file server, log on to a database using a “Trusted” connection. To help you decide we have provided you with a list of the most common services that might need a user account for startup and why. This is not a complete list but does define the most common scenario’s when user accounts will be needed.

Input and Output File Repository Servers

·         When you want to move their root directories to a file server for better backup and fault tolerance

Crystal Reports Job Server

·         When you need to output Crystal Reports to network locations (Unmanaged Disk)

·         When you want to print Crystal Reports to network printers at schedule time

·         When you need to log on to a database using a “Trusted” connection (Active Directory authentication to MS SQL Server for instance) during a scheduled process

Crystal Reports Page Server

·         When you need to log on to a database using a “Trusted” connection (Active Directory authentication to MS SQL Server for instance) during On-Demand viewing of a Crystal Report

Web Intelligence Report Server

·         When you need to output a Web Intelligence document (as PDF or XLS) to a network location (Unmanaged Disk)

·         When you need to log on to a database using a “Trusted” connection (Active Directory authentication to MS SQL Server for instance) during a scheduled process or an On-Demand viewing

Central Management Server

·         When the database server that house the system database or auditing database requires a “Trusted” connection

·         Recommended when using Kerberos authentication for Active Directory integration for users and groups

There may be other occasional situations where other servers may require user account be these are far more rare. The list above is probably sufficient in 80% to 90% of cases. It never hurts to start a service with a user account so, when in doubt, you can always start the server with a user account.

Go to Top  |  Return to Newsletter Contents