What a silly name, what's the story?
Well, it all began with a small batch file called "Snoop"... it collected a few items of interest and populated a text file. Later (in the VB6 days), we created a 2nd major version called "Son of Snoop" that collected about 30 items and populated a Microsoft Access database. When this 3rd major revision was created, we comically called it "Son of Snoop on Steroids". The name stuck, so that's the name we ended up releasing it as.
Are you sure it's free?
Yep, it's completely free... to include making the source code available as "public domain". There is no licensing of any kind, and no restrictions on its use (to include making money from it!)
I get a message that says that I should install something
All of the SOSOS programs require the ".Net Framework" to be installed on the client PC. When using SOSOS to remotely gather information from PCs in a LAN, it is not a requirement that the remote PCs have the .Net Framework installed.
Download and install the latest .Net Framework from: http://www.microsoft.com/net/
I get some message about permissions…
One of the features of the .Net Framework allows users to set Code Access Security (CAS) for the PC (or individual programs). By default, the Framework's own security settings will not allow any program to run from a network share that requires "significant" permissions. Since SOSOS requires a lot of permissions to work properly, the default settings will not allow it run from a network share. Note: The default settings are sufficient when SOSOS is run from a local drive.
To solve the problem, you can either copy the program files to a local drive, or adjust the .Net Framework assembly permissions.
Warning: If you have multiple versions of the Framework installed, make sure you’re adjusting the setting for correct version. Settings for one version have no affect on other versions.
To adjust permissions, you use the .Net Framework 2.0 Configuration control panel applet (on a development PC). Navigate to "Configure Code Access Security Policy", "Adjust Zone Security", "Make changes to this computer". Click on the Local Intranet icon and move the slider up to "Full Trust".
You can also use the .Net Framework 2.0 Configuration control panel applet to create an MSI file that you can use to deploy these changes via a GPO or login batch to the other PCs in your LAN. Click on the "Configure Code Access Security Policy", "Create Deployment Package". When the Wizard opens, click on the "Machine" security policy, and select a folder/name of the MSI file that will be created.
Take a look at the following article to learn more about CAS: http://www.emmet-gray.com/Articles/CodeAccessSecurity.html
I adjusted the permissions, but it still doesn’t work
Make absolutely sure that you have adjusted the settings for the correct version of the Framework.
For version v1.0 and v1.1, Microsoft included the control panel applet with the Framework. But for reasons that only they know, the control panel applet is not installed with version 2.0. Only the development PCs get the control panel applet for v2.0.
That means to adjust the settings on an ordinary PC without the applet, you must use the technique described above to create and deploy an MSI file.
I can’t run SOSOS against a remote computer running WinXP SP2; the connection fails.
Most likely the problem is with the firewall settings. The default setting for the built-in firewall for XP Service Pack 2 (and beyond) excludes remote administration. Run the following on the remote PC to configure the firewall:
netsh firewall set service RemoteAdmin enable
For additional information see:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa389286(v=vs.85).aspx
I can’t run SOSOS against a remote computer running Windows Vista; the connection fails.
By default, Windows Vista blocks WMI traffic, so you should adjust the Windows Firewall settings to allow for WMI traffic to pass. Run the following on the remote PC to configure the firewall:
netsh advfirewall firewall set rule group="windows management instrumentation
(wmi)" new enable=yes
For additional information, see: http://msdn.microsoft.com/en-us/library/aa822854.aspx
I still can’t get SOSOS to run against a remote Vista PC; I get Permission Denied
If you are in a Workgroup environment (not a domain), you will have to disable the User Account Control (UAC) feature on the remote Windows Vista PC.
From the Control Panel, click on User Accounts, and click on "Turn User Account Control on or off". Clear the checkbox and press the OK button. (This change will require a reboot).
I can’t run SOSOS against on a remote computer running WinXP Home
Microsoft has deliberately removed the ability to remotely administer computers running WinXP Home Edition (and Windows Me). Note: SOSOS runs locally on WinXP Home without any problems. Sorry, there is no known work around.
Why does it take so long to gather data on some PCs?
The most likely cause is the collection of the event logs. There are several settings that can be used to reduce the amount of data collected from event logs. See Section 2.5 of the Setup and Configuration Guide for information about changing the Filter by number of lines and Filter by number of days settings.
Alternately you can change the audit policy for the PC to reduce the amount of data being recorded to the event log. For details on the audit policy settings, see http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/516.mspx?mfr=true.
The help file comes up but just contains an error message
Microsoft recently changed the security settings for compiled HTML help files (*.chm). These new restrictions apply when the help file is being open from a network share. See the following for a fix: http://support.microsoft.com/kb/892675
I get a message about the 'Microsoft.Jet.OLEDB.4.0' provider is not registered.
There is no 64-bit Oledb provider for Microsoft Access. You most likely recompiled the application in the 64-bit mode (by selecting the x64 or AnyCPU target). Recompile the application using the x86 target. http://msdn.microsoft.com/en-us/library/5b4eyb0k.aspx
I didn’t get the contents of the Security logs in the Event Logs table
Windows typically has higher security settings on the Security log and therefore only administrators can read from that log. If the user who runs SOSOS is not an administrator on that PC, then you should consider using another deployment scenario. See the Setup and Configuration Guide for details.
I don't get any Virus-related information
SOSOS currently only supports Symantec (Norton) "corporate" anti-virus products.
Some of the records in the database have an error message
SOSOS often records error messages in the database. This is normal. A detailed account of what went wrong may also be recorded in the Error Log file. Some minor errors that are anticipated are not recorded in the log file.
My database is huge! What can I do?
The size of the database is probably due to the collection of Event Logs. There are two ways to "filter" the collection of Event Log data. The Setup/Configure SOSOS/Feature Setting tab has a place to adjust the "Filter by number of lines" and/or "Filter by number of days".
Alternately, you can adjust the security policy on each PC to not collect as much detail in the event log. For additional information on each of the Audit Policy settings, see http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/aptopnode.mspx?mfr=true
In addition to the methods described here to reduce the quantity of data in the database, you can also selectively "turn off" and "turn on" entire sections of the database. The Setup/Configure SOSOS/Feature Selection tab allows you to select which tables you wish to enable or disable.