LoadGen Director and Analyzer: test results tables created outside the dbo schema cannot be opened by other users

October 16, 2026 11:48

LoadGen Director and Analyzer: test results tables created outside the dbo schema cannot be opened by other users

In this support article we explain why LoadGen Analyzer sometimes cannot open the results of a test that a colleague ran, even though the tables are clearly present in SQL Server, and how a SQL Server administrator resolves it. No change to LoadGen is needed.

Problem

A tester runs a LoadGen test with LoadGen Director. The test completes and the results tables appear in the LoadGen database. When another person creates a datasource for that test in LoadGen Analyzer, the results cannot be read.

Symptoms

In LoadGen Analyzer the table is listed in the datasource dialog, but it shows 0 records, charts stay empty, or the message The data source is not available. Please change the data source settings appears.
The LoadGen Analyzer log contains Invalid object name 'DUAF...' (or the same error for a PM, LBH or SMD table).
In SQL Server Management Studio the tables exist, but they are not under dbo. They carry the name of the Windows account that ran the test as their schema, for example DOMAIN\tester.DUAF202603160930001234 instead of dbo.DUAF202603160930001234.
The person who ran the test can open the same results in LoadGen Analyzer without any problem.
A table created by hand in SQL Server Management Studio by a database administrator lands in dbo as expected, which makes the problem look like a LoadGen issue. It is not.
LoadGen Director may also report SQL errors while writing results when a table with the same name already exists in another user's schema.

Context

LoadGen Director creates its results tables without a schema name. The tables are prefixed DUAF (user actions and transactions), PM (performance counters), LBH (LoadBot health) and SMD (session metadata), followed by the date and time of the test.
SQL Server places a table that is created without a schema name in the default schema of the account that creates it. For a LoadGen database that must be dbo.
When a Windows account reaches the database through an Active Directory group, and that group has no default schema, SQL Server creates a schema named after the user and puts the tables there. Nobody configures this: SQL Server does it automatically the first time that account creates an object. Members of the sysadmin role always map to dbo, which is why a test table created by an administrator does not show the problem.
LoadGen Analyzer stores and queries table names without a schema name. It therefore only finds tables in the reader's own default schema or in dbo. For everyone else the table does not exist.
There is no setting in LoadGen Director or LoadGen Analyzer that controls the schema. The schema is decided entirely by SQL Server and the account that LoadGen Director connects with.

Solution

The fix is done in SQL Server by someone with db_owner rights on the LoadGen database. Run the scripts in SQL Server Management Studio against the LoadGen database.

Step 1: Find the affected tables and accounts

List the LoadGen results tables that are not in dbo:

SELECT s.name AS [schema], t.name AS [table], t.create_date
FROM sys.tables AS t
JOIN sys.schemas AS s ON s.schema_id = t.schema_id
WHERE s.name <> 'dbo'
  AND (t.name LIKE 'DUAF%' OR t.name LIKE 'PM%' OR t.name LIKE 'LBH%' OR t.name LIKE 'SMD%')
ORDER BY t.create_date DESC;

List the database users and groups whose default schema is not dbo. An empty default schema on a Windows group is what triggers the problem:

SELECT name, type_desc, default_schema_name
FROM sys.database_principals
WHERE type IN ('S', 'U', 'G')
  AND name NOT IN ('guest', 'INFORMATION_SCHEMA', 'sys')
  AND ISNULL(default_schema_name, '') <> 'dbo';

Step 2: Move the existing tables to dbo

The script below prints one ALTER SCHEMA dbo TRANSFER statement per table. Review the printed statements first, then remove the comment marker on the last line and run the script again to execute them.

DECLARE @sql nvarchar(max) = N'';

SELECT @sql += N'ALTER SCHEMA dbo TRANSFER ' + QUOTENAME(s.name) + N'.' + QUOTENAME(t.name) + N';' + CHAR(13) + CHAR(10)
FROM sys.tables AS t
JOIN sys.schemas AS s ON s.schema_id = t.schema_id
WHERE s.name <> 'dbo'
  AND (t.name LIKE 'DUAF%' OR t.name LIKE 'PM%' OR t.name LIKE 'LBH%' OR t.name LIKE 'SMD%');

PRINT @sql;
-- EXEC sp_executesql @sql;

Indexes move together with the table.
A transfer fails for a table when a table with the same name already exists in dbo. Rename or drop the duplicate first.
LoadGen Analyzer stores the table name without a schema, so existing datasources work again as soon as the tables are in dbo. No datasource needs to be recreated.

Step 3: Prevent it for the next test

Give the account that LoadGen Director connects with dbo as its default schema. Do this for the Active Directory group and for the database user that SQL Server created automatically during the first test. The automatically created user takes precedence over the group, so changing only the group is not enough.

-- The Windows group through which the testers reach the database
ALTER USER [DOMAIN\LoadGen Testers] WITH DEFAULT_SCHEMA = dbo;

-- The user SQL Server created automatically for the tester
ALTER USER [DOMAIN\tester] WITH DEFAULT_SCHEMA = dbo;

Replace the names in square brackets with the group and user found in step 1.

Step 4: Check the rights of the test account

Creating tables in dbo requires rights on that schema. Without them the next test fails with The specified schema name "dbo" either does not exist or you do not have permission to use it.

The account LoadGen Director connects with needs db_ddladmin, db_datareader and db_datawriter on the LoadGen database. Making it a member of db_owner is the simplest option for a database that only serves LoadGen.
Accounts that only read results in LoadGen Analyzer need db_datareader.

Optional: Clean up

Once the schema named after the user is empty, the administrator can drop that schema and the automatically created database user. This is housekeeping only and is not required for LoadGen to work.

DROP SCHEMA [DOMAIN\tester];
DROP USER [DOMAIN\tester];

Alternative: Use SQL Server authentication for the datastore

This problem only occurs with Windows authentication through a group without a default schema. When the LoadGen Director datastore uses a SQL Server login instead, the login's database user gets dbo as its default schema unless someone changes it, and the tables always land in dbo.

Verify the result

Run the first query of step 1 again. It returns no rows.
Open LoadGen Analyzer, edit or create the datasource, select the table of the test. The record count is greater than 0 and the predefined charts show data.
Run a short test with LoadGen Director and confirm in SQL Server Management Studio that the new tables are created under dbo.

Conclusion

LoadGen Director and LoadGen Analyzer expect the results tables in the dbo schema. When the account that runs the test reaches SQL Server through a Windows group without a default schema, SQL Server silently creates tables in a schema named after that user, and only that user can read them in LoadGen Analyzer. Moving the existing tables to dbo and setting dbo as the default schema for the test account resolves the issue permanently.

If you continue to experience issues, please contact LoadGen support and include the output of the two queries in step 1.