SMS to SCCM Upgrade

Dave - Still trying to figure out the best way to upgrade my clients now that I have SCCM up and running with no errors as of yet, woohoo. I'm trying to figure out your steps and a little confused on the logic below. Could you help me once again? I'll try my best to explain what steps I am confused on...
 

1. Create a collection on SCCM site containing migrated SMS clients (clients of version 2.x and subnet (above)). Set the Update Schedule on this collection to be quite low (15 minutes).        -So the actual value of the collection is System Resource, Client Version, and then Value = 2.x  ?? I guess I am unsure of what the value should be. Do I actually type in: 2.x
2. Advertise a SCCM client upgrade package to the above collection, using whatever installation switches you want (SMSSITECODE will not need to be one of them, ) -Shouldn't I use SMSSITECODE just to be safe?
3. Remove boundary from SMS site (target IP subnet)  -If we use AD Site boundary, same difference? Remove the entire AD Site boundary? (300 clients per AD Site boundary, makes me a little scared)
4. Advertise 'Client Upgrade script' to SMS clients from SMS server.
   The clients will run the script, discover their new SCCM management point and the SCCM upgrade process will begin after X time. I say X time because it depends on the refresh times you have on your SCCM collections and the policy polling interval configured in the Computer Client Agent Properties on the SCCM site server. I had my collection refresh set to 15 minutes, and the Client Agent Polling Interval set to 20 minutes. So generally my clients were upgraded within an hour from the initial launch of the SMS job.  -Do you have the exact script that I could use for this? I know you wrote some above but not sure if that is the complete script. Don't see anywhere in there for the new site code.

Sorry for me being a bonehead here and taking up your time, feel free to ignore the whole thing, lol. It just seems like you have this down pat and I would like to replicate your process.

Ryan, no drama... I'll see if I can elaborate a little more. 

1. So the actual value of the collection is System Resource, Client Version, and then Value = 2.x  ?? I guess I am unsure of what the value should be. Do I actually type in: 2.x 
   My query was actually: System Resource.Client Version is less than "4.00.0000.0000" 
2. Shouldn't I use SMSSITECODE just to be safe?
   You can if you want, but then you'll need a different advertised program for every MP that your upgrading clients to. If you've published you SMS / SCCM site servers into Active Directory and removed the correct SMS boundary and added the correct SCCM boundary, the client will discover it's MP correctly from AD. 
3. If we use AD Site boundary, same difference? Remove the entire AD Site boundary? (300 clients per AD Site boundary, makes me a little scared)
   No guts, no glory! Hehehe. But really, just because you've removed the boundary from SMS doesn't stop those clients being managed by the current SMS MP. It's just that the clients will now be classed as "remote" and this can effect some of your existing advertisements if they are configured to not run for "remote" clients. You don't want to create overlapping boundaries between you SMS and SCCM site servers... so it really is a case of all or nothing.  
   
   The only alternative is to not migrate the boundary from SMS to SCCM and then use the SMSSITECODE,  SMSMP and SMSLP switches to prevent the client install process from using the AD lookup (and finding the SMS site). But this just puts more potential issues around you upgrade process. 
   
   My advise, pick the AD Site that has the smallest number of clients, and then work your way up. If that happens to be 300... then so be it. Migrate the boundary from SMS to SCCM, pick 5-10 clients and manually kick off the client upgrade advertisement (i.e. don't make it mandatory from the SMS site) and see how they go. If all good, change the advert to mandatory and the remainder will follow. If there were issues in the test clients, figure out why, then do it again, until you get it right. 
4. Do you have the exact script that I could use for this? I know you wrote some above but not sure if that is the complete script. Don't see anywhere in there for the new site code.
   I've attached a version of the script that I used. I did have to edit it to remove some of our company identification and in house customisations, but it should be in working order. Each sub-routine should be correct. 

I know the process is a daunting one, but honestly at the end of the day it's a lot simpler than it seems. Just get everything in place and the hit the "go" button. In my experience, sure some clients will fail, but that was due to local issues on the clients, not the SMS/SCCM backend. As long and the boundaries are right, the sites are published in AD and the SMS and SCCM adverts/programs/packages are all ready the success rate will be high... in my case around 96-97%.

Attachment(s)

SMS_2_SCCM_Migration.txt (5.18 KB) - downloaded 99 times

rbanse

rtruss


While that may work in mixed mode it can make for a more difficult support world in either mode.  We went to a mixed mode and it was not so fun getting clients working unless we upgraded to the new client.  So we decided to simply wait to transfer clients until we had the whole thing working and a way for techs to use the remote control tools and console.

 
I see. So even though SMS clients have the old client, they can still be seen in SCCM, correct? Things may not work the greatest, but it's possible for them to at least be seen so I can then upgrade them to SCCM. I'm just trying to figure out the best way to upgrade the clients to SCCM in a phase install.

This is incorrect, SMS2003 clients work just fine in an SCCM site.  How could you do an in place upgraded otherwise, and that is an option?  There are some new SCCM features that may not be functional, but otherwise anything you could do under SMS2003 will run under an SCCM site.  You do want to upgrade as soon as you can, but the clients run just fine.

Dave - Just two more things and I believe I should be good to go....
 
1. Within your attached script, can you tell me what I need to add/edit in the script so I can have the new site code already entered instead of having it get auto-discovered by the client?  
 
2.  Can you send me the actual query language you used to create a collection on SCCM site containing migrated SMS clients (clients of version 2.x and subnet (above)).

 

Ryan,

To have the script hard set the site code just change the following section. Remove the line in red and replace the text in blue with your site code value:

If (flg = 1) Then
    set oSMSClient = CreateObject ("Microsoft.SMS.Client")
    oldstrSiteCode = oSMSClient.GetAssignedSite

If (Err.Number <> 0) then                                                                                                                                          
    ResultLog.WriteLine "Unable to get currently Assigned Site - " & Err.Description
Else
ResultLog.WriteLine "The current site code is:" & oldstrSiteCode
strSiteCode = oSMSClient.AutoDiscoverSite  
oSMSClient.SetAssignedSite strSiteCode
ResultLog.WriteLine "The auto discovered site code is: " & strSiteCode
End If

set oSMSClient=Nothing

End If

The query language is:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.ClientVersion < "4.00.0000.0000"

Regards.

Thanks. Worked great. Needed to put the site code in quotes though in the script. 
 
Am I going to be able to advertise soft. packages to this test PC in SCCM if I have not setup boundaries yet on the new server? It appears not as my PC is not recieving any advertisements. What is the point of these boundaries? Mainly for software dist?  It seems like I won't be causing too much grief if I remove the boundaries from the SMS server after I advertise the upgrade script. I think this is pretty much what you told me to do.