Julius's profileJulius Ganns . netzkernPhotosBlogNetwork Tools Help

Blog


    April 30

    Windows Vista File Sharing sucks...

    Hi Everyone,
     
    I just spent 4 hours searching for a solution to one of the most annoying "features" of Windows Vista. I found a lot of people out there who might most likely have the same problem so I share this with you.
     
    I've got my own development server in the office, running Windows Server 2008 and a couple of notebooks and desktops at home. Because I needed to sync my OneNote Notebook to a fileshare on that server (syncing OneNote to SharePoint 2007 is somewhat painful at the moment), I connected my notebook using VPN (PPTP for the geeks) to our firewall (ISA Server for the geeks). Everything fine so far.
     
    I then opened my Windows Explorer and entered \\servername to access my file server through the VPN. Bang. Error:
     
    "\\servername is not accesssible. [...] the user name could not be found."
     
    The first thing an experienced network administrator should think in this moment: Uh, security, of course. ("user name", you get the point...) But there was no problem with security. File permissions, share permissions, username, password, everything was totally fine, because I already synced my notebooks several times before that day. I then figured, it might have something to do with the whole Active Directory / Kerberos infrastructure, invalid ticket, whatever. But that wasn't the case either.
     
    During my tests I discovered that when I entered \\ip-address, a username / password dialog popped up and I could log in - it didn't work automatically, because Windows couldn't be sure whether that address was a trusted ressource or not: LAN behind VPN, so no "local LAN IP address", even thought it was a private address range -and- no trusted extension (like mydomain.net) because I used direct IP to access the share.
     
    So I thought by myself: Just put "servername" to your hosts file to bypass the DNS request. Didn't work either. I then figured, why not try \\servername.mydomain.net (mydomain.net is a placeholder for your Active Directory domain that is severed by your primary DNS server - in my case behind the VPN tunnel). It worked. And: No username / password dialog, because "mydomain.net" is trusted as part of my domain / group policy settings.
     
    At that point, I should have been happy, but I cannot stand things that I do not understand. After searching for a couple of minutes, an idea popped up: As some of you might know, Windows still has two different ways to resolve names in a local area network: DNS and the old NetBIOS name lookup. It even uses two different ways to connect to a file share. The Pre-Windows2000 way by using SMB over NBT (which by itself stands for NetBIOS over TCP/IP, which means that the complete name is SMB over NetBIOS over TCP/IP... oh dear...) and the Post-Windows2000 way using CIFS (SMB over TCP port 445). Since the days of Windows 2000, DNS is the preferred way but NetBIOS still has the advantage that there is no need for a nameserver running in the network, receiving DNS registration requests from Windows machines and responding to queries. With NetBIOS, Windows just broadcasts his name or asks for anothers name using some strange combination of UDP and TCP requests.
     
    I used the nbtstat utility to query the name of my server and it didn't come up with a result - of course, because NetBIOS wouldn't send a broadcast through a dial up connection like my VPN (although I received an IP address in a private range from the gateway, but let's not discuss that right now).
     
    So, my guess in now the following. Whenever I used TCP/IP or DNS names (like IP address or a FQDN like servername.mydomain.net), Windows wouldn't ask NetBIOS to help resolving the name. But \\servername surely looks like NetBIOS could be helpful to the system. I don't know if Windows sents out two requests in a row, starting with a NetBIOS name resolution broadcast followed by a DNS request to the nameserver (or a lookup in my hosts file, which should've been fine to), but it looks that way.
     
    UPDATE:
    I just found the following link which explains the way, Windows 2000 does that name resolution thing. I guess, they haven't changed it since then and so my earlier guess seems to be right.
     
    UPDATE:
    By the way: Disabling NetBIOS over TCP/IP completely might not work for you if you have "older" servers or clients in your network, which do not support the new CIFS way of doing filesharing over TCP port 445 by encapsulating SMB packets. If you have those clients, you might have a real problem here, because if you disable NBT, you won't be able to talk to them at all. Try using the IP address instead. I tried to disable NBT on my VPN dial-up connection with very strange results - sometimes it worked, sometimes it didn't.
     
    The whole name resolution thing doesn't really explain the problem I had accessing the file share. And here I am stuck. The error "the user name could not be found." indicates some kind of access to the server. I will keep you updated with my endeavours.
     
    UPDATE:
    The "CIFS-way" of using SMB works completely without NBT and relies on DNS name resolution. So, I'm starting to think about the following possibility: Maybe Vista is trying to use the "old way" to connect to a file share if the name of the server looks like an old NBT name, so it uses the old "SMB over NetBIOS sessions"-way instead of CIFS (which is used to connect to "real" DNS names and IP addresses). A very interesting overview can be found on Timothy Evan's website. But I'm not sure, yet.
     
    UPDATE:
    Using SMB over NBT is of course using the "old" way of encapsulating SMB packets into NetBIOS packet and sending them through the NBT session port (TCP/UDP 139). Obviously this NBT packet has a header named "CALLED NAME", so the server is aware of the name you used to open the connection (see http://www.ubiqx.org/cifs/SMB.html#SMB.2.1). Maybe this is the problem... Using CIFS (SMB over TCP/IP directly), the service on the server side cannot know what we called him - we just access an IP address that may have been resolved earlier. But using NBT maybe the server is a little bit bitchy, if we do not use the name he wants us to call him...
     
    Looking forward to your comments and maybe if someone from Microsoft comes over this site, he or she can tell me, whether my guesses are correct or not. If they are correct, maybe that someone can tell me, who designed that thing so that I can go and kill him... (just kidding, of course... I surely would torture him at first. ;-))
     
    Take care!
    April 13

    iPhone - Visions about a new platform

    Everyone who knows me and had to listen to my "Why the iPhone will become a great mobile application platform" speach should take a look at the following video (I just finished watching it myself). I haven't had the chance to play around with the SDK until now, but I will definitely do that as soon as possible.
    Of course there is a lot of blabla and fancy words like "unbelievable" and "oustanding" in the whole presentation, but bottom line, Apple invented a device that for the first time has the chance to become a real mobile application platform everyone can use. Palm, Microsoft and RIM worked very hard over the last 8 to 10 years but at the moment, their products cannot compete against the usability and the "personality" of the iPhone.