Version: On prem: 15.0.2

Troubleshooting

Our Troubleshooting docs will help you solve any issues you might walk into while using Omada Identity. Expand the relevant section and read on a solution to your problem.

How to add a link to start a process?

You can add a direct link from an email or CMS to start a process with default values selected. You can use this, for example, to start a process to request access for a specific resource.

Follow these steps to add a link to starting a process:

Use a template activity to add a link using a QUERYSTRING parameter ACTTEMP.
Then, you can also specify a DEFAULTPROPVALUES parameter in the following format:

[Property System Name]:[Value Guid];[Property System Name]:[Value Guid]

You can only specify reference properties.

Look at the following example:

main.aspx?ACTTEMP=18c35f1b-e9ed-4ac7-9f77-9db7dd36df4d&DEFAULTPROPVALUES=ROLETYPEREF:E943A059-ADAB-4C41-8696-B4DEE40F31D3

The ACTTEMP parameter is the UID of the first Activity in the process template. You can find the UID by holding down CTRL + mouse right-click on the activity template details page, then click Form Data UID.

Import incomplete state (!4500), how to solve it?

If an import is incomplete for some reason (such as dtexec.exe being stopped), you cannot restart the import because the status is still shown as running in Omada Identity.

To get the import back into a usable state:

In the odwRun table in Omada Identity Data Warehouse, change the status from Running to Failed.
Go to Omada Identity and configure that the Status field on the import run as .dot. Make sure that the field is not set to read-only.
Edit the JavaScript for the form to allow manual editing of fields.

RoPE timeout when cloning or importing environments, how to solve it?

When cloning or migrating an environment, RoPE can get blocked the first time it runs, when trying to get all the data from Enterprise Server and Omada Data Warehouse. To solve this, Omada recommends to set the QueuingWatermark_ODW setting inside the RoPE tblSettings to the current date and then recalculate all identities. This gives RoPE time to catch up with the data from Omada Data Warehouse.

No provisioning claims

Check that you installed the Enterprise Server Integration feature.
Make sure that the omada.ops.service.exe.config file points to the correct web URL for the Enterprise Server website.
Make sure that you have added the service account that runs the Omada Provisioning Service Windows Service as a user in the Enterprise Server.

Failed to update mapper configuration

This error can occur when you push the configuration from the Enterprise Server to Omada Provisioning Service.

When you push the configuration, OPS validates that properties used in the task mapping are also available in the involved objects. If they are not available, an error appears that is similar to this one:

The error message states that the task mapping named ROPE Account to AD User references a property named ROPE_ATTR_FIRSTNAME, which is not available.

This often happens because the attribute set used on the resource type does not contain a firstname attribute.

No classes found with nameOrTypename

This error is a consequence of an extension assembly not being loaded correctly.

For information on how to resolve the issue, see next section: Extension loader failed to load extension.

Extension loader failed to load extension

If this error message appears, the assembly containing OPS extensions has not been loaded. This could be due to missing referenced assemblies. If your extension references third-party assemblies, copy these to the service folder as well.

If you downloaded the assembly from the Internet/webmail, this error message might appear:

Example

An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework.

This means that the assembly is blocked. To unblock it, right-click the assembly, select Properties, and then Unblock.

Unable to obtain the ODW import lock

If you attempt to run an import while another import is already running on the same database, the system aborts the attempt to run the new import and shows you an error message similar to the one below:

Unable to obtain the ODW Import lock. This means a previously started ODW Import is either already running or has been terminated in an irregular manner. The import holding the lock left the following string: "Omada ODW Import started by ATT2010\Administrator on ATT2010 at 04-09-2012 15:53:32"

In this example, starting new imports is being blocked by the import which was started using the user account ATT2010\Administrator on the machine ATT2010 and at the specified time.

Usually this is because that specific import is still running, and any new imports are to wait until it finishes. But it is also possible that the import that holds the lock has been terminated in an unexpected manner - the process running it might have been killed or some other critical error could have occurred, resulting in the lock not being released.

When that happens, the lock must be released manually before any new imports can be run. This is done by executing the stored procedure ReleaseImportLock in the main Omada Identity Data Warehouse database.

To execute this stored procedure:

Go to Setup > Administration > Connectivity... > Import profiles.
If any import is running, click the three-dot menu and choose Reset Import Status.
A warning will be displayed about the need of ensuring that the DTEXEC.EXE and DTEXECUI.EXE processes are terminated before proceeding. If you confirm by clicking OK, the import lock will be released.

note

Before you do perform the import lock release, it is important to establish that the import instance holding the lock has indeed been terminated. Otherwise, manually releasing the lock could allow two imports to be run simultaneously with unpredictable results.

ODW Import fails due to DC invocation ID mismatch

When a domain controller is restored, the DC gets a new invocation ID. This also happens if ODW is running on a virtual machine, and the machine is restored after a shutdown, including restore of a snapshot in Hyper-V. The subsequent AD import results in this error:

DC Invocation ID mismatch. The domain controller might have been restored. Please re-affiliate LDAP path: using stored procedure UnbindADLDAP.

To solve this problem, run the stored procedure UnbindADLDAP available in the stored procedures for the Omada Identity Data Warehouse database.

Timeouts on ODW queries

If you experience timeouts when you query the Omada Identity Data Warehouse database while ODW Import is running, check that the isolation level has been set to Read committed snapshot. If the ODW installer created your database, this isolation level has already been set.

You can check the isolation level by running the following command in the ODW database: DBCC useroptions.

This is how you change the isolation level:

ALTER DATABASE [OIS Data Warehouse]

SET ALLOW_SNAPSHOT_ISOLATION ON

ALTER DATABASE [OIS Data Warehouse]

SET READ_COMMITTED_SNAPSHOT ON

Conversion failed when converting the nvarchar value

Conversion failed when converting the nvarchar value 'Requesting AD user (Administrator) does not exist in Omada Identity Data Warehouse.' to data type int.

If you get this error, it means that your AD account does not exist in the Omada Identity Data Warehouse. In this case, you must check the LDAP configuration.

Conversion failed when converting the nvarchar value 'Ownership for AD user Administrator to ADMIN is not confirmed in Omada Identity Data Warehouse.' to data type int.

If you get this error, it means that your AD account does not have a confirmed owner in the Omada Identity Data Warehouse. In this case, you must check the AD join rules.

Errors in VerifyFactDataIntegrity

Errors in the VerifyFactDataIntegrity function can be due to any of the following:

Custom tables or views that do not conform with the naming conventions (whose name must follow the pattern xxx_Custom, for example: OIS_Object_Custom).
Unauthorized editing of data in the staging database, master database, or Omada Identity Data Warehouse database. This includes manual editing as well as loading data by any other means than the ODW Collectors.
Editing of VerifyFactDataIntegrity, VerifyDimensionDataIntegrity, or any other procedure or function in the Warehouse database, except for custom procedures.
A bug in the product. Check that the newest patch release is installed.

Check each possibility and make corrections as needed.

Cannot start the columnstore index build

This error indicates that the SQL Server instance hosting the ODW databases does not have enough memory available.

You can solve this issue by making more memory available on the SQL Server. If you cannot enable any more memory, you can allow the SQL Server instance to allocate a larger share of its memory to a single query with the following statements:

ALTER WORKLOAD GROUP (default) WITH

(request_max_memory_grant_percent = 50);

GO

ALTER RESOURCE GOVERNOR RECONFIGURE;

GO

note

Only a system administrator or a person with the CONTROL_SERVER permission can grant this permission to the SQL Server. The change affects everything running on that SQL Server.

Problems uninstalling Omada Service ^on-prem

If you have problems uninstalling an Omada service, use the following:

.netv2.0\installUtil -i OmadaOeservice.exe

ASP.NET security update KB928365 ^on-prem

If you have the ASP.NET security update KB928365 installed, install patch KB942086. If you do not do this, you may experience frequent crashes because of heavy loads on the system. The patch is available from Omada Support.

No database owner in Enterprise Server database ^on-prem

If the user who is accessing the Enterprise Server database is not allowed to have the db_owner role because of company/SQL Server policy:

Install the db_omada role in the Enterprise Server database using the script db_omada.sql.
Grant the user who is accessing the Enterprise Server database the following roles: db_omada, db_datareader, and db_datawriter.

MaxJsonLength error in web.config ^on-prem

If you get the following error message when you call a web service in Enterprise Server:

increase the MaxJsonLength configuration in the web. config file:

<configuration>
  <system.web.extensions>
    <scripting>
      <webServices>
        <jsonSerialization maxJsonLength="50000000"/>
      </webServices>
    </scripting>
  </system.web.extensions>
</configuration>

note

The maximum value is 2,147,483,647.

Multiple XML schema definitions ^on-prem

The following error message that can appear when you try to submit answers to a survey is caused by an incorrect SQL Server Compatibility level for the database.

Error returned by the server Details: The XML Schema syntax 'processContents="lax"' is not supported.

To solve this, change the database mode to use the correct compatibility level. You should set the compatibility level to SQL Server 2016, at least.

You set this in Properties > Options > Compatibility Level for the Enterprise Server database in SQL Server Management Studio.

In addition, make sure that there are no duplicate XML Schema definitions in Setup > More… > Xml Schemas.

Can't start Enterprise Server on any web browser ^on-prem

If you encounter an issue to open Enterprise Server on any web browser, and an error message mentioning DNS operation refused, follow these steps:

Open the web.config file located under **C:\Program Files\Omada Identity Suite\EnterpriseServer\website**.
Go to the line <customErrors defaultRedirect="Error.aspx" mode="Remote.Only"/>
Replace mode="Remote.Only" with mode="Off".
Save and then retry to start Enterprise Server.

info

Once you have successfully opened Enterprise Server, you can rewrite the original file setting.

ODW Import fails due to a timeout ^on-prem

In case the ODW import fails due to a timeout, the name of the source in the SSIS log table can be used to identify whether the timeout originates from a SQL task or an OLE DB component. SQL tasks are prefixed with SQL, whereas OLE DB components are prefixed with either OLE_SRC or OLE_DST.

You can edit the timeout in the Omada ODW Configuration.dtsConfig file.

SSIS Package fails with query timeout in pre-execute Phase ^on-prem

This error can occur if the SQL Server process’s memory limit is too low. Since SSIS allocates memory through the SQL Server process, you must set the memory limit as high as possible.

SSIS Package fails with the error message ‘Insufficient Disk Space or Quota’ ^on-prem

This error can occur even though there is adequate disk space.

It can occur in the following situations:

If the SQL Server process’s memory limit on the SSIS server is too low:
- Because SSIS allocates memory through the SQL Server process, the memory limit must be as high as possible.
If the operating system swaps out the memory of the SQL Server process:
- You can solve this by granting the access right to Lock pages in memory to the service account which runs the SQL Server process. Do this from Administrative Tools > Local Security Policy > User Rights.
If a caching limit is hit:
- Check that the latest service pack has been installed on Windows and SQL Server.
If a maximum size has been configured for virtual memory, which is inadequate:
- Use System managed size instead.

SSIS Package fails with query timeout in ‘SQL TruncateTempUpdateData’ ^on-prem

Omada recommends that you query the sys.dm_exec_requests view in the Omada Identity Data Warehouse database. Check if another session is blocking the SSIS package session.

SSIS Package fails with a “data integrity violation” error ^on-prem

At the end of every source system import, the system performs data integrity checks on the dimension tables. At the end of post-processing, similar checks are done for the fact tables.

If the system detects any integrity violations after an import from a source system, the system stops that specific import and rolls back the transaction which would have committed the integrity violating rows to the Omada Identity Data Warehouse database. Rolling back does not, however, affect the import from any other source systems which have been configured for the Data Warehouse.

Similarly, any integrity violation that is detected at the end of the post-processing terminates and rolls back the relevant step. This rollback does not affect any data imported to the dimension tables before the post-processing began.

The source of the problem could be faulted in the data being imported, errors in extension packages, or issues with ODW itself. Further investigation is generally required to determine the specific cause in each case.

Dimension integrity violations indicate that the fault is in the data being imported. Fact integrity violations indicate that there are issues with ODW itself. If you discover fact integrity violations, you should contact Omada Support for assistance.

As a starting point for further investigation, see the specific error message logged by SSIS. This error message contains a list of the number and kinds of violations that are detected.

Detailed information about integrity check violations

In the TempDimensionIntegrityViolation and TempFactIntegrityViolation tables, you can find detailed information about the database rows involved in the violation. This information is displayed in dimension and fact tables, respectively. The tables are truncated at the start of every import and so only ever contain information related to the latest import run. For each row in either table, the V_Table field displays the name of the dimension or fact table from which the violating row was taken, and V_Type is an integer specifying the type of integrity violation. See information about the various types below.

Type	Description
1	The EffectiveTime or ExpirationTime must be in whole minutes with no seconds or milliseconds.
2	There is more than one effective row for the same Object ID.
3	There is more than one latest row for the same Object ID.
4	Two or more effective Identity rows have the same combination of UID and UID2.
6	The row has IsRowLatest = 0 but b.
7	The Object ID does not have a latest version.
8	The row is marked as latest but does not have the highest expiration time.
9	IsRowEffective is False, but the row has not expired.
10	RowEffectiveTime is later than RowExpirationTime.
12	Different Object IDs share the same business key.
13	The business key contains one or more NULL fields.
14	There are rows with overlapping effective times for the Object ID.
16	Identity UID rows with IsEffective=1 do not have any row with IsPrimary=1.
17	Identity UID rows with IsRowLatest=1 do not have any row with IsPrimary=1.
18	Identity UID(s) rows with IsEffective=1 have more than one row with IsPrimary=1.
19	Effective identity without OISID.
21	OISID for primary identity has mutated.
22	Primary identity where a unique UID has neither been imported nor generated.

In addition to these two fields, the tables also contain copies of all relevant data from the rows involved in violations, which is useful for figuring out the exact cause as the data has not been committed to the actual dimension and fact tables where the problems were detected.

note

A maximum of 100 rows is logged for each violation type + table combination for every import even if the actual number of violating rows in the table is larger than that.

SSIS package fails with 0x80072020 ^on-prem

If there are problems with the LDAP configuration, the following error may occur:

System.DirectoryServices.DirectoryServicesCOMException (0x80072020): An operations error occurred.

If this error occurs, verify the LDAP path and the credentials.

SSIS package fails with 0x800700EASSIS package fails with 0x800700EA ^on-prem

If the domain controller or network performance is poor, the following error may occur:

System.DirectoryServices.DirectoryServicesCOMException (0x800700EA): More data is available.

You can avoid getting this error by configuring the SSIS server:

Edit the .NET 2.0 file machine.config on the SSIS server. Typically, the file is located in C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG. Make a backup of the file before changing it.

Add this inside the <configSections> element:

<section name="system.directoryservices" type="System.DirectoryServices.SearchWaitHandler, System.DirectoryServices, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

Add the following information after the <configSections> element:

<system.directoryservices>
<DirectorySearcher waitForPagedSearchData="true" />
</system.directoryservices>

Save and close the machine.config file.
Restart the program that hosts the SSIS packages.

SSIS package fails with “Server not in operation” ^on-prem

This error means that the DNS server to which SSIS server is pointing does not have an authoritative domain controller answer for the LDAP that is being referred for an import.

To solve this error, you must have administrative access to the DNS server that serves the SSIS server. Add a stub zone in the DNS server for the domain that is being looked for in the LDAP.

Enterprise server - issue with Web Service configuration ^on-prem

If you get a 401: Unauthorized error when running an export from the Omada Identity Data Warehouse to Enterprise Server, you may need to change the Internet Information Services (IIS) settings for the Enterprise Server website. To do so, follow these steps:

In Configuration Editor, go to system.webServer > Security > Authentication > windowsAuthentication.
Set the useAppPoolCredentials settings to True.