Windows Vista, And Administrative Shares

Under Windows XP and earlier versions of Windows, any administrator of a server could gain access to any portion of any drive on the server, through the network. Even if no share was defined, any drive was always available, in its entirety, to anybody with administrative access.

This ability was known as an administrative share. Besides any explicitly defined shares, every server would have a "C$" share (and a "D$", etc, for additional drives). The shares weren't browsable - they wouldn't show up in Network Neighbourhood, and a server with no explicitly defined shares would even show up, at all, under Windows XP. But anybody with administrative access could map a share to "C$" and have access to the entire C drive, instantly.

Windows Vista has removed the administrative share from the default server configuration. Fortunately for many, this ability can be restored, with a simple registry entry.

For registry key [HKLM\ Software\ Microsoft\ Windows\ CurrentVersion\ Policies\ system], add a DWord value LocalAccountTokenFilterPolicy of "1". Then restart the computer.

>> Top

The Command Window, In Windows Vista

Many problems in Windows can best (or sometimes only) be resolved by commands entered in a command window. This is still true, on computers running Windows Vista. Under Vista, you will use the command window slightly differently from earlier versions of Windows.



A Command Window (the title may vary, widely)

• Click the Start button.
• Click All Programs.
• Click Accessories.
• Right Click on "Command Prompt".
• Left click on "Run as Administrator".
• Click the Allow button if it asks you for permission.
• A new window, with varying title, will open.
• Now type whatever you need, into the Command Prompt window, with the cursor positioned for you after the ">", and hit the Enter key after each command.
• Remember to allow for the Path, and the location of the program that you're running, if necessary.
• Close the window when convenient.

• Redirected Output
• Concatenated, Redirected Output

If you run ipconfig, for instance, as

C:\Users\YourAccount>ipconfig /all

you will get the ipconfig output there in the command window. This is good to look at briefly, but isn't very good to copy. Copying from the command window can be done, but will be hard to read.

Redirected Output
By redirecting the output, you can view it and / or copy it in a more convenient way, so it's suitable for posting online. Instead of typing

C:\Users\YourAccount>ipconfig /all

type

C:\Users\YourAccount>ipconfig /all >ipconfig.txt

With the latter command, instead of getting the ipconfig output there in the command window, all you'll see in the command window is another "C:\Users\YourAccount>". Then, type

C:\Users\YourAccount>notepad ipconfig.txt

and Notepad will open with the ipconfig output in a more viewable, and copyable, format.

(Note): If you get an error "Access denied" when you run a command and redirect the output, you may be attempting to redirect output into a file in a folder that you aren't permitted to write into.

Try redirecting into a folder that you are permitted to write into. If the command window opens in "C:\Users\YourAccount", just redirect there.

C:\Users\YourAccount>ipconfig /all >ipconfig.txt

then

C:\Users\YourAccount>notepad ipconfig.txt

Concatenated, Redirected Output
Do you need the output from two commands, run one after the other, presented in a text file? Be sure to concatenate the output from the second onto the first, don't overlay the first.

C:\Users\YourAccount>browstat status >browstat.txt
C:\Users\YourAccount>browstat listwfw pchucklan >>browstat.txt

Note the ">>" in the second command; that concatenates the output from the second command, after the output from the first command.

Finally, type

C:\Users\YourAccount>notepad browstat.txt

and Notepad will open with both browstat outputs, one following the other, in browstat.txt.

>> Top

AutoTuning In Vista Maybe Not Ready For Prime Time

As you surf the web, you will be in conversation with dozens of web servers, and each conversation might have different latency and stability issues. On a less stable (or low bandwidth) connection, a small Receive Window would be a good idea; on a more stable (or high bandwidth) connection, a larger window gives much better performance. With Windows XP and previous, you were limited to a single Receive Window setting, which would apply to all Internet connections, all of the time.

One of the long awaited features in Windows Vista was the ability for it to dynamically determine the Receive Window size, by individual connection. Receive Window Auto-Tuning is one of the many significant improvements in Windows Vista, in my opinion.

For a few owners of computers running Windows Vista, connectivity to the local network, or the Internet, may be problematic. Symptoms are very like the well known MTU Setting problem - some servers, some of the time, can't be contacted, or give poor performance. Copying files locally, from one computer to another, may be fast in one direction, and agonizingly slow in another.

But we know that your local network isn't running through a router, so how would an MTU setting affect your local connection?

The MTU isn't always the culprit in this case. If you have an older firewall or router, that doesn't support Windows Scaling (an essential component in Receive Window Auto-Tuning), you may have this problem. Apparently the lack of Windows Scaling can affect local performance too.

If you are faced by symptoms like an MTU setting problem, that involve a computer running Windows Vista, first try disabling Auto-Tuning. In a Vista command window (Run as Admin), enter

netsh interface tcp set global autotuning=disabled

or

netsh interface tcp set global autotuninglevel=disabled

Then shutdown and restart.

Try Internet access with Auto-Tuning shut off, and see if things stabilise. If they do, see if you can upgrade or replace your router. Check with the vendor, and see if a firmware update is available; if not, consider replacing the router. If your router is incapable of supporting Windows Scaling, it may lack other features that you will also enjoy.

Besides RWin AutoTuning, look at other possible problems with Windows Scaling, in Windows Vista and Scalable Networking.

If you see no improvement in your symptoms, turn Auto-Tuning back on before making other changes. Layered Troubleshooting principles suggest one change at a time.

netsh interface tcp set global autotuning=normal

or

netsh interface tcp set global autotuninglevel=normal

Note the lexicographical variations expressed, above. Some experts state that the relevant keyword is "autotuning", others state "autotuninglevel". There is also a confusion about the value for "autotuning" / "autotuninglevel", which may be either "enabled" or "normal". I suspect that there are two possibilities, "autotuning=enabled" and "autotuninglevel=normal", but I haven't found an authoritative reference, discussing the possibilities.

For more information, see

• Microsoft: (KB934430): Network connectivity may fail...
• MSDN Windows Core Networking: Receive Window Auto-Tuning on Vista

>> Top

Network Printing From A Windows Vista Computer

Long ago, a printer would be a device, attached directly to your computer. The earliest computers called a printer a "Line Printer", and let you connect your printer to a physical post on your computer. Some computers might have up to 3 physical ports - labeled "Line Printer 1", "Line Printer 2", or "Line Printer 3", abbreviated as "LPT1", "LPT2", or "LPT3".

Then network printing was made possible. You could setup a printer, locally attached to your computer on LPT1, and share it with your neighbours. You had YourComputer, and you could designate your printer to be shared as YourPrinter1. Similarly, your neighbour might have TheirComputer, and a printer shared as TheirPrinter1. If you wanted a second printer to use occasionally, you could setup your programs to print to LPT2 on your computer. You could redirect your LPT2 to print to "\\TheirComputer\TheirPrinter1".

Then somebody else started writing programs to print directly to "\\TheirComputer\TheirPrinter1", without involving "LPTn".

Now, accessing either a directly attached printer ("LPT1"), a network attached printer redirected (LPT2 redirected to "\\TheirComputer\TheirPrinter1"), or a directly networked printer ("\\TheirComputer\TheirPrinter1") involves specific code in the printer drivers, both in your computer (the client), and in the other computer (the server).

None of these options are magical, and not all printers will have drivers that will support all 3 ways of using the printer. Some drivers will claim to support all 3, but depending upon how your computer, and your neighbours computer is setup, one may work better than another. That's reality.

It appears that not all printer drivers, written for Windows Vista, support the old LPTn standard. If you can't get your network printer to work as "LPTn" redirected to "\\TheirComputer\TheirPrinter1", try bypassing the LPTn redirection.

1. Install the Vista printer driver on your Windows Vista computer.
2. During installation, you'll be prompted to connect the printer to your computer. Choose the option to proceed with installation without connecting the printer.
3. After installation completes, open the Printers wizard from the Windows Vista Control Panel.
4. Right click on the entry for the new printer, and choose Properties.
5. Go to the Ports tab.
6. Click Add Port, select Local Port, then click New Port.
7. For the port name, enter the network path and share name of your printer (ie "\\TheirComputer\TheirPrinter1").
8. Click OK, and verify that the new port is selected.
9. Click OK to close the printer properties.

(Update 10/30): If you're experiencing these, and similar problems with printing, try the Vista Compatibility, Performance, and Reliability Comprehensive Update.

>> Top

Determining The MTU To A Single Server

If you have connectivity to the Internet in general, but not to some servers, some websites load slowly, or if problems come and go, you may have a problem with the size of the messages that pass between you and the web site in question. The Maximum Transmission Unit, aka MTU, is a setting on your computer, that controls the size of the messages.

Depending upon what networks are accessed, between your computer and a given web site, the MTU that you can use will vary. If you make your MTU exceedingly small, you'll be able to avoid an MTU related problem, but loading a complete web page will take a long time. If you make the MTU too large, you'll see a variety of symptoms.

• Some web pages may load incompletely.
• Some web pages will give you a white screen.
• Some web pages may return the old familiar

  404 Not Found

• Some web pages may return another old favourite

  The connection has timed out.
  The server at xxxxxxx.com is taking too long to respond.

Determining your MTU will be a matter of patience and persistence, using the "ping" command repeatedly. You'll run "ping", as with all text based commands, in a Command Window.

Note here that if your computer is running Vista, you may also want to first try checking the setting for Receive Window AutoTuning.

I start by verifying that I have connectivity - period. I check the problem web site, in this example www.yahoo.com. You should check the web sites that you are having problems accessing, since different target servers may have differing MTU related problems.

C:\>ping www.yahoo.com

Pinging www.yahoo-ht3.akadns.net [209.131.36.158] with 32 bytes of data:

Reply from 209.131.36.158: bytes=32 time=13ms TTL=58
Reply from 209.131.36.158: bytes=32 time=14ms TTL=57
Reply from 209.131.36.158: bytes=32 time=14ms TTL=57
Reply from 209.131.36.158: bytes=32 time=14ms TTL=57

Ping statistics for 209.131.36.158:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 14ms, Average = 13ms

If I see anything different,

C:\>ping www.yahoo.com

Ping request could not find host www.yahoo.com. Please check the name and try again.

Then, I know that I have a different problem - maybe a DNS problem, or even LSP / Winsock / TCP/IP corruption.

Hoping that I'm seeing the first example above, I'll see what MTU I can use. I now know that the IP address, in this case, is 209.131.36.158. And I know that www.yahoo.com (in this case www.yahoo-ht3.akadns.net) will respond to me, with 32 bytes of data. But 32 data bytes is way too small.

So, I'll see what MTU I can use. The maximum that anybody can use is 1500, which includes a 28 byte header. You specify the amount of data, not including the header, in the ping command. Start with a data size of 1472.

And I'll ping using the IP address, so I don't involve DNS - deal with DNS problems, separately.

Now I ping with additional parameters, "-f" (lower case of "-F" = "Do not fragment"), and "-l" (lower case of "-L" = "Send buffer (data) of this size") options.

C:\>ping -f -l 1472 209.131.36.158

Pinging 209.131.36.158 with 1472 bytes of data:

Reply from 209.131.36.158: bytes=1472 time=83ms TTL=58
Reply from 209.131.36.158: bytes=1472 time=84ms TTL=57
Reply from 209.131.36.158: bytes=1472 time=87ms TTL=57
Reply from 209.131.36.158: bytes=1472 time=84ms TTL=57

Ping statistics for 209.131.36.158:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 83ms, Maximum = 87ms, Average = 84ms

That's a good return, and tells me that I don't have an MTU problem. If I had seen either of two other results

C:\>ping -f -l 1472 209.131.36.158

Pinging 209.131.36.158 with 1472 bytes of data:

Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 209.131.36.158:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

That's a fragmentation error from a router, or a server, telling me that my MTU is too large, and I set it to not fragment.

C:\>ping -f -l 1472 209.131.36.158

Pinging 209.131.36.158 with 1472 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 209.131.36.158:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

That could be a normal "This server isn't online" message. But since I did my baseline connectivity test (above) I don't think that this is the case. In this case, a router or server is simply dropping my ping request, as above because my MTU is too large, and I set it to not fragment. This is called a "black hole" router or server.

Both a black hole error (router or server simply dropping my ping) and a fragmentation error (router or server telling me that I have a problem) tell me that I have to reduce my MTU. I'll start by reducing it by 20.

C:\>ping -f -l 1452 209.131.36.158

Pinging 209.131.36.158 with 1452 bytes of data:

Reply from 209.131.36.158: bytes=1452 time=83ms TTL=58
Reply from 209.131.36.158: bytes=1452 time=84ms TTL=57
Reply from 209.131.36.158: bytes=1452 time=87ms TTL=57
Reply from 209.131.36.158: bytes=1452 time=84ms TTL=57

Ping statistics for 209.131.36.158:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 83ms, Maximum = 87ms, Average = 84ms

So 1452 is good, but maybe too small. So now, I'll try making it bigger, in steps of 2.

C:\>ping -f -l 1454 209.131.36.158

Pinging 209.131.36.158 with 1454 bytes of data:

Reply from 209.131.36.158: bytes=1454 time=83ms TTL=58
Reply from 209.131.36.158: bytes=1454 time=84ms TTL=57
Reply from 209.131.36.158: bytes=1454 time=87ms TTL=57
Reply from 209.131.36.158: bytes=1454 time=84ms TTL=57

Ping statistics for 209.131.36.158:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 83ms, Maximum = 87ms, Average = 84ms

Again, too small. Keep going up by 2.

... (later)

C:\>ping -f -l 1466 209.131.36.158

Pinging 209.131.36.158 with 1466 bytes of data:

Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 209.131.36.158:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

OK, 1466 is too large. Back down by 2 to 1464. Add the 28 byte header, giving me an MTU of 1492. This is a common value for the MTU, for many who can't use 1500.

Do you see the technique used? I found the MTU, by bracketing it. I started from a value too large (1472 data bytes), went down by 20 (to 1452, though I might have gone progressively lower) to a value too small, then up by 2 (to 1466) again too large. Then back down to the largest value where no error was seen (1464, in this case), an even number.

There's nothing magical about the sequence "Down by 20, Up by 2". You can use any sequence that pleases you. Try "Down by 60, Up by 20, Down by 2". Or "Down by 80, Up by 8, Down by 2". It's your computer. The point is to find the largest data size that you can successfully ping the target server with, then add the 28 bytes for the header, giving you the maximum MTU that you can use.

Note that I said "maximum MTU". If you find out that "www.yahoo.com" is accessible with an MTU of 1492, but "www.google.com" isn't, you'll have to repeat the process, from the beginning, using "www.google.com" as the target. Always target the problem web site.

Once you know what MTU to use, if your computer is running Windows 2000 or XP, you can set it using the free tool DrTCP, from DSLReports. Download DrTCP, into any convenient folder, and run it from there. You'll be changing the "MaxMTU" or "MTU" value under Adapter Settings. If you have multiple network adapters, be sure to choose the one that provides the Internet service.

If your computer is running Windows Vista, you can set the MTU by using the "netsh" command. If your computer is running Vista, you may also want to first try checking the setting for Receive Window AutoTuning.

The MTU isn't an efficient tuning factor, but you have to use it. It's part of IP networking, and your access to the Internet.

>> Top

The Weak Point In Your Internet Service - The Power

If you have a typical Internet service, you likely (hopefully) have 2 mysterious network devices, connected between your computer and your ISP's service.

• The modem (dialup, cable, or DSL) connects directly to the wire coming out of the wall.
• The router connects between the modem, and your computer.

Both the modem and router have power supplies - also known as "wall warts", because they have big plugs - 3 - 4" cube shaped, that make it hard to find a power outlet with room to plug it in. If you have these, you should know what I mean.

Recently, I thought that my router was slightly faulty. Several times / week, I was losing Internet service, even though the diagnostic lights on my DSL modem, and the router, were normal. Restarting both the modem and router would restore my service, but only until the next time.

I bought a universal power supply at Radio Shack for $15 or so, and swapped it for the power supply for the router for a while, but saw no improvement in the symptom. Service was going out too frequently - first a couple times / week, then daily, and finally multiple times daily. I put the vendor power supply for the router back in service, took the replacement universal power supply, and tried it on the modem, and the problem was solved.

It's summer time here in North America, and I'll bet heat sensitivities are part of the problem. If your Internet service has been acting up on you for a few weeks, and you've been pestering your ISP with no results, check your equipment, and start with the power supplies.

In this situation, the "universal power supply" is a key item. Each different electronic device - modem, router, or what have you, will have differently designed power requirements. Plug size, polarity, and voltage will differ from device to device. In my case, my modem uses 6V DC +, and my router uses 12V DC +. Being able to try the same power supply on both units, by simply changing the switch on the wall wart, made it possible for me to solve my problem.

When you setup the power supply for your modem or router, read the instructions carefully. Plug size (6 choices) is obvious. Polarity and voltage are not obvious, but getting them right is essential. In most cases, the wall warts from the vendor will have clearly labeled requirements, with both polarity and voltage obviously described. Carefully following the instructions with the replacement power supply, you can swap units in a couple minutes.

>> Top

Driver Problems Causing Intermittent Network Problems

Recently, on computers running Windows Vista, and occasionally on computers running Windows XP, you might start the process of copying a relatively large file from one computer to the other. The copy process starts out smoothly (ruling out complex issues like name resolution, or permissions, or even visibility).

Well into the copy process, with several Megs of file content copied, the process abruptly terminates with a monolithic message

The network location is no longer available

Well, what now? Did the other computer go off the network?

So, you start layered diagnostics.

• Check physical issues.
• Check name resolution.
• Check permissions.

And, you find no problem, with either the copy source, or target. Maybe you try copying in the other direction, or start the copy from the other computer, and sometimes this will make a difference.

Frequently, the cause of this problem will be simple. With Windows Vista having been on the market for a rather brief amount of time, the vendors of the various networking adapters are still developing drivers for their products. Either the vendor of the network adapter in your Vista computer has not produced a driver specifically written for Vista, or the driver produced has not been sufficiently tested.

So now, you contact the vendor, and ask about a newer driver. But go to the vendor, not to Microsoft.

>> Top