Extend your Wi-Fi network throughout the house

                                         Extending a Wi-Fi network can be as easy as playing with cardboard and tape, or as difficult as rewiring your house. It all depends how big a boost you need, and how much time and money you're willing to devote to the task.

Here are three ways to increase your signal's range.

Boosters

You know those little antennas that screw onto your router? You can improve the signal by replacing them with bigger antennas, or more directional ones.

You can also improve the existing antenna, making it directional. All you need is a few minutes and some common household materials. See Extend Your Wi-Fi Range With a Parabolic Reflectorfor detailed instructions.

If you're not the do-it-yourself type, or if you need to boost the signal in all directions, you can buy a generic antenna for a few dollars. I've seen this same antenna (see image to the right) sold under different brand names--priced from $2 to $7. And yes, I've tried it and it helps…a bit.

For a more powerful boost than either of those, try the directionalTP-Link TL-ANT2409A. You can get it for $25 if you shop around.

Extenders

You plug one of these devices, also called repeaters, into a wall socket as far from the router as you can get and still receive a good signal. The extender picks up the signal and rebroadcasts it.

In general, I find these more effective than boosters. But they're also more expensive, and are trickier to set up, since you have to find the best location and connect them to the network.

The best one I've tested (and I haven't tested all that many) was theAmped Wireless REC10. If you look around, you can buy one for $70.In general, I find these more effective than boosters. But they're also more expensive, and are trickier to set up, since you have to find the best location and connect them to the network.

HomePlug

I used to be a fan of this technology, which carries network data over your house's electric wiring. The adapters are basically power bricks with Ethernet ports. Some also have Wi-Fi Antennas.

You won't have much trouble adding HomePlug to your network--you just plug it in and it works…if it works.

All sorts of things can interfere with HomePlug signals--wiring, the location of the washing machine, the type of light bulbs you use.

I used HomePlug happily for years. It didn't give me Ethernet speed or even 802.11n speed, but it was faster than my Internet connection and that was all that I needed. Then it just stopped working.

Remote Network Access: Objectives and Architecture

In the this mini-series of posts, I am going to diverge from my usual System Center-only focus to take a fresh look at deploying a Microsoft Remote Network Access solution. First, we'll get you online and working using SSTP, and then extend this base implementation with Network Access protection before finally coming back a little later and elevating these SSTP servers to Direct Access.

Why Remote Network Access?

So why I am doing this? As we build out solutions for System Center, we need a foundation from which to work, and within the latest versions of Configuration Manager we have the ability to integrate with the Windows Network Access Protection and manage our off-site computers with a dial out approach over Direct Access. Also, in the new R2 releases we can integrate both our Certificate Servers (Certificate Authority – CAs) and we finally have the ability to distribute VPN Profiles to our end users. Therefore, I am considering this miniseries as a foundation for illustrating these features and abilities in later posts.

I am building this solution out using the recently published RTM builds of Windows Server 2012 R2, but almost everything I will cover in this series will work from 2008 R2, with some minor adjustments and wizard changes.

Architecture

The environment which we will use for the scenarios is illustrated in the graphic below, showing our client establishing a connection with the RRAS server over TCP443 or what you might better recognize as the HTTPS port. SSTP utilizes this same supporting environment, including the SSL certificates used to protect the tunnel.

I have tagged a number of the components with a  to indicate the initial systems which are engaged in the basic SSTP implementation, including the Network Policy Server (otherwise known as RADIUS), which is used to check the client's authorization to proceed with establishing the requested tunnel.

The remaining servers are added to the scenario as we enable the NAP services, including the Certification Authority, and as an example, a simple Windows Update Server to offer simple remediation to non-compliant clients.

Each of the servers are responsible for different roles in the overall solution. To get a brief understanding of what these are, let's take a quick look at their primary functions.

• NPS Server – This hosts the Network Policy Services and Network Access Protection services. This server can also be referred to as the Radius Server. When we extend the solution with support for Network Access Protection, we will add a second role to this server called Health Replication Authority (HRA), which will connect to our Certificate Server to request and Issue health certificates
• SSTP Server – This server hosts the actual Routing and Remote access installation. It will be configured to primarily offer SSTP-only tunnels, and it will connect to the NPS server for authentication and accounting (storing auditing) information, with the purpose of determining if the clients are indeed permitted to establish the tunnels
• CA Servers – These host PKI certificate templates and issues certificates based on these templates to our systems. It is also responsible for issuing the Health Certificates via the Health Responsibility Authority. We will need to actually create the templates for these Health Certificates as part of the deployment.
• Client Computers – These are domain-joined machines that will subscribe to the new SSTP service that we are implementing. SSTP is supported from Windows 7 and newer versions of the client. Non-domain-joined machines can of course work with SSTP, but for the scope of this mini-series I am focusing on domain-joined systems.

We now have the background and an idea of how the different servers will be used. Our next objective will be to implement this solution. Now would be a great time to get your environment ready and spin up some servers for the jobs we are about to face.

Free Tools from SolarWinds to Help Resolve Network Issues

How to back up the registry in server

How to step by step back up of registry in server 2008, if you are editing in windows registry make sure you have backup of registry. If any problem occurs you can safely restore your registry. You can backup Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008 by this method. Before create a backup you should login with administrator.

Follow these steps to backup registry:-

 1.      Click Start, and then click Run.

 2.      In the Open box, type "regedt32", and then click ok.

 3.      On the Registry menu, click Export.

 

4.      In the Save inbox, select a location in which to save the .reg file, type a file name in the File name box, and then click Save.

How to change the listening port for Remote Desktop

Remote desktop listening port 3389 is working by default in server 2008. You can change and define custom listening port for remote desktop. You can define port number between 1025 and 65535.

How to change the Remote Desktop listening port on Windows Server 2008?

You can change remote desktop listening port on server 2003, windows xp and windows 7 by same method.

1. Click on Start and type “regedit” or you can press windows key + R to lunch run and type “regedit”  and press enter  Registry Editor will open.

 

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber

3. Select PortNumber and double click on it then click Decimal.
4. Find the "PortNumber" subkey and notice the value of 00000D3D, hex for (3389)
5. Type the new port number, and then click OK.
6. Quit Registry Editor.
7. Restart the computer.

Now you can check form other computer start Remote Desktop Connection form start -> all programs -> accessories -> remote desktop connection.

Now type ip address with port of server (IP address:Custom port).

Troubleshooting 

Note When you try to connect to this computer by using the Remote Desktop connection, you must type the new port. Maybe you have to set the firewall to allow the new port number before you connect to this computer by using the Remote Desktop connection.

If you got this message “The remote computer requires Network Level Authentication, which your computer does not support. For assistance, contact your system administrator or technical support”

Using Google Public DNS

Configuring your network settings to use Google Public DNS

When you use Google Public DNS, you are changing your DNS "switchboard" operator from your ISP to Google Public DNS.

In most cases, the IP addresses used by your ISP's domain name servers are automatically set by your ISP via the Dynamic Host Configuration Protocol (DHCP). To use Google Public DNS, you need to explicitly change the DNS settings in your operating system or device to use the Google Public DNS IP addresses. The procedure for changing your DNS settings varies according to operating system and version (Windows, Mac or Linux) or the device (computer, phone, or router). We give general procedures here that might not apply for your OS or device; please consult your vendor documentation for authoritative information.

Note: We recommend that only users who are proficient with configuring operating system settings make these changes.

Important: Before you start

Before you change your DNS settings to use Google Public DNS, be sure to write down the current server addresses or settings on a piece of paper. It is very important that you keep these numbers for backup purposes, in case you need to revert to them at any time.

We also recommend that you print this page, in the event that you encounter a problem and need to refer to these instructions.

Google Public DNS IP addresses

The Google Public DNS IP addresses (IPv4) are as follows:

• 8.8.8.8
• 8.8.4.4

The Google Public DNS IPv6 addresses are as follows:

• 2001:4860:4860::8888
• 2001:4860:4860::8844

You can use either number as your primary or secondary DNS server. You can specify both numbers, but do not specify one number as both primary and secondary.

You can configure Google Public DNS addresses for either IPv4 or IPv6 connections, or both.

Changing your DNS servers settings

Because the instructions differ between different versions/releases of each operating system, we only give one version as an example. If you need specific instructions for your operating system/version, please consult your vendor's documentation. You may also find answers on our user group.

Many systems allow you to specify multiple DNS servers, to be contacted in a priority order. In the following instructions, we provide steps to specify only the Google Public DNS servers as the primary and secondary servers, to ensure that your setup will correctly use Google Public DNS in all cases.

Note: Depending on your network setup, you may need administrator/root privileges to change these settings.

Microsoft Windows

DNS settings are specified in the TCP/IP Properties window for the selected network connection. 

Example: Changing DNS server settings on Microsoft Windows 7

1. Go the Control Panel.
2. Click Network and Internet, then Network and Sharing Center, and click Change adapter settings.
3. Select the connection for which you want to configure Google Public DNS. For example:
   • To change the settings for an Ethernet connection, right-click Local Area Connection, and click Properties.
   • To change the settings for a wireless connection, right-click Wireless Network Connection, and click Properties.
   If you are prompted for an administrator password or confirmation, type the password or provide confirmation.
4. Select the Networking tab. Under This connection uses the following items, select Internet Protocol Version 4 (TCP/IPv4) or Internet Protocol Version 6 (TCP/IPv6) and then click Properties.
5. Click Advanced and select the DNS tab. If there are any DNS server IP addresses listed there, write them down for future reference, and remove them from this window.
6. Click OK.
7. Select Use the following DNS server addresses. If there are any IP addresses listed in the Preferred DNS server or Alternate DNS server, write them down for future reference.
8. Replace those addresses with the IP addresses of the Google DNS servers:
   • For IPv4: 8.8.8.8 and/or 8.8.4.4.
   • For IPv6: 2001:4860:4860::8888 and/or 2001:4860:4860::8844
9. Restart the connection you selected in step 3.
10. Test that your setup is working correctly; see Testing your new settings below.
11. Repeat the procedure for additional network connections you want to change.

Mac OS X

DNS settings are specified in the Network window. 

Example: Changing DNS server settings on Mac OS 10.5

1. From the Apple menu, click System Preferences, then click Network. 
2. If the lock icon in the lower left-hand corner of the window is locked, click the icon to make changes, and when prompted to authenticate, enter your password.
3. Select the connection for which you want to configure Google Public DNS. For example:
   • To change the settings for an Ethernet connection, select Built-In Ethernet, and click Advanced.
   • To change the settings for a wireless connection, select Airport, and click Advanced.
4. Select the DNS tab.
5. Click + to replace any listed addresses with, or add, the Google IP addresses at the top of the list:
   • For IPv4: 8.8.8.8 and/or 8.8.4.4.
   • For IPv6: 2001:4860:4860::8888 and/or 2001:4860:4860::8844
6. Click Apply and OK.
7. Test that your setup is working correctly; see Testing your new settings below.
8. Repeat the procedure for additional network connections you want to change.

Linux

In most modern Linux distributions, DNS settings are configured through Network Manager.

Example: Changing DNS server settings on Ubuntu

1. In the System menu, click Preferences, then click Network Connections.
2. Select the connection for which you want to configure Google Public DNS. For example:
• To change the settings for an Ethernet connection, select the Wired tab, then select your network interface in the list. It is usually called eth0.
• To change the settings for a wireless connection, select the Wireless tab, then select the appropriate wireless network.
3. Click Edit, and in the window that appears, select the IPv4 Settings or IPv6 Settings tab.
4. If the selected method is Automatic (DHCP), open the dropdown and select Automatic (DHCP) addresses only instead. If the method is set to something else, do not change it.
5. In the DNS servers field, enter the Google Public DNS IP addresses, separated by a space:
   • For IPv4: 8.8.8.8 and/or 8.8.4.4.
   • For IPv6: 2001:4860:4860::8888 and/or 2001:4860:4860::8844
6. Click Apply to save the change. If you are prompted for a password or confirmation, type the password or provide confirmation.
7. Test that your setup is working correctly; see Testing your new settings below.
8. Repeat the procedure for additional network connections you want to change.

If your distribution doesn't use Network Manager, your DNS settings are specified in /etc/resolv.conf.

Example: Changing DNS server settings on a Debian server

1. Edit /etc/resolv.conf:

   sudo vi /etc/resolv.conf

2. If any nameserver lines appear, write down the IP addresses for future reference.
3. Replace the nameserver lines with, or add, the following lines:
   For IPv4:

   nameserver 8.8.8.8
   nameserver 8.8.4.4

   For IPv6:

   nameserver 2001:4860:4860::8888
   nameserver 2001:4860:4860::8844

4. Save and exit.
5. Restart any Internet clients you are using.
6. Test that your setup is working correctly; see Testing your new settings below.

Additionally, if you are using DHCP client software that overwrites the settings in /etc/resolv.conf, you will need to set up the client accordingly by editing the client's configuration file.

Example: Configuring DHCP client sofware on a Debian server

1. Back up /etc/resolv.conf:

   sudo cp /etc/resolv.conf /etc/resolv.conf.auto

2. Edit /etc/dhcp3/dhclient.conf:

   sudo vi /etc/dhcp3/dhclient.conf

3. If there is a line containing domain-name-servers, write down the IP addresses for future reference.
4. Replace that line with, or add, the following line:
   For IPv4:

   prepend domain-name-servers 8.8.8.8, 8.8.4.4;

   For IPv6:

   prepend domain-name-servers 2001:4860:4860::8888, 2001:4860:4860::8844;

5. Save and exit.
6. Restart any Internet clients you are using.
7. Test that your setup is working correctly; see Testing your new settings below.

Routers

Every router uses a different user interface for configuring DNS server settings; we provide only a generic procedure below. For more information, please consult your router documentation.

Note: Some ISPs hard-code their DNS servers into the equipment they provide; if you are using such a device, you will not be able to configure it to use Google Public DNS. Instead, you can configure each of the computers connected to the router, as described above.

To change your settings on a router:

1. In your browser, enter the IP address to access the router's administration console. 
2. When prompted, enter the password to access network settings.
3. Find the screen in which DNS server settings are specified. 
4. If there are IP addresses specified in the fields for the primary and seconday DNS servers, write them down for future reference.
5. Replace those addresses with the Google IP addresses:
   • For IPv4: 8.8.8.8 and/or 8.8.4.4.
   • For IPv6: 2001:4860:4860::8888 and/or 2001:4860:4860::8844
6. Save and exit.
7. Restart your browser.
8. Test that your setup is working correctly; see Testing your new settings below.

Mobile or other devices

DNS servers are typically specified under advanced wi-fi settings. However, as every mobile device uses a different user interface for configuring DNS server settings, we provide only a generic procedure below. For more information, please consult your mobile provider's documentation.

To change your settings on a mobile device:

1. Go to the screen in which wi-fi settings are specified.
2. Find the screen in which DNS server settings are specified.
3. If there are IP addresses specified in the fields for the primary and seconday DNS servers, write them down for future reference.
4. Replace those addresses with the Google IP addresses:
   • For IPv4: 8.8.8.8 and/or 8.8.4.4.
   • For IPv6: 2001:4860:4860::8888 and/or 2001:4860:4860::8844
5. Save and exit.
6. Test that your setup is working correctly; see Testing your new settings below.

Testing your new settings

To test that the Google DNS resolver is working:

1. From your browser, type in a hostname (such as http://www.google.com/). If it resolves correctly, bookmark the page, and try accessing the page from the bookmark. If both of these tests work, everything is working correctly. If not, go to step 2.
2. From your browser, type in a fixed IP address. You can use http://18.62.0.96/ (which points to the website http://www.eecs.mit.edu/) as the URL.^* If this works correctly, bookmark the page, and try accessing the page from the bookmark. If these tests work (but step 1 fails), then there is a problem with your DNS configuration; check the steps above to make sure you have configured everything correctly. If these tests do not work, go to step 3.
3. Roll back the DNS changes you made and run the tests again. If the tests still do not work, then there is a problem with your network settings; contact your ISP or network administrator for assistance.

* Google thanks MIT for granting permission to use this URL for the purposes of testing web connectivity.

Diagnosing resolution problems

If you are encountering problems when resolving particular names, and want to verify whether the problem is with Google Public DNS, please try running the following diagnostic procedures. If you want to report a problem to the Google Public DNS user group, please copy and paste the results of the commands in your email. This information is vital to help us to identify the cause of the problem.

Step 1: Check to see if the authoritative nameservers are correct

If Google Public DNS (or any open resolver) has trouble resolving a site, or returns inconsistent answers, sometimes it is because the authoritative nameservers are having trouble. There are various tools and sites to help you check this.

Some users (and Google Public DNS engineers) have found intoDNS very helpful. For example, if you have trouble visiting www.example.com, visit intodns.comand enter example.com (the domain for www.example.com), or visit http://intodns.com/example.com directly.

Additionally, DNSViz is useful for diagnosing DNSSEC related issues. For example, visit dnsviz.net and enter example.com (the domain for www.example.com), or visit http://dnsviz.net/d/example.com/dnssec/ directly.

If these tools identify a nameserver configuration issue, please contact the owner of the nameserver to fix it.

If none of these tools finds any issue with the nameserver, continue to step 2.

Step 2: Verify that your client can communicate with the Google Public DNS servers

IPv4

Open a command prompt, and run the following command:

On Windows

tracert -d 8.8.8.8

On Mac OS X

/usr/sbin/traceroute -n -w 2 -q 2 -m 30 8.8.8.8

On Linux

sudo traceroute -n -w 2 -q 2 -m 30 8.8.8.8

If the last line of the output does not list 8.8.8.8 as the final hop, or if there are significant timeouts, there may be a network problem preventing you from contacting our servers. Please include the output of the command in any communication with the Google Public DNS team.

If the last line of the output does list 8.8.8.8 as the final hop, continue to step 3.

IPv6

Open a command prompt, and run the following command:

On Windows

tracert -d 2001:4860:4860::8888

On Mac OS X

/usr/sbin/traceroute6 -n -w 2 -q 2 -m 30 2001:4860:4860::8888

On Linux

sudo traceroute -n -w 2 -q 2 -m 30 2001:4860:4860::8888

If the last line of the output does not list 2001:4860:4860::8888 as the final hop, or if there are significant timeouts, there may be a network problem preventing you from contacting our servers. Try configuring Google Public DNS for IPv4 to diagnose whether the problem is due to IPv6 connectivity on your network. If IPv4 works for you, you may want to revert your IPv6 configuration and use Google Public DNS with IPv4 exclusively. Otherwise, please include the output of the command in any communication with the Google Public DNS team.

If the last line of the output does list 2001:4860:4860::8888 as the final hop, continue to step 3.

Step 3: Verify that Google Public DNS can resolve the selected hostname

In the following steps, replace www.example.com. with the name that you had difficulty resolving. (Put a period at the end of the name to avoid problems with domain suffixes and search lists.)

IPv4

At the command prompt, run the following command:

On Windows

nslookup -debug www.example.com. 8.8.8.8

On Mac and Linux

dig @8.8.8.8 www.example.com.

If the output shows an answer section with an A record for the hostname, then Google Public DNS is able to resolve the name. Check your settings to make sure your system is correctly configured to use Google Public DNS. If you are still unable to solve the problem, please include the output of the command in any communication with the Google Public DNS team.

If the output does not show an answer for the hostname, continue to step 4.

IPv6

At the command prompt, run the following command:^*

On Windows

nslookup -debug -type=AAAA www.example.com. 2001:4860:4860::8888

On Mac and Linux

dig @2001:4860:4860::8888 www.example.com. AAAA

If the output shows an answer section with an AAAA record for the hostname, then Google Public DNS is able to resolve the name. Check your settings to make sure your system is correctly configured to use Google Public DNS. If you are still unable to solve the problem, please include the output of the command in any communication with the Google Public DNS team.

If the output shows an answer section with an A (IPv4) record for the hostname, then Google Public DNS is able to resolve the name, but the host and/or its nameserver are not configured to return IPv6 results. If you want to verify that you are correctly receiving AAAA records, you can use the hostnameipv6.google.com as a generic test.

If the output for ipv6.google.com, or another host for which you are certain IPv6 records exist, does not show an answer, continue to step 4.

* Note: Google properties will not return AAAA records for all users. Please see the Google over IPv6 page for more information about whether your system qualifies.

Step 4: Verify that Google Public DNS can resolve the selected hostname without performing DNSSEC validation

Google Public DNS performs DNSSEC validation for all DNS queries by default. When a nameserver fails DNSSEC validation, Google Public DNS returns SERVFAIL. To verify whether Google Public DNS can resolve the hostname without performing DNSSEC validation, run the following command:

On Windows

Unfortunately, nslookup does not support DNSSEC and cannot help diagnosis here. Continue to step 5.

On Mac and Linux

IPv4

dig @8.8.8.8 www.example.com. +cd

IPv6

dig @2001:4860:4860::8888 www.example.com. AAAA +cd

If you cannot get a successful result without DNSSEC validation either, continue to step 5.

If you get a successful result, this usually indicates a DNSSEC misconfiguration at the nameserver. Please make sure that you have followed through step 1. If none of the tools finds any issue with the nameserver, continue to step 5.

Step 5: Verify that another open resolver can resolve the selected hostname

At the command prompt, run one of the following commands:

On Windows

nslookup www.example.com. 4.2.2.1
nslookup www.example.com. 4.2.2.2
nslookup www.example.com. 208.67.222.222
nslookup www.example.com. 208.67.220.220

On Mac and Linux

dig www.example.com. @4.2.2.1
dig www.example.com. @4.2.2.2
dig www.example.com. @208.67.222.222
dig www.example.com. @208.67.220.220

(The first two commands test Level 3's DNS servers. The last two commands test OpenDNS's DNS servers.)

If you are unable to get a successful result, this means that there is most likely a problem with the server you are trying to contact. Wait some time and try running the tests again. This may be a temporary problem on the server's side that will likely resolve itself eventually. If it does not, you should contact the owner of the server.

If you are able to get a successful result, there may be a problem with Google Public DNS. Please follow the directions here to report an issue to the Google Public DNS team, and include the output of the commands you ran in the report.

Switching back to your old DNS settings

If you had not previously configured any customized DNS servers, to switch back to your old settings, in the window in which you specified the Google IP addresses, select the option to enable obtaining DNS server addresses automatically, and/or delete the Google IP addresses. This will revert your settings to using your ISP's default servers.

If you need to manually specify any addresses, use the procedures above to specify the old IP addresses.

If necessary, restart your system.