I recently did a webcast on Windows 2003 Remote Administration and ran into a few issues (mainly me being long winded) and wasn’t able to complete some of the demos. As a result, I have received a number of requests for information on specific tools and a number of “How Do I…?” emails. One of the emails I received was this —

Is there a way to run a report on all of the shared folders on our network to find out who has access? (this person is running Windows 2000)

Well yes there is……sort of….

In the Windows 2000 and Windows 2003 Resource Kits (and going all the way back to NT4.0) there is a tool called SRVCHECK.EXE. This is a simple command line tool that can enumerate what shares are on a local or remote machine and list the permissions on those shares. Since it is a command line tool, we can easily create a batch file that will list all the shares on all the file servers in the network……let’s do it!

I am going to work this from a Windows 2003 server but all the information is accurate going all the back back to NT4.

First, get the resource kit installed. The installation of the Res Kit tools does NOT require a reboot. However, the PATH= statement in the System Variables gets updated so you can run the tools from anywhere at the CMD line and that change DOES require a reboot to register. Otherwise you will get “path not found…” when trying to execute tools from the CMD line.

Variables

Now that we are installed, we have access to a virtual cornucopia of tools that can assist us with everyday administrative tasks. The SRVCHECK tool allows us to retrieve information about shares on a machine and what permissions are assigned to those shares. So if we drop to a command prompt now and run SRVCHECK we should get some info……..wrong. Unfortunately SRVCHECK *requires* you supply a machine name. It does not default to the local machine if there are no parameters supplied.

Noparams

So even for the local machine shares you will need to supply a machine name in the syntax:

srvcheck \\computername

Params

On my machine (lonestar) we find a number of shared folders. SYSVOL, NETLOGON, LONESTAR.LOG – because this is a Domain Controller……..Address and Resources$ – Because this is also an Exchange Server and finally…….Storage-Lonestar – Which is a public file repository on the network. We also see a list of accounts or groups as well as their permissions listed.

Now….this tool is only supposed to show “non-hidden” shares. Staring right at us is a hidden share – Resources$ – from Exchange. (hidden shares will have a trailing “$” character)

If we compare this to our Shared Folder properties from Computer Management we do see there are other hidden shares on the system that are NOT displayed by SRVCHECK. Most of these are the administrative shares

CompMgmt

Okie…..back to the permissions. It should be noted that the SRVCHECK tool is NOT enumerating NTFS permissions – only the share permissions. You can change the NTFS permissions all you want but when you run the tool, you will only see the resulting share permissions.

So….two pictures up….where we see \\lonestar\Storage-Lonestar          Everyone            Full Control             this means Everyone that connects to the share over the network has Full Control over the folder and files in the share UNLESS there is an NTFS permission they have or obtain through group membership that limits them in some other way.

To demonstrate, I will change some permissions around…we will add a test group called Goobers with Share Permissions of Full Control and leave Everyone as Full Control. But we will set NTFS Permissions for Goobers to READ.

Changeperms  Gooberntfs

Now when we run the SRVCHECK tool….

Postchanges

We see that Goobers does have Full Control as a share permission even though they only have READ at the NTFS level.

Remember – Share permissions only apply when accessing the object over the network. NTFS permissions apply when accessing the machine locally AND over the network.

Okie…..now that we have shown we can pull the shares and permissions from any machine we name with SRVCHECK, how do we use it to generate a report of ALL the shares on our network? It does require some leg work since the tool can’t scan for shares. You MUST supply a machine name for SRVCHECK to search against. So you will need to collect the names of the machines on your network you wish to scan. For my test network, those machines are -

lonestar, godzilla, wallofvoodoo, vidtopia, and sleestak

We will need to create a batch file (shareperms.bat for my demo) that has the SRVCHECK \\computername parameters….

Shareperms

….save this to wherever you save your system utilities (we all have a folder we save tools in…..) and then run!

Report1

You will notice a failure on my setup because wallofvoodoo is offline. We obviously can’t pull information from a box that is offline so it errors out. If you have a similar situation on your network, you will see a pause while the batch file runs and attempts to locate the offline machine.

Now this is all great……but the output is to the screen only. You can pipe the output to a file though. This requires modifying our batch file just slightly. I am going to add the “>” character which is a near universal means of redirecting the screen output to a file you specify. Check the screen shot below….

Piped

Now when we run the batch file, the screen output is dumped to the files we specified after the pipe character. We end up with a report of each machine we specify in our batch file in a handy text file format.

Output

If you open each of the resulting output files, the results are identical to what you would see on the screen.

Now the downside to this tool is there is no way to combine all of the machines queried to a single file. Nor is there an easy way to append the files over time. Each time you run the batch file it will over write the results. So if you decide to schedule these, you will need to add some logic to the batch file to modify the file name stored. I would suggest adding a date stamp for easy identification. You may wish to keep each machine queried in its own path as well especially if you have a LARGE network you are running this against.

I pinged a few internal aliases for some ways to do this with other methods of scripting as well. I have a couple of responses which I am going to evaluate and may post here at a later time if you want something a little fancier.

 

Cheers!