Ipconfig /all

On December 27, 2004, in SBS Installation, by

Probably the number one asked question back to posters in the newsgroup is


“Please post the results from ipconfig /all at both a workstation and a server”


So many issues with a SBS network are “fixed” with the right Internet Protocol configuration on the server.  It’s amazing how people and go through the wizard and not “get” what they are trying to set up.  I think it’s because of coming from peer to peer and on network card setups and now reading about different ways to set these networks up.  Many people expect that there should be an “Internet connection sharing” tab on the server, but we don’t do things like that. 


The most recommended diagrams to follow for setting up a network can be found here:


While you can do a one nic setup as discussed here:How to Configure a SBS for Full Time Internet Access with a Single Network Adapter:
http://support.microsoft.com/kb/309633  I personally feel that two nics is more “separated“, more flexible and I just feel more comfortble with the wizards of SBS than the configuration of a hardware firewall.


The other KB that talks about two network cards is listed here: How to Configure Small Business Server for Full Time Internet Access with Two Network Adapters:
http://support.microsoft.com/kb/306802


Basically you point to the server, the internal IP address for all your DNS entries.  You only put in the ISP’s DNS information into the DNS configuration as “forwarders“.  This is done automagically in the “connect to Internet“ wizard, but you can see the impact in the Admin tools, DNS.  Right mouse click on the server name, click on the “forwarders tab“ and you can see where the wizard put in the ISP’s forwarders.



See?  That’s the ISP’s DNS that I placed in my box when I ran the connection wizard.  You don’t put that information in the Network card properties as DNS as you would normally in a peer to peer with a Linksys.


This “separates“ and builds a wall between the inside and the outside to better protect you.


So next time you are having issues with your network, review the settings.  Start, command prompt, type in ipconfig /all and hit enter.  Copy what you see there, and paste it into the newsgroups and have us check why you are having issues!






Syntax:  ipconfig [/all] [/renew [Adapter]] [/release [Adapter]] [/flushdns] [/displaydns] [/registerdns] [/showclassid Adapter] [/setclassid Adapter [ClassID]]


/all : Displays the full TCP/IP configuration for all adapters. Without this parameter, ipconfig displays only the IP address, subnet mask, and default gateway values for each adapter. Adapters can represent physical interfaces, such as installed network adapters, or logical interfaces, such as dial-up connections.


/renew [Adapter] : Renews DHCP configuration for all adapters (if an adapter is not specified) or for a specific adapter if the Adapter parameter is included. This parameter is available only on computers with adapters that are configured to obtain an IP address automatically. To specify an adapter name, type the adapter name that appears when you use ipconfig without parameters.


/release [Adapter] : Sends a DHCPRELEASE message to the DHCP server to release the current DHCP configuration and discard the IP address configuration for either all adapters (if an adapter is not specified) or for a specific adapter if the Adapter parameter is included. This parameter disables TCP/IP for adapters configured to obtain an IP address automatically. To specify an adapter name, type the adapter name that appears when you use ipconfig without parameters.


/flushdns : Flushes and resets the contents of the DNS client resolver cache. During DNS troubleshooting, you can use this procedure to discard negative cache entries from the cache, as well as any other entries that have been added dynamically.


/displaydns : Displays the contents of the DNS client resolver cache, which includes both entries preloaded from the local Hosts file and any recently obtained resource records for name queries resolved by the computer. The DNS Client service uses this information to resolve frequently queried names quickly, before querying its configured DNS servers.


/registerdns : Initiates manual dynamic registration for the DNS names and IP addresses that are configured at a computer. You can use this parameter to troubleshoot a failed DNS name registration or resolve a dynamic update problem between a client and the DNS server without rebooting the client computer. The DNS settings in the advanced properties of the TCP/IP protocol determine which names are registered in DNS.


/showclassid Adapter : Displays the DHCP class ID for a specified adapter. To see the DHCP class ID for all adapters, use the asterisk (*) wildcard character in place of Adapter. This parameter is available only on computers with adapters that are configured to obtain an IP address automatically.


/setclassid Adapter [ClassID] : Configures the DHCP class ID for a specified adapter. To set the DHCP class ID for all adapters, use the asterisk (*) wildcard character in place of Adapter. This parameter is available only on computers with adapters that are configured to obtain an IP address automatically. If a DHCP class ID is not specified, the current class ID is removed.


/?: Displays help at the command prompt.





To display the basic TCP/IP configuration for all adapters, type:


ipconfig


To display the full TCP/IP configuration for all adapters, type:


ipconfig /all


To renew a DHCP-assigned IP address configuration for only the Local Area Connection adapter, type:


ipconfig /renew “Local Area Connection”


To flush the DNS resolver cache when troubleshooting DNS name resolution problems, type:


ipconfig /flushdns


To display the DHCP class ID for all adapters with names that start with Local, type:


ipconfig /showclassid Local*


To set the DHCP class ID for the Local Area Connection adapter to TEST, type:


ipconfig /setclassid “Local Area Connection” TEST

 

9 Responses to Ipconfig /all

  1. Carlos says:

    Not sure if this is relevant or not but Windows has a command line tool to configure IP of a network interface. This is VERY useful for folks that travel to sites that do not use DHCP or that switch from sites that use DHCP to sites that do not and vice versa. The tool is “netsh” a full set of documents on the tool can be found at http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/netsh.mspx . I have several batch files that change my settings based on my location. A simple batch might look like this:

    netsh interface ip set address name="LAN" source=static addr=10.0.0.220 mask=255.255.255.0 gateway=10.0.0.254 gwmetric=1

    netsh interface ip add dns name="LAN" addr=10.0.0.1 index=1

    netsh interface ip add dns name="LAN" addr=10.0.0.2 index=2

    Carlos

  2. Tony Su says:

    Ugh, you are correct that probably the number one request is to post back your IPCONFIG to a <Public Newsgroup>.

    And I never stop being amazed at all the people who do just that.

    So, now and forever as long as that Newsgroup is publicly accessible (and posts I’ve made over 10 years ago are still publicly searchable) every potential hacker knows your network’s network ID, the IP address of a machine in your network, your network’s DG and more. Heck, they even know a set of DNS IP addresses which might provide easy entry into your network if they could ever poison specified zone records on those machines (and anyone who knows the difficulties of public DNS can’t dismiss this possibility easily).

    So,

    PLEASE.

    Don’t ask for anyone’s IPCONFIG anything except through a private message. Don’t post your IPCONFIG anything anywhere.

    Unless you "sanitize" the info you post.

    Here is one suggestion if you really feel you must post publicly…

    1. Save your IPCONFIG to a file (ie. IPCONFIG /ALL > C:\ipconfigfile.txt)

    2. Do a "Search and Replace" using Notepad of all the network IDs in your file, ie.

    Search 192.168.16

    Replace 10.0.2

    3. Customize any other information as you see fit

    4. Copy the sanitized IPCONFIG into your post.

    5. When you receive a reply, save to a file and do a reverse "Search and Replace" to view the information in a way that’s relevant to your network.

    Tony Su

  3. Susan says:

    More often than not the two IP addresses are private IP ranges and there’s no DNS info in there as most people have a router on the outside

    Don’t take out those private IP addresses 192.168.x.x and/or 10.0.0.x because they are normal class a/c addresses [like big whoop]

    Granted clean out the public IP addresses, but not the private, as they aren’t that big of a secret and they, more often than not, tell us what is set up wrong.

  4. Tony Su says:

    Private addresses are critical information. Basically if anyone gains a toe-hold into your network (it might be purely blind scripting)… for instance through a mismanaged VPN, knowledge of your internal addresses means instant network compromise instead of buying yourself time while the hacker is testing to find out where everything is.

    Not everyone will consider exposing your private addresses critical. I’m just passing on conventional thought.

    Tony

  5. Susan says:

    We "blast" so much info out our SBS boxes anyway in just our email headers, Tony …

    .local

    .lan

    192.168.16.2 is so default in SBSland and in the world in general.

    People have cleaned "so" much stuff off those IPconfigs that we could not diagnose there issues.

  6. Tony Su says:

    Everything you just said is precisely why a seasoned SBS Consultant will modify those settings when installing… or modify later when given an opportunity.

    If an installation is "typical" I don’t believe that the business or the SysAdmin should want that information posted publicly if they simply pause to consider the consequences.

    I don’t subscribe to the idea that just because people tend to set up generic installations it’s reason to blab that kind of stuff where someone could easily harvest the information. What you’re saying to the world is "If you come and get us, I’m just one of the pack." Is there safety in numbers? I don’t think so in this case.

    The only time someone can allow this kind of information to be publicly available is if they are taking extra steps to ensure their internal security approaches the type of security outside their firewall, and very few people <especially> in the SMB space is doing that.

    There’s no excuse for blatant carelessness. If you don’t have to take a risk, don’t do it.

    Tony

  7. Susan says:

    And private IP ranges that are non routable are normally protected by a good ISA or firewall.

    We certainly don’t do like USAtoday and expose our netbios ports. A properly configured SBS box should be able to withstand typing/disclosing the internal IP address space of that network.

    There’s more risk in email header files IMHO which also exposes internal information. All I’m saying is what resources are you taking to protect that? I think header files are even more exposure as they give the version of your mailclient/Exchange and what patch status you have.

    Like I said, there’s more information, heck there’s even a track back of your IP address when you post comments to the blog.

  8. Tony Su says:

    Susan,

    I’ll stick to my guns. Don’t unnecessarily publicize information which should be private. If you do, you should <know> the risks you undertake and take steps to fortify your defenses.

    My big beef is the common practice of knowledgeable people who request this kind of information be posted by people who can’t make a knowledgeable decision whether to comply.

    – The arguement "Just because plenty other information is leaking makes this leak acceptable" just doesn’t hold water. No, just because you divulge information through email headers is no reason for you to dump more information about yourself on the Public Internet. Private information should stay private.

    – You have no idea what types of vulnerabilities might be discovered in the future and what types of exploits might be created. By divulging useful and probably critical informationn publicly you’re just making it easier to get hacked and you’re increasing the scope of compromise if you are hacked.

    – You’re creating a repository of easily searchable information for hacking and don’t believe it can’t be used. The current/recent Santy exploit is a good example of how this can happen… Like any Internet User, the exploit identifies victims by querying Google (The lookups have since been disabled by Google).

    – Your arguement placing faith in your firewall is obsolete. Today, it’s common knowledge that firewalls can only be a piece in an overall security solution and cannot be relied upon to protect against all threats, even a wide variety of common threats. There are too many ways for exploits to be undetectable by firewalls and gain access to your internal network… Anyone who runs Anti-Virus, Anti-Spam, Intrusion Detection and patches their internal machines knows this. If what you said can be relied upon, these technologies and practices wouldn’t be necessary (and were unheard of 15 years ago). Don’t get trapped by obsolete practices.

    Network information should usually be protected like your SSI and Driver’s License. It’s a good security practice which doesn’t even require you to pay a dime to implement.

    Tony

  9. Susan says:

    And has Wayne as pointed out ….. a lot of info can be "bled" out via telnet. What precautions are you taking for telnet and email header files?