Son of Snoop on Steroids (SOSOS)
Setup and Configuration Guide
SOSOS is a computer hardware and software inventory program. It gathers over 220 pieces of information about computers and optionally stores this information in a database. It can be run locally or can be used by an administrator to scan a network.
It gathers hardware information such as CPU, memory, hard drives, and serial numbers; software information such as operating system, installed software, and software components; configuration information such as IP address, running processes, desktop settings, and services; and security-related information such as shared resources, modems, account policies, security patches, and virus activity.
Note: SOSOS does not gather any personal information, look at emails, user documents, or track Internet activity.
SOSOS is actually a suite of programs consisting of the following:
SOSOS is completely free of charge. The SOSOS source code is considered in the “public domain”. That means you can do anything you want with it, to include making money from it. There is no licensing requirement.
The "official" home of SOSOS is at http://www.sosos.emmet-gray.com.
Section 1 – Compiling the Source Code
SOSOS is available as Visual Basic “source code”. That means that you’ll have to use Microsoft Visual Studio 2005/2008 to compile the source code into a usable program that will run on your computer.
Microsoft provides the Visual Basic Express Edition as a free download at http://msdn.microsoft.com/vstudio/express/vb. However, the Express Edition cannot build Setup projects (for deployment as an MSI file).
Important: If you intend to use SOSOS to gather information from PCs running Windows Vista, then you should also compile the SOSOS suite on a development PC that’s running Windows Vista.
Note: Compiling the SOSOS suite under Windows XP/2000/2003 requires that you use correct Visual Basic project files (*.vbproj) from the WinXP_vbproj.zip file
See Appendix E for a complete “walk through” on how to compile the SOSOS source code.
The SOSOS Distribution Kit consists of a zip file that contains the Visual Basic source code, documentation, and a starter “prototype” database.
The files in the Distribution Kit have the following structure:
Root
Changes.txt – A text-based change log
DatabaseChanges.txt – Change log for the database
Empty.mdb – Microsoft Access starter database
Empty.sql – SQL script for a SQL Server starter database
FAQ.doc – Frequently Asked Questions (Microsoft Word)
LocalIntranet.msi – Install file to configure .Net Code Access Security
Read Me.doc – Introduction (Microsoft Word)
Setup and Configuration Guide.doc (this document)
User’s Guide.doc – SOSOS User’s guide (Microsoft Word)
ConfigureSOSOS – source code directory
ConfigureSOSOS.sln – Visual Basic solution file
PollSOSOS - source code directory
PollSOSOS.sln – Visual Basic solution file
RunSOSOS - source code directory
RunSOSOS.sln – Visual Basic solution file
SOSOS - source code directory
SOSOS.sln – Visual Basic solution file
ViewSOSOS - source code directory
ViewSOSOS.sln – Visual Basic solution file
WinXP_vbproj.zip – Project files for compiling under Windows XP
WinVista_vbproj.zip – Project files for compiling under Windows Vista
There are several other optional applications that are available from the SOSOS web site that are not included in the Distribution Kit.
1.3 Compiling
The SOSOS source code is configured for compiling under Windows Vista. However, the distribution kit includes the Visual Basic Project Files (*.vbproj) configured for Windows XP in a zip file called WinXP_vbproj.zip. When compiling under Windows XP/2000/2003, you should extract these project files (replacing the existing versions). There is also a WinVista_vbproj.zip file that allows you to switch back to the Windows Vista versions of the project files.
It is always a good idea to compile any .Net applications from a development PC that has the latest operating system, .Net Framework version, and all up-to-date patches. This will ensure that the application is using the latest versions of the required DLLs. After the application is compiled, it will run on all platforms/operating systems that support the .Net framework.
The SOSOS suite automatically runs as a 32-bit application on 32-bit operating systems and runs as a 64-bit application on 64-bit operating systems. There is no additional configuration required to support this feature.
The typical way to compile the application is to double click on each application’s solution file. This will launch Visual Studio and load the program’s source code.
Important: You should change the encryption keys in the SOSOS\crypt.vb file from their default settings. Pick any 8 bytes for the variables TheKey() and Vector(). You must recompile all members of the SOSOS suite when you change the encryption keys.
To compile, right click on the project in the Solution Explorer (typically in the upper right hand corner) and select the Build option. Alternately, you can use the Build menu and select Build Solution.
After compiling, the contents of the bin\Release directory will contain all of the files required to run the application.
See Section5.4 for information about deploying the applications.
1.4 Compiling the Setup Projects
Each application has a separate “Setup” project to create an MSI file for deploying the application to other PCs.
To compile the Setup Project, right click the Setup project in the Solution Explorer and select the Build option. You should build the Setup project only after you have tested the applications and performed all of the configuration tasks.
The application’s source code should be configured using the ConfigureSOSOS utility prior to creating the Setup projects. It is recommended that you use the ConfigureSOSOS utility on the “app.config” file inside the source code directory. This will allow the Setup project to perform a clean build of the application using the settings you configure.
See Section 2 on how to use the ConfigureSOSOS utility.
Important: Failure to perform this step on the source code will mean that you will have to configure each application on the target PC after deployment.
Note: Visual Basic Express Edition does not support the Setup project type. Sorry…
Section 2 – Configuring SOSOS
The run-time settings for each member of the SOSOS suite are contained in XML-based configuration files with a file extension of “.config”. For example, the settings for the SOSOS.exe application are contained in a file called SOSOS.exe.config.
The SOSOS application has its own built-in configuration utility. All of the other members of the SOSOS suite require the use of the stand-alone ConfigureSOSOS utility.
To launch the configuration utility inside the SOSOS application, you use the main menu to select Setup and then click on Configure SOSOS. Changes made are not effective until the program is restarted.
Alternately, you can use the stand-alone ConfigureSOSOS application.
Note: You must use this utility to configure the other members of the SOSOS suite.
The ConfigureSOSOS utility will prompt you for the path to the “target” application’s .config file. These files can be either the prototype app.config file found in each source code directory or the application-specific configuration file (i.e. RunSOSOS.exe.config) found in the same directory as the target application.
The first configuration “tab” contains settings that must be configured prior to running many of the SOSOS applications.
The Database Provider and Connect String information is required for database functionality. The Error Log File and Error Logging Level are required for the central error log functions described in Section 6. The Use Ping Validation setting determines if an ICMP “ping” will be used to verify that a remote PC is online prior to attempting a connection.
Database Settings:
Note: Use the button to the right of the pull-down to launch a utility that will help you choose a database provider and build the connection string.
Error logging Settings:
See Section 6 for additional information about the Error Logging Level setting.
Ping Remote PCs before connecting:
· Use Ping Validation – Use “ping” to verify that a remote PC is online
The Feature Selection “tab” allows an administrator to select which features should be used when collecting data. This can be useful in speeding up the collection of data by disabling features that are not required.
Note: The “feature” name corresponds to the database table name as shown in Appendix B.
Note: The feature selection settings are useful for performing a “one-off” scan of the network, where you are only concerned about a few features. This technique works best when you collect the data into a separate database (otherwise existing entries in the database will be deleted and replaced with just the few features selected).
2.4 Polling Defaults
The Polling Defaults “tab” will set the defaults used by SOSOS and PollSOSOS to control polling options, set the location and detail level of the log file, and set the default settings to be used to generate the list of PCs to be polled.
Note: Not all settings are applicable to every polling method.
Set the default values used during polling:
· Poll Timeout – Number of minutes to wait before SOSOS will “abandon” the polling of a “stuck” PC and move on to the next PC on the list.
· Concurrent PCs – Number of PCs to concurrently scan. Increasing this setting will make the polling of PCs run faster, but will put additional strain on the one PC performing the polling.
· Poll Log Directory – Path to a directory where that poll log file will be generated. The file name portion of the poll log file is generated automatically and contains the current date (i.e., PollSOSOS_yyyyMMdd)
· Poll Logging Level – The level of details that will appear in the log file (choices are Full, Errors and Summary, Summary Only, or None)
· Domain – Name of the domain/workgroup to be used to generate the list of PCs
· OU Filter – The “distinguished name” of an Organizational Unit used to generate the list of PCs, i.e., OU=Sales,OU=NorthAmerica,DC=SomeDomain,DC=com (used in Poll By AD Domain only)
· PC Name Filter – The name of a single PC or wildcards used to “filter” the list of PCs, (i.e., SALES*)
· Age of the Record – the age of the database records used to generate the list of PCs (used in Poll By Age only)
· Path to PC List File – The full path to a text file that contains a list of PCs (one per line) that will be polled (used by Poll By File only).
Note: These settings are just the defaults… they can be changed during run time.
The SOSOS application provides an opportunity to change these setting via a form prior to polling. See the User’s Guide for additional details.
The PollSOSOS application uses command line arguments to override the default settings. See Section 3 for the supported command-line arguments.
Note: You may need to experiment with the value for the Concurrent PCs to file the optimum setting for your environment.
2.5 Feature Settings
The Feature Settings tab is used to change the way certain features work. The settings for the Events control how much event log data is collected. The File/Server settings are used for gathering login, version, and server status. The File Information List and Registry List allow an administrator to gather information about an ad-hoc list of files and registry keys.
Note: Event log data is often huge and might take several minutes to collect (particularly on servers). Use these feature settings to limit the amount of data collected and thereby speed up the collection process.
Events:
Note: When used together, data gather stops when either filter condition is “satisfied” (a logical OR condition).
Files/Servers:
See Section 2.8 for additional information about the text files used for Last Login and Install Version.
File Information List
Registry List
The File Information List and Registry List features are designed to satisfy the needs for information that might be specific to your organization without the need to modify and recompile the application. Administrators can merely edit the configuration file to start gathering this “ad-hoc” information.
2.6 User Settings
These settings control the program’s visual defaults that each user may customize.
Note: The user’s default settings are automatically saved when exiting the program. These settings are retrieved and applied the next time the application is launched.
Default User Setting:
Note: These settings are the defaults for new users of the application. They have no effect on existing users who may have already saved these settings.
2.7 Other Settings
The PollSOSOS and MgmtConsoleSOSOS applications require additional settings.
Note: MgmtConsoleSOSOS is an optional part of the SOSOS suite and is not included in the SOSOS Distribution Kit. It is available from the SOSOS web site as an additional download.
PollSOSOS Only
MgmtConsoleSOSOS Only
2.8 Additional Text File Configuration
The SOSOS suite uses several text files that may need to be created or text files that may require permissions to be set.
Error Log: The Error Log file needs to be created on a network share where it is available to all users on the network. This file requires read and write permissions for users of the application.
See Section 5 for the deployment scenarios that may require every user in your organization to have read and write permission to this file.
Last Login: The text file used by the Last Login feature is typically created from a login batch file. The batch file might include the following commands:
echo %USERDOMAIN%\%USERNAME% > C:\Utils\User.txt 2>nul
Note: The contents of the file are not relevant…SOSOS only uses the last modification date of the file.
Appropriate permission would be required for all users to create or overwrite this file.
Install Version: The text file used by the Install Version feature is created when the PC is first loaded. It contains the “signature” of the master image used to clone the PC. The format of the file looks like this:
v1.2.2<tab>1 Jan 2006
<tab><tab>Short description of image v1.2.3
<blank line>
v1.2.3<tab>15 Jan 2006
<tab><tab>Changes made to v1.2.2
Note: Only the last line that starts with the letter “v” is used.
Users only need read access to this file.
Section 3 – Running the Applications
The SOSOS suite consists of the following:
3.1 SOSOS
This is the “main” application that may be the only application that’s required in a home or small office environment.
SOSOS has no command-line options. See the User’s Guide for additional information on the features of the SOSOS application.
3.2 RunSOSOS
This is a “console application” that is designed to run unattended in a login batch file or as a scheduled task to collect and record SOSOS data. It has the following command-line options:
Switch |
Meaning |
Notes |
/q |
Quiet |
Run with no output to the console |
/w |
Wallpaper |
Puts a summary “watermark” on the user’s desktop |
/l |
Login |
Also record login information to the UserLogin table |
/s |
Server mode |
Record progress to the event log |
/wlo |
Wallpaper & Login Only |
Create wallpaper and record only login information |
/auto |
Automatic |
Switch to WLO mode if not an administrator |
When run in a login batch file the command line might include:
RunSOSOS /q/l/w
When run from a scheduled task on a server, the command line might include:
RunSOSOS /s
3.3 PollSOSOS
This is a “console application” that is designed to run unattended in a scheduled task on a single PC/Server to poll the network to collect and record SOSOS data from PCs on a LAN. It can be configured by using the ConfigureSOSOS utility to edit the configuration file and/or by using the following command-line options:
Switch |
Optional Arguments |
Notes |
/UsePingValidation |
None |
Use ICMP “ping” to verify that a PC exists before attempting to collect data |
/Domain |
Name of the domain or workgroup |
The domain/workgroup used to generate the list of PCs |
/OU_Filter |
The “distinguished name” of the OU |
Used to “filter” the list of PCs (Active Directory domains only) |
/NameFilter |
PC Name with wildcards |
Used to “filter” the list of PCs |
/PoolSize |
Number of concurrent PCs to process |
Increase this number to poll the network faster, increases the load on the local PC |
/PollLogDirectory |
Path to an existing directory |
If the polling log file name is generated automatically, this is the location where the file will be created |
/PollLogFile |
Path to the log file |
The full path to the log file (turns off automatic file name generation) |
/PollLogLevel |
Full, Errors, Summary, or None |
Control the level of detail that appears in the Polling log file |
/PollByAge |
Age (in days) that a database record is considered “old” |
Used to “freshen” existing records in the database by polling only those PCs whose records are older than the number of days specified |
/PollByFileFile |
Path to a text file that contains a list of PCs to be polled |
Used to poll a specific list of PCs |
/PollMethod |
AD, NT, Browse, File, or Age |
The method used to generate the list of PCs |
/PollTimeout |
Minutes to wait |
Used to make sure that the polling is not “stuck” on a PC for longer than the number of minutes specified. |
Note: Items in the Configuration file are processed first, followed by the options that appear on the command line.
When used to “freshen” the existing records in the database, the command line might include:
PollSOSOS /PollMethod Age /PollByAge 7 /PollLogFile “C:\Temp\SomeLog.txt”
When used to poll an Active Directory domain, the command line might include:
PollSOSOS /PollMethod AD /Domain consoto.com /OU_Filter OU=Sales,DC=Consoto,DC=com
Note: You should run PollSOSOS from a PC that’s running the latest operating system (i.e. Windows Vista). See Appendix C for more information about the effects on the data collected.
3.4 ViewSOSOS
This is a read-only database viewer for the SOSOS data in the database. It has no data gathering or scanning capabilities.
ViewSOSOS accepts a single PC name as a command-line argument. When used, it will retrieve the existing data for that PC and display the results.
Note: Administrators may prefer to use direct access to the underlying database to view, query, edit, and manage the SOSOS information.
3.5 ConfigureSOSOS
Use this utility to perform setup configuration tasks for each of the SOSOS-related applications. This application does not support command-line arguments.
Note: The configuration files for the “target application” are found in the same directory as the application’s EXE file. Changes are not effective until the target application is restarted.
You can use ConfigureSOSOS to configure applications after deployment or during development. If used during development, you must select the app.config file in the source code directory. When used after deployment, you select the application’s config file that resides in the same directory as the application itself (i.e. RunSOSOS.exe.config)
Note: The ConfigureSOSOS utility cannot be directly used to configure SOSOS_fx1.1 and RunSOSOS_fx1.1 (these programs are available as additional downloads and are not part of the distribution kit). Instead, you must first use ConfigureSOSOS to configure the “normal” versions of SOSOS and RunSOSOS and then copy the encrypted connection string data to the *.config files for SOSOS_fx1.1 and RunSOSOS_fx1.1 by hand (i.e. using Notepad).
Important: This utility is particularly important since the connection strings to the database may be encrypted and therefore editing the configuration files by hand is not possible.
Section 4 – Database Setup
The SOSOS suite does not have a built-in database… instead it relies on a 3rd-party database application to store its information. See Appendix B for a brief description of each database table.
Note: A database is not absolutely required. However a lot of SOSOS functions are designed around a database and will be disabled when a database is not configured.
SOSOS is designed to record the most current information into the database. This means that older records are completely replaced with new records. Therefore, the database does not contain a “history” of previous data. If your organization requires historical data, then you should consider downloading the optional BackupSOSOS source code from the SOSOS web site to create archive copies of the live database.
SOSOS can use any database that is supported by the .Net Framework 2.0. The choice of database “providers” and “drivers” (particularly with the OLEDB and ODBC driver) allows support for practically every database. The more common databases used are:
Microsoft SQL Server Express Edition is an excellent choice and is available as a free download at: http://msdn.microsoft.com/vstudio/express/sql/download/.
4.2 Prototype Files
As part of the setup of SOSOS, you will be required to create a database. To aid in the creation of this database, the SOSOS Distribution Kit includes two files that can be used as a “prototype”.
Most databases have a migration tool that will take a Microsoft Access “mdb” file and convert it into the native structure. Alternately, you can use the provided set of SQL scripts to create the database.
The exact steps required to create a database is highly dependent upon the database vendor and is beyond the scope of this document. It is recommended that an experienced database administrator perform these tasks.
Note: When migrating, make sure that the primary key and foreign key constraints are successfully converted from the prototype.
The security requirements of the database need to match the deployment scenario. See Section 5 for additional details on which options are best for your organization.
Database permissions need to be set to allow appropriate access controls to the database. See your database vendor’s documentation on how to perform this task.
A typical scenario for SQL Server would be to create a “secret” database login for use by ordinary users and also use “Windows Integrated Security” for administrators to authenticate as themselves. This allows ordinary users to have write permission to the database only when running the applications. Ordinary users would not have any permission if they attempted to connect to the database directly. See Section 4.4 for additional information about how the login and password strings are protected.
You might also consider an additional “tier” of security for protecting the contents of the EventLogs table as these entries may contain password information from failed login attempts.
User |
Access Method |
Tables |
Permission |
Administrators |
Direct access |
All |
Read & Write |
Junior Admins |
Direct access |
All (except EventLogs) |
Read |
Junior Admins |
Direct access |
EventLogs |
None |
Database login* |
Via application only |
All |
Read & Write |
Ordinary User |
Direct access |
None |
None |
* The Login Batch Model, described in Section 5, requires that ordinary users have both read and write permissions to all tables. This is normally accomplished by using a database login and password that only the application can decipher.
Important: The contents of the SOSOS database would be rich find for a hacker! Guard this database well.
4.4 Encrypted Database Connection Strings
Each SOSOS application that connects to the database needs to be configured with a “Connection String” that allows the program to find and login to the database. These strings are stored in each application’s configuration file. The configuration file is an XML-based text file with an extension of *.config.
To protect this sensitive data, the Connection String portion of the configuration file may be encrypted by a technique that only the application knows how to decipher. See Section 2 for additional information about how to configure the Connection Strings properties.
In a small office environment the extra complexity of setting up the encrypted connection strings may not be warranted. In those cases where security of the database is not a significant concern, you may optionally disable the encryption of the connection strings in the config files. See Section 2 for additional details.
Important: Changes to the encryption keys in the SOSOS\crypt.c file requires that you recompile all members of the SOSOS suite. Encryption key changes also mean that the previously encrypted connection strings are no longer available.
Important: Do not attempt to edit the configuration file “by hand” or copy a configuration file from one application to another. Use only the provided ConfigureSOSOS application to perform configuration tasks.
Section 5 - Deployment
This section is designed for administrators in a corporate LAN environment, where setting up a system to record information from hundreds of PCs takes a lot of planning.
Note: Home users can safely ignore this section and just double click on the SOSOS.exe file.
An important factor to consider when developing a deployment scenario is whether or not the PCs in your LAN already have the .Net Framework 2.0 installed.
Since SOSOS works best when run with administrator rights, another important factor to consider is whether or not the users are administrators on their own PCs. See Appendix C for the affects of administrator rights on the data that is collected.
5.1 Scenarios
SOSOS can be configured in many different ways to collection information:
Consider the merits of each option:
Model |
Pros |
Cons |
Manual |
Simple, doesn’t require a domain, and database security is simple |
Resource intensive, gathers no login information, data becomes outdated , and requires installation of “prerequisite software” on each PC |
Polling |
Simple, doesn’t require installation of “prerequisite software” on remote PCs, and database security is simple |
Gathers no login information, PCs must be left on, and could take several hours to poll a large LAN. |
Login Batch |
Gathers login information and maintains very timely data. |
Requires installation of “prerequisite software” on each PC and database security is complex. For best results, users should be administrators on their own PCs |
Scheduled Task |
Maintains timely data, is faster than polling, and database security is simple |
Gathers no login information and requires installation of “prerequisite software” |
No single scenario will be appropriate for all situations. In fact, it’s anticipated that most users will use a combination of the techniques to obtain full and timely information in the least amount of time.
For example, a typical organization of approximately 10 servers and 300-400 PCs might use the following combination of techniques:
Type |
Model |
Command line |
Notes |
PCs |
Login Batch |
RunSOSOS /q/l/w |
Run quietly from Login batch, records login info and creates wallpaper. Takes about 30 seconds to run. Most users are Administrators on their own PCs |
Servers |
Scheduled Task |
RunSOSOS /s |
Runs in the middle of the night from a scheduled task on each server. Takes several minutes to run. Quicker than polling servers remotely |
Servers |
Login Batch |
RunSOSOS /wlo |
Runs from login batch (on servers only) to record just the login info and creates wallpaper. Takes about 5 seconds to run. |
LAN |
Polling |
PollSOSOS /PollMethod Age |
Run PollSOSOS as a scheduled task on a central PC. The Age option updates “stale” data on PCs where users rarely login (like Print Server). Takes about 20 minutes to run. |
LAN |
Polling |
SOSOS |
When required, an Administrator runs SOSOS to manually poll a specific PC (or group of PCs) to update existing data |
See Section 3 for additional information about the available command-line options.
All of the SOSOS applications require the .Net Framework 2.0 to be installed on the PC from which the applications run.
Note: When polling PCs remotely, only the local PC requires the .Net Framework… there is no requirement for the .Net Framework on the remote PCs.
Every PC must have Windows Management Instrumentation (WMI) components installed (including remote PCs when polling). Luckily, WMI is already preinstalled on modern operating systems by default.
The minimum requirements for each PC are highly dependent upon the deployment scenario, but use the following as guide:
Note: The table below represents the minimum requirements; it is always advisable to install the latest components.
OS |
Scenario |
SP |
Framework |
MDAC |
Installer |
IE |
WMI |
WinXP |
Local |
2 |
2.0 |
2.8 |
3.0 |
5.01 |
Preinstalled |
WinXP |
Remote |
N/A |
No |
No |
No |
No |
Preinstalled |
Win2k |
Local |
3 |
2.0 |
2.8 |
3.0 |
5.01 |
Preinstalled |
Win2k |
Remote |
N/A |
No |
No |
No |
No |
Preinstalled |
Win2k3 |
Local |
N/A |
2.0 |
2.8 |
3.0 |
6.0 |
Preinstalled |
Win2k3 |
Remote |
N/A |
No |
No |
No |
No |
Preinstalled |
WinNT |
Local |
|
Not supported |
|
|
|
|
WinNT |
Remote |
4 |
No |
No |
No |
No |
1.5 |
Win98/Me |
Local |
N/A |
2.0 |
2.8 |
2.1 |
5.01 |
1.5 |
Win98/Me |
Remote |
N/A |
No |
No |
No |
No |
1.5 |
Win95 |
Local |
|
Not supported |
|
|
|
|
Win95 |
Remote |
N/A |
No |
No |
No |
No |
1.5 |
Note: SOSOS_fx1.1 and RunSOSOS_fx1.1 are available as additional downloads and uses the .Net Framework v1.1 to aid organizations that have not completed the migrated from version 1.1 to version 2.0 of the .Net framework. This also allows WinNT to run the application locally.
The prerequisite software is available from the Microsoft web site:
Component |
Download URL |
.Net Framework 2.0 |
http://msdn.microsoft.com/netframework/downloads/updates/default.aspx |
MDAC |
|
Jet 4.0 |
|
Windows Installer |
|
Internet Explorer |
|
WMI |
5.3 Additional Requirements for Remote PCs
In order to successfully obtain SOSOS data from a remote PC, all of the following must be true:
Administrator Account
The account used on the local PC to gather information on a Remote PC must be in the administrators group on the Remote PC. Typically, you’d use an account that’s in the Domain Administrators group to remotely gather SOSOS data.
The User Account Control (UAC) feature of Windows Vista doesn't allow for a connections to a remote Windows Vista PC when the user in logged in via a local account. This isn’t normally a problem, since members of the Domain Administrators group are “domain accounts” and not a “local accounts”. However, in a Workgroup environment (where you only have local accounts), you must disable UAC on the Remote 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).
Firewall Settings
A common requirement is to configure the firewall settings for Windows XP SP2 clients to allow for “Remote Administration”. You can use a Group Policy Object (GPO) or use the following command line on each PC:
netsh firewall set service RemoteAdmin enable
For additional information on configuring the WinXP Firewall to allow Remote Administration traffic, see: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/connecting_through_windows_firewall.asp.
For Windows Vista, the technique used to allow remote connections via WMI is a bit different.
From the Control Panel, click Security, click Windows Firewall, click Change Settings, and then click the Exceptions tab. In the Exceptions window, put a check for the item Windows Management Instrumentation (WMI). Alternately, you use the following command line:
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
The Windows Vista firewall may also need to be configured to allow File and Print Sharing.
Remote Registry Services
By default, Windows Vista has the "Remote Registry" service set to Manual and it is stopped. So, in order to connect to a remote Windows Vista PC, you'll have to set the service “start type" to Automatic (and start the service).
From the Control Panel, click Administrative Tools and then click Services. Select the “Remote Registry” service and change the Start Type to Automatic.
Administrative Share
All modern operating system have a C$ “Administrative Share” that is configured to allow administrators to gain access to the drive remotely. SOSOS typically does not require any changes to the default configuration.
Additional Notes
Some Microsoft operating systems do not allow Remote Administration at all. Both Windows XP Home Edition and Windows Millennium have the Remote Administration feature deliberately disabled.
Note: That means that you can not use SOSOS to gather information remotely from a PC running WinXP Home. But, obviously SOSOS works just fine when run locally on WinXP Home.
You may be able to coax Win9x clients into allowing remote connections via the DCOM configuration utility, remote registry services, and creating an administrative share. But in practice, it’s difficult to get to work properly and probably not worth the effort (see http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b141460).
5.4 Deploying the Applications
As with practically all .Net Framework applications, there is no need for a formal install procedure. Instead you can just copy the files to a network share without installing anything on the client PCs. Alternately, you could copy the files to directory on each PC.
However, a more formal procedure may be required to deploy SOSOS via an Active Directory domain’s Group Policy Object (GPO). To accommodate this requirement, each application in the SOSOS suite has a Setup project associated with it. You can use these projects to create the necessary setup MSI files to deploy the programs to your client PCs via a GPO.
See Section 2 for additional information about configuring the app.config file in each program’s source code directory prior to creating the Setup projects.
Note: The free Visual Basic Express Edition does not support the Setup project type.
For additional information on how to deploy an application via a GPO see http://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/featusability/inmnwp.mspx.
5.5 Running from a Network Share
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 Code Access Permission settings are sufficient when SOSOS is run from the local drive.
To solve the problem, you can either copy the program files to a local drive, or adjust the .Net Framework assembly permissions on each PC.
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.
Alternately, you can use the LocalIntranet.msi file included in the SOSOS Distribution Kit.
Section 6 – Errors
The core technology of SOSOS is Windows Management Instrumentation (WMI). WMI is a great idea, but is not an exact science... Errors are inevitable.
WMI provides its best information when both the OS and BIOS are very modern. Information also may change slightly if the user is (or is not) the administrator on the local PC. Different errors may also appear if the application is run locally or remote.
The SOSOS suite uses an error reporting system that collects application errors and records them to a central error log file.
See Section 2 for additional information about how to configure the Error Log settings.
6.1 Error Messages
If the program is in the “quiet mode”, the user is typically unaware of an error condition that might arise… errors are silently recorded to the error log file.
See Section 3 for information about the command line options for the “quiet mode”.
Error messages that pop up while not in the quiet mode are intended for the casual user, and do not contain a lot of detailed information. However, the details are still recorded to the error log file.
Note: The error log file was designed to be used by programmers to diagnose problems. So, it includes a bunch of programmer-related gobbly-gook.
6.2 Log Levels
For the first few weeks, it’s recommended that you leave the default settings for the Error Logging Level and Poll Logging Level at “Full”. This will help identify problems with deployment. However, these log level settings will also fill the error log file with lots of extraneous information.
See Section 2 for additional information about the configuration options.
Note: With the log levels at “Full”, you will get entries in the error log file. This is expected and not necessarily a sign that something is wrong.
It may take a while for you to become familiar with the entries in the error log file and determine what is “normal chatter” and what is a real error that requires some attention.
After you’ve reached a comfort level with the deployment, then you should consider changing both the Error Logging Level and Poll Logging Level settings to “Errors”. This will reduce the “chatter” in the log files while preserving those entries that are true errors.
Most minor errors are also recorded in the database. The error messages are generally short and truncated to fit inside the particular table column. Messages are preceded by the text “Error:”. If a numeric field is available, it is set to a negative number.
Note: Logging levels do not affect the appearance of embedded error messages in the database.
Section 7 - Maintenance
The SOSOS suite does not require any maintenance. However the database used by SOSOS will most likely require some periodic tasks.
The database maintenance tasks are highly dependent upon the specific database application installed and therefore are beyond the scope of this document. You should follow the tasks recommended by the database vendor to assure that the following are periodically accomplished:
7.2 Program Updates
There is no formal update notification procedure. Users are encouraged to check the SOSOS web site for updates. The web site contains a text file called Changes.txt which you can use to determine if an update is available.
When updates are available, they are provided as a zip file that contains a complete replacement set of source code files. The updated source code is designed to completely replace all of your existing source code files to include any configuration settings you changed during development.
Important: Remember to record your encryption keys before overwriting your existing source code files.
If changes to the database are required, instructions will be provided in a text file called DatabaseChanges.txt.
Updates are available from the SOSOS home at http://www.sosos.emmet-gray.com.
Administrators are encouraged to view the Error Log file for potential problems. A programmer who is experienced with Visual Basic .Net may be able to edit the source code to solve minor problems that are detected in the log file.
See Section 6 for additional information on the Error Log file.
Appendix A – Deployment Checklist
When deploying SOSOS, consider the following steps:
Pre-deployment:
Deploy the database:
In a lab environment:
Determine the deployment scenario
Deploying the clients (highly dependent on deployment scenario):
Post deployment:
Appendix B – Database Table Descriptions
Table Name |
Description |
Accounts |
A listing of all local accounts |
Admins |
Members of the local Administrators group |
AutoUpdate |
Automatic Update settings |
BIOS |
BIOS information |
Components |
Windows components (similar to installed software) |
CPU |
Processor information |
Desktop |
User’s desktop (screen saver, wallpaper, etc) |
Devices |
Listing of devices (similar to device manager) |
Disks |
Physical disk information |
Drives |
Logical drive information (drive letters) |
|
User’s Microsoft Outlook settings |
EventLogs |
Event Log entries |
EventLogSettings |
Setting for each Event Log |
FileInfo |
Information about an ad-hoc list of files |
Internet |
User’s Internet Explorer settings |
Mapped |
User’s mapped network drives and printers |
Memory |
Quantity and type of RAM |
Modem |
Modem information |
Monitor |
Video Monitor information |
Motherboard |
Motherboard information |
Mouse |
Mouse |
NetAdapter |
Network Interface Card (NIC) information |
NetConfig |
NIC Configuration |
OS |
Operating System details |
PC |
Miscellaneous PC information |
Permissions |
Permissions on network shares |
Ports |
Number and type of ports |
Printers |
Local and network printer information |
Processes |
List of running processes (similar to Task Manager) |
Profiles |
Listing of User Profiles (i.e. C:\Document and Settings) |
QFE |
Updates/Patches (QFE=Quick Fix Engineering) |
Registry |
Information about an ad-hoc list of registry keys |
Services |
List of Windows Services |
Shares |
Information about network shares |
Software |
Listing of installed software |
SOS |
Summary information (root of many tables) |
Startup |
User’s automatic startup applications |
SystemDrivers |
List of system drivers (useful in recovery console) |
SystemInfo |
System identification and serial numbers |
Tasks |
Listing of scheduled tasks |
UserLogin |
Record of every login |
Video |
Video card information |
Virus |
Norton Antivirus Corporate Edition logs |
Appendix C – Affects on Collected Data
Administrator
The following table describes the affect on the information that is collected if the current user is not a member of the local administrators group on the PC.
Table Name |
Notes |
Desktop |
Only entries for the current user and the Default User |
|
Only entries for the current user and the Default User |
EventLogs |
No entries for the Security Log. All other event logs are recorded |
Internet |
Only entries for the current user and the Default User |
Mapped |
Only entries for the current user and the Default User |
Permissions |
No entries |
Startup |
Only entries for the current user and the Default User |
Tasks |
No entries |
Video |
Only partial data will be collected |
User Mapped Drive Letters
SOSOS does not follow files that have mapped drive letters to network shares (such as “H:\SomeFile.txt”). This would most likely happen in the Email table where the user may store his/her PST file on a network share using a mapped drive letter. In this case, the file name is recorded, but the file size will show 0.
Remote Collection
When collecting data from a remote PC running Windows Vista, the Task table will only be populated if the local PC (the one running the application) is also running Windows Vista.
Development Platform
The Task table will only be populated on a PC running Windows Vista if the SOSOS application was also compiled and configured on a development PC running Windows Vista.
Appendix D –
Supported Environmental
Variables
The use of System Path environmental Variables allows SOSOS to more accurately find files on remote PCs. This feature is particularly handy when creating the list if ad-hoc files for the FileInfo feature (See: Section 2.5)
Note: The 64-bit versions of Windows have both a “C:\Program Files” and “C:\Program Files (x86)” directory to allow side-by-side program installation.
The following environmental variables are supported by the SOSOS suite:
Note: The normal file name wildcards (* and ?) can also be used in the ad-hoc files listed in the FileInfo feature. Example: "%SystemRoot%\system32\Macromed\Flash\Flash*.ocx".
Appendix E – Compiling “Walk Through”
Here is a step-by-step “walk through” for compiling the Visual Basic source code to the SOSOS application. There are 3 basic steps:
1. Install Visual Basic 2005/2008 on your computer (any version will do, including the free Visual Basic Express Edition)
2. Download the SOSOS source code (all you need is the SOSOS.zip file)
3. Create a source code directory where you will put the SOSOS source code (i.e. C:\SOSOS_Suite)
4. Extract the source code from the SOSOS.zip file into the directory created in Step 3 (using WinZip or the built-in “compressed folders” feature of Windows XP and above). Make sure you extract the folder structure along with the files.
5. Extract the vbproj files from either the WinXP_vbproj.zip or WinVista_vbproj.zip file. Answer “yes” to overwrite existing files. Again, make sure you extract the folder structure along with the files. If your development PC (the one where you installed Visual Basic) is running Windows XP, then use the WinXP_vbproj.zip file. Otherwise, if you’re running Windows Vista, then use the WinVista_vbproj.zip file. These two zip files are included in the SOSOS.zip file and only appear after you’ve extracted them in Step 4.
6. Navigate to the SOSOS directory inside the source code “tree”. For example, if you extracted the files into a directory called “C:\SOSOS_Suite”, then click on the “C:\SOSOS_Suite\SOSOS” directory.
7. Double click on the SOSOS.sln (the solution file) to launch Visual Basic. If you have configured the Explorer to hide file extensions, the SOSOS.sln file is the icon with an “8” in the upper right hand corner. Note: you might get a window that pops up saying “The application for project c:\SOSOS_Suite\SOSOS\SOSOS.vbproj is not installed”. This is because the free Express Edition does not support the Setup project type. This error can be safely ignored.
8. Check for missing References in the error messages. A few of the SOSOS applications use the Microsoft.Data.ConnectionUI.dll and Microsoft.Data.ConnectionUI.Dialog.dll. There's no way for me to know exactly where those files are located on your PC. The typical directory is something like "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE". You will have to use the Add Reference/Browse tab to navigate to the correct location to find the missing DLLs
9. Do a “test run” to make sure everything is working correctly. From the Visual Basic window, use the “Debug” menu, select “Start Debugging”. This will compile the program inside a special debugging environment and launch it for you to play with. Take your time to explore the application, have fun… and after you’re satisfied that this is something you’d like to use, move to the next step. Note: Do not attempt to configure SOSOS inside the debugging environment, since the configuration settings are overwritten each time you start debugging.
10. Change the default encryption keys in the Crypt.vb file. Open the Crypt.vb file by double-clicking it from the “Solution Explorer” (typically in the upper right-hand corner of the Visual Basic screen). Find the lines that start with “Private TheKey()” and “Private Vector()“. There are 16 hexadecimal bytes (on two lines) that should be changed. It really doesn’t matter what values you use (unlike a password, you won’t have to remember these numbers). Hexadecimal numbers are one or two digits, made up with the numbers 0-9 and the letters A-F. Note: If you are configuring SOSOS for home use, you can probably ignore this step and turn off the encryption feature in step 13.
11. Compile the SOSOS application by using the “Build” menu, and selecting “Build SOSOS”. Take a look at the “Output” windows (typically at the bottom of the Visual Basic window) for any errors or warnings.
12. Create a SOSOS home directory where the SOSOS program will reside (typically this would be “C:\Program files\SOSOS”
13. Copy the files from the development environment to this “SOSOS home” directory. The 10 or so files that were created in Step 10 should be in a directory called C:\SOSOS_Suite\SOSOS\bin\Release. Copy all of the files except for the ones named “SOSOS.vshost.exe” and “SOSOS.vshost.exe.config” to C:\Program files\SOSOS. Copy the help file (C:\SOSOS_Suite\SOSOS\Help\SOSOS.chm) to the SOSOS home directory.
14. Perform a one-time configuration of SOSOS by navigating to the “SOSOS home” directory (typically C:\Program files\SOSOS) and launch the SOSOS program by double-clicking on the SOSOS.exe program. From the “Setup” menu, select “Configure SOSOS”. Configure the items on each of the “tabs”. See the “Setup and Configuration” documentation for the details on each configuration setting.
15. Enjoy!