locked
Side-by-side migration - New Configuration Manager Client Package deployment / installation RRS feed

  • Question

  • Hello everybody,

    I've just completed the migration of all needed objects (Boundaries, S/W Packages, Drivers, Boot images, Task Sequences, etc) from SCCM 2007 SP2 R3 to SCCM 2012 SP1 CU1 and have also enabled DP sharing.

    I now want to verify that I'm able to deploy new computers from the new SCCM 2012.

    The OSD TS I'd been using on SCCM 2007 was migrated successfully and i can see that the step "Setup Windows and ConfigMgr" has automatically changed the package selected to the new "Configuration Manager Client Package" (new SCCM 2012 client).

    This new package has the ID NEW00003.

    I also changed the boot image in the TS so as to use the default ones from SCCM 2012
    These new default boot images have been distributed to the SCCM 2012 DP with no problem and i can verify the existence of the .wim files on the 2012 DP.

    However, when i try to distribute the "Configuration Manager Client Package" to this DP i get the following error on distmgr.log:

    All of the package's tabs/properties are also greyed out, so for example, in the "Data Access" tab I can't select "Copy the the content in this package to a package share on distribution points".

    In the "Content Locations" tab, I can see that the package is assigned to the new 2012 DP but when I try to redistribute the package the SMS_DISTRIBUTION_MANAGER component status displays:

    Distribution Manager failed to process package "Configuration Manager Client Package" (package ID = NEW00003).

    Possible cause: Distribution manager does not have access to either the package source directory or the distribution point.
    Solution: Verify that distribution manager can access the package source directory/distribution point.

    Possible cause: The package source directory contains files with long file names and the total length of the path exceeds the maximum length supported by the operating system.
    Solution: Reduce the number of folders defined for the package, shorten the filename, or consider bundling the files using a compression utility.

    Possible cause: There is not enough disk space available on the site server computer or the distribution point.
    Solution: Verify that there is enough free disk space available on the site server computer and on the distribution point.

    Possible cause: The package source directory contains files that might be in use by an active process.
    Solution: Close any processes that maybe using files in the source directory.  If this failure persists, create an alternate copy of the source directory and update the package source to point to it.

    Can someone help me on this one?

    Could this be related to boundaries/boundary groups perhaps?

    Isn't it possible to run a TS which has content delivered from both the new DP as well as the shared DP from the old SCCM?

    Thanks in advance.

    Wednesday, May 22, 2013 3:52 PM

Answers

All replies

  • Wednesday, May 22, 2013 5:36 PM
  • Thank you very much, that was indeed the issue.

    The strange thing is that during my last reboot on the server i got a warning about a file named "program" on the root of C:\ drive.

    I had renamed it but now that i re-checked it was once again re-created.

    Anyway, thanks a lot for the tip ;-)

    Thursday, May 23, 2013 9:41 AM
  • I had a similar issue with WSUS not working in my lab environment a while ago and i also got a warning...

    Are you using Windows Server 2012 as that was the OS i had running when i had the issue ?

    K

    Thursday, May 23, 2013 9:43 AM
  • No Kurt, I'm installing on Windows 2008R2 Server SP1.

    BTW, right after solving the issue with the client package, i immediately found another problem.

    It is truly hard to successfully perform the migration. Everything seems to be broken :(

    Now i get the classic "0x80091007: Hash value is not correct" when deploying the OS image.

    The image is on the shared DP of the old SCCM server.
    I've updated the DP and tested the OSD TS from the old SCCM and it works out fine.

    However, when i run it from the new SCCM, i get the hash error...

    Thursday, May 23, 2013 2:19 PM
  • hi,

    Just a guess but is Binary differential replication enabled on the image in CM07?

    K

    Thursday, May 23, 2013 3:04 PM
  • Sorry for the late response Kurt but i've been kept back due to some new unexpected problems.

    After installing CU1 everything was working fine till i rebooted the server.

    On startup, the WDS service was missing from the list of services and it would not re-install by disabling/enabling PXE on the DP.

    I finally had to remove/re-add the DP role and a few restarts to make it come back to normal.

    Now, for some other unknown reason, the O/S image package that is currently deployed successfully on the old CM07's shared DP cannot be found during the OSD T/S.
    The image had indeed the binary differential replication checked, so i unchecked it and updated the DP.

    When deploying the T/S from CM12, I'm getting the "Content location request for OLDXXXXX failed (Code 0×80040102)"
    When deploying the same T/S from the old CM07 it's working perfectly.

    I haven't created/distributed a package on the new CM12.
    Should i do that in order to make it work? Is it necessary?
    Shouldn't it be available directly from the old DP package?

    I don't know why, but this migration is an absolute failure...



    Monday, May 27, 2013 10:00 PM