Re: Windows 10 Iot Devices
Niki Wienberg
The Windows.Devices.Bluetooth namespace defines a set of Windows Runtime API that allows UWP app and desktop apps to interact with Bluetooth devices. For more information, see Bluetooth.
Provides functionality to determine the Bluetooth Low Energy (LE) Appearance information for a device. To get an instance of this class, call the BluetoothLEAppearance.FromRawValue method or the BluetoothLEAppearance.FromParts method.
Indicates whether applicable Bluetooth API methods should operate on values cached in the system, or whether they should retrieve those values from the Bluetooth device. See Remarks in the member topic.
I've been having some issues lately with Discovery not identifying Windows devices that it used to find, classify, identify and scan with no problems. Now when scanning a subnet of Windows servers, with known good credentials (I've tested by logging into the servers with the same account running the MID Server service) it will stop in the Identifying stage with a scan status of "Completed 2" and won't identify the CI.
When I check the logs, I get a lot of "Failed Exploring CI Pattern, Pattern name: Windows OS - Servers, To Check Pattern Log Press Here" errors. When checking the pattern log there really isn't anything useful in it:
Thanks for the reply, I did uncover some duplicate relationships, and some that were missing altogether. Once I corrected those it's at least discovering the devices again, though I still get some credential errors (which I just need to find the group responsible for the server and get credentials).
I've checked the probe "Windows - Storage 2008" which includes the PS and WMI probes, and has the "Windows - Storage 2008" sensor defined, so not sure why it's failing on some scans but not all scans.
I figured it out. The time setting for North America/Los Angeles is completely incorrect on tplink side, so it was shutting my internet down (which I have a bedtime setup for). I changed to North America/Phoenix since it's currently same time as Los Angeles. I think tplink needs to fix the time server setting.
I have the same problem of my windows 10 laptop not being able to connect to Internet, while it connects to the deco m9 plus WiFi network. Can you please tell me what time setting you updated ? The windows date and time region ? (I'm in Eastern standard time zone) or is there some time setting on the deco ?
Im also experiencing the same thing only with Windows. My macbook connects fine, also android, android tablet, tv, ps4 etc. Its the freaking windows and Decos. I tried with a neighbors network and my computer is fine. At my office I connect perfectly. I read somewhere to create the Decos Guest network and it is stable. I have internet but at low speed. How can I fix this with my Decos network? Should I reset my 6 devices? That would be a pain in the ass because I have like 40 smart devices configured but if that fixes it, ill do it . In conclusion my decos main network are in conflict with windows. The guest network works fine.
I am having same issue here. Deco m9plus is on latest firmware 1.5.1 and was working fine for couple of weeks now and now all of a sudden all windows laptops are not connected to internet although connected to wifi. Able to get internet on other Android and iOS devices without issues. Please help as this is a major issue for me. I
We recently deployed Teams Rooms devices across our org. We have about 60 devices currently, all Rallybar w/ Tap and Intel Nuc. I've notice that randomly some devices will get stuck at a blank black screen after nightly reboot. I initially thought this was an issue updating from Teams Rooms v. 4.10.10.0 to 4.11.12.0, however today we had 3 devices get stuck that had already updated to the latest version.
We are having the same issue on our end, too. 20 out of our 50 Rallybars with Taps/Intel Nuc's seem to have this issue every single day so far this week. It's become very frustrating and word is starting to get around that our Teams meeting rooms are starting become....unreliable.
The recommendation from @CheetoChester has worked great on a few Logitech Taps that were already on Windows 10, version 20H2 and only installed the Intel Iris Xe Graphics driver version 30.0.101.1191 after the Windows 10 Feature Update. We can just roll back the drivers as recommended.
However, if the drivers were installed before the Feature Update to 20H2, with the Feature Update installed after the drivers, then the button to "Roll Back Driver" is simply greyed out. We have almost 20 endpoints which fall into this category, as they were all deployed in the past 2 weeks.
Something tells me this will require Intel to publish a newer driver version before we see any real relief. They did release 4 newer sets of drivers since version 30.0.101.1191, which can be found on their support website, though this version is still the latest showing for the Intel NUC that was bundled with the Logitech Tap.
We also introduced another problem (static coming through the rally speaker) during our troubleshooting which according to logitech is caused by latest bios on the NUC. Suggested workaround is to disable Intel Platform Trusted Technology setting in the BIOS, which will kill bitlocker in the process.
@hrcc-cg This is so frustrating, we have only two systems but have the same issue on both with a frozen display every morning. I too got the information from Logitech support to upgrade all drivers (through Windows Update) and we have a "crackling" sound in the MIC now and really low volume on the speakers (We have Rally Medium).
We come across a few users reporting that the NUC MTR systems appear to be frozen or unresponsive after the nightly reboot or after displays go into sleep mode. Tap appears dark and unresponsive. The only recovery is to press and hold the NUC power button until the system shuts down and then power it back on. The root cause is an Intel Iris graphics driver update that was pushed via a Microsoft update.
In light of the latest version(30.0.101.1960) of the Graphics driver released by Microsoft on 10/05/2022 and the fact that you already rolled back to 27.20.100.8935 with no improvement, I would suggest updating the Graphics driver to see if that helps. -graphics-windows-dch-drivers.html
It was also reported that Static noise is heard on Rally Bar, Rally Bar Mini or Rally system connected to the MTR NUC when the system is idle and not on a call.
These issues started after the customer recently updated the NUC BIOS to version 0064. Intel is investigating the issue and has paused the BIOS firmware update version 0064. Microsoft MTR Premium has also stopped pushing this BIOS update via their service. The below workaround worked for most of the users.
We did that Firmware update tool awhile ago too and it helped. We haven't had any issues with our HD projectors and displays after running it. Most of our rooms are HD... with one 4K projector. The 4K was giving us issues is my last post. So far, no issues with our 4k projector and the NUC post upgrading the driver to 30.0.101.1960. This driver update seems to be the fix. If I have issues again, I'll be sure to come back and let you all know.
Hi Johan yeah I ended up having an issue a week later after my post. Tried everything that was recommended by Logitech and Microsoft. In the end I had to reset the unit. So to cut a long story short. I gave up with both Logitech and Microsoft, installed a 3rd party software called Deep freeze, that prevents any changes being made to the os, and on restart the system returns to the exact state it was in when the hard drive was "frozen". Been 3 weeks and I haven't had any issue with the system since. I will schedule to push updates this week coming to keep the system complaint.
However, after a period of time, they come back onto SM. I thought maybe a Domain Group Policy was re-pushing the agent out, but when i check it wasn't. So i'm confused. How can it be re-adding devices that for all intents and purposes are no longer part of our Meraki SM.
My workaround is to create a new SM network in the dashboard called decommissioned, then move all decommissioned clients from the production SM network into the decommissioned SM network. Then you can delete the decommissioned SM network from the dashboard and the devices won't have a valid network to connect to anymore. Again not the best option, but seems to work for me.
d3342ee215