Frequently Asked Questions
Part 1: Running the applications
Q: I get a message that says that I should install something
A: 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 .Net Framework 2.0 from: http://www.microsoft.com/downloads/details.aspx?familyid=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=en
Q: I get some message about permissions…
A: One of the features of the .Net Framework allows users to set “code access permission” 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.
Q: I adjusted the permissions, but it still doesn’t work
A: 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.
Q: I can’t run SOSOS against a remote computer running WinXP SP2; the connection fails.
A: 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/library/default.asp?url=/library/en-us/wmisdk/wmi/connecting_through_windows_firewall.asp
Q: I can’t run SOSOS against a remote computer running Windows Vista; the connection fails.
A: 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://msdn2.microsoft.com/en-us/library/aa822854.aspx
Q: I still can’t get SOSOS to run against a remote Vista PC; I get Permission Denied
A: 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).
Q: I can’t run SOSOS against on a remote computer running WinXP Home
A: 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.
Q: Why does it take so long to gather data on some PCs?
A: 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.
Q: The help file comes up but just contains an error message
A: 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/
Part 2: Compiling the source code
Q: When compiling I get a lot of errors about ADOX.
A: You’ve probably got the wrong set of Visual Basic Project files (*.vbproj). When compiling on Windows XP (or Windows 2000 or Windows Server 2003), you should use the project files that are in the WinXP_vbproj.zip file
Q: When compiling, I get a lot of errors about ADODB, ADOX, and TaskScheduler.
A: You’ve probably got the wrong set of Visual Basic Project files (*.vbproj). When compiling on Windows Vista, you should use the project files that are in the WinVista_vbproj.zip file.
Q: When compiling the program, I get a message about something is missing
A: Visual Basic 2005 Express Edition does not support the “Setup” project type, so it will fail to load this part of the solution. You can safely ignore this error.
Q: SOSOS compiles fine, but some of the other programs are missing files
A: Almost all of the SOSOS-related programs share parts of the source code with the main SOSOS program and use “links” to find the files. Therefore you should not change the folder structure of the source code in the zip file. All of the applications should share a common “root” directory (just like in the zip file).
SOSOS Suite (root directory)
|
-----------------------------------------------------------------------------
| | | |
SOSOS RunSOSOS ConfigureSOSOS other SOSOS-related
software goes here
Part 3: The data that’s collected
Q: I didn’t get the contents of the Security logs in the EventLogs table
A: 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.
Q: Some of the records in the database have an error message
A: 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.
Q: My database is huge! What can I do?
A: 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 using the provided ConfigureSOSOS utility. The “Feature Setting” tab as 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
There are also some compile-time variables at the top of the snoop.vb file that will reduce the amount of data that is collected.
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 Feature Selection tab of the Configuration Utility allows you to select which tables you wish to enable or disable.