locked
Migrating workstations from the 2007 ConfigMgr client to 2012 RRS feed

  • Question

  • I am wondering what the best way to migrate from 2007 to 2012 is, and I'm a little fuzzy on a couple of details.

    We're preparing to migrate, and I have enabled SUP deployment of the 2012 client - I saw it on a workstation and ran it, but it didn't update. Upon viewing logs, it looks like it found existing details in the registry from the 2007 GPO that had since been disabled, but the key persists. So the "new" installation of ccmsetup was pointing to the "old" SCCM Server, and so it failed.

    After discovering this, I updated the Client Deployment GPO with the 2012 adm template. (This GPO isn't active still) Will this be all I'll need to do in order for the installs to work? Since the setting is considered a "preference item" it will not be deleted if the GPO is deleted- so this 2012 GPO template should just overwrite that 2007 registry key, right? I'm unable to test this on my test machine since it says the ConfigMgr Upgrade Windows Update already ran....which leads me to my next question...

    What do I need to do in order to re-run that "Important Windows Update?" It's not REALLY an update, so I can't uninstall it like you would an update. I've uninstalled the ccm client, but that was still the 2007 client since the upgrade/migration failed originally. 

    I have also set the SCCM 2012 to publish to AD, with the schema extended, if that has anything to do with it, but I believe using the GPO install settings AND the extended schema will just be doing the same thing, so a bit of overkill on install settings.

    Hopefully this all makes sense.

    Friday, September 13, 2013 7:16 PM

Answers

  • Correct on the GPO. What you've spelled out above on this is why using the GPO is generally a bad thing to do. Is there a specific reason you are using it instead of just deleting the GPO and resetting the registry values? If you've got the schema extended *and* the site/MP info published to AD, then the GPO serves no real value.

    As for re-running the update, not sure. You should just be able to select it in the RAP again because it should still be applicable.


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Paul_131 Monday, September 16, 2013 12:15 AM
    Friday, September 13, 2013 8:44 PM
  • You're right that deleting the GPO won't reset those values, that's why I said *and* resetting them. You'll have to script it out: http://t3chn1ck.wordpress.com/2012/10/05/configmgr-client-gpo-assignment-removal/

    If it was a required deployment, you can just the software update reevaluation cycle also.

    Why are you using the SUP to push it though? Any specific reason there? I much prefer client push and/or a startup script.


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Paul_131 Monday, September 16, 2013 12:15 AM
    Friday, September 13, 2013 11:32 PM

All replies

  • Correct on the GPO. What you've spelled out above on this is why using the GPO is generally a bad thing to do. Is there a specific reason you are using it instead of just deleting the GPO and resetting the registry values? If you've got the schema extended *and* the site/MP info published to AD, then the GPO serves no real value.

    As for re-running the update, not sure. You should just be able to select it in the RAP again because it should still be applicable.


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Paul_131 Monday, September 16, 2013 12:15 AM
    Friday, September 13, 2013 8:44 PM
  • Thanks for the reply Jason.

    I didn't resort to the GPO until after the SUP method failed (which I think is a result of the 2007 GPO,) but I'm glad to hear that as long as the site settings are published in AD I should be ok. I haven't been able to verify that they ARE published in AD, just that SCCM is enabled to do so. I checked the attributes on the object in the System Management container, but didn't see anything that really stood out as far as mp, fsp, slp, etc.

    But what you said here- " Is there a specific reason you are using it instead of just deleting the GPO and resetting the registry values?" struck me a bit funny. The GPO itself says those settings will NOT be removed if you remove the GPO, as they are a preference item (registry key), so they will remain on the PC even if that GPO is disabled. That's why I thought a new 2012 policy would need to be enabled to overwrite that key. (Or push out a script to delete that key in preparation for 2012 CCM client?)

    As for re-running from RAP, I didn't check that; it didn't occur to me since it wasn't originally delivered by SCCM 2007, it came as an Important/Critical Windows Update.

    Friday, September 13, 2013 10:40 PM
  • You're right that deleting the GPO won't reset those values, that's why I said *and* resetting them. You'll have to script it out: http://t3chn1ck.wordpress.com/2012/10/05/configmgr-client-gpo-assignment-removal/

    If it was a required deployment, you can just the software update reevaluation cycle also.

    Why are you using the SUP to push it though? Any specific reason there? I much prefer client push and/or a startup script.


    Jason | http://blog.configmgrftw.com

    • Marked as answer by Paul_131 Monday, September 16, 2013 12:15 AM
    Friday, September 13, 2013 11:32 PM
  • Ah, guess I misread your reply.

    Honestly, we planned on using SUP because the training representative said it was the route to go. When we implemented 2007 we used a combination of GPO and zenworks to push out the client.

    I'd like to continue using push method, but thought the sup idea was kind of interesting. I maybe got lost in the "neatness" aspect of it, but having been in charge of software installs for the past two years I've definitely learned that efficiency trumps neatness.

    It was also just a single test pc I was working on this afternoon and hasn't done any push settings yet. I think that may be the route to go. 

    Saturday, September 14, 2013 1:21 AM