locked
SCCM 2007 to 2012 migration RRS feed

  • Question

  • Hi all,

    I am currently on SCCM 2007 and performing a migration over to SCCM 2012.  SCCM 2012 server is built, SQL 2012 Standard is installed, and SCCM 2012 SP1 installed.  I am configuring a source hierarchy to my SCCM 2007 environment and when I click on 'Test Connection' I get this error: "The type of initializer for 'System.Data.SqlClient.SqlConnection' threw an exception.  I bypassed this error initially and the gathering process continued and I see objects that I can migrate over if I create a migration job, but I am not sure if this error is a problem or not. 

    I am using a service account that is a member of the domain admins group.  I have added that service account on both servers to be local administrators and sysadmins for both SQL instances.  I have also tried adding the SCCM 2012 computer account as a local administrator and sysadmin for SQL on both the 2007 and 2012 servers.  Honestly, I am not sure if this is what I should be doing, but I just wanted to try to see if granting those permissions will get rid of this error.

    Any help is much appreciated!

    Thank you!

    Friday, May 3, 2013 7:46 PM

Answers

All replies

  • no worries, if you can migrate jobs you are all good. Maybe the test was not performed against the CM07 database (it's master by default).

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

    Saturday, May 4, 2013 7:48 AM
  • Hi Kent,

    Thank you for your response.  The SQL verification window defaulted to the CM2012 server and the CM2012 database name.  I changed the values to the CM07 server and the CM07 database name, but I still get that error.  I haven't actually migrated anything over yet but I see the objects that I can migrate over and they match what I have in the CM07 environment.  One thing that surprised me and I may have just overlooked it on the migration instructions, was that after the gathering process, I noticed that the boundaries from my CM07 environment came over already, even before running a migration job.  Is that expected? 

    I am also guessing that I probably gave out to many rights to the service account in both environments? 

    I have also read a ton on what should be done with boundaries during a migration and the threat of overlapping boundaries for site assignment.  I am using AD site boundaries and would like to do the same with the CM2012 environment.  Currently in the CM07 environment, I am using the client push installation method and I specify the SMSSITECODE.  I do not use auto site assignment.  I plan to do the same with the CM2012 environment with the client push install.  If both environments are configured in that way, would I have overlapping boundaries or need to worry about it even though I have the same AD site boundaries on both sites? 

    I also haven't been able to find much about the ability to use the same PKI certificates in the CM2012 environment as I did in the CM07 environment.  I don't specifically see anything in the certificates (server and client) that would reference the CM07 environment so I am guessing I can still use them.  I have already requested the certificates (site server signing, web server, and client) on the CM2012 server and they seem to be working fine.

    Thanks again for all our advice!

    Monday, May 6, 2013 6:03 PM
  • Hi All,

    Any ideas about my questions regarding boundaries and PKI certificates in my previous post?

    Thanks!

    Wednesday, May 8, 2013 6:01 PM
  • Hi, Certificate requirements are pretty much the same. But I would double check that all is correct.

    Client Certificates are usually good to go, so migration from CM07 to CM12 are without worries.

    You also have a report that show what clients can run PKI mode.

    All though you have to get new certs for the CM12 environment of course, Mangement Point, Distribution Point and so on.

    http://technet.microsoft.com/en-us/library/gg682023.aspx


    Nicolai

    Thursday, May 16, 2013 10:00 AM