[Web4lib] Determining the IP address in Windows Server 2003

[J.P.Knight]

On Fri, 26 Oct 2007, Carl W Feucht wrote:
> Here's the situation: We're running a Windows Server 2003 with IIS & ASP 
> installed. IP's are assigned via DHCP.
>
> I'm poised to buy access to a database for use in the library and request a 
> trial. Agreeing to my request, my vendor requests an IP range to authenticate 
> our school network.
>
> I email my IT Team requesting same. [Here's where I get confused] They come 
> into the library and explain all I need do is bring up a C:\ prompt, run 
> IPConfig All, cut and paste the results into an email and send it back to my 
> vendor.

That will tell you the IP address of the server and the subnet mask of the 
subnet it is on.  That might not be the same as the subnet that your 
client machines are on - depends on how your local network is structured. 
Here for example we've got two of what used to be called Class B networks 
in the pre-CIDR days, which are subnetted into a couple of hundred subnets 
of varying sizes.  In our case, the subnet some random server lives in is 
almost guaranteed to be different from the subnet a staff or student or 
visitor's PC is in, so the "ipconfig \all" trick wouldn't be much use 
here for finding the campus IP address ranges.  YMMV of course as this is 
very dependent on how your LAN is set up.

Having this many addresses can sometimes blow the mind of 
database vendors who have on occasion been surprised when passed 
131.231.0.0/16 and 158.125.0.0/16 as the ranges to use!  Its much easier 
to give them the /16s though than all the myriad subnets that these are 
broken into.

> Long story short, this does not get me access to the trial database. I'm 
> thinking there is another way. I'm thinking there must be an IP range 
> assigned by our ISP that we plug into our DHCP setting. When I take this 
> thought to our IT Team I'm told they don't know what I'm referring to.

You need to ask your IT staff if they're doing NAT in any way, shape 
or form.  If they are things are more interesting because the IP addresses 
that your servers and clients have locally will not necessarily be the 
same as the IP address that the remote database will see (depending on 
how the remote database is testing the IP address).  You may also have 
issues if you've got a proxy cache between your LAN and the Internet 
(either configured directly in the browser, using autoconfig or a network 
level transparent cache).  We often have to make certain web based 
database that rely on IP addresses bypass the campus cache as they can 
screw up sessions, authentication, etc.  That's usually the sign of poorly 
written web front end in my experience though.

If possible put your network folk and the database vendor in direct touch 
with one another so that they can hash out what it is they need to supply 
to each other.

I wish vendors wouldn't rely on IP addresses as means of 
authentication/authorisation as they so often break things for one reason 
or another.