none
Some clients will not re-assign to new site.

    Question

  • I’ve put up a new CM site to replace an old dilapidated site. Everything has gone smooth and I’ve been able to reassign >2000 client to the new site. I’ve got 100ish that will not reassign. Unfortunately I do not know much of these client history. Boundaries look good, and like I've said most clients have reassigned just fine (clients in same site). The site I am trying to assign these to is a child primary, however they will not reassign to the central primary either.

     

    Here is what I know (log file excerpts).

     

    LocationServices.log - I am focusing in on the two bold lines, but cant make heads or tails about them.

    Attempting to retrieve default management point from AD    LocationServices    7/9/2009 4:57:46 PM    3840 (0x0F00)
    Retrieved Default Management Point from AD: OLDSERVER.NET.FMCTI.COM    LocationServices    7/9/2009 4:57:46 PM    3840 (0x0F00)
    Unknown task LSProxyMPModificationTask in non-quarantine - ignoring.    LocationServices    7/9/2009 4:57:46 PM    2012 (0x07DC)
    *** Executing Group Policy Site Assignment Task (1/360)***    LocationServices    7/9/2009 4:58:07 PM    2608 (0x0A30)
    Assignment site code for site 'NEW' is 'OLD'Site codes do not match    LocationServices    7/9/2009 4:59:24 PM    1896 (0x0768)

    Current AD site of machine is HOU1    LocationServices    7/9/2009 4:59:57 PM    3964 (0x0F7C)


    ClientLocation.log

    GetCurrentManagementPointEx    ClientLocation    7/9/2009 5:00:04 PM    2072 (0x0818)
    Current Management Point is OLDMP.NET.FMCTI.COM with version 6221 and capabilities: <Capabilities SchemaVersion="1.0">
    </Capabilities>.    ClientLocation    7/9/2009 5:00:04 PM    2072 (0x0818)
    Setting Assigned Site    ClientLocation    7/9/2009 5:00:04 PM    1488 (0x05D0)
    Assigning client to site 'NEW'    ClientLocation    7/9/2009 5:00:04 PM    1488 (0x05D0)
    Attempting to assign client to secondary site    ClientLocation    7/9/2009 5:00:04 PM    1488 (0x05D0)
    Raising event:
    [SMS_CodePage(437), SMS_LocaleID(1033)]
    instance of SMS_RemoteClient_ClientNotAssigned
    {
        AttemptedSitecode = "NEW";
        ClientID = "GUID:483F8CC7-034F-4911-B947-27178B073F17";
        DateTime = "20090709220004.875000+000";
        MachineName = "computername";
        ProcessID = 3080;
        SiteCode = "OLD";
        ThreadID = 1488;
    };
        ClientLocation    7/9/2009 5:00:04 PM    1488 (0x05D0)


    Reinstalling the client has done nothing. The client while assigned to the wrong site, it working just fine in the old site (inventory, software deployment, etc.). And though this has little technical value, all of the effected machines are old. We have reciently refresh most machien in the organization, and these 100 are thoes that have not been refreshed. My guess is that the cleints on these machiens were installed using WSUS/SUP and this mught have soemthign to do with the issue, but I am not sure where to begin troubleshooting that, or if infact there is any validity to this guess.

    Any pointers in this situation would be greatly appreciated.

    neilp




     

     

     

     

     

    Friday, July 10, 2009 2:12 AM

Answers

  • Thanks for the help all - I've got it figured out. At some point in the organization someone had implemented a GPO (admin template) to assign the CM site. This GPO was also at some time before me removed; however the registry settings remained tattooed on the client.

    HKLM\Software\Microsoft\SMS\Mobile Client\GPSiteAssignmentCode - Changing this value from the old site to the new fixxed the issue.

    neilp
    Monday, July 13, 2009 4:08 PM

All replies

  • That's the problem: "Attempting to assign client to secondary site". You cannot assign clients to secondary sites - only primaries.
    Also make sure that there's nothing left from you old site in the system manegement container.
    What happens if you try to assign the client manually (using the control panel applet)?
    Friday, July 10, 2009 6:48 AM
    Moderator
  • Yeah that’s the bizarre part the new site in question is a primary site. I have deployed no secondary sites. 95% of my machines have had no issues assigning themselves to this site.

    My old site is still up and I planned to leave its objects in the Systems Management container until completion of the project. However for testing purposes I have removed them and still no luck with the site reassignment.

    If tying to manually change the site code a “Failure to update site assignment” is thrown.  Furthermore I’ve taken two almost identical machines, in the same subnet. On machine one (which represents 95% of my fleet) clicking on the Auto Discover button results in a successful discovery of the new primary site. On machines two (representing 5% of my fleet) clicking on this button results in "Automatic Site discovery was unsuccessful" (all old objects are still removed from AD). Something that keeps sticking out to me, that I have never seen before, is the first line in this LocationServices.log. "Found Assigned Site Code <OLD> by Group Policy". I am not aware of site assignemnt trhough Group Policy and furthermore, would not know where to look for this. I have scoured the local policy on the machine and can find nothign obvious. All machines are subject to the same GPO's

    This is the complete logging when clicking on the auto discover button for an effected machine. 

     

    LSGetAssignedSiteFromDirectories: Found Assigned Site Code <OLD> by Group Policy     LocationServices    7/10/2009 9:07:11 AM    3628 (0x0E2C)
    LSVerifySiteVersion : Verifying Site Version for <OLD>    LocationServices    7/10/2009 9:07:11 AM    3628 (0x0E2C)
    LSGetSiteVersionFromAD : Failed to retrieve version for the site 'OLD' (0x80004005)    LocationServices    7/10/2009 9:07:11 AM    3628 (0x0E2C)
    Attempting to retrieve SLPs from AD    LocationServices    7/10/2009 9:07:11 AM    3628 (0x0E2C)
    Retrieved SLPs from AD    LocationServices    7/10/2009 9:07:11 AM    3628 (0x0E2C)
    Raising event:

    instance of CCM_CcmHttp_Status
    {
        ClientID = "GUID:483F8CC7-034F-4911-B947-27178B073F17";
        DateTime = "20090710140712.418000+000";
        HostName = "NEWCENTRALPRIMARY";
        HRESULT = "0x00000000";
        ProcessID = 360;
        StatusCode = 0;
        ThreadID = 3628;
    };
        LocationServices    7/10/2009 9:07:12 AM    3628 (0x0E2C)
    Raising event:

    instance of CCM_CcmHttp_Status
    {
        ClientID = "GUID:483F8CC7-034F-4911-B947-27178B073F17";
        DateTime = "20090710140712.481000+000";
        HostName = "OLDPRIMARY";
        HRESULT = "0x00000000";
        ProcessID = 360;
        StatusCode = 0;
        ThreadID = 3628;
    };
        LocationServices    7/10/2009 9:07:12 AM    3628 (0x0E2C)
    LSGetSiteVersionFromSLP : Retrieved site version as '4.00.6221.1000' from SLP for site <OLD>    LocationServices    7/10/2009 9:07:12 AM    3628 (0x0E2C)
    LSVerifySiteVersion : Verified Client Version '4.00.6221.1000' is not greater than Site Version '4.00.6221.1000'. Client can be assigned to site <OLD>.    LocationServices    7/10/2009 9:07:12 AM    3628 (0x0E2C)

     

    Thanks again for any help.

     

    neilp

     

    Friday, July 10, 2009 2:14 PM
  • Can you check the value in following registry key at one of the fail client HKLM\software\microsoft\ccmsetup?

    Thanks,
    Minh.
    Minh
    Friday, July 10, 2009 9:41 PM
  • Thanks for the reply - sampling three clients the values all appear to be somewhat unique to the client.

    CCMSetupStampHigh 0x01c91e66 (30015885)
    CCMSetupStampLow 0x4ccd7300 (4215003040)


    CCMSteupStampHigh 0x01ca018d (30015885)
    CCMSetupStampLow 0xfb3bd7a0 (4215003040)


    CCMSetupStampHigh 0x01ca00c6 (30015686)
    CCMSetupStampLow 0x65x367f0 (170730444)



    And here is a good client

    CCMSetupStampHigh 0x01ca00e0 (30015712)
    CCMSetupStampLow 0x1b2f9d20 (456105248)


    Thanks.

    neilp



    Monday, July 13, 2009 1:15 PM
  • Thanks for the help all - I've got it figured out. At some point in the organization someone had implemented a GPO (admin template) to assign the CM site. This GPO was also at some time before me removed; however the registry settings remained tattooed on the client.

    HKLM\Software\Microsoft\SMS\Mobile Client\GPSiteAssignmentCode - Changing this value from the old site to the new fixxed the issue.

    neilp
    Monday, July 13, 2009 4:08 PM