Izu

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.

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

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

No, it doesn't confirm success/failure. Rgds, Izu

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

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

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.

It's no longer in use.

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?

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.

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.