Can you post your switch configuration especially the VLAN 90 IP interface and DHCP server portions? In vWLAN, what locations do you have? How have you configured the role? What location is set in the role?
The problem seems to be corrected, though not positive why. It rejects the location i created defined as being VLAN 90 and creates a vLoc-0-192.168.90.0/24 with VLAN ID 0. Now with the trunk set to native VLAN 90 I assume there's be no tagging for 90 so that makes some sense. Both locations were added to the master location group used by the entire district, and I tried both locations defined within the AP values. Still, this seems to be behaving differently than the sites with the Windows DHCP. Because of differing sizes, number of client VLANS, etc., two of the other sites have APs on the management VLAN with all clients on other VLANs, two have APs on client VLANs like this site, and all work fine and always have.
(1234 Gen 2)
ip dhcp pool "Ramsey"
network 192.168.90.0 255.255.255.0
dns-server 192.168.153.249 192.168.105.194 18.104.22.168
lease 0 2 1
interface gigabit-switchport 0/2
switchport mode trunk
switchport trunk native vlan 90
interface vlan 90
ip address 192.168.90.1 255.255.255.0
ip route-cache express
What is going on here is that in vWLAN you configured a location likely using 192.168.90.0/24 with VLAN ID 90. However, when you think about this in terms of the switch, VLAN 90 is native, meaning it is untagged. To explain this in more technical terms, the Ethernet frames have no 802.1q header. So as far as the APs are concerned, the VLAN ID for VLAN 90 is absent, or 0. That is also why the APs are autodiscovering the other location. The APs will always send out DHCP messages on the native, untagged VLAN and then vWLAN creates a location if one does not match.
I would wager that if you went to Status > Locations, the VLAN 90 location you created would be inactive. Then you might want read up on BSAP Location Discovery and Troubleshooting Inactive Locations which would further explain what I'm saying here. This also explains why clients are not getting an IP address assuming you assigned the inactive location to their role. When vWLAN handles role placement, there is no active role for the users.
I think I had tried it the correct way in one of my numerous attempts, however the IP stickiness of the clients played a role in not diagnosing it correctly, where I corrected the config but it appeared to still not be working so I kept making changes. Even now, clients that have been attached to vWLAN at other sites are going there, showing an address from other sites, but if I forcibly drop them they reconnect pulling a correct local address. This seems to be especially true for Androids and iPhone/iPads, which do have some issues with DHCP functions. When I was originally there, I didn't think to forcibly drop anyone.