I just happened to notice that most of the workstations here all show Not Scanned In 30 Days and the “fix” URL doesn’t fix it. I am thinking it could be our upgrade to the Symantec Cloud based antivirus.

What should I open or exclude in the Symantec Cloud settings? Or could this be something else?

Thanks…

2 Spice ups

file and printer sharing (ports 135, 137/139 perhaps).

Giving that a shot.

if from the SW server you can connect to \machinename\admin$ then you should be ok.

Be sure pings are enabled too

Just as a test manually force a scan of a device that hasn’t scanned in over 30 days. Make sure it is online with a ping and make sure that what DNS says the IP address of the device is matches what you confirmed on the device.

I’m having the same exact issue in a customer’s environment. I see waves of systems that haven’t scanned in 30 days. Groups will seem to stop scanning on specific dates. If I force the system to scan (from the device details toosl->scan now) it will scan the device and pull in the current inventory, but the device will not scan during the normal daily scans. For full disclosure they did move from another vendor to Symantec SEP 12 earlier in the year. But because the device does scan we ruled out SEP. I do have a ticket open with Spiceworks support but right now we don’t have an answer or a solution. I’m now interested in seeing if you are having a similar set of conditions.

George, I’d be interested to know something if you find out from SW.

I would believe forcing a scan tries to connect to said device and scan, directly, however running a scan from the main menu, I am going to guess does a ping sweep, finds nothing and moves on - the forced scan if I am right would just try to scan the device by name, moving past the ping sweep detection.

Let me know if you get confirmation.

1 Spice up

I think this did it…the number of not scanned in 30 days is going down… will report back final result.

Good to hear

Just for clarity, here are the spiceworks firewall recommendations.

http://community.spiceworks.com/education/projects/Windows_Firewall

For those systems we’ll generally create a PDQ deployment package and push out the firewall settings to all computers prior to a first scan, just to get that issue out of the picture. Ideally, we would create a GPO firewall policy to ensure these ports remain open.

Right now we are trying to chase down a possible wbem repository corruption on the target computer, but I don’t think that is the root of the issue.