SMS to SCCM Upgrade

We currently have SMS 2003 and will be upgrading to SCCM in the next two weeks. We are not worried about any sort of data migration from the old SMS to the new SCCM. Planning on installing SCCM fresh on a new server with a new site code, and then manually rolling over any packages, and such. The SMS 2003 server will still be up and running while I install SCCM and clients will still be pointing to the old SMS server. But I have a question about the client side upgrade once I am ready to upgrade the clients...
 
1. From what I have read, SMS clients can point to the new SCCM server, even though they have the old client, correct? How do you do this? By setting the boundaries in SCCM? I don't want to do a mass upgrade of the clients so just making sure I won't be accidently upgrading clients by setting up the boundaries. I think this is possible but just looking for some verification. Delete the old boundary on the SMS server and then setup the same boundary on SCCM?
 
2. Once the clients are pointed to the new SCCM server, I will be pushing out the new client in phases. Any tips on the best way to do this? Manually within the SCCM console, or should I use a login script?
 
Thanks for any help!
 
-Ryan
 
 

We thought like that as well.  Leave the old clients pointing to your old server until you are ready to go to the new one.  SMS client will not work with SCCM server, especially if you are using native mode.  Use group policy to install the cient as well as setting the client install parameters and to enforce the site assignemnts.  The templates are on the sccm install media.  They are called CONFIGMGR2007ASSIGNMENT and CONFIGMGR2007INSTALLATION.  We use both here and so far it has been working well and we are still in the process of rolling SCCM out in the Americas and Mexico and then to Europe/Asia after that.

rtruss


SMS client will not work with SCCM server, especially if you are using native mode. 

 
Really? SMS Clients cannot point to SCCM and work without being upgraded? I was told that SCCM is backwards compatible with SMS clients and was actually given a script from this forum on how to point SMS clients to the new SCCM server, and then to do the upgrade of the client after everything was pointing to the new SCCM.

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.

SMS clients can report into SCCM server in mixed mode.  The only thing you need to be careful is to ensure that once you point the SMS client to the SCCM server, it doesn't ever get assigned back to an SMS server, HW inventory won't work anymore. We had this issue at my old company.  When the SMS client is assigned to the SCCM server that data becomes signed, if you reassign the client back to SMS server that data is still signed, and SMS 2003 doesn't know what to do with it and will throw away HW, SW inventory, etc.  We didn't sign our SMS data, but SCCM doesn't give you a choice.  My guess is that if we had signed data turned on in SMS and then assigned it to SCCM and then back to an SMS server again it would of worked, since the data has always been signed, but that's something we didn't have setup.

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.

Ryan, not quite sure what issues others have had, but I've just completed a 5000+ client migration from SMS to SCCM SP1 R2 with side-by-side infrastructure. SCCM is running in Mixed mode, and the critical point to support SMS clients is to ensure that the properties of your SCCM site server (on the "Site Mode" tab) is configured with the option "This site contains only ConfigMgr 2007 clients" disabled. You also need to make sure that the site approval setting (also on the Site Mode tab) is set to "Automatically approve computers in trusted domains....."

In addition to this, the only other gotcha I had was an issue with the client migration  process and the SMS clients 'Remote Control' driver. For some reason when the clients migrated MP from the SMS site to the SCCM site the Remote Control driver would update it self. Then later on when the entire client was upgraded from SMS to SCCM, the uninstall of the SMS client would fail when trying to remove the updated Remote Control components. This was highlighted in the Setupapi.log , where it will halt at: #I289 Removing device "ROOT\*SMS_MOUSE\0000"
To resolve this, I just disabled the Remote Tools Client Agent on my SCCM sites for the duration of the client migration process.

The only other significant addition to the migration process was that I advertised a script to the target clients from the SMS site to launch the migration. This script made sure that all Pending Assignments for the SMS client were cleared prior to the migration process as these caused issues on some clients. Here is the code for the script:

[font="'courier new'"]strObjPath = "SMS_PendingSiteAssignment=@"

[font="'courier new'"]


[font="'courier new'"]'check the WMI

[font="'courier new'"]strObjPath1 = "SMS_PendingSiteAssignment"

[font="'courier new'"]strComputer = "."

[font="'courier new'"]Set objLocator = CreateObject("WbemScripting.SWbemLocator")

[font="'courier new'"]Set objService = objLocator.ConnectServer(".", "root\ccm")

[font="'courier new'"]Set colSWbemObjectSet = objService.InstancesOf(strObjPath1)

[font="'courier new'"]intErr = colSWbemObjectSet.count

[font="'courier new'"]


[font="'courier new'"]If intErr >0 then

[font="'courier new'"]objService.delete strObjPath  

set objLocator = nothing

[font="'courier new'"]set objService = nothing

End If

In addition to the code above, the script also got the client to perform a Site Code Discovery, then a Restart of the Agent service, and finally a Machine Policy refresh. All of these operations can be completed in one script and the script made into an SMS package. When advertised to the SMS clients, make sure that the properties of the advertisement are configured to Allow execution from Remote Distribution Points!!

So basically my migration approach was this:

1. Ensure SCCM site server is configured to accept SMS clients
2. Configure SCCM site server to publish site info to Active Directory
3. Configure SCCM site servers 'Remote Tools Client Agent' as disabled
4. Create a collection on SMS site containing target clients (I did this by subnet)
5. 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).
6. 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, )
7. Remove boundary from SMS site (target IP subnet)
8. Add boundary to SCCM site (target IP subnet)
9. 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.

As an additional check I also created a collection on my SCCM site which was looking for all clients with a client version of 2.x. This assisted in helping me pickup any clients which failed the upgrade process... and plenty did. Some due to WMI issues, some due to missing environment variables... this list goes on :-)


Hope this helps... good luck.

David M.
 

Thanks David for the detailed steps, appreciate that. A couple questions for you or anyone else.
 
1. What type of package do I use for this SCCM client install? Where do I find this?
 
2. I would like to install the new client just on my PC as a test, but the way the site boundaries are setup on my SMS server is by using AD Sites, so not sure how I would handle that. If I removed the site boundary that my PC exists in, that would then remove the boundary for around 300 computers. Can I just add a site boundary by my specific PC's IP address on the new SCCM server? But then wouldn't that cause problems as my PC is part of the AD Site boundary on my SMS server?
 
3. You mention some clients failed due to WMI problems. This has been an issue with us for quite a while (corrupt WMI not allowing for SMS client to install). Any tips on how to fix the WMI on the client side? I have tried so many things already with trying to repair the WMI (Msft white papers) but none have been successful. We have around 10 PC's that just cannot for the life of them get the SMS client to install due to WMI corruption. 
 

I just went through a similar upgrade.  We had some issues with the new clients reporting to the new SCCM server once we turned on the client push.  What we found out was that even though the clients had the new Config Manager client they retained the old SMS certificates so they would not report to the new config manager server.
 
The fix for this was to delete the old certs off of the system and restart the ccmexec.  However I found out after the fact of course :) you can add RESETKEYINFORMATION=TRUE as a switch to the ccmsetup.exe that will reset the certificates during the installation and allow your clients to report back successfully.
 
Here is a heloful link that has all of the switches that you can put on the ccmsetup.exe that might help you.
http://technet.microsoft.com/en-us/library/bb680980.aspx 

Ryan, you create a SCCM client install package from the following share on you site server. \\ServerName\SMS_SiteCode The directory 'Client' within this share is your SCCM client installation files.

As Thermes  mentioned, you can also utilise the cmmsetup.exe switches to control you client installation. The following switches will allow you to have the client install and use an SCCM site server as it's management point, without that site server having a boundary defined for the client. SMSSITECODE= and SMSMP= also you may need to use the SMSSLP= switch to force the client to utilise the SCCM server locator point.
So you can migrate clients without having boundaries defined on you SCCM site server... but if you do those clients will be classed as "remote" to the SCCM site so SCCM advertisements which are not configured to run from remote sites will not be actioned by the clients.

If I were you, I'd do a couple of individual client tests to chech that you process works, using the ccmsetup switches mentioned. Then I'd bite the bullet and remove the AD site boundaries (one at a time) from my SMS sites to my SCCM. The SMS clients will still talk to their SMS site servers , but they will now be "remote" so the rules above apply. Then kick of you migration (staggered) as soon as you can.

I always use the same WMI rebuild script... and so far it hasn't let me down. Just place the text below into a CMD/BAT file.

sc config winmgmt start= disabled

net stop winmgmt /y

%systemdrive%

cd %windir%\system32\wbem

if exist repository.old rmdir /s/q repository.old

rename repository repository.old

regsvr32 /s %windir%\system32\tscfgwmi.dll

wmiprvse /regserver 

winmgmt /regserver

sc config winmgmt start= auto

net start winmgmt

for /f %%s in ('dir /b *.mof') do mofcomp %%s


for /f %%s in ('dir /b *.mfl') do mofcomp %%s

cd %windir%\system32\ccm


for /f %%s in ('dir /b *.mof *.mfl') do mofcomp %%s

Good luck.

does that script also repair sms/sccm agents if they're having WMI issues?

Thanks Dave, really good stuff. One last question for you. Currently, I have a login vb script that gets processed each time a user logs on. Basically it checks to see if the SMS client is installed on the PC and if not, it goes ahead and installs the client. It has worked really well for us and I would love to continue using it with SCCM. If you have time, can you look it over and see if it would still work with SCCM? Here it is...
 
Option Explicit
Dim strSiteCode
Dim strMode
strSiteCode = "LSE"
If WScript.arguments.count > 0 Then
 strSiteCode = WScript.arguments(0)
End If
Dim WshShell, lngExitCode
Set WshShell = CreateObject("WScript.Shell")
If ClientInstalledAndAuto("") = False Then
 Dim oExec, strCmdLine
 strCmdLine = ScriptDir & "\Ccmsetup.exe /service SMSSITECODE=" & strSiteCode
 lngExitCode = WshShell.Run(strCmdLine, 0, True)
 WshShell.LogEvent 0, "Started SMS Advanced Client Install: """ & strCmdLine & """" & CHR(10) & "Exit code was " & CSTR(lngExitCode)
Else
 WshShell.LogEvent 0, "SMS Advanced Client service (ccmexec) is installed and set to Automatic.  No action required."
End If
Function ScriptDir
 ScriptDir = Left(WScript.ScriptFullName,Len(WScript.ScriptFullName) - Len(WScript.ScriptName) -1)
End Function
Function ClientInstalledAndAuto(strComputerName)
 ClientInstalledAndAuto = False
 On Error Resume Next
 
 If Len(strComputerName) = 0 Then
  strComputerName = "."
 End If
 
 Dim objWMI, objList, objItem
 
 Set objWMI = GetObject("winmgmts://" & strComputerName & "/root/cimv2")
 If err.number <> 0 Then
  Exit Function 
 End If
 strMode = ""
 
 Set objList = objWMI.ExecQuery("Select StartMode from Win32_Service where Name=""CcmExec""")
 For Each objItem In objList
  strMode = objItem.StartMode
  Exit For
 Next
 
 If strMode = "Auto" Then
  ClientInstalledAndAuto = True
 Else
  ClientInstalledAndAuto = False
  If Len(strMode) = 0 Then
   WshShell.LogEvent 0, "SMS Advanced Client service not found."
  Else
   WshShell.LogEvent 0, "SMS Advanced Client service (CCMEXEC) is set to " & strMode
  End If
 End If
End Function

Ryan, no problem. Without dissecting the code too deeply, I don't need to because the ccmsetup process for SCCM is the same from SMS. If you current script works with SMS it will work with SCCM. There are no switches that your using which aren't valid under SCCM, so it will work just fine.

Having said that... it's not a mechanism I utilise so I'm not aware of what issues might exist. I'm sure others who use this process will give you their 2c's worth if they see an issue.

Cheers.

I like that script for installing the client at least the part where it checks wmi for the startup options so I may add t hat to the one we users here in conjunction with the SCCM GPO templates in my first post.  One forces the site assignment and the other passes the ccmsetup.exe paramters during install which allows us to use 1 script in any location.

'=======================================================================
' AUTHOR:  Roger Truss
' COMPANY: Brunswick Corporation
' DATE:    07/26/2010
' COMMENT: This Script installs the SCCM Client
'=======================================================================
'***********************************************************************
' settings and variables section
'***********************************************************************
on error resume next
Set wshShell = CreateObject("Wscript.Shell")
Set oFSO = CreateObject("Scripting.FileSystemObject")
Set objService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\.\root\cimv2")
Set objWMIObjects = objService.InstancesOf("Win32_Process")
DIM sSetup, oArch, sCcmExecPath
sSystemRootKey = "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot"
sSystemRoot = WshShell.RegRead(sSystemRootKey)
Set colItems = objService.ExecQuery("SELECT * FROM Win32_ComputerSystem", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
For Each objItem In colItems
  oARCH = Left(objItem.SystemType,3)
next
'**************************
' Package naming structure.
'**************************
sInstalledFrom = "WEB"  '"web" or "sms" or "ris" or "manual" or "CD"
sInstallType = "Setup" '"setup" or "update" or "remove" or "upgrade"
sInstallVer  = "2007"
sInstallName = "SCCM"
sInstallMaker = "Microsoft"
sClientVer    = "4.0.6487.2000"
Select Case LCase((oArch))
  Case "x86"
    sCcmExecPath = ssystemroot & "\System32\CCM\ccmexec.exe"
  Case "x64"
    sCcmExecPath = ssystemroot & "\SysWOW64\CCM\ccmexec.exe"
  Case Else
    whsShell.LogEvent 1, "Setup could not detect Processor Type, installation can not continue on a " & UCase(oArch) & " based system."
    Wscript.quit(1)
End Select 
If oFSO.FileExists(sCcmExecPath) Then
  sCcmExecVer = oFSO.GetFileVersion(sCcmExecPath)
  If sCcmExecVer < sClientVer then install
Else 
  install
End If
sub install
  sinstall  =  "file://bcfdlsccmp01.brunswick.com/SCCM_Client_Install/ccmsetup.exe"
 whsShell.LogEvent 1, "sinstall: " & sinstall & " was initiated on " & now & "."
' wscript.echo sinstall
' wscript.Quit
  title = "SCCM Installer Utility"
  msg = "Installing/Upgrading SCCM Client."
  WshShell.Popup msg,5, title, 64
 WshShell.Run sInstall, 1, True
End Sub

dmatthews79


Ryan, no problem. Without dissecting the code too deeply, I don't need to because the ccmsetup process for SCCM is the same from SMS. If you current script works with SMS it will work with SCCM. There are no switches that your using which aren't valid under SCCM, so it will work just fine.

Having said that... it's not a mechanism I utilise so I'm not aware of what issues might exist. I'm sure others who use this process will give you their 2c's worth if they see an issue.

Cheers.

Tried the WMI script, but still get the same error as before. Seen it before? I'm googled it plenty of times and it seems to come back to corrupt WMI.
 

OK So Ihave modified my client script to now check that client startup if the installed version matches the script version and it works nicely.  thanks rbanse.

here it is................

'=======================================================================
' AUTHOR:  Roger Truss
' COMPANY: Brunswick Corporation
' DATE:    07/26/2010
' COMMENT: This Script installs the SCCM Client
'=======================================================================
'***********************************************************************
' settings and variables section
'***********************************************************************
on error resume next
Set wshShell = CreateObject("Wscript.Shell")
Set oFSO = CreateObject("Scripting.FileSystemObject")
Set objService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\.\root\cimv2")
Set objWMIObjects = objService.InstancesOf("Win32_Process")
DIM sSetup, oArch, sCcmExecPath
 Dim objWMI, objList, objItem
sSystemRootKey = "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot"
sSystemRoot = WshShell.RegRead(sSystemRootKey)
Set colItems = objService.ExecQuery("SELECT * FROM Win32_ComputerSystem", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
For Each objItem In colItems
  oARCH = Left(objItem.SystemType,3)
next
'**************************
' Package naming structure.
'**************************
sInstalledFrom = "WEB"  '"web" or "sms" or "ris" or "manual" or "CD"
sInstallType = "Setup" '"setup" or "update" or "remove" or "upgrade"
sInstallVer  = "2007"
sInstallName = "SCCM"
sInstallMaker = "Microsoft"
sClientVer    = "4.0.6487.2000"
Select Case LCase((oArch))
  Case "x86"
    sCcmExecPath = ssystemroot & "\System32\CCM\ccmexec.exe"
  Case "x64"
    sCcmExecPath = ssystemroot & "\SysWOW64\CCM\ccmexec.exe"
  Case Else
    whsShell.LogEvent 1, "Setup could not detect Processor Type, installation can not continue on a " & UCase(oArch) & " based system."
    Wscript.quit(1)
End Select 
If oFSO.FileExists(sCcmExecPath) Then
  sCcmExecVer = oFSO.GetFileVersion(sCcmExecPath)
  If sCcmExecVer < sClientVer then install
  If sCcmExecVer = sClientVer then ccmstartcheck
Else 
  install
End If
sub install
  sinstall  =  "file://bcfdlsccmp01.brunswick.com/SCCM_Client_Install/ccmsetup.exe"
 whsShell.LogEvent 1, "sinstall: " & sinstall & " was initiated on " & now & "."
' wscript.echo sinstall
' wscript.Quit
  title = "SCCM Installer Utility"
  msg = "Installing/Upgrading SCCM Client."
  WshShell.Popup msg,5, title, 64
 WshShell.Run sInstall, 1, True
End Sub
Sub ccmstartcheck 
 Set objWMI = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\.\root\cimv2")
 If err.number <> 0 Then
  Exit sub
 End If
 strMode = ""
 
 Set objList = objWMI.ExecQuery("Select StartMode from Win32_Service where Name=""CcmExec""")
 For Each objItem In objList
  strMode = objItem.StartMode
  Exit For
 Next
 
 If strMode = "Auto" Then
  ClientInstalledAndAuto = True
 Else
  ClientInstalledAndAuto = False
  If Len(strMode) = 0 Then
   WshShell.LogEvent 0, "SMS Advanced Client service not found."
   Install
  Else
   WshShell.LogEvent 0, "SMS Advanced Client service (CCMEXEC) is set to " & strMode
  End If
 End If
End sub 'ccmstartcheck

rbanse


Tried the WMI script, but still get the same error as before. Seen it before? I'm googled it plenty of times and it seems to come back to corrupt WMI.
 

Sorry Ryan, can't say I've had that particular issue. There is a WMIDiag utility (http://www.microsoft.com/downloads/details.aspx?familyid=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d&displaylang=en) that you could have a look at. It may show some issue.


Basically, if a client was giving me that much grief, I'd just rebuild it. Takes less than an hour and then I can move on to something else. 

Cheers.

dmatthews79

rbanse


Tried the WMI script, but still get the same error as before. Seen it before? I'm googled it plenty of times and it seems to come back to corrupt WMI.

 
Sorry Ryan, can't say I've had that particular issue. There is a WMIDiag utility (http://www.microsoft.com/downloads/details.aspx?familyid=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d&displaylang=en) that you could have a look at. It may show some issue.


Basically, if a client was giving me that much grief, I'd just rebuild it. Takes less than an hour and then I can move on to something else. 

Cheers.

Yea, that is exactly what we do (re-build), but it stinks that we have to do this in order to fix the WMI. Oh well. Thanks again!

Hot dog! I found a script that fixes my WMI issues, namely with the problem of smsclient.mof when the agent tries to install. Here is what worked for me (found it on a msft blog)....
 
Winmgmt /clearadap
Winmgmt /kill
Winmgmt /unregserver
Winmgmt /regserver
Winmgmt /resyncperf
net stop "sms agent host"
net stop winmgmt
c:
cd %systemroot%\system32\wbem
rd /S /Q repository
regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll
mofcomp cimwin32.mof
mofcomp cimwin32.mfl
mofcomp rsop.mof
mofcomp rsop.mfl
for /f %%s in ('dir /b /s *.dll') do regsvr32 /s %%s
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s
net start winmgmt
net start "sms agent host"
pause

Awsome, well done. Thanks for posting the resolution.  I'll grab a copy and store for rainy WMI day. 

Cheers.