locked
App-V Packages fail to migrate all other migration jobs succeed! RRS feed

  • Question

  • Hi,

    We have a new 2012 Standalone Primary site in place. Our old 2007 Primary site is set as the source hierarchy for migration. To test the migration process I have created a bunch of migration jobs for different types of object and all of these migrate successfully except all App-V packages fail.

    Hierarchy configuration is set to use the Machine account of 2012 Site Server.

    All of our content (Native and App-V) is stored on a Domain DFS root.

    The Migmctrl log shows the same error for any App-V package as follows.

                                                                    [Worker]:                                 Migrating AppV package MindGenius V4 (SMS_Package.PackageID=ITS002DD) SMS_MIGRATION_MANAGER 1/19/2013 12:00:13 PM 6192 (0x1830)
                                                                    WARNING: [Worker]:                                 Failed to connect to share \\campus.unn.ac.uk\SCCM\Enterprise\App-V\MindGeniusV4 : Error 0x80070056 SMS_MIGRATION_MANAGER 1/19/2013 12:00:13 PM 6192 (0x1830)


    The Above error comes back as The specified network password is not correct.

    Native (MSI/EXE) based packages stored in the same location migrate fine so access appears to be ok. I have of course checked share access and this looks ok. Running CMD via PSEXEC as system on the site server allows me to navigate the entire tree of the dfs and access all content, so again access appears fine!

    Changing the source hierarchy to use a user account still fails for App-v with a different error:

                                                                    [Worker]:                                 Migrating AppV package SupportWorks Client 7.4.1. AppV (SMS_Package.PackageID=NOR002EF) SMS_MIGRATION_MANAGER 1/19/2013 12:12:48 PM 6192 (0x1830)
                                                                    [Worker]:                                 Impersonation is about to start ... SMS_MIGRATION_MANAGER 1/19/2013 12:12:48 PM 6192 (0x1830)
                                                                    [Worker]:                                 Impersonation succeed, current user identity is: DOMAIN\USERNAME SMS_MIGRATION_MANAGER 1/19/2013 12:12:48 PM 6192 (0x1830)
                                                                    WARNING: [Worker]:                                 Failed to connect to share \\campus.unn.ac.uk\sccm\Enterprise\App-V\Supportworks_741 : Error 0x80070520 SMS_MIGRATION_MANAGER 1/19/2013 12:12:49 PM 6192 (0x1830)

    Which equates to A specified logon session does not exist. It may already have been terminated.

    Again this account has site admin on 2007 and full control over the DFS and all content.

    The final error in Migmctrl after all the above is 

    ERROR: [MigMCtrl]: FAILED to EXECUTE job. error = Unknown error 0x80131500, 80131500 SMS_MIGRATION_MANAGER 1/19/2013 12:18:53 PM 6192 (0x1830)

    Anyone got an ideas where to check next I don't want to manually  move 300 App-V packages.



    • Edited by Philaitman Saturday, January 19, 2013 12:36 PM
    Saturday, January 19, 2013 12:33 PM

Answers

  • I finally received a workaround that I have confirmed will work.  The fix may be included with CU2, but they weren't certain.  The workaround is as follows:

    1. Reconfigure your Data Gathering step to use the computer account (if not already done)

    2. Run the Data Gathering

    3. In the CM12 database, change the MIG_SiteInfo table Account column to NULL (it should be empty before the change)

    4. Perform the migration job(s)

    One huge caveat is, that you cannot rerun a Data Gathering after step 3, or step 4 will fail as it always has.  So if Data Gathering is run (either manually, or through its normal 4 hour progression), you will need to re-follow these steps above to run a successful migration job.

    • Marked as answer by Philaitman Tuesday, April 23, 2013 8:36 AM
    Friday, April 19, 2013 2:26 PM

All replies

  • I haven't seen that error before. Here is what  I would do on a single package (just to test). Change the source location of the package to a local source on the old site server and run the migration once Again. That way we can quickly verify if the issue is related the DFS.

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

    Saturday, January 19, 2013 1:58 PM
  • Thanks for the quick response Kent. I'll try this when im back at the office on Monday am and update this post with the results.

    Saturday, January 19, 2013 3:45 PM
  • Hi,

    Creating a duplicate package on the 2007 site Server migrates sucessfully.

                                                                    [Worker]:                         Migrating object ... SMS_MIGRATION_MANAGER 1/21/2013 9:39:41 AM 6192 (0x1830)
                                                                    [Worker]:                                 Migrating object  ECOTEC2011-test 1  with ID: SMS_Package.PackageID='ITS00396' ... SMS_MIGRATION_MANAGER 1/21/2013 9:39:41 AM 6192 (0x1830)
                                                                    [Worker]:                                 Set the status of the job entity  ECOTEC2011-test 1  to Running. SMS_MIGRATION_MANAGER 1/21/2013 9:39:41 AM 6192 (0x1830)
                                                                    [Worker]:                                 Migrating AppV package ECOTEC2011-test (SMS_Package.PackageID=ITS00396) SMS_MIGRATION_MANAGER 1/21/2013 9:39:42 AM 6192 (0x1830)
                                                                    [Worker]:                                 Impersonation is about to start ... SMS_MIGRATION_MANAGER 1/21/2013 9:39:42 AM 6192 (0x1830)
                                                                    [Worker]:                                 Impersonation succeed, current user identity is: DOMAIN\USER SMS_MIGRATION_MANAGER 1/21/2013 9:39:42 AM 6192 (0x1830)
                                                                    [Worker]:                                 Successfully connected to share \\launceston\TEMPSourcefiles\app-v SMS_MIGRATION_MANAGER 1/21/2013 9:39:42 AM 6192 (0x1830)
                                                                    [Worker]:                                 Successfully disconnected from share \\launceston\TEMPSourcefiles\app-v SMS_MIGRATION_MANAGER 1/21/2013 9:39:42 AM 6192 (0x1830)
                                                                    [Worker]:                                 Impersonation is reverted. SMS_MIGRATION_MANAGER 1/21/2013 9:39:42 AM 6192 (0x1830)
                                                                    [Worker]:                                 Impersonation is about to start ... SMS_MIGRATION_MANAGER 1/21/2013 9:39:42 AM 6192 (0x1830)
                                                                    [Worker]:                                 Impersonation succeed, current user identity is: DOMAIN\USER SMS_MIGRATION_MANAGER 1/21/2013 9:39:42 AM 6192 (0x1830)
                                                                    [Worker]:                                 Successfully connected to share \\launceston\TEMPSourcefiles\app-v SMS_MIGRATION_MANAGER 1/21/2013 9:39:42 AM 6192 (0x1830)
                                                                    [Worker]:                                 Successfully disconnected from share \\launceston\TEMPSourcefiles\app-v SMS_MIGRATION_MANAGER 1/21/2013 9:39:42 AM 6192 (0x1830)
                                                                    [Worker]:                                 Impersonation is reverted. SMS_MIGRATION_MANAGER 1/21/2013 9:39:42 AM 6192 (0x1830)
                                                                    [Worker]:                                 Trying to create SMS_Application ECOTEC2011-test SMS_MIGRATION_MANAGER 1/21/2013 9:39:43 AM 6192 (0x1830)
                                                                    [Worker]:                                 Create SMS_Application ECOTEC2011-test (ScopeId_D764F1CF-26B7-4A8D-AAA4-9A7B0A26AF4D/Application_b2f262a1-6902-40cb-808a-3322e418b724/1) successfully SMS_MIGRATION_MANAGER 1/21/2013 9:39:57 AM 6192 (0x1830)
                                                                    [Worker]:                                 CopyMembership: Copying org folder membership for SMS_Package.PackageID='ITS00396' SMS_MIGRATION_MANAGER 1/21/2013 9:39:57 AM 6192 (0x1830)
                                                                    [Worker]:                                 Set the status of the entity  ECOTEC2011-test 1  to Completed. SMS_MIGRATION_MANAGER 1/21/2013 9:39:57 AM 6192 (0x1830)
                                                                    [Worker]:                                 Set the status of the job entity  ECOTEC2011-test 1  to Completed. SMS_MIGRATION_MANAGER 1/21/2013 9:39:57 AM 6192 (0x1830)

    So it looks like the issue could lie with DFS, I'll check it all again. However the PSEXEC test pretty much confirms the permissions are correct.

    /scratches head....

    Monday, January 21, 2013 9:44 AM
  • Hello,

    I'm running into the same issue.  All App-V applications that have a source on the old share on the site server have migrated successully.  However, App-V applications with source data on the new DFS share fail through the migration process with the same errors as above.

    Has anyone found a solution to this?

    Thanks!

    Monday, February 4, 2013 4:37 PM
  • Hi,

    I've confirmed some further details of this possible bug and submitted it to Connect (If you could head over there and confirm you have the issue also it may attract more attention.

    Attempting to migrate and App-V package with no space in the name returns error 80070520
    A specified logon session does not exist. It may already have been terminated. 

    Attempting to migrate and App-V with a Space in the Name/Path returns error 80070043

    The network name cannot be found.

    Again this only applies to App-V packages. Native packages in the same location migrate successfully regardless of the name format.

    Tuesday, February 5, 2013 3:40 PM
  • Sounds great.  I have filed a possible bug report with Connect and also have an open call with CSS.  I will update this thread as I learn more.

    -DG

    Tuesday, February 5, 2013 5:17 PM
  • Thanks, I've voted your bug as 'I can reproduce'

    I too will keep this thread up to date If i find anything else or hear anything back.

    • Proposed as answer by russellca Sunday, February 10, 2013 11:44 PM
    • Unproposed as answer by russellca Sunday, February 10, 2013 11:44 PM
    Wednesday, February 6, 2013 2:40 PM
  • I had the same error. Removing the backslash at the end of the path resolved the 80070035 error.

    But I still get the 80070520 when migrating from a DFS.
    Bypassing DFS and going directly to the share works fine, but I really want to keep the DFS path for my APP-V applications.

    Sunday, February 10, 2013 11:52 PM
  • CSS responded today that this is bug specific to SP1.  They are working towards debugging. 

    I will reply as I recieve updates.

    -DG

    Thursday, February 14, 2013 10:09 PM
  • CSS just responded that this is a confirmed bug.  I asked them to pursue a fix and I will fill out a Business Impact Statement (BIS). 

    Whoever else is experiencing this, I would suggest you contact your TAM and do the same; that way we can put a little pressure on this situation.

    -DG

    Friday, February 15, 2013 7:24 PM
  • Hi Derek,

    That's excellent news. I've been working with our 3rd party support partner, as of this morning they are escalating this as a bug to Microsoft. Fingers crossed for a hotfix soon, this is really holding us back at the moment.

    Monday, February 18, 2013 10:32 AM
  • Hi Derek,

    Have you had any further feedback regarding this. I'm going around in circles with our support partner at the moment troubleshooting none existent AD/DFS issues. We have a number of projects on hold until this issue/bug is fixed, so time is getting tight on us now.

    Thanks

    Phil

    Tuesday, March 5, 2013 12:11 PM
  • Hi Phil,

    I just received a possible fix that I attempted and still failed with error 0x80070056.  I have emailed the engineer back and will keep you updated.

    Thanks,

    Derek

    Tuesday, March 26, 2013 6:05 PM
  • Thanks for the Update Derek, Fingers crossed they get a fix out soon.
    Wednesday, April 3, 2013 1:04 PM
  • I finally received a workaround that I have confirmed will work.  The fix may be included with CU2, but they weren't certain.  The workaround is as follows:

    1. Reconfigure your Data Gathering step to use the computer account (if not already done)

    2. Run the Data Gathering

    3. In the CM12 database, change the MIG_SiteInfo table Account column to NULL (it should be empty before the change)

    4. Perform the migration job(s)

    One huge caveat is, that you cannot rerun a Data Gathering after step 3, or step 4 will fail as it always has.  So if Data Gathering is run (either manually, or through its normal 4 hour progression), you will need to re-follow these steps above to run a successful migration job.

    • Marked as answer by Philaitman Tuesday, April 23, 2013 8:36 AM
    Friday, April 19, 2013 2:26 PM
  • Thanks for the information Derek, I'll give this a try.
    Tuesday, April 23, 2013 8:36 AM
  • Is this what the table is supposed to look like or is "Allow Nulls" supposed to be unchecked?  I am getting the same exact errors with total failures of migrating AppV packages but we are not using DFS in our environment. 
    Wednesday, May 29, 2013 3:13 PM