Showing results for 
Search instead for 
Did you mean: 

Device profiled as "Asus-Device" instead of "Windows10-Workstation"


Hi all;

This is my scenario:

We have several workstations that have "Asus"-based motherboards. Although these workstations have Windows 10 installed, joined to the domain, and the required attributed are all collected from Active Directory probe (like operating system type and version), ISE profiles these devices as "Asus-Devices"...

We are using ISE 3.1 with Patch 5 installed.

Any ideas?


12 Replies 12

Rob Ingram
VIP Master VIP Master
VIP Master

@rezaalikhani under the endpoint, what result attributes do you get back from the AD Probe? The AD probe performs a lookup based on the computer name of the endpoint, so you need ensure the hostname is learnt by ISE via DHCP, DNS or NMAP probes.

With the DHCP probe you need device sensor feature configured on the switch to learn DHCP information via DHCP snooping or an IP helper address pointing to the ISE PSN configured on the VLAN SVI.

The DNS probe will perform a reverse DNS lookup, it does require ISE has already learnt the IP address of the endpoint.

Refer to the ISE Profiling Guide for more information -


under the endpoint, what result attributes do you get back from the AD Probe?

All the standard (default) attributes that AD probe can gather, are presented.


The AD probe performs a lookup based on the computer name of the endpoint, so you need ensure the hostname is learnt by ISE via DHCP, DNS or NMAP probes.

I have enabled DHCP and DNS probes and all the related attributes are gathered successfully, too.


Arne Bier
VIP Advisor VIP Advisor
VIP Advisor

The profile with the highest Certainty score wins. But in your case, it looks like the Windows10 PC is either not using DHCP, since that is what ISE would use as the base policy (called "Workstation") to detect a Microsoft operating system. or DHCP profiling is not working correctly (if the DHCP data is not getting into ISE)

Asus-Device is 5 points based only on the MAC address prefix (MAC OUI contains "Asustek").

Windows10-Workstation is based on the parent policy Microsoft-Workstation, which is based on the base policy Workstation.


 - Microsoft Workstation

     - Windows10 Workstation

Is your PC enabled with DHCP?  Are you sending DHCP data to ISE (using Cisco Device Sensor or via the ip helper) ? When you inspect the Endpoint in ISE, do you see the DHCP Client Identifier for example? If you don't see this in ISE Context Visibility, then ISE won't consider this to be a "Workstation" and then operating system profiling will be doomed.

Thanks for your reply;

  • I have nearly 150 PCs with Windows 10 installed and ISE correctly profiled them as Windows10-Workstation.
  • I have DHCP service in my network and switches are configured to send DHCP packets to ISE and the actual DHCP servers.
  • As I said before, ISE gathered all the default attributes of AD probe, related to that workstations successfully.
  • As you said, the CF of "Asus-Device" profile policy is 5 (I know this), but I have this problem with only ASUS-based systems.


Arne Bier
VIP Advisor VIP Advisor
VIP Advisor

I did some lab work to try and reproduce the issue. I don't have an Asustek Ethernet adapter - but I used my raspberry pi connected to a Cisco C9300 switch running device-sensor.

I changed the MAC address of the raspi to look like an Asustek

root@raspberrypi:/home/admin# macchanger --mac=00:0C:6E:01:02:03 eth0
Current MAC:   b8:27:eb:2c:50:0c (Raspberry Pi Foundation)
Permanent MAC: b8:27:eb:2c:50:0c (Raspberry Pi Foundation)
New MAC:       00:0c:6e:01:02:03 (ASUSTEK COMPUTER INC.)


And I also created a DHCP request that looks like a Windows DHCP request.


send host-name DESKTOP-YT66D2F;
request subnet-mask, broadcast-address, time-offset, routers,
        domain-name, domain-name-servers, domain-search, host-name,, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers,
        netbios-name-servers, netbios-scope, interface-mtu,
        rfc3442-classless-static-routes, ntp-servers;
send vendor-class-identifier "MSFT 5.0";
send dhcp-client-identifier 1:00:0c:6e:01:02:03;

The result is that my IE 3.2 p2 deployment correctly profiles the device as a Microsoft-Workstation. Since I don't have an AD, I can't profile my endpoint more accurately (e.g. Windows10) - but at least it's not stuck on Asus-Device.

CORE01#show device-sensor cache interface gi 1/0/22
Device: 000c.6e01.0203 on port GigabitEthernet1/0/22
Proto Type:Name                       Len Value                       Text
DHCP    61:client-identifier            9 3D 07 01 00 0C 6E 01 02 03  =....n...
DHCP    60:class-identifier            10 3C 08 4D 53 46 54 20 35 2E  <.MSFT 5.
                                          30                          0
DHCP    50:requested-address            6 32 04 AC 16 80 B2           2.,.^@2
DHCP    12:host-name                   17 0C 0F 44 45 53 4B 54 4F 50  ..DESKTOP
                                          2D 59 54 36 36 44 32 46     -YT66D2F

And the Endpoint in ISE

AAA-Server	labise02
AllowedProtocolMatchedRule	Default
AuthenticationIdentityStore	Internal Endpoints
AuthenticationMethod	Lookup
AuthenticationStatus	AuthenticationPassed
AuthorizationPolicyMatchedRule	Default
BYODRegistration	Unknown
Called-Station-ID	F8-B7-E2-4F-57-16
Calling-Station-ID	00-0C-6E-01-02-03
ClientLatency	0
DTLSSupport	Unknown
DestinationPort	1812
Device IP Address
Device Type	Device Type#All Device Types#SWITCH
DeviceRegistrationStatus	NotRegistered
ElapsedDays	0
EndPointMACAddress	00-0C-6E-01-02-03
EndPointPolicy	Microsoft-Workstation
EndPointProfilerServer	labise02.rnlab.local
EndPointSource	RADIUS Probe
EndPointVersion	196
FQDN	raspberrypi.rnlab.local.
FailureReason	-
Framed-IPv6-Address	fe80::1d20:83:6e62:a123
IdentityGroup	Workstation
IdentityPolicyMatchedRule	Default
IdentitySelectionMatchedRule	Default
InactiveDays	0
IsThirdPartyDeviceFlow	false
Location	Location#All Locations
MACAddress	00:0C:6E:01:02:03
MatchedPolicy	Microsoft-Workstation
MessageCode	3002
NAS-Identifier	CORE01
NAS-Port	50122
NAS-Port-Id	GigabitEthernet1/0/22
NAS-Port-Type	Ethernet
Name	Endpoint Identity Groups:Profiled
Network Device Profile	Cisco
NetworkDeviceGroups	Device Type#All Device Types#SWITCH, IPSEC#Is IPSEC Device#No, Location#All Locations
NetworkDeviceName	CORE01
NetworkDeviceProfileId	b0699505-3150-4215-a80e-6753d45bf56c
NetworkDeviceProfileName	Cisco
OriginalUserName	000c6e010203
PolicyVersion	17
PostureApplicable	Yes
PostureAssessmentStatus	NotApplicable
PreviousMACAddress	00:0C:6E:01:02:03
RadiusFlowType	WiredMAB
SSID	F8-B7-E2-4F-57-16
SelectedAccessService	MAB
SelectedAuthenticationIdentityStores	Internal Endpoints
SelectedAuthorizationProfiles	MAB_PERMIT_ALL
Service-Type	Call Check
StaticAssignment	false
StaticGroupAssignment	false
StepData	5= Normalised Radius.RadiusFlowType, 7=Internal Endpoints, 12= EndPoints.EndPointPolicy
Total Certainty Factor	30
TotalAuthenLatency	1
UseCase	Host Lookup
User-AD-Last-Fetch-Time	1685107210384
User-Fetch-User-Name	00-0C-6E-01-02-03
User-Name	00-0C-6E-01-02-03
UserType	Host
allowEasyWiredSession	false
chaddr	00:0c:6e:01:02:03
dhcp-class-identifier	MSFT 5.0
dhcp-client-identifier	01:00:0c:6e:01:02:03
dhcp-message-type	DHCPREQUEST
dhcp-parameter-request-list	1, 28, 2, 3, 15, 6, 119, 12, 44, 47, 26, 121, 42
epid	epid:248796463613620224
flags	0x0000
hlen	6
host-name	DESKTOP-YT66D2F
htype	Ethernet (10Mb)

Maybe you can share some of your endpoint data and profiling information - to compare notes.



The following is the compressed version of the attributes of one of that clients:

161-udp snmp
162-udp snmptrap
AAA-Server ISE-Primary
AD-Fetch-Host-Name Win-PC-02$
AD-Host-Candidate-Identities WIN-PC-02$
AD-Host-Exists true
AD-Host-NetBios-Name DOMAIN
AD-Host-Qualified-Name WIN-PC-02$
AD-Host-Resolved-DNs CN=WIN-PC-02\,OU=Network\,DC=domain\,DC=com
AD-Host-Resolved-Identities WIN-PC-02$
AD-Host-SamAccount-Name WIN-PC-02$
AD-Last-Fetch-Time 1684323738984
AD-OS-Version 10.0 (19045)
AD-Operating-System Windows 10 Enterprise
AllowedProtocolMatchedRule Dot1X Authentication
AuthenticationMethod MSCHAPV2
AuthenticationStatus AuthenticationPassed
AuthorizationPolicyMatchedRule Domain Wired - Computers-PEAP
BYODRegistration Unknown
Called-Station-ID F8-4F-57-5C-00-85
Calling-Station-ID 00-0C-6E-6C-C4-72
ClientLatency 0
DTLSSupport Unknown
DestinationPort 1645
Device IP Address
Device Name Win10-PC
Device Type Device Type#All Device Types
EndPointMACAddress 00-0C-6E-6C-C4-72
EndPointPolicy Asus-Device
EndPointSource Active Directory Probe
EndPointVersion 121
FailureReason -
IdentityGroup Profiled
RadiusFlowType Wired802_1x
SelectedAccessService EAP-TLS
Service-Type Framed
Software Version 12.2(55)SE12
StaticAssignment FALSE
StaticGroupAssignment FALSE
operating-system-result Windows 10 Enterprise
chaddr 00-0C-6E-6C-C4-72
dhcp-class-identifier MSFT 5.0
dhcp-client-identifier 01:00:0C:6E:6C:C4:72
dhcp-message-type DHCPINFORM
dhcp-parameter-request-list 1, 15, 3, 6, 44, 46, 47, 31, 33, 121, 249, 43, 252
host-name WIN-PC-02
htype Ethernet (10Mb)
operating-system-result Windows 10 Enterprise



Arne Bier
VIP Advisor VIP Advisor
VIP Advisor

I don't see what your "Total Certainty" value is.

It makes no sense. If other (non Asus) endpoints are correctly profiling as Windows 10, then I don't see why this should be any different - unless the Asus-Device Policy has been modified to have a higher certainty than Windows.

One other possible reason might be that the switch on which these Asus endpoints are connected, is not handling the CoA requests from ISE (perhaps CoA not configured with the correct ISE IPs or shared secret is wrong). Do you have endpoints on that same switch that are profiling correctly? If so, then disregard that theory.


I managed to reproduced the problem again!

 AD-Groups-NamesDOMAIN.COM/DOMAIN Servers & Admins/FAVA/Groups/ISE-SuperAdmin, DOMAIN.COM/Users/Domain Users, IDOMAIN.COM/DOMAIN Servers & Admins/FAVA/Groups/FavaGroup
 AD-Host-Resolved-DNsCN=PC01\,OU=WorkStations\,OU=FAVA\,OU=DOMAIN Servers & Admins\,DC=DOMAIN\,DC=COM
 AD-OS-Version10.0 (19041)
 AD-Operating-SystemWindows 10 Enterprise
 AD-User-Resolved-DNsCN=Reza Alikhani\,OU=Users\,OU=FAVA\,OU=DOMAIN Servers & Admins\,DC=DOMAIN\,DC=COM
 AllowedProtocolMatchedRuleAuthentication Dot1.X-DOMAIN
 Days to Expiry328
 Device IP Address192.168.141.11
 Device TypeDevice Type#All Device Types
 EndPointSourceActive Directory Probe
 Extended Key Usage - Name130
 Extended Key Usage - OID1.
 IdentityPolicyMatchedRuleAuthentication Dot1.X-DOMAIN
 IdentitySelectionMatchedRuleAuthentication Dot1.X-DOMAIN
 Issuer - Common NameDOMAIN-RootCA
 Issuer - Domain ComponentDOMAIN, COM
 Issuer - Fingerprint SHA-2562b293c9133edeec7184cb452d39c273b0170435c6dababf74270971b697aafbf
 Key Usage0, 2
 LocationLocation#All Locations
 Network Device ProfileCisco
 NetworkDeviceGroupsIPSEC#Is IPSEC Device#No, Staged Deployment#Staged Deployment#Low-Impact Mode, Location#All Locations, Device Type#All Device Types
 Serial Number42 00 00 11 41 44 FA 63 63 17 C2 7B 7F 00 00 00 00 11 41
 Staged DeploymentStaged Deployment#Staged Deployment#Low-Impact Mode
 Subject Alternative Name - DNSPC01.DOMAIN.COM
 Subject Alternative Name - Other Namer.alikhani@DOMAIN.COM
 Template Name1.
 Total Certainty Factor5
 operating-system-resultWindows 10 Enterprise

As you can see above, although ISE has recognized the OS of the endpoint, but profiled it as "Asus-Device"!

Any ideas?



Cisco Employee
Cisco Employee

@rezaalikhani ISE Profiler Policies are hierarchical. For Windows 10, the profiling order is (1) Workstation, (2) Microsoft-Workstation, and (3) Windows10-Workstation.

It seems none of your attributes matched with Workstation so that is where it stops. You may either modify the Workstation policy directly or duplicate it and update the duplicated copy and add a condition on AD-Operating-System.

Thanks for your reply;

My problem is that I have nearly 200 PC as Windows 10 and non of them except 5 of them have this problem. Do you think I still need to modify the Workstation profiling policy?


Cisco Employee
Cisco Employee

@rezaalikhani Please compare the list of endpoint attributes between working and not-working ones. As Arne said, dhcp-class-identifier or User-Agent are used typically. If you are unable to get these attributes for the not-working ones, then yes, customize the profiling policy is the way to go, until our team updates the profiling policies.

CSCwf74895 open for tracking and you should be able to read it by next week.

I managed to gather more information regarding this problem:

  1. Several switches are included in this problem. One of them is 2060-X with the Cisco's recommended IOS on it.
  2. I have seen this problem with clients with static IP addresses and leased IP addresses from a DHCP server.
  3. The involved switch has other clients that ISE correctly profiled them (so CoA configuration is not suspicious).
  4. The problematic clients has various operating systems from Windows 7 to Windows 10 and 11.
  5. I compared the attributes of two devices, one of them is profiled correctly and one of them is not. Nothing special was there except, the profiled devices had CF as 50 and problematic devices were 5.
  6. I tried to import the provided .zip file but I encountered "Internal Error - Import Failed. Unknown enum." error message.


Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers