Showing posts with label file sharing. Show all posts
Showing posts with label file sharing. Show all posts

Saturday, January 8, 2011

Windows 7 to XP FIle Sharing Problems

Recently, I had serious issues with trying to enable file sharing between my newly-installed Windows 7 laptop and my Windows XP SP3 desktop.

Windows 7's Network and Sharing Center

I have a home wireless network, where my Windows 7 laptop, on wireless, normally shares files perfectly well with my Windows XP desktop. Inexplicably, one day the capability to share files via wireless ended; I couldn't even ping my XP desktop from my 7 laptop let alone browse its file shares, whether by computer name or IP address. And yet, over a wired connection, file sharing performed flawlessly!

Here's a list of what I tried:
  • Updated drivers for network hardware.
  • Disabled Windows Firewall on both machines.
  • Verified internet connectivity from the laptop.
  • Ensured both PCs share the same workgroup name.
  • Verified connectivity over wireless, from the laptop to the router.
  • Completely reinstalled the TCP/IP stack on the Windows XP computer.
  • Deleted and recreated routes using the ROUTE command on both computers.
  • Reinstalled the Link Layer Topology Discovery (LLTD) responder on the XP box. 
  • Followed Microsoft's docs on enabling File and Printer Sharing under Windows 7.
  • Verified that shared folders on both PCs had proper permissions.
  • Removed remnants of Norton Internet Security with the Norton Removal Tool from the XP box, which I'd long since uninstalled but remnants of which still remained.
  • Followed Microsoft's steps for sharing files among different Windows versions, including rerunning the network setup wizards for each respective operating system.

In spite of all these steps, I still couldn't even ping the XP box from the 7 laptop, and I couldn't see the XP box from the 7 laptop in the network, although I could see, but not access, the 7 laptop from the XP box.

The solution turned out to be unexpected.

A few years ago, I replaced the factory firmware of my venerable Buffalo WHR-HP-G54 wireless router with DD-WRT, a free, open-source, Linux-based firmware which can be applied as a drop-in replacement for the manufacturer firmware, and can expand the features of your router to boot.

The firmware, as with most anything in IT, is evolving, and it'd been some months since I'd last updated the version of DD-WRT; it was v24 SP1 from around August, 2010, whereas the newest version is v24 pre-SP2. Some other DD-WRT users had reported issues sharing files on their own networks. DD-WRT itself has an option under Wireless => Advanced Settings called AP Isolation, which allows you to prevent wirelessly networked devices from interacting with one another, and presumably with wired clients, via the router (in my case, this option has always been disabled).

At this point, my options were exhausted, so I took the plunge and updated the DD-WRT firmware. Even though the latest version is technically still in beta, it seemed worth a shot; I've never had trouble since first installing DD-WRT, and the fact that it allows you to preserve your existing settings without wiping the router's NVRAM made it even more appealing.

The result? It worked! Suddenly, rather than being met with the dreaded System Error 53 when attempting to map a network drive letter from the laptop to the desktop or trying to browse to a shared folder via Windows Explorer, I got a prompt asking me to authenticate to the XP box using my credentials, and finally regained access!

If you haven't updated your router's firmware in a while, it might be worth a shot, particularly if you use DD-WRT as I do and have perhaps encountered what might be a bug in your current version of the firmware. 

If you still have the factory firmware, I'd strongly suggest you consider replacing it with DD-WRT or another like Tomato, which can not only offer your router and network more stability and performance, but also unlock features that the manufacturer might not even offer in their own relatively anemic firmware. 

Thursday, September 11, 2008

A Problem Sharing Files via Remote Desktop

While on vacation, I'd left a PDF on my home computer which I wanted to browse on my laptop on vacation. It's about 75 MB, not exactly feasible to email.

Both machines run Windows XP, however, and I figured I could use its ability to bring the resources of my laptop, including its hard drive, to the remote session on my desktop at home. I opened Remote Desktop, expanded Options, then clicked on Local Resources, and checked so that sharing all available drives was enabled.

No such luck, at first. Although I could see the laptop's CD-ROM drive present as \\TSCLIENT\D its hard drive, which should've been there as \\TSCLIENT\C was nowhere to be found! My laptop is a machine I normally use at work, and is part of their Active Directory and various group policies. I'm not privy to what the group policies specifically secure, but my guess was that some policy setting might be responsible for making my drive inaccessible via the remote session.

After some thought I remembered an old friend from the DOS days, the SUBST utility.

When diskettes were popular, some developers hard-coded their software specifically to look for the A: drive, with no option to select another. This was fine if you had a newer PC with a 3.5" drive as A:, but what if you'd upgraded some old clunker which had an older 5.25" drive as A:, and a newly installed 3.5" as B: instead? You'd be stuck having to crack open the case and swap around the drives... if not for SUBST.

I decided to try SUBST here to see if I could bring my laptop's hard drive to the remote session, masquerading as a different drive letter on \\TSCLIENT. Thus, I opened a command prompt and entered the following from my laptop:


This basically tells your computer to use a given substitute drive letter Z: to represent drive C: which is somewhat similar to using symbolic links in the *nix world. I opened My Computer, and now I could see a Z: drive, and clicking it brings up an Explorer window with the exact contents of my C: drive.

Now, I open Remote Desktop, and open a session to my home computer. Lo and behold, drive Z: appears in the remote session as well! I could then Paste my PDF file from my home machine to my laptop and browse it happily. Of course, this copy process takes a LOT longer than it might over a normal, unencrypted connection, but it gets the job done, and sometimes that's all that matters.