A Configuring Advanced Properties in the Portal Configuration Files

This appendix describes how to modify the portal configuration files.

Oracle WebCenter Configuration Manager

Oracle WebCenter Configuration Manager enables you to manage the configuration settings of Oracle WebCenter products through a user interface rather than having to edit .xml files. This section describes the settings in the Portal Service section of the Configuration Manager.

Setting	Description
Analytics Communication
Enable	Select this option if you want the portal to pass information to Oracle WebCenter Analytics.
Crawler Settings
Web Crawler file timeout (seconds)	Enter the number of seconds you want a web crawler to try to get to a web page before it times out.
SOAP file timeout (seconds)	Enter the number of seconds you want a remote crawler to try to get to a document before it times out.
Gateway
Gateway Enabled	Select this option if you want to allow portal content to be gatewayed.
Gateway temporary directory	Enter the full path to the directory where temporary files will be stored.
Gateway max upload (in bytes)	Enter the maximum file size allowed for uploads.
Gateway min upload (in bytes)	Enter the minimum file size allowed for uploads.
Gateway min streamable (in bytes)	Enter the minimum size of streamable content.
Gateway temporary file pool size	Enter a value that is greater than the number of ASP/JAVA worker threads for the portal.
Logging
Server	Enter the application name that will uniquely identify log messages sent from this application. Oracle WebCenter Logging Utilities will use this string to determine the location from which log messages originate. The application name can be any string that meets the following restrictions: it must not be empty, it must not exceed 128 in length, and it may only contain non-white-space visible ASCII characters and the space character. Most Oracle WebCenter Interaction products follow the naming convention [product-name].[machine-name].[user-name].
Local only	Select this option to limit broadcast of this application's logging messages to only the computer on which this application is installed.
Main Portal Settings
Web home directory	Enter the directory for the Portal's JAR files.
Image Server base URL	Enter the base URL for the Portal's Image Server.
Image Server secure base URL	Enter the base URL for the Portal Image Server running HTTPS.
Image Server connection URL	Enter the base URL that is used when the Portal Server connects to the Image Server to retrieve JSRegistry information. In many configurations this URL is the same as the Image Server Base URL.
Image Server connection URL timeout (seconds)	Enter the timeout for the Image Server Connection URL, in seconds. -1 means do not check during startup. Note that if this is invalid, your portal will not work.
Administrative Portal base URL	Enter the base URL to the Administrative Portal. It is required that absolute URL be used in Security Mode 3.
Temporary file home directory	Enter the temporary files directory to be used by the portal. This should not be Web accessible.
Portal Database
Vendor	Enter the database vendor.
Host	Enter the name of the computer that hosts the database.
User name	Enter the name of the database user.
Password	Enter the password for the database user.
Port	Enter the port number on which the database services requests.
Minimum pooled database connections	Enter the minimum number of pooled connections.
Maximum pooled database connections	Enter the maximum number of pooled connections.
Database Name (Microsoft SQL Server only)	Enter the name of the database.
Portal International Settings
Locale	Enter the default locale for users. Setting it to the string “UseBrowser” causes the portal to derive the locale from the browser's language settings and store it as the user's locale.
Time Zone (numeric value)	Enter the default time zone for the user. If it is -1 then the time zone of the computer on which Portal is deployed is used.
Mandatory Object Language	This setting allows the administrator to set the language for all new objects. If it is blank, the user creating the object can choose the language for the object. If it is not blank, the value will be used as the language for all new and edited objects. The value should be a locale string (for example, it should match the name of a folder under the msgs directory.)
Portal System Properties
Server name	Enter the name of the portal server or virtual load-balanced server (for example, the main load balanced server name: portal.mycompany.com).
Machine name	Enter the machine name (for example, the physical name of the individual portal server machine behind the load-balancer: portalserver1243).
Performance comments	This setting specifies whether the performance comments in the HTML source are enabled. 0 means the comments and stacktraces are disabled. 1 means the comments and stacktraces are enabled. 2 means the comments are enabled but stacktraces are disabled. 3 means the comments are disabled but stacktraces are enabled.
Debugging mode	This setting specifies whether debugging features are enabled. This is disabled by default. You can enable this to debug portal startup issues, especially if you have made customizations to XML files. Make sure to set to disable debugging when you are done troubleshooting. 1 means debugging is enabled. 0 means debugging is disabled.
Doctype specification	1: none, 2: HTML 3.2, 3: HTML 4.0 Transitional, 4: HTML 4.0 Frameset, 5: HTML 4.0 Strict. Note that neither the portal nor any other Oracle WebCenter Interaction product has been verified to support either the transitional or strict document type specification. By default the portal does not include a specific doctype declaration in its HTML because doing so would limit the display of portlets in which the doctypes were invalid or inconsistent with the portals declared doctype. If you are confident that all your portlets adhere to a particular doctype you should set that document type here.
Adaptive layout mode	Enter a numeric value indicating whether or not page and/or portlet layout modes are enabled. Both are enabled by default. 0 means layout mode is disabled. 1 means page and portlet layout modes are enabled. 2 means page layout mode is only enabled. 3 means portlet layout mode is only enabled.
Virtual directory path	Enter the virtual directory path. It is typically /portal/.
HTTP entry point	Enter the portal main Servlet mapping name. This has to be the same has the mapping name for HTTPInterpreter in web.xml. It is typically server.pt.
HTTP Port	Enter the port number for the Portal running HTTP.
HTTP Secure Port	Enter the port number for the Portal running HTTPS.
SSO virtual directory path	Enter the SSO Virtual directory path. It is typically /portal/.
SSO servlet name	Enter the SSO Servlet mapping name. This has to be the same has the mapping name for SSOLoginPage in web.xml. It is typically SSOServlet.

Configuring Portal Settings Using the Portal Utility

If host names or IP addresses change after your initial deployment, you can use the Portal Settings Utility to modify portal URLs.

To access the Portal Setting Utility you must be a member of the Administrators Group.

Click Administration.
From the Select Utility list, choose Portal Settings.
Modify the portal URLs as needed.
Click Finish.

Modifying the portalconfig.xml File

If your configuration requirements change after initial deployment, you can modify the portalconfig.xml configuration file located in the PT_HOME/settings/portal directory. PT_HOME is the Oracle WebCenter installation directory, for example, C:\bea\alui or /opt/bea/alui.

URLMapping

The URL mapping determines the portal base URL according to the requested URL from the request object. The portal base URL is the base URL for every single link and redirection. For example, if your portal base URL is: http://portal.company.com/portal/server.pt, then the link to the default My Page would be: http://portal.company.com/portal/server.pt?space=MyPage.

You can add as many entries as you want to the mapping. Mapping URLs should start with http:// or https:// and end with the HTTP entry point name (unless it's the default value, “*”).

Note:

If requests will come from both an http URL and an https URL you must create a separate mapping for each one. Then map each of these request URLs to an application URL and a secure application URL.

ApplicationURL0: In SecurityModes 2 and 3, ApplicationURL should be set to the same value as SecureApplicationURL. In mode 0, ApplicationURL0 might be equal to “*”. In this case, the Application Base URL will be the URL from the Request object.
SecureApplicationURL0: In SecurityMode 0, SecureApplicationURL is not used. In modes 2 and 3, SecureApplicationURL0 might be equal to “*”. In this case, the Application Base URL will be the URL from the request object.

PersonalSettings

The following configuration parameters apply to personal settings.

Parameter	Description
Greeting	The default greeting for the user. If a user wishes to override this greeting, then they can do so by changing their personal settings.
Accessibility	The default portal interface type. 1: Assistive Technology Portal (508 Compliant) 2: Low Bandwidth Portal 3: Standard Portal
OverrideGuestAccessStyle	Override the guest user access style (from the DB) with the Accessibility value above. 0: The portal will use the DB value. 1: The portal will override the DB value with the value from this file.

CachedSettings

The following configuration parameters apply to cached settings.

Add entries for personal settings that should be cached on the http session of each user. Personal settings that are not included in this list will be retrieved from the portal every time they are requested. Settings that are on this list are obtained from the portal on login and are cached for the duration of the user's http session.

Note:

AccessStyle, Locale, and TimeZone should always be cached by the server.

Users can customize these settings by clicking My Account in the portal interface.

The following settings are cached by default:

Parameter	Description
Greeting	Stores the personalized greeting that displays on the portal banner when the user logs into the portal.
AccessStyle	Stores the user display option.
Locale	Stores the preferred language of the portal interface. Portlet names and content display in the selected language only if the language is supported by the portlets. It also stores the format for portal entries (including search requests). For example, if the user chose British English, the portal displays and expects dates in the DD/MM/YYYY format (whereas in American English, the portal displays and expects dates in the MM/DD/YYYY format).
TimeZone	Stores the time zone of the user.
PortletTimeout	Stores the maximum time to wait for a portlet to load.
CollapsedGadgets	Stores which portlets were minimized by the user.
COMCollapsedGadgets	Stores which portlets in the community page were minimized by the user.
MyPageRefreshRate	Stores the refresh rate of user My Pages.

Authentication

The following configuration parameters apply to authentication.

Parameter	Description
AllowGuestAccess	Allow the guest user to access the portal. If guest access is not allowed, the portal will always prompt for login information.
GuestRedirectToLogin	If the guest user does not specify a space in the URL query string, this setting determines the initial page the user sees. Users can navigate to different portal pages by including `space=xxxx` strings in the URL query string. For example, if the user were to type: `http://MYSERVER/portal/server.pt?space=MyPage`, the user will be directed to the My Page (the access privileges of that page will be in effect). However, if the user did not include a `space=xxxx` string in the query string (that is, the user only typed: `http://MYSERVER/portal/server.pt`), the portal directs them to a default page, depending on the GuestRedirectToLogin setting and the experience definition settings, as follows: 0: The portal will redirect the guest user to the home page defined in the current experience definition (usually a My Page or community page). 1: The portal will redirect the guest user to the login page as defined in the current experience definition.
RedirectOnLogout	After logging out the user is redirected to a default page as follows: 0: The portal will redirect the guest user to the home page defined in the current experience definition (usually a My Page or community page). 1: The portal will redirect the guest user to the login page as defined in the current experience definition.
AuthTokenExpiration	This setting allows you to set how long the portal remembers your login password after doing an HTTP Basic Authentication for WebDav. The value should be formatted in minutes and is defaulted to 30 minutes. Entering 0 will disable the cookie from being set.
AllowDefaultLoginPageAuthSource	Controls the use of the default authentication source for portals (that do not use single sign-on) on the login page and Login Portlet. It also lets you configure the authentication source list.
DefaultAuthSourcePrefix	Sets the default authentication source prefix that will be prepended to the login name when users log into your system, unless they select another authentication source from the list on the login page. In the case of SSO, this is the authentication source category for all of your SSO users. You can use AuthSourcePrefix tags to order the items in the authentication source list. Entries in the list should look like the following: <AuthSourcePrefix[i] value="Auth Source Prefix"> </AuthSourcePrefix[i]> Where [i] is replaced with the items' order in the list (starting with 1). To include the WCI Authentication Source in the list, simply make an entry with “WCI Authentication Source” as the value. The WCI Authentication Source is for users who are created in the portal, manually, through invitations, or through the Create an Account page. For example, to include the WCI Authentication Source as the third item in the list, use the following tag: <AuthSourcePrefix3 value="WCI Authentication Source"> </AuthSourcePrefix3> Authentication source prefixes in the ordered list are displayed first in the list and are followed by any authentication sources not included in the ordered list. Authentication Source Modes: 0: This is the default mode. In this mode the portal does not use the default authentication source, and the list has no special ordering. 1: In this mode the portal uses the default authentication source, and the list is hidden, but there is a link users can click to show the list. This lets users select a non-standard authentication source. To use this mode, you must turn off the caching on the Login Portlet or disable the Login Portlet and set the `DefaultAuthSourcePrefix` tag to the prefix of the authentication source that is the default for all users. 2: In this mode the portal uses the default authentication source, and the list is shown with the default authentication source selected. To use this mode, you must turn off the caching on the Login Portlet or disable the Login Portlet and set the `DefaultAuthSourcePrefix` tag to the prefix of the authentication source that is the default for all users. 3: In this mode the portal uses the default authentication source, and the list is unavailable.
AllowAutoConnect	Setting for saving passwords in cookies. 0: Turns off the option of saving passwords in a cookie. 1: Users will see a “Remember my password” check box on the login page of your portal. Passwords are saved as cookies for users that select this check box, which lets users who navigate to your portal be logged in automatically.
SSOVendor	Sets the single sign-on configuration. For information on SSO, see Deploying Single Sign-On.
CaptureBasicAuthenticationForPortlets	Determines whether or not to capture basic authentication information (login and password) and store it in the session (to send to portlets). The basic authentication information cannot be captured when users select “Remember my password” to login via a cookie. 0: The authentication information will not be stored in the session. 1: The authentication information will be stored in the session.
RememberPassword	This setting allows you to set how long the portal remembers your login password. The value should be formatted in minutes. The default is one week.
BrowserLoginTokenExpiration	This setting allows you to set whether or not the portal caches a login token in a browser session cookie that will expire when the browser is closed. Entering 0 will disable the cookie from being set, and is the default value. Entering a positive number controls how long the login token will remain valid. Note that the cookie is only valid as long as the browser is open, so if the user closes their browser, the login token will be removed. The login token expiration is an upper limit if they don't close their browser. A reasonable value for this would be 600 minutes (one workday). The value should be formatted in minutes. Note: The BrowserLoginTokenExpiration setting is only active when AllowAutoConnect is set to 1.

Security

The following configuration parameter applies to security.

Parameter	Description
SecurityMode	This setting determines which pages will use SSL encryption. You must install a digital certificate and enable SSL on your Web server before changing the default value of 0. Note: Changing the security mode affects the URL Mapping. For more information, see Chapter A, "Configuring Advanced Properties in the Portal Configuration Files." 0: The portal does not check the security of incoming requests. In mode 0, ApplicationURL0 and SecureApplicationURL0 may be equal to “”. In this case, the Application Base URL will be the base URL from the Request object. 1: Selected pages that involve sensitive information such as passwords use SSL, while other pages are sent unencrypted for better performance. Only pages of Activity Spaces listed in SecureActivitySpaces.xml (which is located in the same folder as portalconfig.xml) are sent through HTTPS. The portal verifies that links and redirections to Secure Activity Spaces uses HTTPS. If a secure Activity Space were requested through a non-secure URL, the portal would redirect the same request to HTTPS. If XPRequest.GetRequestURL() is equal to URLFromRequest0, ApplicationURL0 and SecureApplicationURL0 might both be the Application Base URL, depending on the security of the Activity Space. You must install a digital certificate and enable SSL on your Web server. 2: Every page uses SSL.The portal verifies that every single incoming request uses HTTPS. If it does not, the portal will redirect this request to HTTPS. This setting is best for very secure applications where performance is not a major concern. If the URL from the Request object is equal to URLFromRequest0, SecureApplicationURL0 will be the Application Base URL. URLFromRequest0 has to be equal to “”. This is the default entry. It will be used if no mapping entry matched the URL from the Request object. You must install a digital certificate and enable SSL on your Web server. 3: Select this mode if you are using an SSL Accelerator. Because the portal is behind an SSL Accelerator, the security of the incoming requests is not verified. The portal trusts every request from the SSL Accelerator. All the links and redirections are in HTTPS. If URL from the Request object is equal to URLFromRequest0, SecureApplicationURL0 will be the Application Base URL. URLFromRequest0 has to be equal to “*”. This is the default entry. It will be used if no mapping entry matched the URL from the Request object. You must install a digital certificate and enable SSL on your Web server.

Parameter

Description

SecurityMode

This setting determines which pages will use SSL encryption. You must install a digital certificate and enable SSL on your Web server before changing the default value of 0.

Note: Changing the security mode affects the URL Mapping. For more information, see Chapter A, "Configuring Advanced Properties in the Portal Configuration Files."

0: The portal does not check the security of incoming requests.

In mode 0, ApplicationURL0 and SecureApplicationURL0 may be equal to “*”. In this case, the Application Base URL will be the base URL from the Request object.
1: Selected pages that involve sensitive information such as passwords use SSL, while other pages are sent unencrypted for better performance.

Only pages of Activity Spaces listed in SecureActivitySpaces.xml (which is located in the same folder as portalconfig.xml) are sent through HTTPS.

The portal verifies that links and redirections to Secure Activity Spaces uses HTTPS. If a secure Activity Space were requested through a non-secure URL, the portal would redirect the same request to HTTPS.

If XPRequest.GetRequestURL() is equal to URLFromRequest0, ApplicationURL0 and SecureApplicationURL0 might both be the Application Base URL, depending on the security of the Activity Space.

You must install a digital certificate and enable SSL on your Web server.
2: Every page uses SSL.The portal verifies that every single incoming request uses HTTPS. If it does not, the portal will redirect this request to HTTPS. This setting is best for very secure applications where performance is not a major concern.

If the URL from the Request object is equal to URLFromRequest0, SecureApplicationURL0 will be the Application Base URL.

URLFromRequest0 has to be equal to “*”. This is the default entry. It will be used if no mapping entry matched the URL from the Request object.

You must install a digital certificate and enable SSL on your Web server.
3: Select this mode if you are using an SSL Accelerator. Because the portal is behind an SSL Accelerator, the security of the incoming requests is not verified. The portal trusts every request from the SSL Accelerator. All the links and redirections are in HTTPS.

If URL from the Request object is equal to URLFromRequest0, SecureApplicationURL0 will be the Application Base URL.

URLFromRequest0 has to be equal to “*”. This is the default entry. It will be used if no mapping entry matched the URL from the Request object.

You must install a digital certificate and enable SSL on your Web server.

Documents

The following configuration parameters apply to documents.

Parameter	Description
NewDocumentTime	The number of days that a document or folder displays “new” after its name.
DocumentLastUpdated	The number of days that a document displays “updated” after its name.
OpenNewWindow	The default setting for the open in new window preference. 0: The document opens in the same window. 1: The document opens in a new window. Users can override this setting by changing their personal preferences.
SubFolderBrowseThroughSearch	This parameter sets the Subfolder Browsing source. 0: Subfolder browsing is driven through the database. 1: Subfolder browsing is driven through search. Note: Database driving browsing may often be faster for subfolders, while search may be faster for documents.

Crawlers

The following configuration parameter applies to content crawlers.

Parameter	Description
MaxWebCrawlRadius	The setting for the maximum number of links away from the target page that you want to crawl. For example, if you select 1, the content crawler attempts to import every page directly linked to the target page; if you select 2, the content crawler attempts to import every page directly linked to the target page, and every page directly linked to those linked pages. This setting corresponds to the Crawl Radius list in the Web Content Crawler Editor. The default maximum is 4, which means the list allows a crawl radius of 1 to 4.

Parameter

Description

MaxWebCrawlRadius

The setting for the maximum number of links away from the target page that you want to crawl. For example, if you select 1, the content crawler attempts to import every page directly linked to the target page; if you select 2, the content crawler attempts to import every page directly linked to the target page, and every page directly linked to those linked pages. This setting corresponds to the Crawl Radius list in the Web Content Crawler Editor. The default maximum is 4, which means the list allows a crawl radius of 1 to 4.

Search

The following configuration parameter applies to search.

Parameter	Description
NumSearchResultsPerPage	The default number of search results to show per search results page.

Style

The following configuration parameter applies to style.

Parameter	Description
StyleSheetName	The name for the portal's default stylesheet.

Communities

The following configuration parameters apply to communities.

Parameter	Description
DefaultCommunityID	Configure this setting only if your navigation scheme is Tabbed Section Left Vertical Navigation or if you use a custom navigation scheme that uses the IPluggableNavModelRO.GetDefaultCommunity() method. In these cases, the setting specifies the ID of the default community to display when a user clicks the Community tab.
CommKnowledgeDirLinksPerPage	The number of links to display on one screen in the community Knowledge Directory.

Administration

The following configuration parameters apply to administration.

Parameter	Description
IsAdminSite	Determines whether the computer is an administrative portal or a browsing-only portal. 0: Sets the computer into a browsing-only portal. 1: Sets the computer into a browsing and administrative portal.
AdminObjectsPerPage	Determines the number of administrative objects of a single type (for example, content crawlers or content sources) allowed to display on one screen. This controls the number of items displayed on the administrative interface. The default is 10.
MaxResultsToDisplay	This setting is currently used only by Group editor, to set the maximum number of users to display.

Invitations

The following configuration parameter applies to invitations.

Parameter	Description
IsInvitationURLSecure	Sets the security of the invitation URL. Note: Use a secure URL only if you disable http. 0: Unsecure. The URL uses http://. You can use an unsecure invitation URL with any security mode, so long as you do not disable http or have http URLs redirect to https. 1: Secure. The URL uses https://. If the SecurityMode setting in your portalconfig.xml file does not allow http, you must select this mode.

Parameter

Description

IsInvitationURLSecure

Sets the security of the invitation URL.

Note: Use a secure URL only if you disable http.

0: Unsecure. The URL uses http://. You can use an unsecure invitation URL with any security mode, so long as you do not disable http or have http URLs redirect to https.
1: Secure. The URL uses https://. If the SecurityMode setting in your portalconfig.xml file does not allow http, you must select this mode.

Gateway

The following configuration parameter applies to gatewayed URLs.

Parameter	Description
PutUserIDInURL	This setting controls if the user ID should be part of the gateway URLs or not. 0: User ID in the gateway URL is always set to 0. 1: User ID in the gateway URL contains real user ID. Note: HTTP caching proxies will work better if userid is not part of the URL.

Parameter

Description

PutUserIDInURL

This setting controls if the user ID should be part of the gateway URLs or not.

0: User ID in the gateway URL is always set to 0.
1: User ID in the gateway URL contains real user ID.

Note: HTTP caching proxies will work better if userid is not part of the URL.

Navigation

The following configuration parameter applies to navigation.

Parameter	Description
intMyPortletPrefButtonInPortletHeader	This setting controls if the My Portlet Preference button on is displayed in portlet headers. 0: Button is displayed. 1: Button is not displayed.

Customizing the Tokens in Friendly URLs

By default, the portal areas are represented by the following tokens in friendly URLs: mypage, community, user, directory, document, and gw. However, the portal administrator can change these tokens to fit the needs of the company.

Open the following file in a text editor: Install_Dir\bea\alui\settings\portal\FriendlyURLs.xml.

For example: C:\bea\alui\settings\portal\FriendlyURLs.xml or /opt/bea/alui/settings/portal/FriendlyURLs.xml
Edit the <key> values as desired.

You can change the following tokens:
- mypage — represents a My Page object
- community — represents a community object
- user — represents a user
- directory — represents a Knowledge Directory folder
- document — represents a document
- gw — represents gatewayed object
For example, you might change the token for directory to “folder” as in the following code:
```
<FriendlyURLMapping>
<key>folder</key>
<classId>17</classId>    
</FriendlyURLMapping>
```
This would mean that users could access Knowledge Directory folders through a friendly URL in the format: http://portal.company.com/portal/server.pt/folder/object_name/[object_id]

Disabling Friendly URLs

By default, you can direct users to portal areas with simple URLs, referred to as friendly URLs. However, you can disable friendly URLs for your deployment if you want to.

Open the following file in a text editor: Install_Dir\bea\alui\settings\portal\FriendlyURLs.xml.

For example: C:\bea\alui\settings\portal\FriendlyURLs.xml or /opt/bea/alui/settings/portal/FriendlyURLs.xml
Comment out any FriendlyURLMapping you want to disable.

For example, you can disable friendly URLs for Knowledge Directory folders by commenting out the following code:
```

```

Friendly Gateway URLs

Gatewayed content is displayed with an URL that makes it easy to read and extract information from.

Gatewayed URLs include several tokens to make it easier to determine where the gatewayed content came from.

Here is an example of a part of a gatewayed URL: ../gw/ws2000_c230_u1/..

The first part of the gateway URL is the gateway token — gw

Note:
Your portal administrator can customize this token in the FriendlyURLs.xml file. For information on customizing friendly URL tokens, see Customizing the Tokens in Friendly URLs.
The second part of the URL specifies where the content came from:
- If the content came from a web service, like in our example, you see ws followed by the web service ID.
- If the content came from a portlet, you see pt followed by the portlet ID.
The remaining parts of the URL specify any additional parameters, separated with underscores (_):
- If there is a community parameter, you see c followed by the community ID.
- If there is a page parameter, you see p followed by the page ID.
- If there is a preference parameter, you see r followed by the preference ID.
- If there is a user parameter, you see u followed by the user ID.

About Fine-Tuning the Search Service Configuration

The installer sets most Search Service configuration parameters to useful defaults. In addition to the default configuration file, the Install_Dir/ptsearchserver/10.3.0/config directory includes template configuration files for Search Service deployments.

The templates include settings appropriate for a number of operating systems and RAM configurations. RAM determines the recommended maximum number of documents in the search collection, and this collection size determines many of the settings in the template configuration files. Examine the contents of these files, choose the one appropriate for your deployment, and rename the template node.ini (the active configuration file).

Note:

If the Search Service component resides on the same host computer as other portal components, consider using a template tuned for a smaller amount of memory to prevent system paging that adversely affects Search Service performance.

In some cases you might be able to further improve performance by modifying some of the values in the node.ini file. This section includes the following sections that describe the parameters in node.ini:

Default Search Service Parameters
Optional Search Service Parameters

Default Search Service Parameters

The following parameters appear in node.ini by default.

Parameter	Description
RFINDEX	Directory used to store Search Service index files. By default, the installer puts these files in the `Install_Dir/ptsearchserver/10.3.0/index` subdirectory. The directory should have sufficient space for the collection you are indexing. You should not change this parameter unless you move your index files or are instructed to do so by customer support.
RFPORT	Port that the Search Service uses for communication with other processes (mainly the portal). The installer prompts for this port number during installation. This value displays in the Search Service Manager, on the Host Settings page. If you change this value in `node.ini`, you must also change the value in the Search Service Manager or the portal will malfunction.
RF_MAPPING_TOKEN_CACHE_SIZE	Specifies the size of the cache of mapping tokens. These tokens represent thesaurus and Best Bets entries read from the mappings collection. The default value is 5000. This parameter is chosen in the configuration file templates to reflect the expected number of tokens associates with the maximum supported collection size. The value of this parameter does not have a large effect on Search Service performance. Each cache element is 120 bytes in size, so the default mapping cache will occupy 600 kilobytes of memory.
RF_LOG_VERBOSITY	Numeric parameter that determines how much information is logged in the Search Service logs. Values range from 0 to 5. The default is 3 (high verbosity). You generally do not need to change this parameter. We recommend you not set this below 3. If RF_LOG_VERBOSITY is set below 3, the reports generated by the Search Log Analysis external operation (and viewable on the Search Results Manager) will not contain all of the information needed to support log analysis.
RF_DOCUMENT_TOKEN_CACHE_SIZE	Numeric parameter that specifies the size of the cache of document tokens. These tokens are words from the actual indexed content in the Search Service. The default value is 250000. This parameter has a significant effect on Search Service indexing and query performance, with larger values providing better performance. This parameter is chosen in the configuration file templates to reflect the expected number of tokens associates with the maximum supported collection size. Each cache element is 120 bytes in size, so the default document token cache occupies 29 megabytes of memory.
RF_SPELL_TOKEN_CACHE_SIZE	Numeric parameter that specifies the size of the cache of spelling tokens. These tokens are word fragments from the spelling data derived from the indexed content. The default value is 250000. This value does not need to be larger than the number of tokens in the spell collection, and it does not need to exceed the value in the configuration file templates provided in the `config` directory. This parameter has a significant effect on indexing performance, spell checking, and wild card queries. If these operations seem particularly slow, you can increase the value specified by this parameter. In practice, values larger than 1000000 provide diminishing return while consuming significant amounts of memory. Each cache element is 120 bytes in size, so the default spell cache occupies 29 megabytes of memory.
RF_INDEX_CACHE_BYTES	Numeric parameter specifying the size of the index cache in bytes. The default value is 78643200 (75 megabytes). The value of this parameter has a significant effect on Search Service query performance. The index and docset (see RF_DOCSET_CACHE_BYTES) caches should be made as large as possible while leaving sufficient memory available for the Search Service's other needs.
RF_DOCSET_CACHE_BYTES	Numeric parameter specifying the size of the document cache in bytes. The default value is 2614400 (25 megabytes). The value of this parameter has a significant effect on Search Service query performance. The index and docset (see RF_INDEX_CACHE_BYTES) caches should be made as large as possible while leaving sufficient memory available for the Search Service's other needs.

Optional Search Service Parameters

Optionally, if advised by customer support, you can add the following values to the node.ini file.

Parameter	Description
RFLOG	Directory where the Search Service writes its logs. The default is the `SearchServerInstall/logs` subdirectory. Edit this value only if you change this directory; the new directory must exist and must be writable by the Search Service.
RF_HIGH_PRIORITY	If this parameter is set to any value, Search Service attempts to increase its process priority over that of other processes. This is not normally necessary, but might be useful on a computer where other processes compete for resources with the Search Service.
RF_MAX_WILDCARD_EXPANSIONS	When a user enters a query that uses a wildcard (for example, “plum”), this parameter determines the maximum number of terms into which the wildcard is expanded (for example, plum, plums, plumber). The default is 100 terms. This limit keeps overly general queries (“ing”) from expanding into a huge number of terms and consuming too much time and memory. In large installations, you might need to increase this value.
RF_MAX_QUERY_MSECS	Maximum time, in milliseconds, for user queries. The default is 10000 (ten seconds). After processing the query for this much time, the Search Service returns results it has found so far. You might want to lower the value of this parameter if end users complain that ten seconds is too long to wait for query results.
RF_MAX_TOTAL_RESULTS	Maximum number of results returned by a query. The default is 10000. You do not generally need to change this parameter because the portal displays fewer results than the Search Service maximum.
RF_MAX_NUM_STATIC_ARCHIVES	Maximum number of static archives per collection created in the index directory. The default is 50; this means that there will be up to 50 archive.NNN.docset files (where NNN is a number), archive.NNN.index files, and so on. There can also be up to 50 spell.NNN.docset files, spell.NNN.index files, and so forth. You do not generally need to change this parameter; the only reason might be an operating system (such as Solaris 2.6) that does not allow the Search Service to use enough file descriptors to open all the files at once. Lowering this number causes archive merges to use more memory and disk space.
RF_QUERY_THREADS	Number of threads to dedicate to query processing. The default is 8. You might need to increase this parameter if your Search Service is under heavy load. The value should represent the expected number of simultaneous queries. If this value is too low, incoming queries will wait on a queue for the next free query thread and users will experience longer query times (possibly several seconds).
RF_QUERY_QUEUE_SIZE	When all Search Service query threads (see RF_QUERY_THREADS) are busy, incoming query requests are placed on a queue to wait for the next available query thread. This parameter determines the length of that queue. The default value is 20 and usually does not need to be changed. Should the query queue ever become full, additional query requests are rejected and a message is written to the Search Service logs. If this happens, you can increase RF_QUERY_QUEUE_SIZE.
RF_INDEX_THREADS	Number of threads to dedicate to indexing requests. The default is 2. You might need to increase this parameter if the indexing performance of your Search Service is too low. However, devoting additional system resources to indexing will reduce query performance. Ideally, the value of RF_INDEX_THREADS should not exceed the number of CPUs on the system.
RF_INDEX_QUEUE_SIZE	When all Search Service index threads (see RF_INDEX_THREADS) are busy, incoming index requests are placed on a queue to wait for the next available index thread. This parameter determines the length of that queue. The default value is 20. To estimate a good value, add the number of threads in all content crawlers that might be running simultaneously (you can request up to four threads when setting up a content crawler). To be conservative, make your estimates high. If this parameter is too low, content crawlers can fill the index queue and the Search Service rejects additional index requests until the queue has room for more requests. Note: It is better to schedule nonoverlapping crawls than to set a high value for RF_INDEX_QUEUE_SIZE; consider changing the crawl schedule before modifying this parameter.
RF_HANDSHAKE_THREADS	Number of threads to dedicate to servicing incoming socket connections. The default is 5. This value should never need to be changed.
RF_HANDSHAKE_QUEUE_SIZE	Socket connections from Search Service clients are placed on this queue to await acknowledgement by one of the handshake threads (see RF_HANDSHAKE_THREADS). This parameter determines the length of that queue. The default value is 20. Once successfully acknowledged, the connections are assigned to either the query or index queue. Under exceptionally high loads, this queue might fill up and the Search Service will reject new connections until the queue has room for more requests. Should this happen, you can increase the value of this parameter.
RF_TOKEN_LEXICON_REBUILD_LIMIT	Maximum lexicon size, measured in number of tokens, to rebuild automatically. If the Search Service detects that the lexicon was closed improperly, the lexicon is rebuilt as part of the startup process. This can be time consuming. The default value is 400000, ensuring that the rebuild requires no more than a few minutes. Larger lexicons needing repair must be rebuilt with the standalone examinearchive utility. You might change the value or set it to zero to allow automatic rebuild of arbitrarily large lexicons. In Windows Systems: Setting this value too large can result in error dialogs being posted by the Windows Service Control Manager when the Search Service is run as a Windows service and a lexicon rebuild is performed. These error dialogs indicate that the service is failing to start in a timely manner. They can be disregarded.
RF_USE_DATA_FILE_CACHE	Numeric parameter indicating whether the Search Service should use caches when accessing index and document data. A value of zero disables the caches and causes the Search Service to use memory-mapping. A nonzero value activates the caches. The default value is 1. We strongly recommend you do not change this value. This parameter serves as the master on/off switch for RF_INDEX_CACHE_BYTES, RF_DOCSET_CACHE_BYTES, RF_INDEX_CACHE_MAX_PAGES_PER_BLOCK, and RF_DOCSET_CACHE_MAX_PAGES_PER_BLOCK. When RF_USE_DATA_FILE_CACHE is zero, these other parameters have no effect. Disabling the caches for small search collections (less than 1 gigabyte of data) might provide a slight improvement in performance depending upon the amount of available physical memory on the Search Service host. In memory-mapped mode, the Search Service fails if the index and document data, plus the Search Service's internal data structures should exceed 2 or 3 gigabytes (depending upon the operating system configuration).
RF_REQUIRED_DISK_SPACE	Amount of disk space (in KB) required to start a dynamic index merge. When merging dynamically indexed data into the search collection, the Search Service verifies that this amount of free space is available on the volume containing the search collection. If the space is not available, the merge process aborts, the Search Service enters read-only mode, and further dynamic indexing requests are rejected. The default value for this parameter is 40000 and should not need to be changed.

When you modify cache settings, keep the following important values and relationships in mind:

An RF_DOCSET_CACHE_BYTES:RF_INDEX_CACHE_BYTES ratio of 1:3 has been empirically determined to provide near-optimal cache performance for typical search collections.
Token cache entries occupy 108 (32-bit platforms) or 120 (64-bit platforms) bytes.
Reasonable values for RF_MAPPING_TOKEN_CACHE_SIZE are 500 to 10000.
For performance reasons, document offsets and index offsets data is accessed via memory-mapping, regardless of the setting of RF_USE_DATA_FILE_CACHE in the node.ini file. This means that the memory footprint of a running Search Service depends on the size of the search collection, and this consideration has been calculated in the settings for the configuration file templates in the config directory. The amount of memory needed for these mappings can be calculated approximately as (Size of *.docsetOffsets files in bytes) + 0.006 * (Size of *.index and *.key.index files in bytes).
Leave sufficient address space (and, ideally, physical RAM) available for the number of query and index threads. Allow 10 MB per query thread (see RF_QUERY_THREADS) and 50 MB per index thread (see RF_INDEX_THREADS).