Tuesday, January 27, 2009 5:12 PM Brian S. Tucker

SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

There have been a few really good posts about how to do a side by side migration, but I ran across a bit of a different scenario recently and wanted to share the process with you if it fits into what you are looking to do. It's actually quite painless and you keep everything you have including collections, packages, advertisements, reports and queries.

Requirement: Perform a Side by Side upgrade from SMS 2003 with SQL 2000 on a X86 2003 server to Server 2003 Enterprise X64 & SQL 2005 X64

Problem: SMS 2003 is not only unsupported, but will NOT install on a X64 server. So, how do we accomplish this task?

While I had a few ideas, I finally came up with the following scenario that has worked 100% and will for you if this is your intended goal.

  1. Backup your current SMS 2003 server 100%.
  2. Build a standard Server 2003 box and load SQL 2005 SP2 (or SQL 2008 with the supported hotfix). Install all the IIS requirements that SMS 2003 requires.
  3. Install SMS 2003 SP(X) as a new primary server to match what you currently have as a SMS 2003 Central Primary. Configure all the settings. Create an address from the new server to the old and one on the old to the new. Add the Server$ name to the local admin group on each server and give the new server permission as required on the System container in AD. Change the settings on the new SMS server not to be a Central Primary and have it report to the old (current) Central Primary site code. Now you have your current Central Primary and a new child primary in the hierarchy. Allow the collections, packages and advertisements to transfer to the new child. Once all has been replicated, you can proceed.
  4. On the child primary, run the SCCM prerequisite checker and fix ALL warnings and or errors. Once you have all the prerequisites resolved, extend the AD schema for SCCM. Once SCCM is installed, configure the server as required. Make sure you don't have ANY overlapping boundaries between both sites.
  5. Delete the address you created on the SCCM and SMS boxes to break the hierarchy. Change the SCCM server from being a child primary to be a central primary. Wait for all the padlocks to remove on all the replicated objects. The collections, advertisements and packages will NOT be orphaned by this process. They will still hold all the ID's from the old SMS server.
  6. Now you have a Central Primary SCCM server with a new site code. At this stage, you have 2 central primary servers in your environment. Now we want to do the same process, but on the final X64 server with SQL X64 (optional, but suggested). On the X64 server, install SCCM the same way you did before and give it a unique site code. During the install process, make it a primary server... Once you have SCCM installed, do the same process you did on your last server by making it a child primary of the SCCM Central Primary. Allow time for the replication of all the objects, just like before. Once they are all there and padlocked, remove the addresses and make the X64 SCCM server a central primary again. That's the basics of the process, but here are a few more things you should know.

Note:

  • As stated, all your collections, adverts and packages will be migrated with the SAME old ID's. This is actually good to keep things working. This entire process can almost be considered an "in-place" upgrade!
  • Queries and Reports do not migrate. You will have to export them from the old SMS server into .mof files and import them on the SCCM server. Queries seem to import well, but if you have a lot of reports, you might want to export them in multiple files. If you had 1,000, they would export ok, but the import would hang forever. Watch out for duplicates from what was in SMS and what''s in reports and queries in SCCM.
  • Another key thing to note is that for all objects: collections, packages, advertisements, reports and queries... if they are in a folder that you have made, they will not replicate or able to be exported. All replicated objects and imported objects will go direct to the root folder for that given object.
  • Package source directories will remain as they were. If you package source was NOT on the SMS server, then you don't have to worry about anything. However, if they were on the old server, then you have to do a little fix. Copy the entire package source folder over to the new SCCM server. I have attached a script written by Francisco Merizalde (with his permission) which will simply change the server name for all packages. The command line is included in the attached text file.
  • You can delete all collections for the ITMU if you had it installed with SMS as this will not be an option in this scenario. To continue patching, you will need to install WSUS 3.0 SP1 (current release at the time of this post) and setup your SUP role.
  • Of course you will have to remove all the boundaries of your old SMS server and add them to your SCCM server.
  • Since all your clients are still SMS 2003, they may not get the new site code until you decommission your SMS server. If the SMS server is still up and running, you can use one of the 3rd party tools to change the site code.

This was an interesting upgrade and I don't think that it's been documented this way, but it's easy and works 100%. If you have any questions, just post a comment. If I think of anything I missed in the process, I will update this post.

If the attachment is not listed, below are the instructions for the script.

Throw this in a .vbs file and run from the command line using cscript. Make sure and put the servername that should be the source for the packages after the script name on the commanline.Cscript <Script Name> <SERVER Name>i.e.cscript packagemodify.vbs SERVER123 (where SERVER123 is the new server you have copied the source to)


Copy code below this line---------------------------------------------------


Dim oWbemServices
If UCase(Right(Wscript.FullName, 11)) = "WSCRIPT.EXE" Then
    Wscript.Echo "This script must be run under CScript."
    Wscript.Quit
End If
If WScript.Arguments.Count <> 1 Then
    WScript.Echo "Wrong number of arguments were passed."
    WScript.Quit
End If
 
CONNSCCM()

For Each oPackage In oWbemServices.execquery("select * from sms_package")
  sOldPathString = oPackage.pkgsourcepath
  If InStr(sOldPathString,"\\") Then
                iStart = InStr(3,sOldPathString,"\")
                sNewPathString = Right(sOldPathString,(LEN(sOldPathString)-iStart))
                sNewPathString = "\\" & WScript.Arguments(0) & "\" & sNewPathString
                WScript.Echo "Setting Package Path for " & oPackage.Name & " from " & sOldPathString & " to " &  sNewPathString
                oPackage.pkgsourcepath = sNewPathString
                oPackage.put_
  End If
Next

WScript.Echo "Done"

Sub CONNSCCM()
  Set oWbemLocator = CreateObject("WbemScripting.SWbemLocator")
  Set oWbemServices = oWbemLocator.ConnectServer(".", "root\sms")
  Set oSCCMProvLoc = oWbemServices.InstancesOf("SMS_ProviderLocation")

  For Each oLoc In oSCCMProvLoc
        If oLoc.ProviderForLocalSite = True Then
            Set oWbemServices = oWbemLocator.ConnectServer(oLoc.Machine, "root\sms\site_" + oLoc.SiteCode)
        End If
  Next
End Sub

Share this post:                                       
Filed under: , , , , , , , , , , , , ,

Comments

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Tuesday, February 03, 2009 6:04 AM by GenerAHL

Brian,

Great post! I follow your suggestions up until: "The collections, advertisements and packages will NOT be orphaned by this process. They will still hold all the ID's from the old SMS server." However, since my machines haven't "migrated", the collections are empty even if I start moving clients over (after breaking parent-child) to the new site. I guess it's because they get new ResourceIDs at this point.

Any suggestion how I can get my 10k+ machines over to the new site without keeping the parent-child relationship forever?

Sorry if the question is confusing, in a nutcshell "How do I get my machines to move from one site to another with maintained collection-memberships/ResourceIDs or what-ever necessary to avoid issues."

Thanks!

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Tuesday, February 03, 2009 3:17 PM by Brian S. Tucker

That's the idea, you don't migrate your clients during the migration. Once you have your X64 server, you can then enable your AD discovery. Machines will show up as not assigned and will not get any advertisements. Slowly remove your boundaries from the SMS side and add them to the SCCM side. Once you do that and they show as assigned, run a client push to them and they will be upgraded and approved. You should not have any issues provided you follow the steps I outline above. This allows you to still keep your SMS hierarchy working while building the SCCM side. Does that make sense to you?

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Wednesday, February 04, 2009 1:44 AM by GenerAHL

That makes perfect sense, except that I will have to keep the parent-child relation for quite some time I.e I cannot upgrade the new SMS-box to SCCM (since an SCCM site cannot be a child to an SMS site).

When I do break the parent-child (and upgrade SMS to SCCM), how can I get the discovered clients to retain their collection-memberships? I wouldn't want thousands of clients to start installing things again. :)

In the end "Machines will show up as not assigned and will not get any advertisements" is not a good thing since I would have to re-do all the collections again and there are many...

In summary; the whole procedure makes perfect sense and I have already done it a couple of times (writing a few scripts along the way that you might be interested in) but the missing part right now is that my shiny new SCCM server has 10k+ clients assigned to it, discovered through the AD, without any advertisements since they are not member of any collections...

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Thursday, February 05, 2009 4:28 PM by Brian S. Tucker

You don't have to keep the SMS child primary as SMS. If your adverts, collections and packages have replicated, you can then extend the AD schema and upgrate the server and then proceed. When you break the hierarchy, remember, the collections, adverts and packages will ALL have the same ID. The ID's on the clients are held in the registry. This way, clients who have successfully received an advertisement will not get it again. As for the machines being assigned, don't add the old boundaries until you are ready to migrate. You don't want overlapping boundaries. Your 10K clients on SCCM will get new advertisements as they are created and should be assigned to the same collections they were before. The issue is that the 10K clients are all SMS clients. If in the properties of the Central Primary, you still have checked only SCCM clients are supported, you can uncheck that box to get inventory and such, you just won't get Software Updates if you plan to use them.

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Thursday, February 19, 2009 8:15 AM by GenerAHL

I agree, but I guess you assume that no collections have direct memberships. Collections based on AD-group membership are fine but direct memberships won't stick.

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Monday, April 27, 2009 8:34 AM by Pascale421

Hi Brian

Having broken the parent-child relationship, the future new central site will remain long without receiving information from the childs sites. Indeed, the information from the childs sites are always directed to the SMS 2003 central site. When the new central site sccm 2007 will be the only central site and that the childs sites it will all be tied, there will be no problem with loss of data ??

Thanks

Pascale

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Thursday, June 04, 2009 3:32 PM by JAG

First off, this is a great guide and I have successfully followed it multiple times in my test environment and boy is it a time saver!

Now I have secondary sites that need to be upgraded and in my testing I'm seeing that the compressed version of packages is being deployed even though the compressed and uncompressed package is already in the proper locations on the Secondary sites.  There must be a way around this...I hope

Hope you can answer this Brian!

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Thursday, June 04, 2009 6:54 PM by Brian S. Tucker

I'm happy that this post has helped you! I try and share real world scenarios that may help others.

I think I understand your question on Secondary sites, but can you be more specific? Sorry..

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Friday, June 05, 2009 9:26 AM by JAG

I have 47 secondary sites at branch office locations around the US, they all need to be upgraded as part of our migration to SCCM from SMS 2003.  There are probably 100 or more packages that have been replicated at these locations as they are also DP's.  When installing these sites as Secondary's(SCCM) I was hoping that since the Package ID was transferred  over via the process above that there would be no actual data transfer when installing the Secondaries in SCCM.  Basically all the packages are already on the servers along with the compressed files.  What I'm seeing in my test environment is that the compressed files are still being transferred.

Is there a way to avoid this?

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Wednesday, June 24, 2009 6:46 PM by GWD

Hi all,  wondering if anyone has any more info on secondary sites after this process has been completed.  I am pretty sure SMS 2003 secondary sites will need to be re-installed under the new SCCM structure.  My question is when I use preloadpkgonsite.exe after a new secondary site install will the old packages (from when it was a sms 2003 secondary server) import ok?  Thus saving me transferring the packages again?

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Wednesday, June 24, 2009 6:53 PM by GWD

Hi all,  wondering if anyone has any more info on secondary sites after this process has been completed.  I am pretty sure SMS 2003 secondary sites will need to be re-installed under the new SCCM structure.  My question is when I use preloadpkgonsite.exe after a new secondary site install will the old packages (from when it was a sms 2003 secondary server) import ok?  Thus saving me transferring the packages again?

# sccm - StartTags.com

Monday, March 01, 2010 7:47 PM by sccm - StartTags.com

Pingback from  sccm - StartTags.com

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Thursday, May 13, 2010 12:08 PM by muppielee

Hi brian,

Quite an interesting post, wish i had found this earlier..however, i have set up the relationship and replication looks just fine but the exception is that the"set parent site" tab on the child site is greyed out? Any clues has to why this is so?

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Friday, February 25, 2011 12:45 PM by inzou

Hi Brian,

how to define the new sms server boudaries.

both sites share the same bondaries???

your help will be appreciated.

thanks

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Monday, October 03, 2011 8:47 AM by Kianna

I've never tried to create some applications for programs. It's very hard work.

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Thursday, December 01, 2011 6:19 AM by AnnaTochenaya

Really enjoyed reading your content regularly! nice blog! I love it!

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Thursday, December 01, 2011 6:39 AM by AnnaTochenaya

This was really something very special and interesting.

# re: SMS 2003 to SCCM 2007 SP1 R2 Side by Side Migration X64 Style

Wednesday, December 28, 2011 4:28 AM by AnnaTochenaya

Very informative reading. I will keep you bookmarked