Steve G

Hi @Martyn Houghton, All request types are supported by this tool, see RequestTypesToImport > ServiceManagerRequestType in the wiki documentation. Cheers, Steve

Hi @Joyce, I've just tested the PowerBI R scripts, and they are working as expected so it's possible there's an environmental issue in play. Could you try your script in a new data source in Power BI Desktop, as this should then give you an error to start debugging from? Thanks, Steve

Hello everyone,The latest update of Hornbill ITOM (27) has been released to live.The change log for this update is as follows: Change Added [Manage Executed Runbooks] to application navigation Plugged-in new application navigation using same style as new admin navigation Moved the Runbooks and Installed Packages links from admin area to user application menu Styling improvements across the application Fix Issue with the job view console trying to scroll down on page load Time zone selector of a scheduling job was missing Unexpected error when opening scheduled runbook jobs Issue when filtering the inventory by a list and then looking for unmanaged inventory macOS package filtering issue Issue where the breadcrumb was not visible on the site integration services panel Issue when opening a job from a parent job Unable to delete a job from the job list Issue where the Hornbill package library button did not respond Package command line cursor in Operation form mis-aligned

@Melissa Gurney sure, you can apply filters to the clean utility config to remove a specific set of assets, as per the documentation: I'd recommend running both tools in dryrun mode first, and review the output in the logs, before running either in live mode. Cheers, Steve

Hi @Melissa Gurney, When you say removing the data afterwards, are you meaning that you want to delete any assets that were created during the import process? If so, we have the Clean Utility that can do what you need. Thanks, Steve

Hi @samwoo, Apologied for the late response on this. I can see why this isn't working, and will raise it with the relevant development team to get this fixed. Cheers, Steve

Hi @Martyn Houghton, I've had a quick look, and this feature is only available in the beta version of the Graph API. I've added the request to the list though, and when the API changes are out of beta then we'll get it added into the iBridge operation. Cheers, Steve

Hi @Rob Gething, I've just tested the operation using an Auto Task, and it's working fine: As @Steve Giller has mentioned, the Error output parameter should contain information returned from Microsoft regarding the failure. What do you have in here? Thanks, Steve

@AndyHill, I've tested both operations in the PRTG package and they are working with our PRTG server. But to help with your diagnosis, we've just released an update to the PRTG package that outputs more debugging information. Let me know how you get on, and please post any errors here so we can investigate further if need be. Kind regards, Steve

Hi @Martyn Houghton, That's done. You now have a new operation to get the account ID for a given user, and I've updated the Add Watcher, Create Issue and Update Issue to support Account IDs. Let me know how you get on. Cheers, Steve

Hi @Martyn Houghton, I can see what is required here, will change those now as workflows using these integrations will be broken. Will let you know once done. Cheers, Steve

Hi @davidrb84, Sure have Take a look at the example PVA here: https://github.com/hornbill/hornbillPowerVirtualAgent There are Power Automate flows contained within the solution that do exactly what you need. You need a subscription that allows for the use of premium connectors within Power Automate though, as the flows make use of the HTTP Request connector to make the calls into Hornbill, and this is a premium connector. Note: we're releasing an update to the PVA in the next few days, with an additional flow to assist in the identification of your chatbot users against your Hornbill users, so keep a look out for that. Let me know how you get on. Cheers, Steve

@Kevin Allitt, As well as Keith's curl explanation, there are examples of how to make API calls using Python here: https://github.com/hornbill/pythonPowerBIHornbillDataSources And we also have a library for making API calls from Python easier, which lives here: https://github.com/hornbill/pythonApiLib Cheers, Steve

Hi @Andy Gilbert, I've just had a look at what is required here, and the last logged on user data is currently only available in the beta version of the Intune Graph API and not v1.0. In their beta API, the windowsManagedDevice collection returns an object called usersLoggedOn, which is a collection of loggedOnUser objects. Contained within each object in that collection is the userId (objectId) and lastLogOnDateTime properties. So you could use that, along with the Get-HB-User cmdlet from the HornbillHelpers PowerShell module to populate the appropriate columns when creating/updating asset records. Once Microsoft have moved their beta API to production, I'll make sure the above changes get added into the Intune import script. Cheers, Steve

Hi @Adrian Simpkins, As @SamS has mentioned, the template that is required is defined in the Gov.UK Notify platform. To find the template ID: Sign in to GOV.UK Notify. Go to the Templates page and select the relevant template. Select Copy template ID to clipboard. Once that's in your clipboard, you can paste it into your Hornbill workflow. Cheers, Steve

Hi @Andy Gilbert, Apologies, it appears that @SamS thought you were referring to the database asset import utility, and not the Intune asset import script, so I've deleted the comment so as not to confuse anyone else who visits this topic I'll review the code, as it's been a while since I looked at it, and will get back to you. Cheers, Steve

Hi @lee mcdermott, I can see you've requested the "dynamic autotask content" in another post, I'll flag that with the relevant team who will reply accordingly. Cheers, Steve

@Martyn Houghton Seems to work ok for me? I've added an update timeline automation after the decision, which is writing the iBridge returned error into the timeline: Do you have the correct variable reference in the request update automation? Cheers, Steve

Hi @lee mcdermott, Post To Channel is a deprecated operation (still there so as to not break existing workflows) that uses keysafe keys of type Microsoft, and has been replaced by: Microsoft > Teams > Channel > Send Message, which uses the Microsoft Teams keysafe key type. So if you switch over to the new operation, you will see your Teams key listed. See the Hornbill Wiki for more information. Cheers, Steve

Hi @Blowerl, I've just tested it on a 2022 machine, and it is indeed compatible. Cheers, Steve

Hi @Martyn Houghton, FYI Cheers, Steve

@Berto2002 Excellent

Hi @lukeb, I'd suggest using the -dryrun=true argument when running the tool, and check the resulting log. This will not delete any records, and will output details of each record that would have been deleted if you had run it without the dryrun argument... And as always - check twice, run once. Thanks, Steve

Hi @Berto2002, The new Teams integrations that post to chats or channels in Teams do not require Azure/Office 365 admin access, so you can create a generic Service Desk account and use that account against the keysafe key that is performing your post operations. The required rights are: ChannelMessage.Send, User.Read, Chat.ReadWrite. And the iBridge operations that require these basic rights are: Channel Reply to Message Send Message Chat Create Chat Send Message As per the description against the content box, HTML formatting tags are supported by the API that we use to make the calls into Teams so you should be able to format those messages as required: https://docs.microsoft.com/en-us/graph/api/channel-post-messages?view=graph-rest-1.0&tabs=http See 2 above, same formatting restrictions apply A very basic example of formatting: Hope this helps, Steve

Hi @Martyn Houghton, I'll add the error code into an output parameter in the next release of the iBridge content pack, will let you know once that's done. Re: the reporter field, that's just how Jira works as far as I'm aware - the field being updated needs to be on the process appropriate screen even when updating via the API. There's nothing we can do about that I'm afraid Cheers, Steve