/build/static/layout/Breadcrumb_cap_w.png

Replication shares NOT WORKING

I am not sure they have ever worked...

It seems that the shares are populated, and they seem to have everything required, but for some unknown reason, I still cannot run patching with a replication share involved! It works everytime when I set "Failover to K1000" or Disable the replication share, but it fails when the replication share is enabled and not set to failover.

 

I have checked passwords, usernames, different methods of typing in usernames, erased the entire share and let it rebuild, and even got support involved, but nothing has been able to resolve it. Anyone else ran across this?

 

The error I get is:

"error (Handshake Failed)"

 

I checked the debug logs and it says the following:

[Wed Sep 25 08:31:40 2013] DownloadSMBFile: unable to copy file from: '\\SERVER\nas_rep/repl2/dell/FOLDER01749242M/1/InvColPC_7.0.46.1.exe.23b61890c58d8b23274c3c1f65b4f939' to: 'C:\ProgramData\Dell\KACE\dell\InvColPC_7.0.46.1.exe': (1326) Logon failure: unknown user name or bad password.

I have also checked and the handshake.LST file comes from the K1000:

 

[Thu Nov 14 10:02:44 2013] DownloadFile: download with no speed limit

[Thu Nov 14 10:02:44 2013] DownloadFile: Downloaded C:\ProgramData\Dell\KACE\patches\HANDSHAKE.LST.gz from http://K1000.domain.com/service/patchhandshake.php?kuid=577A79F4-756A-45A8-B103-BD4573358019&path=windows/ Download speed: 23000.000000 bytes/second

[Thu Nov 14 10:02:44 2013] pluginPatching: DownloadResource: download Required for 'C:\Program Files\Dell\KACE\windependencies.ospx'

[Thu Nov 14 10:02:45 2013] DownloadSMBFile: unable to copy file from: '\\SERVER\nas_rep/repl2/patches/windependencies.ospx.e409b34955e77020d8dec9ca22214354' to: 'C:\Program Files\Dell\KACE\windependencies.ospx': (1326) Logon failure: unknown user name or bad password.

[Thu Nov 14 10:02:45 2013] pluginPatching: VerifyPartChecksum: Part file does not exist 'C:\Program Files\Dell\KACE\windependencies.ospx.part'

[Thu Nov 14 10:02:45 2013] pluginPatching: DownloadPatchEssentials: failed to process '"windependencies.ospx""1""e409b34955e77020d8dec9ca22214354""2073242""smb://user@domain.password@SERVER/nas_rep/repl2/patches/windependencies.ospx.e409b34955e77020d8dec9ca22214354"""' error 99

[Thu Nov 14 10:02:45 2013] pluginPatching: Failed to download and process patch essentials.

[Thu Nov 14 10:06:37 2013] pluginPatching: kpiRecvPayload: adding message to the queue (queued messages=0) len=323 recv='HANDSHAKE

http://K1000.domain.com/service/patchhandshake.php?kuid=577A79F4-756A-45A8-B103-BD4573358019

http://K1000.domain.com/service/kbot_upload.php?machineId=3046&filename=handshake.log.gz&checksum=849a2857a1d4e36c072c12fb83c5a226&mac=577A79F4-756A-45A8-B103-BD4573358019&patchscheduleid=31
Asked 11 years ago 9748 views
1 Comment   [ + ] Show comment
  • Have you checked your ports to make sure they're open between the K1 and the rep share box? We ran into that initially. Also, is your \\SERVER the host name or IP? I would recommend the IP. - nheyne 11 years ago
    • I'm not sure what ports that would be, but the files are getting to the Replication Shares, or else it's filling up with 50+ GB of random files...

      Server is populated using the replication share PC that has the agent installed and I can't control that. - easterdaymatt 11 years ago
      • I should have specified, we had the ports open between the K1 and the rep share box but not from the box to our PCs. So the files were being placed on the rep share, but no one could authenticate to it from their computers. Since you're getting authentication errors specifically, that might be something to pursue. I believe they only need port 80 open but I could be wrong on that. - nheyne 11 years ago
      • You can specify the download path that your PCs will use to reach the rep share, that's what I was referring to with the comment about using the IP. - nheyne 11 years ago
    • I changed the password (had a special character), and I also changed the download path to IP. *crossing my fingers* - easterdaymatt 11 years ago
    • Still no go...I also attempted to map the folder using the user name and password from the download user, and it worked! But i still get "Bad user name or password" at the clients. Trying to download: \\10.1.3.65\so_rep/repl2/patches/windependencies.ospx.e409b34955e77020d8dec9ca22214354 - easterdaymatt 11 years ago

Answers (2)

Posted by: Ronny 10 years ago
Senior White Belt
3

I experienced a very similar issue with my 12 replication shares never completing successfully once I upgraded my K1000 to v5.5. The problem continued even after I upgraded to v6.0 My replication shares would either restart completely or the amount of files/data in the replication queue would fluctuate, increasing or decreasing randomly. Also, when attempting to perform a patch job on my desktops, it would fail with a "Error (Handshake Failed)" status.

I eventually resolved this issue on my own, even though I had worked with KACE support. In my replication share settings, under Destination Share > Path, I used a UNC path of \\ServerA\KACE_Share. I had a User and Password specified. The issue was resolved when I specified a local path of C:\KACE_Share (my replicating device was also storing the replicated data) with no Username and no Password (neither are needed for local paths). Once I made this change, my replications completed successfully and patching from replication shares had no errors. Specifying a UNC path was never an issue before v5.5 and KACE support made no mention of it when they reviewed my replication share settings.

I hope that writing about my experience saves someone else a lot of time. 

Comments:
  • Thank you Ronny! I have been beating my head against a wall for too long on this... Tried local and domain credentials, Windows and Linux servers, contacted Support, hired a KACE trainer... No one could figure this out...
    You are the man! - cbtopher 10 years ago
    • You're welcome. I spent a couple weeks myself trying to figure it out. I'm glad my write-up was understandable and helpful. FYI, I haven't had any issues with replication or patching since my last post. - Ronny 10 years ago
  • The current Admin Guide (http://www.kace.com/~/media/Files/Support/Documentation/K1000/v60/K1000_AG.pdf) still says a UNC path is OK to use but I am also finding it doesn't work the same as before 5.5:

    "Path
    The path the Replication device uses for the Replication Share. Applications are copied from the K1000 to this location. For a local drive, use local drive syntax, for example:
    C:\k1000share
    For a network drive, use UNC format, for example:
    \\kaceRep\k1000share" - RichB 10 years ago
  • If I change the replication share destination to the local drive instead of a UNC path, what are you using for the download share path to that local drive and what user (or blank)? - RichB 10 years ago
    • My Download Share path is a UNC format. It needs to be a UNC because this path is what the agents will use to download patches from. The user I specified was an AD user account that has read-only permission to the share. I did not need to precede the username with my domain name. In other words, for the User field, I have "BillyJean", NOT "My.Domain\BillyJean". - Ronny 10 years ago
      • OK, thanks. I created a new replication share folder on the local hard drive at the root of C called k1000share and then shared that folder with "Everyone" having read capability. I have an AD user account for the download but since everyone can read that share can't the user name and password be left blank with the UNC path to the local share (\\replicationcomputername\k1000share). Isn't there a limit on the concurr3ent users that can be connected to a share like this? The network server UNC path previously used didn't have a limitation but I am concerned about the local share not being avaialble to clients if more than 20 tried to connect. - RichB 10 years ago
      • It's possible that the User field could be left blank, if the Everyone group has access to the share. You'd have to test it to confirm. The limit on concurrent connections to your share is determined by the OS you are running. - Ronny 10 years ago
Posted by: tekCTRL 11 years ago
Third Degree Green Belt
1

I would try and use the SERVER IP address instead of its hostname first. Also in regards to the username and password how are you entering it? Are you adding in the DOMAIN NAME if you're on a domain or WORKGROUP if it is not?

Comments:
  • From what I see you have to select the server from a pulldown that is from the KACE Inventory. It shows the hostname and the ip address when you look at it in the pulldown. - jwanner@myersind.com 10 years ago
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ