locked
All App-V packages are failing to migrate. RRS feed

  • Question

  • I am having a similar problem as this thread.  Basically all App-V packages are failing to migrate.  The migmctrl.log contains:

    WARNING: [Worker]:                                 Failed to connect to share \\server\ApplicationFiles\UniversitySystems\APPV_Nolij_5.0.72\1_NolijProdTesting\Packaged : Error 0x80070056    SMS_MIGRATION_MANAGER    6/3/2013 11:41:55 PM    43512 (0xA9F8)
    [Worker]:                                 Set the status of the entity  Nolij 5.0.72 Production A 2  to Failed.    SMS_MIGRATION_MANAGER    6/3/2013 11:41:55 PM    43512 (0xA9F8)
    [Worker]:                                 Set the status of the job entity  Nolij 5.0.72 Production A 2  to Failed.    SMS_MIGRATION_MANAGER    6/3/2013 11:41:55 PM    43512 (0xA9F8)
    ERROR: [Worker]:                         Microsoft.ConfigurationManagement.Migration.MigrationException: Failed to connect to share \\Server\ApplicationFiles\UniversitySystems\APPV_Nolij_5.0.72\1_NolijProdTesting\Packaged : Error 0x80070056     at Microsoft.ConfigurationManagement.MigrationManager.ConnectionHelper.ConnectToShare(IMigrationSiteInfo siteMapping, String share)     at Microsoft.ConfigurationManagement.MigrationManager.AppVMigrator.MigrateAppVPackages(String objectPath, String contentDest)     at Microsoft.ConfigurationManagement.MigrationManager.AppVMigrator.MigrateObject(MIG_Entity entity)     at Microsoft.ConfigurationManagement.MigrationManager.Migrator.<get_ExecutionPlan>d__0.MoveNext()    SMS_MIGRATION_MANAGER    6/3/2013 11:41:55 PM    43512 (0xA9F8)

    ERROR: [MigMCtrl]: FAILED to EXECUTE job. error = Unknown error 0x80131500, 80131500    SMS_MIGRATION_MANAGER    6/3/2013 11:41:56 PM    43512 (0xA9F8)

    We are not using DFS on our servers though.  In the same thread it suggests to change the MIG_SiteInfo table Account column to NULL after a data gathering job.  I think this column is already set to null on my database.  Am I looking in the wrong place?

    Tuesday, June 4, 2013 6:11 AM

Answers

  • Hi Misha,

    I encountered the same issues as your OP in this thread, and the workaround presented in this other thread did work for me:

    http://social.technet.microsoft.com/Forums/en-US/configmanagermigration/thread/0e831d02-fa16-4ad8-b3c2-f2e55b35df0a

    Your screenshot above is not the correct view, though.  This unfortunately cumbersome procedure did work for me:

    1.  Attempt a migration of App-V package and observe the failure, verify the error code is as you posted in the screenshot.

    2.  Force a gather data from source hierarchy operation

    3.  Fire up SQL Management Studio and connect to the 2012 Site DB

    4.  Locate the MIG_SiteInfo table in the 2012 Site DB as you have done in the screenshot

    5.  Right click MIG_SiteInfo and choose 'Select top 1000 rows'

    6.  Confirm in the returned result set that the 'Account' column is blank (empty)

    7.  Right click MIG_SiteInfo again and choose 'Edit top 200 rows'

    8.  Scroll to the right and select any field that has the value NULL (text may appear italicized), and right click and select copy

    9.  Select, right click and select paste on the the 'Account' column field.

    10. Press the ENTER key to save the changes

    11. Verify the change took effect by switching back to the tab that was created for step 5 and pressing the 'execute' button again, or alternatively perform step 5 again.

    12. Back in the SCCM 2012 console, restart the Migration job that failed on the App-V packages

    It is crucial that you verify the field says null in step 11, and that you DO NOT run the 'gather' process or create a new migration job between steps 11 and 12.  If you run gather again after the database edits or create a new migration job after the edit, the change will be lost and the App-V package migration will fail again.

    This seemed to work enough to get me through migration of my App-V packages.  Unfortunately, it appears migrating App-V packages does not migrate deployments like regular package migration does.  The documentation basically states that the newly created Application object in 2012 creates deployment types based on the existing advertisements in 2007, but does not seem to create the actual deployments themselves, at least this is what happened on every App-V package I was able to migrate.  Perhaps this is another bug or simply a poor documentation effort by Microsoft.  I will be re-creating the deployments to the necessary collections manually.

    Hopefully this helps!

    - Joel

    EDIT:  In the advertisements section of the TechNet article: http://technet.microsoft.com/en-us/library/gg712672.aspx#Plan_Migrate_content it does mention this:  You cannot migrate advertisements for virtual packages. This is an exception to the migration of advertisements.  So I suppose it is technically documented, and this does not appear to be a bug.  I'm guessing its because the system isn't capable of performing the automatic conversion to an Application and then deciding which deployment type belongs where.


    • Edited by Joel Nolan Saturday, June 8, 2013 7:14 PM
    • Marked as answer by Misha Rudiy Tuesday, June 11, 2013 2:39 PM
    Saturday, June 8, 2013 6:27 PM

All replies

  • manually editing the database is totally unsupported. Have you tried changing the source location for one of the packages? That way you can easily verify if it is current source location causing the issue. What permissions do you have on the share?

    Kent Agerlund | My blogs: blog.coretech.dk/kea and SCUG.dk/ | Twitter: @Agerlund | Linkedin: Kent Agerlund | Mastering ConfigMgr 2012 The Fundamentals

    Tuesday, June 4, 2013 9:30 AM
  • 0x80070056 = The specified network password is not correct.

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

    Tuesday, June 4, 2013 2:31 PM
  • I have not tried to change the source location of the App-V packages because all driver packages and regular software packages that were on the same source location migrated over just fine.
    Tuesday, June 4, 2013 2:34 PM
  • Hi Misha,

    I encountered the same issues as your OP in this thread, and the workaround presented in this other thread did work for me:

    http://social.technet.microsoft.com/Forums/en-US/configmanagermigration/thread/0e831d02-fa16-4ad8-b3c2-f2e55b35df0a

    Your screenshot above is not the correct view, though.  This unfortunately cumbersome procedure did work for me:

    1.  Attempt a migration of App-V package and observe the failure, verify the error code is as you posted in the screenshot.

    2.  Force a gather data from source hierarchy operation

    3.  Fire up SQL Management Studio and connect to the 2012 Site DB

    4.  Locate the MIG_SiteInfo table in the 2012 Site DB as you have done in the screenshot

    5.  Right click MIG_SiteInfo and choose 'Select top 1000 rows'

    6.  Confirm in the returned result set that the 'Account' column is blank (empty)

    7.  Right click MIG_SiteInfo again and choose 'Edit top 200 rows'

    8.  Scroll to the right and select any field that has the value NULL (text may appear italicized), and right click and select copy

    9.  Select, right click and select paste on the the 'Account' column field.

    10. Press the ENTER key to save the changes

    11. Verify the change took effect by switching back to the tab that was created for step 5 and pressing the 'execute' button again, or alternatively perform step 5 again.

    12. Back in the SCCM 2012 console, restart the Migration job that failed on the App-V packages

    It is crucial that you verify the field says null in step 11, and that you DO NOT run the 'gather' process or create a new migration job between steps 11 and 12.  If you run gather again after the database edits or create a new migration job after the edit, the change will be lost and the App-V package migration will fail again.

    This seemed to work enough to get me through migration of my App-V packages.  Unfortunately, it appears migrating App-V packages does not migrate deployments like regular package migration does.  The documentation basically states that the newly created Application object in 2012 creates deployment types based on the existing advertisements in 2007, but does not seem to create the actual deployments themselves, at least this is what happened on every App-V package I was able to migrate.  Perhaps this is another bug or simply a poor documentation effort by Microsoft.  I will be re-creating the deployments to the necessary collections manually.

    Hopefully this helps!

    - Joel

    EDIT:  In the advertisements section of the TechNet article: http://technet.microsoft.com/en-us/library/gg712672.aspx#Plan_Migrate_content it does mention this:  You cannot migrate advertisements for virtual packages. This is an exception to the migration of advertisements.  So I suppose it is technically documented, and this does not appear to be a bug.  I'm guessing its because the system isn't capable of performing the automatic conversion to an Application and then deciding which deployment type belongs where.


    • Edited by Joel Nolan Saturday, June 8, 2013 7:14 PM
    • Marked as answer by Misha Rudiy Tuesday, June 11, 2013 2:39 PM
    Saturday, June 8, 2013 6:27 PM
  • Thanks for the detailed instructions Joel.
    Tuesday, June 11, 2013 2:41 PM