Home > SCCM > Moving SCCM server to new hardware – Part 2

Moving SCCM server to new hardware – Part 2

My last post deals with the procedure taken to move Windows 2003 SCCM SP2 R2 server to a new Windows 2008 R2 hardware. as i wrote, the procedure finished successfully and all components seems to work fine. is it possible ?

Several hours after the hardware migration we started to see some error massages in statview console. the problems divided to clients side and servers side.

Clients Side:The main problem with clients was an SMS Public Key issue. the new server have a new key and the some clients can not retrieve it from the site server. (70% of site server clients!!!). i can not explain way those clients did not refresh the key. i couldn’t find any explanation for that.

Solution: Open statview.exe and filter to message id 10822 “The trusted key, mp certificate and the mp machine have changed on server. The client cannot validate the authentication information.”.
i used this script to delete the TrustedRootKey from client store, the script gets the computer name as variable.

‘on error resume next
Dim ObjWMIService,TrustedRootKey,RootKey,ObjComp,ObjWMI

if wscript.arguments.count < 1 then
wscript.quit
else
objcomp = wscript.arguments(0)
wscript.echo “strarting on computer:” & objcomp
end if

objWMI = “winmgmts:{impersonationlevel=impersonate}!\\” & ObjComp & “\root\ccm\locationservices”

Set ObjWMISErvice = GetObject(objWMI)
Set TrustedRootKeys = ObjWMISErvice.ExecQuery(“select * from TRustedRootKey”)

For Each RootKey in TrustedRootKeys
if Rootkey.TrustedRootKey <> “Insert The New key from site server” Then
wscript.echo “TRusted root key did not match key – delete it”
bFOundERrors=TRUE
RootKey.Delete_
Else
wscript.echo “Root Key match”
End If
Next

wscript.echo “done for computer: ” & objcomp

to get the key do the following:

1. In a text editor, edit the file C:\program files\bin\x86\mobileclient.tcf.

2. Locate the entry SMSPublicRootKey= and write down the key or copy it to the Clipboard.

3. When you install the client, using any client installation method, use the Client.msi property SMSPublicRootKey=<key>, where key is the string you copied from mobileclient.tcf.

more information on TechNet.

 

Server Side: here i needed to deal with more then one problem (and i hope that i can remember them all for future use)

x32 to x64 migration – the old SCCM server installed to “c:\program files”, and when we move to new hardware we must keep the same installation folder. when SCCM start to reinstall components after site repair some new data stored in “c:\program files(x86)”.

R2 – R2 installation failed. the process could not find any SCCM installation on server (!?!?!?)  and that because it looks at “c:\program files(x86)”!!!! I’m still trying to find a solution for that.

Share Permission issue – in windows 2003 the share permissions was “everyone” – Full Control. the site server DP could not create new distribution folder under SMSPKGC$, after we set the permissions the DP start to publish new packages.

Registry Permissions – this problem occurs on all DP’s servers. i found this error massage in smsexec.log. ”Could not connect to the “REGISTRY” inbox source on computer PRIMARY SERVER NAME.  Sleeping for 60 seconds.  The operating system reported error 997: Overlapped I/O operation is in progress.”. to solve this problem i found that all machine accounts do not have access to site server registry. the problematic key is “HKEY_LOCAL_MACHINE\SOFTWARE\wow6432node\Microsoft\SMS\inbox source”. the missing permission are for SMS_SiteToSiteServerConnection_<SiteCode> local group. the permissions should look like:

image

Summery: I think that if SCCM installation folder is  “c:\program files” , you should think about other ways to migrate (new site server with new site code).

Advertisements
Categories: SCCM Tags: ,
  1. 22/10/2010 at 10:49 AM

    I agree with you conclusion – SMS and SCCM really do not like if you change their installation folder. It’s just a no-go and therefore the SCCM installation directory should always be simple and never change (like C:\SCCM – if you really have to use the OS drive. Keep in mind the inboxes produce a lot of i/o traffic, the installation itself should be on a seperate array and if possible even controller)

    • 25/10/2010 at 9:03 AM

      Hi Christophe,
      You are absolutely right. SCCM must be installed to a simple folder otherwise the move procedure could led to a non functional SCCM.

      Kobi

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: