I have seen several hits on the support blog regarding searches for scan error codes. So, today we will discuss what exactly happens during an agentless patch scan. This is similar to what I would teach in our classroom training. The goal is to give you a better understanding of what is happening under the hood. At each step I will describe what the engine is doing. Where possible you will see validation options which show you how to test equivalent functionality outside our product for troubleshooting and validation purposes. You will also see possible error codes that would result at that point in the scan. Each will include troubleshooting steps and possible SKBs that show steps on how to resolve them. Steps 1-3 have this information. Step 4 and beyond are written to the DB and tracked via logs. I will not be stepping into that level of detail in this particular write-up.
Step 1: Machine Resolution – How the machine is added into the machine group determines how resolution of the target occurs. If we add a machine by Hostname we would discover the machine in the network using its name through NetBIOS (TCP 139) or DirectHost (TCP 445). If we add a Domain or OU we will query AD and determine a list of names to resolve and once we have the name we will resolve via NetBIOS or DirectHost. If we add IP addresses or ranges we will resolve via IP to discover machines. Each method may be useful in different ways. Examples: IP range can be used to do a discovery scan to find machines you may not be aware of. Using Domain, OU, and IP Range are methods that are dynamically updated each time you do a scan to reduce Machine Group maintenance.
Validation options: Ping, NSLookup
Possible Protect Errors and Troubleshooting options at this step:
–Level 200 Error codes
- System Pre Reqs. This is usually a prerequisites issue, although it can be network related as well.
- Can you PING the machine or NSlookup by the method you added the machine to the group?
- NET USE \\MACHINENAME\C$ /user:DOMAIN\USER PASSWORD
Step 2: Connect to Admin Share – Once we have resolved the machine we will connect to its Admin share by connecting to C$ (or whatever the default system drive is. In 6.0 and later you can also utilize a feature to create an admin share on the fly if they have been removed or hidden). This connection would be equivalent to doing a Net Use \\machine\C$ and browsing the target machines files system. There are a few different errors that could result at this point:
Validation Options: Net Use \\machine\C$ /user:domain\username password
Possible Protect Errors and Troubleshooting options at this step:
–Level 300 Error codes
- 6.x and 7.x: go to tools > options > Authentication and check the box to Create a temporary systemdrive share if none exists.
- 5.x: Set the value for the following keys to from 0 to 1 HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\paratermers\AutoShareServer HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\paratermers\AutoShareWks
- MS Articles on Admin Shares that may be of help.
http://support.microsoft.com/kb/318755
http://support.microsoft.com/kb/314984
– Error code 451
–Error code 452
Step 3: Connect to Remote Registry – Registry values play a big part in the detection process so we connect to the registry on a machine so we can validate this information.
Validation Options: From the console open Regedit > click on file > Connect to Remote Registry. When prompted supply the credentials you are trying to scan with.
Possible Protect Errors and Troubleshooting options at this step:
–Level 500 Error codes
Step 4: Determine OS\SP\Language – Once we have established the connection to the machine we can begin the process of detecting what is on the machine. The first step is to validate what OS edition is running and what service pack level it is at. This will begin to filter down the scope of what could possibly be required for this machine. We do a few tests to confirm this information such as checking DLLs\Reg keys etc.
Step 5: Determine Installed Products and versions – Note for a Patch Scan this is not a WMI scan. We have scripted product detection for each of the products we support including Registry, Service, and File level checks. With these Product Detection scripts we determine what products are installed that Shavlik supports scanning for. The engine knows what products are potentially applicable to the OS\SP that it determined in Step 4.
Step 6: Determine Patch Status – At this point we know what OS\SP is on the machine and what products are installed. The Patch Engine now has all the info it needs to determine what patches apply to the machine in question. We can now build the list of vulnerable patches based on information gathered in steps 4 and 5. Scan against Registry and File checks for each potential vulnerability. (note our engine prunes out patches that are not necessary such as superseded and effectively installed patches prevent scanning of patches we are not concerned about. There are options to show superseded patches and effectively installed patches if you choose. This is in the scan template general tab, check include effectively installed.)
Step 7: Send result to arrivals – Once the result for a machine is completed we drop it into the arrivals folder to be processed. The arrivals folder is located under NetChk\DataFiles and is processed by our importer utility into the database on a regular interval. Agent results are also processed this way.
-Chris Goettl
Sales Engineer, Shavlik Technologies