1. Log in to the Replay Server interface.
2. Click the SessionList link.
3. Select a session that was loaded. If no session was loaded, you can use the home page of the interface to load one from your local desktop.
4. Select a session with a link like the following: SessionNNNN_NNNNNNNNNN.
5. Click the NavList link. All pages, their render times, and other information are displayed.
6. Select individual pages to review their rendered HTML, looking for irregularities.
7. You can also check the Page Load Details (PLD) link for each page, where render times and load times are published. Less than 10 seconds for each page is considered a reasonable time.
8. If you see load times that significantly exceed 10 seconds:
   • If the excessive load time applies to a single page, there may be problems with accessing content referenced on the individual page. Check out the references on the page, and try to load them in your browser.
   • If the excessive load times apply to multiple but not all pages, see if you can identify whether the slow times apply to individual servers, which may indicate connectivity or network issues.
   • If the excessive load times apply to all pages on the server, verify that the issue applies to multiple sessions. If so, there may be a problem with Replay Server. Contact Support.

To diagnose this issue, do the following.

1. Replay a session in BBR.
2. Log in as an administrator to the server hosting the Replay Server. Typically, this server is the Portal Server, too.
3. Open a browser window. Navigate to the following:

   
   http://localhost:38000
   

   Note: If you connect from the localhost and if authentication is enabled, you may use ssadmin/ssadmin for the username and password.
4. In the Replay Server interface, click Cache.
5. Review the Cache listing. If you see multiple entries with a byte length of 0 and no content type, then Replay Server is having difficulty communicating with the origin server through the internal Tealeaf proxy.

If the above information is present, then the Replay Server was configured to use WinInet to access the server of origin. This method of connection cannot use a proxy when running with the local system account, which is the default setting for Replay Server. WinInet is configured based on the settings that are used by the Internet Explorer instance on the hosting server. These settings cannot be configured for a service running as the local system account.

To configure the Replay Server to use a named account in the domain:

1. Log in to the server hosting the Replay Server as an administrator.
2. In the Administrator's Control Panels, open the Services panel.
3. Right-click Replay Server and select Properties.
4. Click the Log On tab.
5. Click the This Account radio button.
6. Enter the domain and user name of the named account in the following format:

   
   SomeDomain\SomeUser
   

7. Enter the password twice.
8. Click Apply.
9. Restart the Replay Server service.
10. Configure Internet Explorer: Open the instance of Internet Explorer.
11. Select Tools > Options.
12. Configure a Proxy server for use in Internet Explorer.
    Note: For more information, the product documentation that is accessible through the installed version of Internet Explorer.
13. Clear the IE cache within the browser.
14. Click OK to close the Options window.
    Note: After you configured Internet Explorer, you must restart Replay Server through the Services control panel so that the cache is cleared.
15. To verify configuration, you can test the cache settings by using the following URL. It is processing a static content URL through the Replay Server on the local machine:

    
    http://localhost:38000/GetCacheFile?href=http://www.tealeaf.com/images/
       home/slide-deck-1.jpg
    

16. If the above URL displays an image, then the configuration is working.
17. If not:
    1. Try substituting a different URL after href=, which points to a known static content object on your web application.
    2. If that fails, revisit the configuration settings with your IT staff.

During replay, the response content may be replaced by the following error message:

Page not rendered. Pages that contain AJAX responses with a text/html content 
type or or malformed HTML are not rendered. 

Consider adding a replay rule to remove this page.

If the above message appears, then the Replay Server was unable to properly render the page. There could be a number of different reasons for why the page was unable to be displayed. The simplest solution is to remove the page from replay.

To remove a page from replay:

1. In BBR, right-click the currently selected page in the Navigation List.
2. Select Remove This Page from Replay.
3. When the session next replays for any Tealeaf user, it is skipped during replay.

Use the following procedure to adjust replay screen dimension values so that you can replay sessions that were either captured incorrectly, or that were captured from devices with dimensions smaller than the defined threshold.

1. Go to the Portal\WebApp\js directory and open the file named replayConfig.js.
2. Edit the values in minDeviceWidth and minDeviceHeight
3. Save your changes.
4. Clear the browser cache to view the changes.

By modifying the variables in replayConfig.js, Browser Based Replay is able to replay the session correctly.

Any changes you make to replayConfig.js will not be overwritten if you upgrade to a new version.

If you want to apply the edits made to replayConfig.js to a new release, you can merge the changes in replayConfig.js with the file in Portal\WebApp\CFG.

While there are multiple possible reasons as to why the session cannot be retrieved, the issue may be caused by some of the timestamps in the session data.

When a hit is reassembled by the CX Passive Capture Application, the PCA attempts to locate and generate timestamp information. If this information is malformed or missing, the PCA writes the value 01/01/1970 by default.

When this hit is passed to the Processing Server, the following things happen in the order listed below:

• The session attribute information in the hit is processed and written to the cxReveal search database.
• The hit is written to a session archive file with the above timestamp.
• Once per hour on the hour, the session archive file is purged, as the data in it is considered to be too old for storage in the Processing Server.

So, when a cxReveal user performs a search for this session data, the Search database indicates that the data exists in the Processing Server, yet it might be purged. When cxReveal attempts to access these session files, they are not found because of the bad timestamp values.

To test, complete the following steps:

1. Through TMS, locate the directory where the session files are stored.
2. Near the end of an hour, log in to the Processing Server as an administrator.
3. Navigate to the directory that you found through TMS.
4. Locate any files that contain the 1970 timestamp in their file name. The file name pattern should look like the following:

   
   LSSN_19700101_<hostname>
   

5. Using search, try to retrieve a session from this archive.
6. If you are able to locate these sessions, replay the session through BBR and attempt to ascertain why the timestamp value in the request is corrupted.

   Timestamp information is stored in the [timestamp] section of the request.

For example, suppose some Javascript files are stored behind an authentication server and Tealeaf users do not have access to this server. During replay, any references to these pages fail to retrieve and execute the Javascripts, which can result in many different kinds of issues in replay.

• If the file behind the authentication server is an image file, then the image is missing from the screen in the browser-based or RTV replay.
• By default, Tealeaf does not retain static reference content such as images, stylesheets, and Javascripts, as these items require significant additional storage and rarely change. As a result, Javascripts that are blocked from Tealeaf users cannot be applied during replay, and the effects on replay depend on the functionality of the Javascript.

To correct the replay issue with authentication, you can make one of the following changes:

1. Move the referenced files outside of the authentication server.

   You can place them somewhere within your corporate firewall in a location that is accessible to Tealeaf accounts.

2. Copy the referenced files outside the authentication server.

   If you don't want to make changes to the web application, you can create a copy of the referenced files in an accessible location. From within replay, you can create rules to map to this new location.

   Note: Each time that these files are updated on the live web application, you must make the updates available to Tealeaf when session data begins to reference and require them.

For archived sessions, you may see the following error message:

The session <session number> in Canister LSSN_* cannot be loaded:
LSSN open failure on <Server name>.

1. To fix, you can request the corresponding TLX files from Search Server from the index/Portal machine or the Canister machine, or you can use the Canister session ID to access.
2. If neither of the above works, request the TLC file from the Search Server.
3. If that works, quit Acoustic™ Tealeaf CX and verify that the Acoustic Tealeaf CX Server settings for the two-machine configuration have correct values through the Portal.
4. Try to replay again.