I have several devices appearing as "unknown" in the Print dashboard that are actively reporting in Fleet. It seems to be devices that were added after the Uniprint connector was activated. All devices were added manually with the Device Scout Discovery tool. Will these devices/data sync eventually?

Looks like the Uniprint scout is having trouble determining what a device is that people are printing to. Can you send me the Diagnostics logs from the Uniprint scout? They should be out in C:\ProgramData\PharosSystems\PrintScout\Logs.

Clayton, I believe you've been working with Jesse directly to resolve this issue. If there are any further issues, please let us know.

For others with a similar inquiry, currently Beacon does not support community strings for Uniprint Scouts other than "public". If Uniprint customers want other strings configured they should contact Pharos. These conversations may begin in the community, but we advise against posting community strings publicly.We do anticipate adding this functionality in a future version of Beacon.

Seeing as it is that Carrie's account is deactivated, she must have moved to another company. Rich, Rachel, another moment an active, accurate org chart would be helpful.

However, after a discussion with Cal, I just discovered something within Beacon that I wasn't aware of, in part reflected in this message thread. If you set your SNMP "public" community name to anything other than "public", the default Beacon device scout discovery advanced setting of "public" in "SNMP Communities" means Beacon will NOT discover those devices whose IP addresses are valid (etc.), but that have something other than "public" as their community name.

Our IT group is asking us to make sure we don't leave "public" as a default community name, given the attacks they fear can come through that channel (I don't know for that kind of security, so I have no clue what kinds of attacks they may be). So I've changed about half our devices away from "public" to something else (common between all the devices, and not disclosed). Once I added the new community name to the "SNMP communities" box, I was able to push scan the data, upload it to the server, and all of my devices were reported as having been collected in the last 30 days at the same, correct time. Those that read false about the last 30 days are no longer in my system, and their last collect date/time I assume will stay the same way forever. Their replacement devices were correctly scanned and reported.

All you have to do is put your cursor into the "SNMP Communities" box after the "public" entry, press return, and enter your other SNMP community name. So I guess Carrie's answer of 12/3/15 should now read "currently Beacon does support community strings for [Device] Scouts other than 'public'." Whether this is the case for Uniprint scouts, I can't say.

Glad you were able to get this working! You're correct that you can add strings other than 'public' to the device scout discovery settings. Note for this to be permanent, you'll want to do it via the web configuration (Discover --> Device Scout --> Configure --> Advanced tab):

If this is done in the Device Scout Discovery utility, it will only persist while the discovery utility is running (which may be all you need if you're just looking to scan and upload a couple non-standard devices).

Also, you're correct that you'll want to leave 'public' in the list of strings if you still have devices using that string, it will NOT be used if you take it out. (As an aside I'm interested to hear from anyone else who has the requirement of removing 'public' from their devices and the security rationale behind it... )

Currently neither the print scout nor Uniprint scout can be configured with SNMP strings other than 'public', although this is a capability we hope to add in the future. As Carrie mentioned, we can work around this limitation by adding them behind the scenes in a pinch, simply open a support ticket and we can do this.

I think Aaron Johnson may have been experiencing a similar issue based on conversations at the User's Conference. I know Bill Sullivan was going to be working with him on some issues and thought I would point out this conversation in case it is helpful.

Yeah, we had all kinds of issues with Beacon. It wasn't 100% clear to me what was causing the problem. But we do have a different community name and added that into the SNMP settings. I left public there in case someone resets a printer and doesn't update it properly.

Jesse, thanks for that. I went in and set it there, and will check to make sure it's available to me come next month (if not before).

As to the change from "public" on SNMP's community name it's something that has come down from our use of Nexpose as a campuswide security tool. I have a call out to the security team to find out specifically why it's listing as something to change. However, and for example, outside sources show there seems to be an actual reason, as opposed to blanket changing. One from SANS, though it's already 16 years old: SANS: Intrusion Detection FAQ: Using SNMP for Reconnaissance and another from 2014: Vulnerability Management: Just Turn It Off! Part III | The State of Security. While I can't vouch for just how severe a problem it is were this to happen on our campus, our security folk do want us to change from "public" to a more complex key. same for "admin", which is also default (for the read-write access; "public" is read-only).