Ben Maddams Posted April 25 Share Posted April 25 Hi all, We had working jobs being processed until just recently, I've attempted to run them and receive the following: Package is not cached, downloading package from library: /secure-content/download/YVPbyO8puhB2A2VOqiOzw3MP3JT2XpjTVer_ZwEODw3owP7pTYcK1u-CYP1Khdw47B7318y3hdCQRwkFHffL_ftMfZxVewXLhty-BC3O--Iu90Fu3Y_dPb0dKlpxgxqs9gwa839TcBEC46K1MSM7-_leOcv_aGtuBnBCtfAgvXumnTUIfD9IviHeyLtDinoHzLBZpGFnkMSfcMu7XYMe12_RrSBuynY6fEr4ZlDel4KP Remote job creation failed. It was not possible to connect to the remote system. HRESULT: 0x80338005. Deferred until 2024-04-25 11:53:17Z Can anyone suggest a reason for this? I couldn't find a reference to the error code in the ITOM documentation, and the log files don't appear to have anything regarding this job run attempt in them. Many thanks, Ben Link to comment Share on other sites More sharing options...
Ben Maddams Posted April 25 Author Share Posted April 25 Hi all, We had working jobs being processed until just recently, I've attempted to run them and receive the following: Package is not cached, downloading package from library: /secure-content/download/YVPbyO8puhB2A2VOqiOzw3MP3JT2XpjTVer_ZwEODw3owP7pTYcK1u-CYP1Khdw47B7318y3hdCQRwkFHffL_ftMfZxVewXLhty-BC3O--Iu90Fu3Y_dPb0dKlpxgxqs9gwa839TcBEC46K1MSM7-_leOcv_aGtuBnBCtfAgvXumnTUIfD9IviHeyLtDinoHzLBZpGFnkMSfcMu7XYMe12_RrSBuynY6fEr4ZlDel4KP Remote job creation failed. It was not possible to connect to the remote system. HRESULT: 0x80338005. Deferred until 2024-04-25 11:53:17Z Can anyone suggest a reason for this? I couldn't find a reference to the error code in the ITOM documentation, and the log files don't appear to have anything regarding this job run attempt in them. Many thanks, Ben Link to comment Share on other sites More sharing options...
Steve G Posted April 25 Share Posted April 25 Hi @Ben Maddams, According to the error, your SIS is unable to connect to the job target machine, as that message comes back to the instance from the SIS itself, and your SIS was able to pull the copy of the package from your instance. Quote Remote job creation failed. It was not possible to connect to the remote system. This would suggest that the target is maybe switched off or you have a local DNS or network issue in play. Cheers, Steve Link to comment Share on other sites More sharing options...
Ben Maddams Posted April 25 Author Share Posted April 25 Just to add some troubleshooting: The target machines for the job are both show as available under the ping/DNS checks under the managed device inventory. The authorising account hasn't changed since running succesfull jobs. The EpSis Service is running as normal and the SIS server is up and contactable. Link to comment Share on other sites More sharing options...
Steve Giller Posted April 25 Share Posted April 25 (I merged the double-post) Link to comment Share on other sites More sharing options...
Graham Posted April 25 Share Posted April 25 @Ben Maddams Hi Ben The error code 0x80338005 is coming back from the operating system, specifically the WinRM system. As a first diagnostic, on the machine you are trying to connect to (i.e. the target of the job, not the SIS server itself), can you run, from an elevated command prompt: winrm qc and post what the result is? The ping and DNS checks you mention only apply at the time of device discovery - they are not a "live" check in that sense. 1 Link to comment Share on other sites More sharing options...
Ben Maddams Posted April 25 Author Share Posted April 25 @Graham @Steve G The machine is on (its our main DC) and returns the following: WinRM service is already running on this machine. WinRM is already set up for remote management on this computer. I don't believe anything has changed on our side. Cheers, Ben Link to comment Share on other sites More sharing options...
Graham Posted April 25 Share Posted April 25 @Ben Maddams In that case, what does winrm id say? Again, this is run on the target computer from an elevated prompt. Link to comment Share on other sites More sharing options...
Ben Maddams Posted April 25 Author Share Posted April 25 @Graham I'm getting this back: IdentifyResponse ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd ProductVendor = Microsoft Corporation ProductVersion = OS: 10.0.14393 SP: 0.0 Stack: 3.0 Link to comment Share on other sites More sharing options...
Graham Posted April 25 Share Posted April 25 @Ben Maddams That indicates that WinRM is working OK on the target. Do you get problems running jobs against other targets? There's been no SIS software releases recently, so the most likely explanation is that something has changed on your side - we just have to find out what! Can you also run winrm id on the SIS server please, just to check? Link to comment Share on other sites More sharing options...
Ben Maddams Posted April 25 Author Share Posted April 25 @Graham Same results on the SIS server. I've only got the one target I can run against - We've got our admin box (hosting SIS) and the DC as the target. Selecting our admin box as the target provides the same error code. Link to comment Share on other sites More sharing options...
Graham Posted April 25 Share Posted April 25 @Ben Maddams Can you re-run the discovery of the target, with the Protocol set to Auto? Let's see what that does. It does look like something odd is going on with WinRM, but I'm unable to replicate it here. A discovery protocol of Auto will try using both DCOM and WinRM, so hopefully DCOM will work. Link to comment Share on other sites More sharing options...
Ben Maddams Posted April 26 Author Share Posted April 26 @Graham As the target has had a recent job attempted on it I'm going to have to wait for the time-out period to expire, as I can't unmanage a device that has recently had a run attempt on it. I'll try a little later today. Link to comment Share on other sites More sharing options...
Graham Posted April 26 Share Posted April 26 @Ben Maddams You won't need to unmanage the device to run the discovery. There's something strange going on with the connection to the target, and I'm hoping that the discovery results will shed some light on what is happening. Link to comment Share on other sites More sharing options...
Ben Maddams Posted April 26 Author Share Posted April 26 @Graham I reran Discovery on both machines, the admin box updated fine, but this was the result from the DC. Standalone processing started. Process ID: 18500 Payload processing started as Local System. PID: 27948 09:58:42 Starting Hornbill Discovery Tool (build 3381, x64) run at 2024-04-26 08:58:42Z 09:58:42 Using SIS context (instance=rbgkew, sis=Hornbill SIS Integrations) 09:58:43 Discovery job ID: 63 09:58:43 Scan mode: list 09:58:43 Using dynamic threading 09:58:43 List discovery: XXXXXX 09:58:43 Ping required for scan: Yes (hop count=30, timeout=5) 09:58:43 Discovery probe protocol: Auto 09:58:44 Discovery username: XXXXXXX 09:58:44 Scan found 1 computers for detailed discovery 09:58:44 Performing DNS lookups on 1 computers 09:58:44 Using 1 threads 09:58:44 DNS lookups complete. checked=1, resolved=1, failed=0 09:58:45 Running ping check on 1 computers, timeout=5000ms, hops=30) 09:58:45 Using 1 threads 09:58:45 Pinging XXXXXX => 10.4.1.1 09:58:45 Ping checks complete. checked=1, responded=1, failed=0 09:58:47 Performing discovery of 1 computers 09:58:47 Using 1 threads 09:58:47 Performing WMI probe for XXXXXXXX 09:58:47 Performing SSH probe for XXXXXXXX 09:59:08 Discovery information probe for XXXXXXX failed (time taken 21s) 09:59:08 Merging discovery results 09:59:09 Discovery results merged 09:59:09 Discovery time taken: 22 seconds 09:59:09 Starting discovery data upload 09:59:09 Generating discovery log 09:59:09 Adding discovery log 09:59:09 Adding computers 09:59:09 Adding hardware vendors 09:59:10 Adding software vendors 09:59:10 Archived discovery data: 1 computers, 0 hardware vendors, 0 software vendors 09:59:10 Starting discovery data upload 09:59:10 Discovery data archive is 946 bytes 09:59:10 Uploading discovery data to /sis/discovery/job_63.zip 09:59:11 Discovery data uploaded 09:59:11 Notified instance to initiate data discovery import process 09:59:11 Generating summary Summary ======= Information Acquisition Failure ------------------------------- XXXXXX: WinRM: HRESULT: 0x80338005. DCOM: Access is denied. SSH: Failed to connect. Failed to establish initial TCP/IP connection All Computers ------------- XXXXXX: WinRM: HRESULT: 0x80338005. DCOM: Access is denied. SSH: Failed to connect. Failed to establish initial TCP/IP connection The discovery was executed successfully. The results are now being imported. Link to comment Share on other sites More sharing options...
Graham Posted April 26 Share Posted April 26 @Ben Maddams That's helpful, thanks. 'Auto' will also try to connect via SSH, but as most Windows servers don't have SSH enabled, that failure can be ignored. The WinRM connection issue is the one we see when running the job, so that too is expected in this case. However, the 'Access denied' for DCOM is interesting. I think the next step is to check the credentials used for the discovery. Have they been changed in Keysafe, or have users/passwords been changed on the target? Link to comment Share on other sites More sharing options...
Graham Posted April 26 Share Posted April 26 @Ben Maddams If you still have them, it would be useful to see what the results were from previous discovery jobs. You can filter the job queue by type and so limit it to just discoveries. Link to comment Share on other sites More sharing options...
Ben Maddams Posted April 26 Author Share Posted April 26 @Graham Looks like the original job completed using WinRM without issue. I'm checking the credentials now. (EDIT Looks like one of our AD admins changed some account details - I've just re-run this under a new keysafe entry and it has worked. Testing onpremAD change jobs now) Standalone processing started. Process ID: 15672 Payload processing started as Local System. PID: 88280 15:51:12 Starting Hornbill Discovery Tool (build 3381, x64) run at 2024-02-23 15:51:12Z 15:51:13 Using SIS context (instance=rbgkew, sis=Hornbill SIS Integrations) 15:51:13 Discovery job ID: 1 15:51:13 Scan mode: list 15:51:13 Using dynamic threading 15:51:14 List discovery: XXXXXx 15:51:14 Ping required for scan: Yes (hop count=30, timeout=5) 15:51:14 Discovery probe protocol: WinRM 15:51:14 Discovery username: XXXXXX 15:51:14 Scan found 1 computers for detailed discovery 15:51:15 Performing DNS lookups on 1 computers 15:51:15 Using 1 threads 15:51:15 DNS lookups complete. checked=1, resolved=1, failed=0 15:51:16 Running ping check on 1 computers, timeout=5000ms, hops=30) 15:51:16 Using 1 threads 15:51:16 Pinging XXXXX => 10.4.1.1 15:51:16 Ping checks complete. checked=1, responded=1, failed=0 15:51:18 Performing discovery of 1 computers 15:51:18 Using 1 threads 15:51:18 Performing WMI probe for XXXXXX 15:51:25 Discovery information probe for XXXXXX completed OK (time taken 7s) 15:51:26 Merging discovery results 15:51:27 Discovery results merged 15:51:27 Discovery time taken: 9 seconds 15:51:27 Starting discovery data upload 15:51:27 Generating discovery log 15:51:28 Adding discovery log 15:51:28 Adding computers 15:51:28 Adding hardware vendors 15:51:28 Adding software vendors 15:51:29 Archived discovery data: 1 computers, 1 hardware vendors, 5 software vendors 15:51:29 Starting discovery data upload 15:51:29 Discovery data archive is 4823 bytes 15:51:29 Uploading discovery data to /sis/discovery/job_1.zip 15:51:30 Discovery data uploaded 15:51:30 Notified instance to initiate data discovery import process 15:51:30 Generating summary Summary ======= Successful Discovery -------------------- XXXXXX All Computers ------------- XXXXXXX: Success The discovery was executed successfully. The results are now being imported. 15:51:40 Starting the discovery import process 15:51:41 Opening import archive 15:51:41 Data discovery source: sis:Hornbill SIS Integrations 15:51:41 Device XXXXXX is being added to the inventory 15:51:43 Deleting discovery import file 15:51:43 Added: 1 15:51:43 Updated: 0 15:51:43 Skipped: 0 15:51:44 Missing: 0 15:51:44 Failed: 0 15:51:44 Discovery import complete Link to comment Share on other sites More sharing options...
Graham Posted Thursday at 11:00 Share Posted Thursday at 11:00 @Ben Maddams Hi Ben, Just a quick follow-up on this. Are your jobs now running OK? Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now