6 Replies Latest reply on Dec 13, 2016 2:31 AM by FrugalRain

    Replication is failing on .*.xml files

    Rookie

      Our replicators are all failing on the same files, I assume this is because there is no MIME type for .*.xml files, and there is no way to add a MIME type for them in IIS. These are Adobe files create with AAMEE, and for the time being i can just manually copy them over, but this would be nice to figure out.

       

       

      A couple examples from the replicator log:

      Failed to download file \\<servername>\LDLogon\Software\Windows\Adobe CS6 Base\Build\Patches\AdobeIllustrator16-mul_x64_16.5\payloads\AdobeIllustrator16zh_TWLanguagePack_x64-171112152641\AdobeIllustrator16zh_TWLanguagePack_x64-171112152641.boot.xml

      Failed to download file \\<servername>\LDLogon\Software\Windows\Adobe CS6 Base\Build\Patches\AdobeIllustrator16-mul_x64_16.5\payloads\AdobeIllustrator16zh_TWLanguagePack_x64-171112152641\AdobeIllustrator16zh_TWLanguagePack_x64-171112152641.proxy.xml

      Copied/verified 9142 out of 9258 files

      Duration: 0 hours, 7 minutes, 34 seconds

      One or more files were not copied for this source/target

      Current time: 2016-12-09  06:38:21

       

       

      As you can see there are a LOT of .*.xml files that need to be replicated. I have tried browsing to the files from the replicator like the replication troubleshooting suggests, and since they're .xml files the browser just displays their content, sop i assume its not a permissions issue. I have already created MIME types for . and * so that isn't the issue either.

       

       

      We are running LANDesk Management Suite v. 10.0.0.271

        • 1. Re: Replication is failing on .*.xml files
          Jharris3400 Apprentice

          Adding myself to the chain incase an answer is given

          • 2. Re: Replication is failing on .*.xml files
            FrugalRain Apprentice

            We had issues ongoing for a long time with content replication failing at different stages/places.

            Once we switched to using Robocopy via a scheduled task from LANDesk no issues and it cleans the preferred servers content up properly using the mirror switch.

            • 3. Re: Replication is failing on .*.xml files
              Rookie

              That certainly a good workaround as that's how i initially got the content replicated over, however when all replication is complete after I run robocopy, the same package/files that were failing to replicate are failing to be downloaded by the target machine when installing the package. I think this is indicative of an issue with the way LANDesk handles some extensions.

              • 4. Re: Replication is failing on .*.xml files
                FrugalRain Apprentice

                Basic question, but did you reset the hashes on the distribution package itself ? before doing the content replication / robocopy ?

                • 5. Re: Replication is failing on .*.xml files
                  Rookie

                  I had not since the package was created after all replication had been manually completed by a robocopy, but i just did in case that was it. After doing so the package still fails as it did before the hash reset.

                   

                  Mon, 12 Dec 2016 10:47:14 ******* sdclient starting to process task *******

                  Mon, 12 Dec 2016 10:47:14 Task id to process: 5912

                  Mon, 12 Dec 2016 10:47:14 Command line: /policyfile="C:\ProgramData\LANDesk\Policies\CP.5912.RunNow._V&#47jLNw4btFro9819a6IBy6m09tI=.xml"

                  Mon, 12 Dec 2016 10:47:35 The nostatus flag has NOT been set.

                  Mon, 12 Dec 2016 10:47:35 Core name '<coreserver>' obtained from the registry

                  Mon, 12 Dec 2016 10:47:35 Sending task status, cmd line -coreandip=<coreserver> -taskid=5912 -retcode=229392442 "-ldap=<LDAP_User_Path>" -pkgid=1224

                  Mon, 12 Dec 2016 10:47:36 File (http://<coreserver>/ldlogon/Software/Windows/Adobe CS6 Base/Build/Adobe CS6 Base.msi) is cached locally

                  Mon, 12 Dec 2016 10:47:37 The nostatus flag has NOT been set.

                  Mon, 12 Dec 2016 10:47:37 Core name '<coreserver>' obtained from the registry

                  Mon, 12 Dec 2016 10:47:37 Sending task status, cmd line -coreandip=<coreserver> -taskid=5912 -retcode=229392444 "-ldap=<LDAP_User_Path>" -pkgid=1224

                  Mon, 12 Dec 2016 10:47:39 About to call DownloadFiles (2834 files) with these settings:

                  Mon, 12 Dec 2016 10:47:39 m_allowedBandwidthWAN: 85

                  Mon, 12 Dec 2016 10:47:39 m_allowedBandwidthLAN: 95

                  Mon, 12 Dec 2016 10:47:39 m_discardPeriodSeconds: 604800

                  Mon, 12 Dec 2016 10:47:39 m_preserveDirectoryStructure: 1

                  Mon, 12 Dec 2016 10:47:39 m_bUseWanBWForPush: 0

                  Mon, 12 Dec 2016 10:47:39 m_bSynchronize: 0

                  Mon, 12 Dec 2016 10:47:39 Allowed download methods(m_downloadControl):

                  Mon, 12 Dec 2016 10:47:39 PeerOneSource

                  Mon, 12 Dec 2016 10:47:39 Peer

                  Mon, 12 Dec 2016 10:47:39 Source

                  Mon, 12 Dec 2016 10:47:39 m_preferredServerControl: AttemptPreferredServer

                  Mon, 12 Dec 2016 10:47:55 GetPreferredServerList(called on http://<coreserver>/ldlogon/Software/Windows/Adobe CS6 Base/Build/Patches/AdobeDreamweaverCS6-12_12.0.3/payloads/AdobeDreamweaver12cs_CZLanguagePack-071212141502/AdobeDreamweaver12cs_CZLanguagePack-071212141502.boot.xml) returned:

                  Mon, 12 Dec 2016 10:47:55 <coreserver>

                  Mon, 12 Dec 2016 10:47:55 Putting preferred servers in the following order by time:

                  Mon, 12 Dec 2016 10:47:55 <coreserver> (5430)

                  Mon, 12 Dec 2016 10:47:55 Updating system environment variable LDMS_PREFERRED_SERVER: <coreserver>

                  Mon, 12 Dec 2016 10:47:56 DoDownloadFromSourceSteps: DOWNLOAD_ERROR_GENERAL_FAILURE

                  Mon, 12 Dec 2016 10:47:56 Download Error: err=1, path=http://<coreserver>/ldlogon/Software/Windows/Adobe CS6 Base/Build/Patches/AdobeDreamweaverCS6-12_12.0.3/payloads/AdobeDreamweaver12cs_CZLanguagePack-071212141502/AdobeDreamweaver12cs_CZLanguagePack-071212141502.boot.xml

                  Mon, 12 Dec 2016 10:47:56 processing of package is complete, result -1918107543 (0x8dac0069 - code 105)

                  • 6. Re: Replication is failing on .*.xml files
                    FrugalRain Apprentice

                    Sorry bit confused -  sounds like you run the replication using robocopy then reset package hashes, that wont work in that order.

                     

                    Every time i have trouble like this i start from the core server and go through step by step in following order to ensure packet hashes are correct everywhere..

                     

                    1. Console on Core Server - Reset package hashes on the distribution package itself.

                    2. Console on Core Server - use Landesk content replication to replicate the necessary files onto our replication server

                    3. Run task from Landesk to update all preferred servers in regional offices using robocopy. (Robocopy all files from replication server to preferred servers which includes hash files)

                     

                    This maybe what your doing but just wanted to be clear to try and help:)