Jump to content

Steve G

Hornbill Developer
  • Posts

    746
  • Joined

  • Last visited

  • Days Won

    30

Posts posted by Steve G

  1. Hi @Josh.F,

    That would suggest the device you're trying to return the details of either doesn't exist within Intune in your Azure tenant, or the user against the key in keysafe doesn't have the rights to read that device. I've just tried on our Intune and it's working fine, so I think this must be your config and/or Intune access.

    Could you send over a screenshot of the workflow node which is trying to get the record please? 

    Thanks,

    Steve

  2. 5 hours ago, JanS2000 said:

    What variable should the MemberIdentity be using?

    It depends what you have stored in your user records to be honest, and in which fields. That automation requires one of the following to be able to identify the user in your on-premise Active Directory domain:

    • A distinguished name
    • An object GUID
    • A security identifier
    • A SAM account name

    If you don't have one of those stored against your Hornbill user records, then you could always extract the sAMAccountName portion on your user, using the String Utilities in the workflow. So you could first search for the location of the @  character in your user ID (you would use the current variable instead of steveg@mydomain.co.uk):

    image.png

    Then use the Result output of that node as the To input of a Substring node, with 0 as the From input, and your User ID variable as the Input Text, as so:

    image.png

    So in my example autotask, below:

    image.png

    Outputs as so:

    image.png

     

    Hope this helps,

    Steve

     

    • Like 1
  3. Hi @JanS2000,

    Are you able to run the following in a PowerShell command line on the target machine as defined in the job, and see if both are able to return the account details as expected?
     

    Get-ADUser -Identity yourusername@yourdomain.gov.uk

    And

    Get-ADUser -Identity yourusername

    I suspect that your sAMAccountName against your AD account is just yourusername, and Get-ADUser (a Microsoft cmdlet that we're using to check if the user account exists) won't see yourusername@yourdomain.gov.uk as a valid identifier.

    Cheers,

    Steve

  4. Hi @Jeremy,

    I've just tested this and it's working fine, so I expect this is an issue with the refresh token, or rights on the Google account. 

    First thing I would try would be to revoking the key in Keysafe (the revoke button, do not delete the key or you'll have to update all your workflows that use it!), then remove Hornbill from the list of approved third party apps in the relevant Google account, and then hit the connect button in your Keysafe key. Authenticate and approve as usual and you should be fine.

    Let me know how you get on,

    Steve

    • Thanks 1
  5. @Dave Longley Solved should have a lower-case s, as per the Zendesk API response:

    image.png

    Totally agree with @Steve Giller though, looping every 2 minutes is a really bad idea so you need to extend that period by quite a lot. What you should really do though, is to implement a proper 2-way integration - use Zendesk triggers & an appropriate marketplace app (Zapier or the like) to make API calls back into Hornbill to update the Hornbill ticket when the Zendesk ticket is set to Solved.

    Steve

  6. Hi @Art at BU,

    The "System.Drawing.Common" issue is a pretty new one - it appears that Microsoft have removed support for the provision of embedded icons in Teams bot solutions - without documentation. To fix this issue, if you edit the generated bot.xml  file and delete the entire iconbase64 tag from the xml, save the file then perform the tar command as in @SamS's instructions above, then the solution import should go a whole lot smoother :) 

    image.png

    We'll get the PVA package updated on GitHub as soon as we can to remove this now-unsupported tag.

    Cheers,

    Steve

    • Like 1
  7. Hi @Met,

    To answer your questions:

    • Where there is more than one manager with the same display name, how will Hornbill decide which account to choose? Will it return an error?

      • No, it uses the first match it finds in the cache. I can see how this would be problematic though, and will review this code in more detail to see if there's a better solution (probably an error to the log as you mentioned)

    • Where the user already has the correct associated manager recorded against their account (because our "first time import" queries the entire sub tree and therefore includes all managers), will Hornbill still error out or will it leave the manager as the one that currently exists?

      • No errors, but unless you specify __clear__ in the mapping for the manager then the manager against the user records will be left alone.

    • Is there enough justification to have a second LDAP query which is used when looking up manager details?

      • That's probably one for the community to answer :)

    Let me know if you need any more detail.

    Cheers,

    Steve

  8. Hi @Giuseppe Iannacone,

    The API to get posts and comments from an activity stream (timeline) is: https://api.hornbill.com/activity/?op=activityStreamQueryItem

    Re: your other question, I'm not sure why the uploaded file would be corrupted. We use a similar process in our import utilities, check the code here against yours as this is working in production: https://github.com/hornbill/goLDAPUserImport/blob/master/image.go

    Cheers,

    Steve

  9. Hi @Adrian Simpkins,

    In your AssetTypes import config, have you set the AssetIdentifier->Entity value to match the entity where h_serial_number lives, as per the wiki documentation and the configuration example?

    If you're importing computer type assets and matching on h_serial_ number, the entity should be AssetsComputer as so:

    "AssetIdentifier": {
        "SourceColumn": "SystemSerialNumber",
        "Entity": "AssetsComputer",
        "EntityColumn": "h_serial_number"
    }

    Cheers,

    Steve 

    • Like 1
  10. Hi @Giuseppe Iannacone,

    The API you need is: https://api.hornbill.com/apps/com.hornbill.servicemanager/Questions?op=queryExec

    And here's an example payload:

    <methodCall service="apps/com.hornbill.servicemanager/Questions" method="queryExec">
    	<params>
    		<queryName>getRequestQuestions</queryName>
    		<requestId>SR00013867</requestId>
    		<rowstart>0</rowstart>
    		<limit>100</limit>
    		<resultType>allData</resultType>
    	</params>
    </methodCall>

    Cheers,

    Steve

  11. Morning @Martyn Houghton,

    That's standard CRON behaviour I'm afraid - if DOM and DOW are provided, then it's an OR not an AND, so it'll run the scheduled job if the day of the month is between 15-21 OR the day of the week is a Wednesday. From the CRON specification:

        While normally the job is executed when the time/date specification fields all
        match the current time and date, there is one exception: if both "day of month"
        (field 3) and "day of week" (field 5) are restricted (not "*"), then one or both
        must match the current day.[3]

    Cheers,

    Steve 

     

  12. Hi @Berto2002,

    It is indeed the Object ID, as per the documentation in the workflow operation:

     image.png

    The wiki URL you have provided is for Azure Automation, which is a different product on the Azure platform. The wiki page is actually: https://wiki.hornbill.com/index.php?title=Microsoft

    To get the User Object ID, you can use either of the following operations:

    • Microsoft/Azure/Users/Get User by Email - this will search for users by emil address
    • Microsoft/Azure/Users/Get User - this will return the user by their UPN

    Cheers,

    Steve

×
×
  • Create New...