wnmanual.log assessing assignment states failing to find site

[gregzielinski]

The problem is clients are failing their installs and not showing up or getting assigned.

You see multiple lines like
Assessing assignment state from "\\MONBDC1\SMSLOGON\SITES\AUS"
Assessing assignment state from "\\MONBDC1\SMSLOGON\SITES\BOS
Assessing assignment state from "\\MONBDC1\SMSLOGON\SITES\NYC

Each one is followed by
CHK ASSMT : To become assigned, the potential client must match the follwing 'IP Subnets' data. Using DLL 'SMSDISCV.DLL', Entry Point 'GetSMSAssignmentStatus' to fetch this data.

Then the Correct subnets for those 3 sites are listed and don't match so it logs

Card at index 1 is not valid for assignment~
Function return - Client not assigned

After going through the 3 sites is ends with

Function return - Client not assigned $$<CliEx32.dll><Fri Aug 30 13:03:08.791 2002><thread=1088 (0x440)>
After adding any new sites, there are 1 site keys and 0 sites in the site list $$<CliEx32.dll><Fri Aug 30 13:03:08.801 2002><thread=1088 (0x440)>
Site Key #0: &quot;LAX&quot; $$<CliEx32.dll><Fri Aug 30 13:03:08.811 2002><thread=1088 (0x440)>
Not writing Site List data back to the registry (no new sites) $$<CliEx32.dll><Fri Aug 30 13:03:08.811 2002><thread=1088 (0x440)>
Client is not assigned to any sites - finished. $$<CliEx32.dll><Fri Aug 30 13:03:08.821 2002><thread=1088 (0x440)>

One of the problems is that there are 8 sites and those are the only 3 that get listed in the log. So OUR site &quot;CHI&quot;, never lists it's boundaries and then never gets assigned.

This has been only recent. 200+ other clients have installed fine. Their logs show ALL sites listing their boundaries and of course finds the the CHI boundary and adds it.

Now the &quot;CHI&quot; site gets skipped and never lists it's boundaries so the client never gets assigned.

 

[Brindles]

Greg,

Did you ever find a solution to this problem? I had to delete the entire site and re-install.

They way we created sites as to delete the default Client Connection account ie. SMSClient_<sitecode> and create 3 X new Client Connection accounts within the SMS Admin. console. We also disabled the default account ie. SMSClient_<sitecode> within AD.

The sites we did this to did not receive site information located under <DC>\SMSLOGON\SITES\<sitecode> and therefore caused the same problem as you described.

I am trying to determine if this is the cause, but if you have resolved it, I would be grateful if you could remember how.

Regs,
Brindles