[Hornbill LDAP Import Configuration settings Issue]

Prior to installing the most recent LDAP_Import utility; the configuration settings was implemented via two configuration files ( i.e. one for the Cost Centre and the other for the Department) hence the previous LDAP_Import utility was executed twice.

With the new LDAP_Import utility; the configuration setting is implemented via the 'Data Configuration Manager' but we would like to confirm that the cost centre and department details are imported and linked as previously done.

[Hornbill LDAP Import Issues]

We have identified some issues within the LDAP_Import log files and we would like some clarification/investigation.

The issues are as follows:

1. The user account entries in the log files provides details of accounts in which errors have occurred during the creation/update process but no entries for user

accounts that have been successfully created or updated.
It does seem that the difference in user account information has been in place after we implemented the new LDAP Import utility.

2.We have observed that the size of the log file varies between 4KB and 944KB and the runtime for the 4KB log is just over 3 minutes while that for a file above 900+KB is

20+ minutes. We would like to know the reason for this disparity.

3. Furthermore, there are differences on a day-to-day basis on the 'Error Count', 'Profiles Updated' and 'Images Updated' values  hence  we would like to know the

reason for the wide disparity in these values between daily log files.

Below are extracts from the log files generated on the 19th and 20th December 2018.

 

2018/12/20 21:33:18 [ERROR] Error Count: 18
2018/12/20 21:33:18 [MESSAGE] Accounts Processed: 3997
2018/12/20 21:33:18 [MESSAGE] Created: 0
2018/12/20 21:33:18 [MESSAGE] Updated: 1
2018/12/20 21:33:18 [MESSAGE] Status Updates: 0
2018/12/20 21:33:18 [MESSAGE] Profiles Updated: 3994
2018/12/20 21:33:18 [MESSAGE] Images Updated: 23
2018/12/20 21:33:18 [MESSAGE] Groups Added: 6
2018/12/20 21:33:18 [MESSAGE] Groups Removed: 0
2018/12/20 21:33:18 [MESSAGE] Roles Added: 1
2018/12/20 21:33:18 [MESSAGE] Time Taken: 3m18s
2018/12/20 21:33:18 [MESSAGE] Total Traffic: 4086
2018/12/20 21:33:18 [MESSAGE] ---- XMLMC LDAP Import

2018/12/19 21:53:22 [ERROR] Error Count: 7187
2018/12/19 21:53:22 [MESSAGE] Accounts Processed: 3996
2018/12/19 21:53:22 [MESSAGE] Created: 2
2018/12/19 21:53:22 [MESSAGE] Updated: 0
2018/12/19 21:53:22 [MESSAGE] Status Updates: 0
2018/12/19 21:53:22 [MESSAGE] Profiles Updated: 0
2018/12/19 21:53:22 [MESSAGE] Images Updated: 3990
2018/12/19 21:53:22 [MESSAGE] Groups Added: 5
2018/12/19 21:53:22 [MESSAGE] Groups Removed: 0
2018/12/19 21:53:22 [MESSAGE] Roles Added: 3993
2018/12/19 21:53:22 [MESSAGE] Time Taken: 23m21s
2018/12/19 21:53:22 [MESSAGE] Total Traffic: 15185
2018/12/19 21:53:22 [MESSAGE] ---- XMLMC LDAP Import

 
 

[Service Manager update function]

Based on the fact that anyone who clicks on the Service Manager 'Update' symbol can implement the update for every user on the instance; Is there a specific user permission that applies to the right to update Service Manager?

Rgds,

Izu

[API Scheduler - running the utility has no effect]

No, it doesn't confirm success/failure. 

Rgds,

Izu

[API Scheduler - running the utility has no effect]

Hi Steve,

I am unable to see a service request generated by the API Scheduler. I checked via a view and inputted the catalogue name  as a condition.

Please, could you have a look and let us know your feedback.

Rgds,

Izu  

[API Scheduler - running the utility has no effect]

Hi Steve,

Thanks for the update.

I have applied the steps mentioned above. Please, could you advice on how I can check/confirm that the scheduler has generated the service requests.

 

Rgds,

Izu 

[API Scheduler - running the utility has no effect]

We have executed the API Scheduler with the '-dryrun' parameter set to 'true' and 'false' as well with no error messages. My colleague who carried out the necessary checks indicated that she does not think it worked.

Furthermore; The scheduled task that was set up to run the utility never stops running hence every time I execute the task; I always manually end the task else it runs indefinitely.

[Implement a Rule on a closed mailbox]

It's no longer in use.

[Implement a Rule on a closed mailbox]

How do we implement a rule on a closed Service Desk mailbox that forwards a reply message to anyone who send an email to the mailbox?

[Hornbill Cleaner - Requests backups]

I would like to know if you would be able to take a backup of all requests in our live instance prior to us executing the Hornbill Cleaner utility.  

[Hornbill Cleaner - config settings]

I would like to confirm what the 'RequestServices' parameter in the config file represents and the value(s) to associate to the array. Furthermore, in order to implement three separate retention policies (i.e. IT, Security and Accessibility); I do want to know the specific parameter to use in each config file.