locked
Gathering package status fails RRS feed

  • Question

  • Hallo,

    I've got a huge problem wih the Data Gathering: It fails most of the time. My 2007 infrastructure consists of a Central Site and 50 (!) Child Primary Sites. The 2012 CAS just has to gather a part of the 2007 Primary Sites, but it's just sometimes successful. If I disable distribution point sharing, Gathering needs a few minutes and is successful. With distribution point sharing enabled, it fails all the time.

    I checked permissions on local machine of Primary Site, on SQL-server and on console. But please, could you repeat, how it should look like?

    Failures in the migmctrl.log:

      ERROR: [Worker]:                                 Failed to execute:                       WHILE (1 = 1)                      BEGIN                          MERGE TOP (1000) PkgServers_G AS C                          USING   (  SELECT                                       ps.PkgID, NALPath = dps.PkgServerFQDN, SiteCode = @CurrentSiteCode, SiteName = @CurrentSiteCode, SourceSite = @CurrentSiteCode, ps.LastRefresh,                                       ps.RefreshTrigger, 0 AS UpdateMask, 0 AS Action, ps.ISVData                                      FROM #MIG_PkgServers ps                                      JOIN #MIG_DistributionPointSource dps ON ps.NALPath = dps.PkgServer                                      WHERE PkgID in (                                          SELECT PkgID collate SQL_Latin1_General_CP1_CI_AS from dbo.SMSPackages_L                                          UNION                                          SELECT V4PkgID FROM MIG_AppVPackageMapping)                                  ) AS T                          ON      (C.PkgID = T.PkgID AND C.NALPath = T.NALPath AND C.SiteCode = T.SiteCode)                          WHEN    NOT MATCHED THEN                              INSERT  (PkgID, NALPath, SiteCode, SiteName, SourceSite, LastRefresh,                                       RefreshTrigger, UpdateMask, Action, ISVData)                              VALUES (T.PkgID, T.NALPath, T.SiteCode, T.SiteName, T.SourceSite, T.LastRefresh,                                       T.RefreshTrigger, T.UpdateMask, T.Action, T.ISVData)                          WHEN    MATCHED AND (                              C.SiteName != T.SiteName                              OR C.SourceSite != T.SourceSite                              OR C.LastRefresh != T.LastRefresh                              OR C.RefreshTrigger != T.RefreshTrigger                              OR C.UpdateMask != T.UpdateMask                              OR C.Action != T.Action                              OR C.ISVData != T.ISVData                              ) THEN                              UPDATE SET                                  C.SiteName = T.SiteName,                                  C.SourceSite = T.SourceSite,                                  C.LastRefresh = T.LastRefresh,                                  C.RefreshTrigger = T.RefreshTrigger,                                  C.UpdateMask = T.UpdateMask,                                  C.Action = T.Action,                                  C.ISVData = T.ISVData                          WHEN NOT MATCHED BY SOURCE                              AND EXISTS (                                  SELECT * FROM MIG_DistributionPointSource dpsrc                                  WHERE dpsrc.PkgServerFQDN = C.NALPath AND dpsrc.SourceSiteCode = @SourceSiteCode                              )                              AND NOT EXISTS (                                  SELECT * FROM MIG_Job job                                  WHERE Type = 3 AND dbo.fn_GetNALPathFromMIGJobConfiguration(job.AdditionalConfiguration) = C.NALPath                              )                              THEN DELETE ;                             IF @@ROWCOUNT = 0 BREAK                      END

    ERROR: [Worker]:         System.Data.SqlClient.SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.     at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)     at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)     at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)     at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)     at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)     at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)     at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)     at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()     at Microsoft.ConfigurationManagement.MigrationManager.MigrationRepository.BulkCopyData[T](Snapshot snapshot, LegacyRepository legacyRepository, IntlSqlFormatter formatter, Func`2 watermarkFunc, T lastMaxId, Boolean doNotDrop)     at Microsoft.ConfigurationManagement.MigrationManager.MigrationRepository.BulkCopyData[T](Snapshot snapshot, LegacyRepository legacyRepository, IntlSqlFormatter formatter, Func`2 watermarkFunc, T lastMaxId)     at Microsoft.ConfigurationManagement.MigrationManager.SyncAgentJob.<SyncDPSettings>d__5f.MoveNext()     at Microsoft.ConfigurationManagement.MigrationManager.ExtensionMethods.<AttachErrorHandler>d__6`1.MoveNext()

    ERROR: [Worker]: Microsoft.ConfigurationManagement.Migration.MigrationException: 1 exceptions occurred during syncing.     at Microsoft.ConfigurationManagement.MigrationManager.SyncAgentJob.<get_ExecutionPlan>d__7.MoveNext()     at Microsoft.ConfigurationManagement.MigrationManager.Job`1.ExecuteNext()

    ERROR: [MigMCtrl]: FAILED to EXECUTE job. error = Unknown error 0x80131500, 80131500

    What other ideas do you have to resolve this issue?

    Wednesday, April 30, 2014 9:25 AM

Answers

  • Too many primary sites indeed.

    Just to share what helped us last time we faced this, some of the things that helped us get around that 60 minutes timeout during merge operations for data gathering was tweaking MaxDOP and max memory for destination SQL. In our situation, reducing MaxDOP to 1 and reducing max memory to 8GB (or less) for the duration of the data gather with DP sharing enabled gave a much greater rate of success.

    Unfortunately, as more and more DPs got migrated, the success rate for data gathers got lower and lower. By the time we had migrated about 1600 DPs, the success rate became close to zero and had to resort to other methods to finish the migration and migrate the remaining DPs.

    Friday, March 24, 2017 1:07 PM

All replies

  • If I disable distribution point sharing, Gathering needs a few minutes and is successful. With distribution point sharing enabled, it fails all the time.


    I've read about that issue on our MVP mailing list ... let me see if I can find any details.
    Edit: any chance that there are orphaned (secondary) sites (still in the database, no longer visible in the console)? Or that a DP was removed from the database?

    Torsten Meringer | http://www.mssccmfaq.de


    • Edited by TorstenMMVP Wednesday, April 30, 2014 11:58 AM
    Wednesday, April 30, 2014 11:51 AM
  • Yes, we deleted Secondary Sites with preinst.exe. But not on every Primary Site of the failed ones, I think.

    In which table should I look for orphaned sites?

    Is it neccessary, that the CAS can connect all the Child Sites (or Child Site servers) of the 2007 Primary Site?


    Wednesday, April 30, 2014 12:13 PM
  • Did you fond a solution for this? I am having a similar problem.
    Sunday, December 20, 2015 7:26 PM
  • We didn't find a solution. We changed Migration-path because of another Problem we had.

    A guess was, that it got more and more problematic with every Distribution Point we migrated (we had over 600)

    Somebody had the idea to cleanup Migration-Feature in ConfigMgr 2012 and start this again. Maybe this will help you?

    Good luck!

    Monday, December 21, 2015 2:12 PM
  • Additional information:

    In the infrastructure of another client, we migrate from SCCM 2012 to Current Branch. And we have the same issues again.

    2012: CAS, 10 Primary Sites, 150 Distribution Points

    Distribution Point Sharing fails since first day. We worked with Microsoft Support for over 3 months and they weren't able to provide a solution.

    We now changed our migration plan.

    "Migration" is a great feature (not).

    Friday, March 24, 2017 12:26 PM
  • 2012: CAS, 10 Primary Sites, 150 Distribution Points

    ...

    "Migration" is a great feature (not).


    I feel sorry for having to deal with 10 primaries and a CAS ... :-)
    I migrated a CAS with 3 primaries to a standalone primary last month (with DP sharing) and was not running into any issues at all.

    Torsten Meringer | http://www.mssccmfaq.de

    Friday, March 24, 2017 12:50 PM
  • Too many primary sites indeed.

    Just to share what helped us last time we faced this, some of the things that helped us get around that 60 minutes timeout during merge operations for data gathering was tweaking MaxDOP and max memory for destination SQL. In our situation, reducing MaxDOP to 1 and reducing max memory to 8GB (or less) for the duration of the data gather with DP sharing enabled gave a much greater rate of success.

    Unfortunately, as more and more DPs got migrated, the success rate for data gathers got lower and lower. By the time we had migrated about 1600 DPs, the success rate became close to zero and had to resort to other methods to finish the migration and migrate the remaining DPs.

    Friday, March 24, 2017 1:07 PM
  • I worked on the problem for months. Lot of month. With MS support.

    I changed the MaxDOP of Table "DistributionPoints" in Destination Hierarchie from 0 to 1. And it worked. Our Distribution Points are shared now! 0 seems to be a default value, because I didn't change back, but it is changed back (automatically)

    Thanks a lot!!! I already invented another solution for migration, but now we maybe can use the build-in feature. Thank you for posting your experience here!

    Monday, March 27, 2017 9:04 AM
  • You're welcome, let us know if we can help you further.
    Thursday, March 30, 2017 1:33 PM