The file lspcommon.h is part of the LSP sample, you should be able to find it in the 'common' subfolder. (C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\netds\winsock\lsp\common)
If you double click on one of your errors the editor will open focused on the line that's giving problems. Do that for lspdef.h line 22 and you'll see the code looks like this...
#ifndef _PSDK_BLD
#include <nt.h>
#include <ntrtl.h>
#include <nturtl.h>
#endif
That means, the nt.h file (and two others) is only included if the macro _PSDK_BLD is not defined. Look a little lower at line 35 and you'll see the code looks like this...
#ifndef _PSDK_BLD
#include <lspcommon.h>
#else
#include "..\common\lspcommon.h"
#endif
In this case, if the macro is not defined the code includes the file lspcommon.h, but if the macro is defined then the code includes the file lspcommon.h from the common foider.
It seems likely then that your problems are happening because _PSDK_BLD is not defined. From the style of the #ifdef it doesn't look like the macro has to be defined to any specific value, just defined.
In Visual Studio, go to Project Properties, drill down to C/C++ and then Preprocessor. Then find the preprocessor definitions line and click on the value. Now select edit and add _PSDK_BLD to the list of preprocessor definitions.
Watch out for that leading underscore, and remember to make the change for Debug and Release configurations (and for all the platforms you may have defined)
The error LNK2005 means that the linker found two definitions for the object it is trying to link - which is a problem because there's no way for the linker to be able to tell which of the two definitions it should use.
In this particular case, the object the linker is trying to resolve is "struct _GUID gProviderGuid". If you look in the files instlsp.h, lspdef.h (both of them) and lspcommon.h you'll see code that looks like this
extern GUID gProviderGuid;
That declares an external variable called gProviderGuid of type GUID (which is a struct). The linker has to resolve that external reference in any file that included one of those header files and then made a reference to gProviderGuid.
From the "already defined in lspguid.obj" part of the error we know the linker has looked inside the file lspguid.obj and found a definition of gProviderGuid. Sure enough, if we look inside lspguid.cpp we can see a definition of gProviderGuid with a value starting 0xc5fabbd0.
From the "C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\netds\winsock\lsp\instlsp.obj" part of the same error we know that the linker has also looked inside the file instlsp.obj and found a second definition of gProviderGuid. If we look inside intlsp.cpp we can see another definition of gProviderGuid (this time without any value).
The problem then is that the linker is looking in both lspguid.obj and intlsp.obj and finding conflicting definitions of gProviderGuid.
Those two files should not be part of the same build so we shouldn't expect a single run of the linker to read them both at the same time.
The LSP project is made up of four parts: lspcommon which is used to generate the static library lspcommon.lib; ifslsp which is used to generate the file ifslsp.dll; nonifslsp which is used to generate the file nonifslsp.dll and install which is used to generate the file Instlsp.exe. See the readme.txt file in lsp and the makefile files in the various folders for more details.
If you are going to build LSP inside Visual Studio, you really need four different projects in your solution, one each for lspcommon, ifslsp, nonifslsp and install.
