Jump to content

Osman

Hornbill Users
  • Posts

    59
  • Joined

  • Last visited

Everything posted by Osman

  1. OK, decided to try one more thing. Recreated the import.cfg after adding the API Rules, it is now working through the Task Scheduler. Thanks Osman
  2. Looks like I am back to square one, the underlying cause of the error on my last post was that there were missing rules in the API Key. I am still getting the following error: 2024/03/18 09:05:16 [WARN] Current version 4.2.0 (patch) is greater than or equal to the latest release version on Github 4.2.0 2024/03/18 09:05:16 [ERROR] Error processing authentication: Decryption of authentication data failed: Key not valid for use in specified state. Having been through the Azure Import documentation again, there is a suggestion that the executable should be in the profile folder of the user that undertook the first run, tested this on the offchance that it would make a difference, still getting the error above. I still don't understand how running from the command line works without issue, but fails as part of a Scheduled Task.
  3. Hi Steve, Did exactly as suggested and it has actually made things worse, I got an error on recreation of the import.cfg of: [ERROR] Error Loading KeySafe Authentication: The API key being used does not have permission to access this keysafe record This has not only broken the User import, but it has also broken all other imports we had setup. Any suggestions? Thanks Osman
  4. Hi Steve, But neither of the conditions in the Documentation: When the user who runs the import is not the same user who first ran the import; When the import is run on a different computer from the one that originally performed the authentication details encryption. Is true in my case, as I have stated at least twice already. It is the same device and using the same user that originally processed it. Also, this does not explain why running the import manually using the command prompt works? Anyway, I will do as suggested. We have three other imports that are also run for other types of user, what impact will it have on those, as they are all running through a schedules task? Thanks Osman
  5. Hi Steve, Which scenario, do you mean: That was from SamS' response of the 7th Feb? If so, I already clarified that both the Scheduled Task and the manual execution of the import are being performed by the exact same account. Thanks Osman
  6. Morning All, I am now having to run this manually on a daily basis, some assistance with the error owuld be appreciated. Thanks Osman
  7. Afternoon All, I am still seeing the same error as posted on the 8th February and I am having to continue to manually run the script, any thoughts? Thanks Osman
  8. Afternoon All, Any further thoughts on this as it has consistently failed again for the last week and only manual triggering has worked? Thanks Osman
  9. Have downloaded 4.2.0 and given it a go, log file now looks like this: 2024/02/08 09:09:53 [WARN] Current version 4.2.0 (patch) is greater than or equal to the latest release version on Github 4.2.0 2024/02/08 09:09:53 [ERROR] Error processing authentication: Decryption of authentication data failed: Key not valid for use in specified state. Thanks
  10. Hi Sam, I suspect the version check logic is broken, as I am reasonably certain 4.1.1 is an older version than 4.2.o, or at least it should be. Will give 4.2.0 a go and will report back. Thanks Osman
  11. Hi Sam, Apologies if I didn't clarify. Both the Scheduled Task and the manual running of the import are both being conducted in the context of the service account. Thanks Osman
  12. Hi Steve, No, it is running as a Service Account created explicitly for this task. From the perspective of setup of the Scheduled Task, nothing has changed. Thanks
  13. Afternoon All, A bit of a weird one. The Azure Import for users has been working happily for some time now. However, over the last month or two the process is falling on the Scheduled Task and the content of the log file is: 2024/02/07 14:08:15 [MESSAGE] ---- Azure Import Utility v4.1.1 ---- 2024/02/07 14:08:15 [MESSAGE] Flag - config goAzure2HUserImport 2024/02/07 14:08:15 [MESSAGE] Flag - logprefix 2024/02/07 14:08:15 [MESSAGE] Flag - dryrun false 2024/02/07 14:08:15 [MESSAGE] Flag - instanceid 2024/02/07 14:08:15 [MESSAGE] Flag - apitimeout 60 2024/02/07 14:08:15 [MESSAGE] Flag - workers 1 2024/02/07 14:08:15 [MESSAGE] Flag - forcerun true 2024/02/07 14:08:15 [WARN] Current version 4.1.1 (patch) is greater than the latest release version on Github 4.2.0 2024/02/07 14:08:15 [MESSAGE] Loading KeySafe Authentication Data: 13 However, if I run this directly from the command line, which in essence is exactly the same thing, it works without issue. Any ideas? Thanks Osman
  14. Hi Steve, Within a Incident or Service Request, under the Details node, there is the option at the bottom to preview the generating email. There used to be, on a previous instance of the UI, a Back button to return to the ticket, this seems to have dissapeared. Thanks Osman
  15. Afternoon All, Looks like since the new UI has been released the back button has disappeared from the email view, see below: Is this by design, or is there a setting available to reinstate it? Thanks Osman
  16. Hi Gerry, I am not sure that I would say bypass it altogether, I am thinking more that we would have either: - A url that uses SSO without choice of direct login that we would be able to publish internally; - The sign in page has a detection method that can see that the browser is signed in with a valid SSO account and sign straight in without displaying the options. We have other SAAS systems that are capable of doing this, our room booking system for example. Thanks Osman
  17. Thanks Gerry, Unfortunately, it is already off:
  18. Morning All, I am reasonably certain that this has been asked for before, I just can't find it in the community. When we access our SSO url, in a browser that has an active, signed in session, we are always presented with the Single Sign-On/Direct Login options. Is there any way to adjust this so that the system detects the signed in status of the browser and immediately provides access? This is more of an issue for Basic users accessing the portal. Thanks Osman
  19. Hi Nanette, I should have said, yes I did. I have subsequently received more information from the person that reported this to me and the underlying cause was a duplicated email address....don't ask. Thanks for your assistance Osman
  20. Morning All, This is a bit weird. I have been advised that a User has not able to access the self-service portal. I have checked the sync log and can see that there are the following entries: 2023/11/02 03:02:58 [DEBUG] Azure User ID: '{UserID}' NOT Found 2023/11/02 03:02:59 [DEBUG] User Create: {UserID} ({UserID}) 2023/11/02 03:02:59 [ERROR] Unable to Create User: {UserID} Error: User already exists with account status: archived I have checked the database, user doesn't exist. I have manually eyeballed the user list, user doesn't exist. I have attempted to manually re-add the user, and get an error that the user exists in an Archived state. Any advice would be welcomed as to how I can re-activate the user? Thanks Osman
  21. Hi All, With other ITSM's I have been lucky enough to administer there have been methods by which I was able to allow the Service Desk to create quick tickets for regular requests and incidents. I believe I can do the same simply by creating Workflows that pre-populate specific fields. What I would like to know is whether it is possible to publish these quick tickets in a Service Desk, or IT only area? Ideally, I would like a Portal similar to the user facing Self-Service portal but with the previously mentioned quick tickets linked. On the face to it, the only way I can think of to achieve this would be to create a new Service in the Service Portfolio and limit it to the IT Teams that would use it and then add the Quick Ticket workflows to that Service. Any other suggestion/ideas? Thanks Osman
  22. Thanks, much appreciated, I will give it a go.
  23. Afternoon All, Hopefully a simple one. I need to be able to respond to any user that emails into a Closed Incident or Service Request advising it has been closed and suggesting they log a new ticket. I found: And assume if I disable these it will stop updates happening, but I also want an email sent. Can this be done? Thanks Osman
  24. Hi Steve, Thanks for this, all sorted. Looks like the old exe was still working, I actually put a typo in the Client ID when updating the conf.json after creating a new Secret when it had expired in AAD. I have now moved over to the new exe anyway as I assume the new security process will eventually be mandatory. Thanks Osman
  25. Hi Steve, Have downloaded the tool and attempted to get it working, but the documentation isn't particularly clear on what authentication information is required to be added to the conf.json. As each time I do a -dryrun it is asking for the Instance ID and API key even though I have specified a conf.json with the information included? Thanks Osman
×
×
  • Create New...