Graham

Hi @Sam P Unfortunately, we can't add the Outcome column to the job queue. The reason for this is that the Outcome from a job r is not part of ITOM itself, but just one of the output parameters from the some of the packages in the Hornbill Package Library. The column would have no meaning for discovery jobs or any library or customer package that did not include this output parameter. It's been discussed internally, and the problem is that the Powershell scripts inside the packages are returning a success code even if one of the operations fails, and while this might seem incorrect, there are some valid reasons for this implementation. However, all is not lost. There is a change that is being considered that will allow the job to report a failure from an operation within the package. Nothing confirmed yet, but I'll be able to update you in the New Year. Graham

Hi @Sam P To follow up on this, it's now with the development team and an update to the package is expected early next week. Graham

Hi @Sam P Thanks for the update. It looks like you're doing all the right things, so in the first instance, I think we'll need to take a look at the operations inside the User Update package and make sure those are working as expected. Graham

Hi @Sam P So we can best understand what's going on, would you mind clarifying how you're processing the expiry date/time once it's been generated? Are you calling one of the ITOM packages and passing this value as a parameter? Graham

Hi @Sam P Yes, it is fully compatible with Server 2022. Apologies for the documentation oversight - this has now been corrected.

@JanS2000 The package is calling the Powershell cmdlet "Get-ADUser", passing in the value of the MemberIdentify parameter as the value of the -Identity parameter to the cmdlet and it's that part which is failing. I understand the redactions, and while I'm not asking you to "unredact" them, can you confirm that the value passed into the job is one of: A distinguished name An object GUID A security identifier A SAM account name

@JanS2000 No, the Group Management package is the one you need. That's me leading you astray by asking the wrong question! I should have asked about the Group Management package! Assuming that's on version 14 (the latest), then it would appear that the problem is that the user you're trying to add can't found. There's two possible reasons for that: either the user doesn't exist or the package is querying the wrong directory server. Which domain is the user you're trying to add in and which domain is the SIS server itself in?

@JanS2000 Let's check the version of the package first, and make sure that's up to date. Within ITOM, if you go to Package Management -> Installed Packages, what version do you see for Active Directory User Management? Graham

@JanS2000 Hmmm... That doesn't sound right! Can you post a screenshot of the job setup that's giving you that error? Not sure what you mean by "I couldn't run the discovery as it doesn't detect the virtual server". The discovery is the process that detects the servers on the network, so if the discovery job itself isn't running, that will be for some other reason.

@JanS2000 What was the error? Did the discovery job run? If you can post the output from the job, I may be able offer some further assistance.

@JanS2000 It's certainly possible to discover a virtual server, and you can use the SIS virtual server as the target for your IT Automation jobs. As a first step, you'll need to set up and run a Discovery Job - Hornbill . That will only need to use a Manual List - Hornbill of one computer - the SIS server itself. Once that is discovered, then you can go into the Inventory - Hornbill and mark the discovered server as Managed. In order to run the discovery job, you will need a KeySafe - Hornbill entry of type 'Username + password' that contains valid credentials to connect to the server. Graham

@SJEaton In addition to @Steve Giller 's question, would you mind posting the expression that you're currently using, please?

@Gareth Roberts When the SIS service runs a job remotely, an executable is copied to that remote system, along with the relevant package and the executable is started remotely. This is carried out in part using WMI and the error you are getting indicates that the SIS service is not able to establish a WMI connection to the remote system. The connection is made using the credentials specified in the "Admin" section of the job settings. The first thing I would check is that the service account has permission to connect via WMI to the remote machine. As a diagnostic step, I would suggest adding all permissions for the service account to the root node. If that solves the issue then the permissions can be reduced (I think you will need at least the Enable Account, Execute Methods and Remote Enable permissions) and those permissions can also be applied to just the CIMV2 node. Graham

Hi @Gareth Roberts A couple of initial clarification questions: What do you mean when you say "the service account"? Is this an account that the SIS service is running under? When you say you've added credentials, to where have you added them? Graham

Hi @CraigP We've had a look at this and the API is implementing an incorrect check on the values of the rowStart and maxResults parameters. A fix is being implemented and will be available in an upcoming release of the platform. Graham

@lokent Hmmm.. That's not what I was expecting! So, maybe my assumptions are wrong. How are you creating and running the report?

@lokent The maximum length of a field on the reports is controlled by the value of the reporting.reports.maxFieldLength setting. What value is that set to? Graham

@QEHNick We do have some limits on the size of files that can be added to packages for the free ITOM tier, and the error you're getting is because you are exceeding those limits. Can I ask what you are attaching and what it will be used for? How will the package be processing this file? Graham

@QEHNick A fix for this issue has been released to the live environment.

@QEHNick For the computers that fail the ping, as you have configured discovery to ping them first, they won't be added. For the computers that fail the DNS lookup, discovery will also not add a computer where it can't resolve the name, because it can't connect to that computer and so can't get any inventory information from it. However, that would be one for your network administrators to look at. I would expect that all computers in the domain would be resolvable. It may be that the DNS configuration on the ITOM server needs to be reviewed and modified. Are there any other errors in the summary report, apart from the ping and DNS lookup failures?

@QEHNick Are all the objects it's discovering computers? Your comment of "It happily reads the user objects." is making me wonder! What the discovery process is doing is enumerating all the OUs in the top-level container, the OUs within those and so on down the whole OU hierarchy and then, for each OU, extracting all the objects with a category of "computer".

Whereabouts in the console output? Can you post the full line that you are seeing, and ideally a few lines above and below for context? If you click the green button to the top right for the current job, that allows you to re-run the job. It copies all the input parameters, so that will show you the configuration for the current job. As you are using Active Directory for the mode, what do you have for the container? Also, are you seeing this error for every system listed in the summary report?

@QEHNick Where are you seeing this error? This should only apply to executing packages, and not to discovery. For this, can you share the discovery job configuration? In particular, the discovery mode you are using and the related discovery settings?

Hi @QEHNick There should be more detail about the failure in the summary report. This is presented in both the Execution Log tab and the Console Output tabs for the discovery job. The Console Output is the better of the two, as it does not include all the other information related to running the job. The summary groups the discovered computers. What do you have in the "Information Acquisition Failure" section?

Hi @Kevin Allitt You need to include the requestType parameter between the description and customerId parameters. The requestType is a required parameter and so cannot be omitted. See https://api.hornbill.com/apps/com.hornbill.servicemanager/Requests?op=logRequest Graham