SamS
-
Posts
1,511 -
Joined
-
Last visited
-
Days Won
25
Content Type
Profiles
Forums
Enhancement Requests
Posts posted by SamS
-
-
Hi @QEHNick,
I appreciate that that is the Query from the configuration file.
I am looking for the query from the .log file. You will find that in the "log"-folder alongside the .exe.
The log file will contain the full SQL as was sent to the DB Server.
I can see from the configuration files you have posted what SQL is supposed to be there, I want to confirm the actual SQL matches expectations.
-
Hi @QEHNick
There should be a line in the log file which gives the full SQL query being run (per asset type).
[DATABASE] Query for [[AssetType]] assets: ...What is the query stated there...
This log entry should be in between the two lines (per type) you provided - which will have been visible on screen.
-
Hi @Oscar Stankard,
The "Connect"-button will NOT work - there is no "destination" to check against. It is also NOT needed.
The "Connect"-button is a recent addition, so I tried my test config against a new oAuth configuration entry and that also (still) worked (just in case the "Connect"-button brought something else with it).
According to the error message, the API key you are using is NOT the same as configured against the keysafe entry, which explains why the Tenant ID/API Endpoint isn't being returned.
The way to check whether the "Azure AD API Key" APIKey Permission is indeed the one you are using with the utility is to add the API key you are using to the list (again). IF it matches the API key there, then you will get a "The specified permission is already granted"-error - otherwise it will add the API key to the list.
-
Hi @Mike Hillman,
You can manage the Activities (Tasks) in the same way you can Requests - there is a "My Activities"-listing available via "Home" navigation group.
Within the listing you can select different users, roles and groups to filter your list.
-
Hi @Oscar Stankard,
Within "Add Permission from User API Keys" search for the user you have created the API key for and then select that API key to include it with the KeySafe entry.
-
Hi @Oscar Stankard,
What happens when you add the API Key you are using for the import to the "API Key Permissions"-list, and try the import again?
Don't forget to marry the API key to the Keysafe entry - and, when creating the Azure App, don't forget that the (Sys) Admin needs to confirm the permissions.
-
Hi @Oscar Stankard,
If you are seeing a "Connect"-button within the KeySafe entry, then you likely have set up a "Microsoft:OAuth2"-Type.
Please use a regular "OAuth2" - displays as "oAuth 2.0".
For running the Azure User Import, you will need to fill in the KeySafe form as detailed in the Azure User Import Wiki entry.
Don't forget to pair the API key to the Keysafe entry - and, when creating the Azure App, don't forget that the System Administrator needs to confirm the permissions.
-
Hi @AndyHill,
The "Result" should give you the substring it found. What is the regex and what is the sample text?
-
For 2: the trick is to use the "Regex Substring" from the "String Utilities". Regular Expressions aren't for the faint of heart, though.
-
Hi @Ann,
That totally depends on whether the people doing the integration work are actually populating the project task with that (external reference) information.
If the integrators are not populating the external reference field, but another field instead, then that other field needs to be reported on.
If the integrators are populating the descriptive text with the reference, then reporting won't work (easily), so they might want to think of populating the external reference field instead.
-
Hi @Ann,
That is correct: TSK followed by 14 digits -that is the reference for a task.
In what context are you getting a four digit reference?
-
Hi @Smurfy,
The first error you highlight suggests firewalls (socket access) - you might need to set HTTPS_PROXY and or HTTP_PROXY if you have proxy servers set up.
It wouldn't surprise me that the subsequent errors are caused by the first error - that particular gobbledegook is for the developer to know where to have a look at figuring out what is happening. I would venture that there is some code on line 45 of main.go that would fail if there is no network connection (that would be over the socket the initial error is complaining about). There might be a more graceful exit on the networking error, but that is what I would focus on.
-
Hi @Berto2002,
Could you please confirm that you have in fact published the BP and not just saved it before testing (i.e. last published=currently active BP having 5min in it)?
From my brief test, the module works as expected - the expected outcome being current time minus thirty minutes.
You could output the resulting timestamp(SQL) in the timeline or so, just to see what the utility outputs rather than what the DB interprets it as (just to remove that potential problem).
-
Hi @Rob Gething,
FYI: I've been informed an updated PVA solution is going to appear some time later this month.
-
Hi @Rob Gething,
You might want to add a few more items to the permissions list (the script can run with fewer - see attached). There are permissions in there for when the script runs to "find" users.
In the App under "Authentication", there is an "Advanced settings"-section. "Allow public client flows" needs to have "mobile and desktop flows" enabled.
The $Instance is case-sensitive - that is if the 401 error is coming from our server.
Finally, try the $Resource URL in https://developer.microsoft.com/en-us/graph/graph-explorer and see if that gives any issues (if so (eg 401), then it would indicate an issue with the Credentials).
I hope this helps
-
Hi @Rob Gething,
Yes, for the time being those are the constraints.
If I were you, I would set up a single account to test. Once you confirm that it "works in principal", you can think about how you would like to extend on things (and play around a little).
Hopefully by then you will have an updated version of the script that allows a different matching fields (although I expect that the matching field in Hornbill will remain User ID - it MIGHT become (interchangable with) Login ID at some time in the future).
-
Hi @Rob Gething,
As far as I know, the UPN is full format abc@def.com - just the "abc" part is, invariably, the sAMAccountName.
-
Hi @Adam Toms,
Please find a late (or very early) Xmas present: https://github.com/hornbill/goHUserRoleRemover
-
1
-
1
-
-
Yes @Rob Garton, IF your User ID in Hornbill is RGETH, then your UPN should also bee RGETH.
We ARE working on making it configurable so other (AD) fields can be used to identify the user (eg email), but for the moment, you are limited to UPN matching User ID.
-
Hi @Rob Gething,
Thanks for the error payload.
Could you please confirm whether the UPN of the session user matches the User ID (of a User) within Hornbill? That is still a requirement - mentioned in the documentation.
-
Hi @Dave Woodhead,
Also not knowing your exact configuration, the simplest remedy would be to have at least three LDAP configurations (more are possible) run in sequence:
1) Only Create - to create the users (this is what you appear to have)
2) Only Update - to disable (archive) only those users which are disabled (you appear to have a way of telling which users they are - i.e. via either a specific OU or via useraccountcontrol (you appear to have this as well)
3) Only Update - to enable only those users which are NOT disabled (this configuration might also be used to keep the account information fresh in Hornbill; you might have this set up - but without setting up the Account Status to update) - this would require modifying the search to exclude disabled accounts.
HOWEVER:
IF your main (Create) configurations search ONLY contains Active users (i.e. disabled users are not in that OU or are already filtered out here), THEN you "just" have to set "Status" "Action" to "Both" (in your screenshot you have it as "Only Create".
The "problem" with the above solutions is that when the account status is manually changed WITHIN Hornbill, the status will be overridden next time the import utility runs.
-
Hi @Drew Davies,
The value set in Status.Value isn't actually merged with data from the DB. The utility is literally passing through the value set in the configuration file.
It's on my radar - I'll get it added in 2.3.1 (or so; check the CHANGELOG). FYI: there are two places within the utility-code which expect that to be static within the configuration (so it is not as easy as "just merge").
---> added to 2.3.1 : https://github.com/hornbill/goDb2HUserImport/releases/latest
-
Hi @Jeremy& @Paul Alexander,
Are you using the latest utility?
A couple of weeks ago we've discovered an issue with updating the "Attributes" in all of the user import scripts.
In the LDAP utility that was fixed in 3.11.I'm not aware of any issues updating the email field, though.
-
You can have as many LDAP import configurations as you want.
You can run as many import utilities as you want and, more importantly, in whatever order you want.
IF you have two imports configured to populate the same field, and the imports are set up to Update or Both, then, after running both configurations, the data contained within that field will be populated with the data from the SECOND source (provided that source actually has data in it) - as that would have overwritten the data populated by the first source.
IF the second import is NOT configured to populate that field (i.e. it was left empty) then the field will contain the data put in their by the first source.
I hope this helps.
DBAsset Import SQL issue
in Integration Connectors, API & Webhooks
Posted
Hi @QEHNick,
Thanks for that, it is indeed what I needed:-)
From the log file I can tell that your binary/executable is v3.0.0 whereas your configuration file is (still) in the v2.x format.
Either downgrade back to v2.4 of the asset import utility or migrate your configuration to the new configuration format (you will notice that predominantly the top area of the configuration has changed).