Hi @Stijn Hensen 

Can you please generate a log file of verbosity 3? can you also please send some examples of fields which you cannot currently seem to extract in the Cdata provider? I will then pass these details onto Cdata

To generate a log file for a data source connection in TimeXtender portal for 6506.1

To generate a log file in 20.10.45

Hi Christian,

Sorry for the late reply, but in attachment you have the logfile.  I created a new logfile on verbosity3, did a sync and a transfer.  I hope that’s enough.

Anyway, fields that I would like to extract, are:

msExchHomeServerName
msExchMailboxGuid
msExchRecipientDisplayType
msExchRecipientTypeDetails
targetAddress

They are added into Active Directory when you have a on premise Exchange.  But the provider doesn’t seem to recognize them.  We are trying to install the CData for Exchange momentarily, but it gives issues, so maybe we have to use that one.  But I would think it’s strange as these properties are just attributes in Active Directory.

Thanks for passing it to CData!

Stijn Hensen

Hi @Stijn Hensen 

Please use the latest version of the Microsoft Active Directory 2023 provider v. 23.0.8790.0

Also please see the following response from Cdata:

To extract custom attributes added in the Active Directory, utilize "custom schemas." For more info please see the following link: https://cdn.cdata.com/help/CDJ/ado/pg_ldapTables.htm

1. In the data source settings, under the schema section, set the location property to a path (e.g. C:\CData\AD)
2. Run the sync and transfer task. This should create a Users.rsd file in the path specified above
3. Make the necessary changes required to add a custom column to the users table in this copied file.

   

4. Run the sync and transfer task again

Hi Christian, 

Thanks for the reply.  That could indeed help.  I don’t know if I can install the latest version, as installation of drivers is pretty secured.  But I will propose it anyway.

Kind regards,

Stijn Hensen

Hi @Stijn Hensen 

did you get a chance the test the proposed solution above?

Hi Christian,

I tested it, but unfortunately, the cdata driver does not create the schema files, even if I change the default location.  I asked for an update of the driver, as I cannot do that myself in the hope that would solve that issue.  But no answer yet.  If you’re sure the schema files will be created with the latest version of the driver, you may close this.  

Thanks,

Stijn

@Stijn Hensen OK please let us know if you can extract the custom attributes once the data source provider has been upgraded

Hi @Stijn Hensen did you manage to test with the latest version of the provider?

Hi Christian,

I got the rights to update the driver myself today, but unfortunately, no schema files are created.  Also, the transfer task ran now 4 times as long as before.  I hope this is just a one time recurrence.

Is there a way we can force the creation of the schema files?  Like creating an empty person.rsd file?  The documentation says:

You can find the Person.rsd file in the db subfolder in the installation folder of the CData ADO.NET Provider for Microsoft Active Directory

But I cannot find this anywhere.  Driver is installed here: E:\ProgramData\TimeXtender\ODX\Components\CData\ActiveDirectory\23.0.8790.0, but no db folder exists here.

Thanks,

Stijn

Hi @Stijn Hensen 

If the location property is set to the default, then the rsd file will be in the installation folder of the CData ADO.NET Provider for Microsoft Active Directory, as you mention.

You can also set the Location property to a specific folder (e.g. C:\CData\AD) and then the rsd file will be created here instead.

Please try to make the necessary changes to the rsd file as described above to add a custom column to the table.

Hi Christian,

I checked the default location, but the schema files are not installed anywhere.  Not in the default location, and not in the location I set in the properties.  I checked the folder in E:\users\”Serviceaccount”\AppData\Roaming\CData\AzureActiveDirectory Data Provider\Schema, but it is empty.  In Programdata, it’s empty.

Also, I had to do a rollback of the driver version.  As mentioned before, it took more than 4 times as long, and I had several conversion errors (string could not be converted to nvarchar).  Even if I added all the fields as they were from the ODX, no conversion at all.  So it seems the default column properties between the 2 driver versions are different.  Something what we could solve with schema files.  However, as mentioned, they don’t seem to be generated anywhere.

Now, this is for the same client as the high priority ODX issue we are currently solving, and the drivers are installed on the E-drive, not the default path on C.  Maybe that can cause an issue?

Thanks,

Stijn

Hi @Stijn Hensen 

Please make sure that the user running the ODX service has access to the specified folder on the E drive. Alternatively try with a folder on the C drive.

Hi Christian,

The service account does have the necessary rights, as I was able to create schema files with another connector.  I tried to save schema files on the C-drive, but that did not work either.

Greetz,

Stijn

Hi @Stijn Hensen 

I have created a support ticket for this

@Stijn Hensen and I managed to resolve this by implementing the above workaround. The Users rsd file was manually copied into the folder and the additional columns were added to the rsd file. There were some sync issues following this, but these were resolved after the folders for the AD data source were removed from Azure Data Lake and the sync and transfer tasks were re-executed