Computer name not displaying properly in Description

[CML_Todd]

Recently I've noticed computer names not displaying properly in Dashboard.  I've attached a screen shot 

The top 3 names in the list are an example of what I'm talking about. 

I opened a ticket with Meraki, and they said:

"what you are seeing there is the MDNS name which has a higher weight than NetBIOS and DHCP when reporting to dashboard. "

This is also happening on Apple devices. These names just started showing up in my dashboard a couple of months ago.  This makes troubleshooting clients cumbersome.  Meraki claims nothing has changed within Dashboard's back end configuration.  Support's suggestion was to manually enter the computer name in dashboard, but that's not practical with thousands of machines over 25 separate networks.  

Has anyone else seen this?  Is there a way to disable mdns names in a client?  Or to change it? 

[kYutobi]

Click on the client and hit the pencil to edit the name.

[CML_Todd]

That's the part I wanted to avoid, if possible.  I would have thousands of devices to update.

[Happiman]

@CML_Todd 

I am having the exact same issues so opened a case a couple of months ago.

Meraki Tech replied...

=======The name you mentioned looks like a MDNS hostname learnt by the Dashboard. This happens when the client is reporting a hostname via MDNS packets and this overrides the NetBios and DHCP Hostname that might have been configured on the client device.

To mitigate this issue, there are a couple of things that can be looked into:

1) Verify where the MDNS hostname is configured and change it to any expected hostname that needs to be on the Dashboard.

2) Stop MDNS services on the client device so that it does not update the MDNS hostname on Dashboard.

3) Manually update the client device's hostname using the following instructions: https://documentation.meraki.com/MX/Monitoring_and_Reporting/Rename_a_Client_Hostname Hostname broadcasted by MDNS gets priority over DHCP and NetBios and hence, the hostname gets updated when the client sends MDNS traffic. Let me know if you have any questions.

Regards, Siddhant Marar Cisco Meraki

========

I was trying to disable the MDNS service from Windows PC but even I couldn't locate it.

[CN]

Just curious, does there seem to be any common software installed on the devices that are showing the alphanumeric name. Perhaps a remote desktop app or maybe a meeting place app? If it's happening across device types, it could be some application that is sending MDNS traffic that the MX/MR are registering as the device name. It might be doing this to try and discover other devices on the LAN network that it is able to communicate with. 

As @Raj66 mentioned, mDNS is going to be preferred once learned (unless renamed). 

[Roux]

No additional software is installed that would send mdns. I verified bonjour isn't installed as well. It is pretty random. It does it for windows 7 and windows 10. Each model has a different image and some of the same models display correctly on the mx and others display with the mdns like name.  Some of these systems have been on the network for a long time and suddenly about 3 months ago started doing this. The Mac systems aren't imaged, so each one is a different install.

[kYutobi]

I got this link from @Nash who was able to inform me.

https://dashboard.meraki.com/api_docs#provisions-a-client-with-a-name-and-policy

Hope it helps.

[PhilipDAth]

The names you are seeing are "privacy" names, and devices like Apple and Chromebooks have moved to using them on purpose.  Great for domestic users, a pain in the arse for companies.

[Roux]

We are having the same issue and it start about 3 or 4 months ago. Opened a ticket with support and was told mDNS takes priority over netbios. Wireshark showed my clients are sending the mDNS request with the weird names, so I disabled LLMNR  on the client, deleted the client from Meraki and forced an ipconfig release and renew. This still ended with zero success. My clients are still registering with the weird names.

[Griz]

Just chiming in to say "me too". Something obviously changed in the last few months, and not for the better. Does anybody know of a situation where it is preferable for a cryptic MDNS name to take precedence over NETBIOS name in the dashboard? There has to be a way to identify what has changed and reverse it, right?

[CML_Todd]

Glad to see I'm not the only one having this problem.  Unfortunately, there doesn't seem to be a solution other than manual intervention.  I've tried many of the same steps everyone has described to no avail.  

[Roux]

I'm curious, is anyone using a firmware version before 15.12 having the issue?

[GregCrider]

I'll add a me too.  I opened a ticket in August and got the same response as everyone else. 

I have a network that is running 15.9 and it is reporting the mDNS names the same as my 15.15 networks.  

[CML_Todd]

Yes, I'm running 14.39 on all of my networks.

[Roux]

Thanks. I just wanted to verify the change wasn't in a firmware update. It can't be a Windows update because we are recently seeing it for our Mac OS devices as well. This would seem Meraki pushed out some kind of configuration change. I reopened our ticket with support on early Friday and I am awaiting a response.

Can anybody with Meraki chime in?

[Raj66]

Hello All,

Just wanted to chime in and provide my point of view on this as many people are seeing this behavior in the dashboard.

This is definitely not related any latest firmware update or configuration change from Meraki side. The way the dashboard identifies the hostname hasn't been changed recently. It has always been the same. The preference order is, the name given manually on the dashboard > mDNS > NetBIOS > DHCP. So, if the client is generating an mDNS name for itself, that will be given priority over DHCP hostname.

One way to change this is to rename the client manually on the dashboard. However, if there are a large number of clients whose name needs to be changed, you can leverage this API call to rename the clients

https://dashboard.meraki.com/api_docs#provisions-a-client-with-a-name-and-policy

Cheers!

Raj

[CptnCrnch]

Thanks a lot for the explanation @Raj66!

[EvolutionNoel]

Where do we all chime in for a feature request where we get a dropdown box to choose the mDNS, NetBIOS, DHCP or custom name?

This is a portal. This is an EASY change. Right now you just get an edit button. Can I get a million Kudos on this?

[CML_Todd]

Guess we need to add it to the Make a Wish section of the client view.

[Roux]

I submitted it to the wishlist. We may all need to submitted to get it added.

[CML_Todd]

I will too. That's a good idea.

[Roux]

We should have an option to choose what the mx will use to determine device names.  I have thought that since I found out mDNS has priority. 

@EvolutionNoel  Are you saying this is just a view setting in the portal and not actually a setting on the MX?

[CML_Todd]

That's a good idea.  But that setting should probably be made at the Network level, not device level (MX) because I'm also seeing it on my AP Networks too.  

[Roux]

Agreed, the network is what holds the MX/MR configurations.

[EvolutionNoel]

@Roux No, I am saying it SHOULD be.

[WLF]

We have this issue as well, very annoying. Wish and support request done.

[BaoNinh]

Me too

[Jnewman]

Could ISP DNS such as googles be part of the problem?  Just curious because I did not notice the changes until a month or two after changing my ISP connection DNS to Googles.  previously I had used the ISP given DNS.  If we are looking a common settings... I also deliver DHCP to the clients using the meraki MX... along with AD DNS I allow 8.8.8.8 and of course 8.8.8.8 is also part of my servers set DNS.  Curious to see what kind of feedback I get if people are willing to put for the effort.

[JED2021]

Very good note.

I moved to Google DNS as well.  Since I was using my both ISP DNS servers but SDWAN was trying to send my DNS queries out one ISP and when DNS entered the other it fails so I was getting dns slips.

BUT

works correctly on Lan but not WIFI

[CN]

Is anyone using Chromecast devices in their network? AppleTV? Roku? These devices use MDNS to find which device to cast to. It might be that during the handshake process there's just enough MDNS data to create a new name for the device. 

In my network, the Roku has an MDNS name of 34 characters. Chromecast 36. The macOS and iPhone have 36 character MDNS names. 

One way to find the true name of the devices is to use the API to get the client details. The Meraki Tools for Google Sheets add-on can be run to easily find the name of the device. 

https://community.meraki.com/t5/Developers-APIs/Meraki-Tools-for-Google-Sheets-add-on/m-p/50838

[DaveG]

Here are some questions that I would like Meraki to address:

• For the purpose of displaying clients on the dashboard, why does Meraki place a higher weight on cryptic MDNS names rather than easily identifiable names?
• I’ve been using Meraki for over 6 years now and not until June of 2019 had I ever even seen an MDNS name for a client in the dashboard. If MDNS names have always had the highest priority why are they just now all of a sudden showing up for everybody when they never have before?
• So far it seems like Meraki’s stance on this issue is “Well this is how it’s always been and this is expected behavior.” Does that mean for all these years that the dashboard has been displaying easily identifiable names instead of MDNS names that it was exhibiting unexpected behavior?
• Why is Meraki not looking into why this admittedly widespread problem came about in the first place and help us find a solution to the root cause of this change in behavior on the dashboard? And I don’t mean come up with workarounds. I mean find out what actually broke or changed in the first place and fix it.

[JosephWelchIV]

This has been plaguing a couple of my clients recently. Although it should be a configurable option within the portal (if you are experiencing this issue please request this via the "Make a wish" button), I am leaning towards windows devices displaying MDNS names may be a software related issue. As mentioned by another user this could be a screencasting/sharing application. I picked two of my clients roughly the same size around 300 users per location. One has around 120 windows devices showing MDNS names, the other has 2. 

I will be running a comparison of installed software between these clients but unless the offending application is unneeded I am in the same boat as everyone else, trying to mitigate this egregious configuration on Meraki's behalf. 

[Rudy]

We've been seeing this problem recently too (after never seeing it for years.)  I'm not expert but I'm thinking that since this problem began to affect people without Meraki's firmware changing, I think the common culprit might be something like the Chrome (and/or Safari) browser.

I believe the Chromecast uses mDNS/Bonjour so is it possible that when a user launches Chrome, the browser uses mDNS to search for any available Chromecast devices (to display on the cast tab) and Meraki is picking up the mDNS name linking it to the PC for the dashboard description?  Obviously, if this theory is correct, we all started seeing the problem after Google updated Chrome to some specific version...

Right or wrong, I agree that Meraki should allow us some control over the prioritization of protocols so we can have it ignore the mDNS transmissions and keep our dashboard clean and manageable!

[FSlicer]

On MacOS , I was able to set the "HostName" on the device, as it was unset.   The command to do that is:

sudo scutil --set HostName <devicename> . (This command will set the HostName value.)

scutil --get HostName .   (This will show what HostName is set to.)

where the <devicename> is the name you want.

Other device names can be seen using:

scutil --get HostName

scutil --get ComputerName

scutil --get LocalHostName

[JRLewis]

Add me to the list as well. Submitted a case to Meraki on Jul 2nd about this issue and got the same spiel about it always being the case. It hasn't always been the case. In addition, I was told that if the name had been set in the Dashboard that the set name would take priority, but just today I note that Apple devices on one of my networks are now mDNS strings instead of the hostnames that I myself set previously.

Just one of the latest in a long string of mystery issues we have with the Meraki service that we don't have the power to prevent/correct (except in tedium), and that don't get the attention we deserve from support and 'engineering'.

[CML_Todd]

JRLewis,

Thanks for the input. I haven't had any of my devices with manual descriptions switch to the mDNS strings, that's a new one. Hopefully Meraki support can come up with a fix or gives users the option to select what name should take priority in dashboard.

[TheMCC]

Same issue as everyone else, around the same time. Told the same thing from support, less than helpful.

I've made a wish request before (make the left side menu collapsible) super simple coding asked years ago. Still waiting.

Also found that Meraki MX devices with Meraki Switch reports incorrect usage. Told it's a known issue. Still waiting.

Really disappointed in Meraki right now. Going to dump them and ask for a refund. The only reason I'm with them was for the insights and reporting now I don't trust their devices and reporting. I can't support a security device that doesn't work on the simplest of requests. 

[seroal22]

Hi all!

Is somebody still experiencing this issue and can somebody say, what could be the root cause?

It affects different operating systems: Windows 10, Android, iOS. So if Meraki really didn´t really change anything, what change could be a root cause affecting all different systems? 

@PhilipDAth 

 You are describing a "privacy" names feature. Do you have a source of information to this new feature? 

Appreciate your feedback.

[ITPointeMan]

I second this - I am STILL experiencing this issue and have not found a fix for it.

[Roux]

Same here. We are still experiencing the issue as well. We submitted a suggestion to allow admins to select which will take priority, since this may differ for each business and/or environment.

[ITPointeMan]

Worth a shot I suppose, I added that also under the "Make a Wish" section. Thank you!

[Happiman]

"make a wish" is broken. They don't care anymore since they realized that  the market share is growing.

[seroal22]

@ITPointeMan

@Roux 

Hey guys,

Meraki claims, that something on the client side supposedly changed. This could technically be, but I think it is very unlikely.

What for operating systems are affected in your network? Others than Windows10, iOS, Android? 

Did you make packetcaptures to verify the claim, that MDNS is the root cause and the devices actually broadcast these strange names? I also do not believe, that clients do not have an uniqe identifier in the Meraki world.

I checked it and I could not see any packets containing these strange hostnames, I only found the correct ones. So up to know, there is no proof that could back up Meraki´s claims.

I´m still waiting for a logical explanation...

[ITPointeMan]

Greetings!

I've not done packet captures but I did do a test with a Win7 host using registry entries to disable mdns (https://www.blackhillsinfosec.com/how-to-disable-llmnr-why-you-want-to/). 24 hours later and the host is now displaying the computer name rather than the random string of characters.

I second the solution allowing admins to prioritize how PCs get their name but doubt that will ever happen.

[BaoNinh]

Me too ! It needs support and it is too inconvenient and difficult to manage users

[seroal22]

Probably you can forget it, I´ve come to a point to say, I do not care any more, because they want you to proof, that they are doing something wrong, you should show packetcaptures where this can be clearly seen. But that´s not to easy, because you cannot forget a client completely in the dashboard, the hostnames are kept in there, even if you use the "forget client" feature. So you cannot use one client to perform different tests. mDNS Hostnames can only be overwritten by new mDNS information. This makes testing very difficult, as you always need new clients.

My assumption:

I think that code in software beeing used on the devices, is generating mDNS packets with hostnames in it. In this case, if you see this UUID like information in the dashboard as a hostname, it is not the operating system itself, but an application generating it. The problem here is: Meraki does not differentiate between "only" applications sending out some packets, that should not be analysed for the hostname to be displayed in the dashboard.

In general Meraki says, it is not an issue, its an isolated case:

Message from 11.09.2020:

"Greetings,

Thanks for your reply,

I've investigated this further with our internal product specialist teams and confirmed there are no reports of this issue currently and more so we would need to acquire further data from the case to troubleshoot this further."

---

So all of you, having problems, in real you don´t have no problems! Since a few month since creating this ticket and reading all the posts from users with the same issue, I can say, that they don´t really care.

[Rudy]

I find it hard to believe that only a "handful" of users are experiencing this problem when there doesn't seem to be anything specific on our end that is causing it.  Why isn't everyone seeing this behavior?  Does everyone override the client name by manually entering one?  I doubt it...

It is quite frustrating that this problem hasn't been fixed by now and that Meraki doesn't seem to really care about things that negatively affect their customers and/or the functionality of their products!

Come on Meraki, please focus some resources on this issue and address it beyond just claiming that there's nothing to see here!!

[Roux]

Manually changing them isn't the answer when you have thousands of clients and hundreds added every year. You can change the client names by leveraging the API calls. I still see this as a work around and not a fix. Since my clients are running dhcp, I wouldn't pull a list of clients from DNS and just run with it. I would interrogate the client to verify there identity, then make the API call. This is a complicated way of completing this task across multiple subnets compared to checking a radio button to change the priority on the admin page. It would be easier to manage if the admins could change the priority of how the DNS names were chosen vs. making an API call.

Meraki support, I request someone put in this request so admins as myself and others here can reclaim our time for other tasks assigned to us.

[Rudy]

Agreed!  Telling us that the solution is to "simply" disable mDNS on each and every client is not a solution, it's just a way for them to avoid dealing with this.

At this point, I'm not asking for much.  To resolve this issue, all I'm hoping for is for Meraki to give us the ability to prioritize what is populated in the client name field.  This way, we can bump the mDNS name down the list and allow one of the other methods to appear.  

In other words, I'm not expecting Meraki to re-engineer everything so that the mDNS name is ignored, just let us choose which name we would like to utilize!  That can't be too difficult to implement, can it?

[seroal22]

@Rudy wrote:

Why isn't everyone seeing this behavior?  Does everyone override the client name by manually entering one?  I doubt it...

---

I agree, maybe, there is an explanation for it... I can only imagine, that other customers don´t really use this part of the dashboard to view information about the connected clients. Maybe, they are also only looking at IP or Mac address...?! Maybe it is also depending of how your device landscape looks like, what software and software firewallsettings are there?!

What I can say is, that I´m responsible for different meraki customers, with thousands of clients. And I see this in many networks.... 

[Roux]

Isolated? Sarcastically speaking, does this mean it's a wide spread isolated issue?

[LB1]

Meraki support told me I needed to buy another Cisco product to manage our devices.

[Roux]

Out of curiosity, what product is that?

[EvolutionNoel]

Do tell....I already have a product...which is the whole cause of this debacle

[Roux]

Exactly, this issue only exists from a Cisco product I have now. So, we need another Cisco product to fix an issue the original Cisco product created.

[JED2021]

My MACOS devices appear correctly if on an MS ethernet port. but not on an SSID.

Has anyone else seen this?

[MerakiAboveAll]

I'm having the same issue.  Has there been any updates to this?  Does anyone have a workaround besides disabling MDNS?  Are there issues with disabling MDNS and can this be done via group policy?  

[Jhunax]

Anyone had a concrete answer to this and how to fix it?

[JGill]

I know this is an old thread, but did anyone ever figure out an easy way to resolve this issue?   Tried a few of the hacks to disable MDNS but doesn't seem to work, unless I'm missing something.   Have a new requirement for tracking which would be super easy with the Wi-Fi API and or Splunk data if the machine names were correct.  Manually updating 7,000+ clients even by API doesn't float to the top of my solutions list.  

[EvolutionNoel]

This was listed above:

https://developer.cisco.com/meraki/api-v1/introduction/#meraki-dashboard-api

[JGill]

Hoping not to do this via API.  Just trying to figure out exactly what Meraki is using so we can tweak the Domain / Network setup.  I have one workstation working now, so trying to back into exactly "why" its working with the handful of changes / commands ran. 

[JGill]

On a personal mission to figure this out.   It's not the Active Directory Device GUID, but its something like that.  The MDNS advertised GUID is not what shows up in the console.  Not sure if its encoded, encrypted, or just random.

What I do know is if you resolve the computer name with .local   the name magically updates in the Meraki Console, and they seem to stay that way so far.   If the names stick I'll look a scripting it up as a one off update.   

I'm sure this is a local subnet fix only, but using it to narrow down how Meraki is updating the names. 

Sharing in case it jogs ideas from the group or you see something in the traces I'm missing. 

Steps to get names to update on console for testing:

1). From the clients page of your local network, get the IP address of a client with a gobbledygookname.

2). NSLOOKUP the IP to get the AD Computer name

        nslookup 172.22.22.132 

          Name: Computer1.yourdomain.com

          Address: 172.22.22.132 

3) Use the powershell command resolve-dnsname to lookup name with .local appended (without your domain).

        resolve-dnsname Computer1.local

    Name Type TTL Section IPAddress
    ---- ---- --- ------- ---------
    Computer1.local AAAA 60 Answer fe80:8EC1f5:351D:ABF3
    Computer1.local A 60 Answer 172.22.22.132

Check your console in about 2 minutes name will be updated. 

You will see in a packet trace that when you query the device with .local, the host replies to the multicast  query.  Meraki must be picking that up with a DNS Snooping type process to grab the name and update the console.  Not as simple as a lookup with ipaddress.local, must be hostname.local.  And since its multicase this will only work on your local subnet, so not an enterprise answer, but a start....