[Forum FAQ]How to troubleshoot common issue when configuring user device affinity from usage data

Question

Symptom:
Some clients might fail to automatically configure user device affinity from usage data if you have manually configured user device affinity before.
When you check the UserAffinity.log, you can find the similar error messages as below:
User 'XXXXX\XXXXX' has xxxxx usage minutes UserAffinity 
Setting auto affinity for user 'XXXXX\XXXXX'. UserAffinity 
Found same state message existing. (was sent before) Skip sending same state message for user 'XXXXX\XXXXX'.. UserAffinity 
Figure 1. Error Message in UserAffinity.log
Cause:
As the log said, there is a user affinity state message existing in WMI which prevents client from sending new user affinity state message.
Resolution:
We can delete the user affinity state message in WMI to force the client to resend the user affinity state message.
We can follow the steps below:
  1. Run Windows Management Instrumentation Tester (“Wbemtest”).
  2. In Windows Management Instrumentation Tester dialog box, click “Connect”.(Figure 2)
Figure 2.
  3. Type “root\ccm\statemsg” under the Namespace table and then click “Connect”.(Figure 3)
Figure 3.
  4. Click “Enum Classes”. (Figure 4)
Figure 4.
  5. Choose “Recursive”
in Superclass Info dialog box.(Figure 5)
Figure 5.
  6. Double-click “CCM_StateMsg” in Query Result dialog box.(Figure 6)
Figure 6.
  7. Click “Instances”
in Object editor for CCM_StateMsg dialog box. (Figure 7)
Figure 7.
  8. Choose the messages that contain "domain/user_Auto" and click “Delete” in the Query Result dialog box.(Figure 8)
Figure 8.
After you delete user affinity state message in WMI, the user affinity state message for the user will be resent. After a period time, we can check the UserAffinity.log to
see if the user affinity state message has been successfully sent. The related information would be similar as below:
Successfully sent user affinity state message for user 'xxxxx\xxxxx'.
Successfully created pending user affinity for user 'xxxxx\xxxxx' into WMI.
Figure 9.
Please click to vote if the post helps you. This can be beneficial to other community members reading the thread.

Answer 1

I'm not sure whether this is the appropriate place to add this but - a (possible) cause that I have seen which is not mentioned above is a request for an AAAA record (IPv6 address)
being responded to with an A record (IPv4 address).
DNS debug logging (Windows 2008 R2 SP1) captured requests to
192.225.156.200 and the corresponding responses. In each case the response was followed in the debug log by the event “The DNS server encountered an invalid domain name
in a packet from 192.225.156.200. The packet will be rejected. The event data contains the DNS packet.”
The domain name in the response was the same as that in the query, and looks OK.
The logged query shows an AAAA record (IPv6 address) request and the logged response returned an A record (IPv4 address).
http://www.rfc-editor.org/rfc/rfc4074.txt “Common
Misbehavior Against DNS Queries for IPv6 Addresses” says, under “Expected Behavior”:
   Suppose that an authoritative server has an A RR but has no AAAA RR
   for a host name.  Then, the server should return a response to a
   query for an AAAA RR of the name with the response code (RCODE) being
   0 (indicating no error) and with an empty answer section (see
   Sections 4.3.2 and 6.2.4 of [1]).  Such a response indicates that
   there is at least one RR of a different type than AAAA for the
   queried name, and the stub resolver can then look for A RRs.