SamS

Hi @Llyr, Just set the Request Parameter Enable Security to true

Hi @samwoo, What you are trying to do is not (currently) possible with the tool. Because CSV is flat-file, it was not envisioned to be used to populate the "Installed Software" area. The CSV can be used to populate Software Assets, without a problem. There would be a few solutions that the developer would need to consider on how to incorporate it: A JSON field with all installed software might be easy for the developer, but it would be quite difficult for most people to provide that data structured correctly in a CSV. A more straightforward alternative would be to have the installed software listed in a separate CSV file (with a specific field to identify the asset it relates to - so filtering on that file can happen) OR over multiple CSV files with the file name somehow linking back to the asset. Both these CSV formats would be easier for people to create.

Hi @Llyr, As you mentioned both AD (via ITOM) and AAD/Entra, am I right in guessing you are working in a hybrid environment? It could well be possible that (with AD replicating/synching into AAD) an group creation in AAD is not allowed. You can capture the Error/Status/Group ID & Mail results from the AAD Group Creation in a timeline entry, that way you can tell within the request what response you got from Entra and that will lead you to figure out why it's not working.

@Osman then I frankly don't know what the issue might be. From the error message it appears that your import utility is not self-updating (because your version seems newer than what is on github) - you could try the new 4.2.0 exe and see whether that works (not that I can see anything in that particular release which would make a difference in this particular issue).

@Osman, The authentication details (Instance ID & API Key) is stored in the import.cfg file that is created/stored with the .exe. Only the WINDOWS account which CREATED the import.cfg has access to the details it contains! IF you are running the .exe in YOUR account and all works, then that would explain why the Service Account can't get the info out. Use "Run As..." or "runas" with the service account to set up the import.cfg which the Service Account will use (under the Task Scheduler)

@Berto2002you literally have to trigger the Hornbill webhook by doing the action. If I'm not mistaken, there is a little explanation on how the expressions work on the page itself, just hit the question mark icon. The expression is SQL-ish and it should give you predictive text style assistance. Just type in the word "record" and you should see a few suggestions. record.h_field_name will give you the contents of that field to check (for assets you would have different fields that for requests etc).

@JanS2000 "It depends" - whatever you have currently set up as an import to keep the records up-to-date (assuming one of our user import utilities), just needs to match the "NEW" account (from source) to the "Existing account" in Hornbill. Depending on what field you are matching the records with, you can manually modify that field within Hornbill for the import utility to match. The only exception on this, is the User ID field. That field cannot be changed, so you might be able to look into reconfiguring the user import utility to use a different field to match records on.

Hi @Jörg Walther, There is indeed no easy way of doing it - ideally the mistake/categorisation doesn't happen in the first place. I am aware that our specialists can likely(*) do it for you, though that will be chargeable - you will have to go through your account manager/CS contact. (*) a few caveats exist

To deconfuse what was happening and to be perhaps of some use to someone else: An Azure User Import was running and failing. The error mentioned above was NOT visible anywhere regarding this particular issue (i.e. that error appeared to be a connection issue to LDAP/AD). The import was scheduled to run using Windows Task Scheduler. Going by the logs it had clearly worked previously - until the import suddenly didn't work anymore. It turned out that the context/account the task was running under had changed to a service account without re-generating the import.cfg file (the file containing the Instance ID and API Key linked to the account generated (which in this context was the individual's account the Windows Task was set up with)). https://docs.hornbill.com/data-imports-guide/users/database/command

@will.good In addition to @Gerry's comment, both the Azure and the DB User Import Utilities allow for a GUID to be generated if needed (i.e. for when a SID or so is not available).

Hi @Ketan.lakhani, I'm a bit confused: LDAP/AD OR Azure? What are you trying to do? Azure or AD User import? Are you using the correct tool? And not perhaps the LDAP/AD user import to connect to an Azure server or vice versa?

@Berto2002, Webhooks would probably be the way to go - the way @Gareth Cantrell outlines. A mention has to go out about the "Trigger Expression" - I would urge you to use that, so that not ALL updates to ALL requests trigger the webhook into Jira.

@Berto2002, I'd look at the JIRA side on what is possible there: https://support.atlassian.com/cloud-automation/docs/jira-automation-triggers/ https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Send-web-request

@samwoo FWIW: as of this writing, the way the roadmap is updated is when their respective app is upgraded.

Hi @Jules2218, though not exactly what you are looking for, you might find Snippets useful: https://wiki.hornbill.com/index.php?title=Snippets

Hi @Alisha, I can't be much of a help here for you, as it works for me - without a hitch - from AutoTask. BUT I CAN add, for anyone who is interested: IF the asset is configured to be "Shared", then "Used By" of True will only work if the individual customer/user is LISTED as an individual under the "Shared With" list - as opposed to being IMPLIED (i.e. the user is part of the Team/Organisational Unit)?

Hi @davidrb84, That is indeed the most up-to-date documentation. We are in a process to move Wiki-material (with necessary edits) to our new documentation portal. The PVA-article has not been brought across.

@Julie K, in short "No". It is currently not possible to have a calculated field in the result set.

Hi @Jim, I can't speak for the developers on whether this can and will be considered, but a simple workaround until then would be to add a rule to your email client to syphon off these empty report emails if the size of the email is smaller than x kb (i.e. the file size without any results). The obvious caveat here is that I hope the difference between a empty and single line report is at least 1kb. That might be achieved by incorporating a graph (assuming PDF report here, instead of csv).

@HHH A final alternative is to have field_2 and field_3 on SEPARATE customized forms(*) - each with the same Form ID AND Field ID (eg secondForm.field_2)(*) - then effectively both answers will be "merged" on the BP-side (as secondForm.field_2). (*) i.e. the Decision-node happens in the IC AFTER field_1. (**) you WILL get a warning that you may have set up your IC incorrectly, but - as you did it on purpose -

Hi @Cristian, The error is with the utility trying to contact Azure, so my guess is that one or more of the following is not correctly set in the Keysafe entry: Tenant ID, Client ID or Client Secret. The values can be had from the following instructions: https://wiki.hornbill.com/index.php?title=Azure_App_Registration_Instructions

Hi @Cristian, The KeysafeKeyID you need to use can be taken from the URL when you are looking at the specific KeySafe entry (17 in the below example):

Hi @Cristian, My GUESS (because I will admit that I ran into this issue the first time I used v4.x) is that you are referencing KeysafeID instead of KeysafeKeyID... Please double-check the capitalisation of the letters AND on what level it is in the configuration file. I suggest you compare this with the bundled json file. With the KeySafe entry, the Client Secret can be removed from the configuration file. The final error suggests there is a typo in the configuration file (my GUESS an extra right-curly brace).

Hi @Met, Which "Office Location"/"Site" are you using (in the Data Import Config)? The one mentioned in the "User Account"-section? Or the section within "User Options"? It is the latter (User Options) which you need to have configured - I am pretty sure the other one gets ignored.

@DRiley, I've had a chat with MS regarding the OData filtering in InTune. In short: they are aware that not all filtering works AND there is no documentation on what specifically does and doesn't work (eg startsWith doesn't appear to work at all, UNLESS you check the full word - in which case "eq" could/should be used. Things might/should change at some stage in the future. In the meantime, the best way would be to code the filters within the Runbook - i.e. have a developer implement the following PSEUDO-code: if ($Device.model = 'iPhone'){ $AssetType = "123"; } else if ($Device.model = 'iPad' || $Device.make = 'Samsung'){ $AssetType = "205"; } else skip this import If the assetClass changes, then some more tinkering will be required.