LLMNR – Another Reason to Upgrade

The ultimate goal of any network administrator is system uptime and the consistent availability of network resources . This should be easy, but alas DNS and WINS can be fickle creatures.

In the Windows 2000/Windows XP days, losing a DNS server usually meant a total lack of connectivity for a network.  WINS, while not nearly as important as it once was, was also the source of a lot of grief when it wasn’t working properly.

Now, we have IPv6 entering the scene which has created its own set of problems. WINS doesn’t support it at all, and DNS is not so keen on mixing the two types of addresses (although it is possible). The need for a technology to fill the gap was evident. There had to be a better way of keeping machines talking to each other on subnets.

The answer was LLMNR or Local-Link Multicast Name Resolution.  The RFC for LLMNR (#4795) arose from a need for a way to get hosts communicating with each other on a small network with zero configuration.  As the name implies, it is only on the local link, so this is not a substitute for DNS, but rather a complementary system that will improve connectivity. The technology works with both IPv4 and IPv6 and is included and enabled by default on Windows Vista, Windows Server 2008/R2 and Windows 7.

This feature alone, is reason enough for me to recommend an upgrade to customers. I have set up several small networks now with Windows 7 boxes and they were able to communicate and share files within minutes of being attached to the network. Browsing by hostname was reliable and easy.  Anybody that has done the same thing on a small Windows XP network will be all too aware of how easily name resolution can be broken. The bottom line is that this technology will save companies money as it will surely reduce calls from end-users with connectivity issues.

So, how does all of this magic work? It is not all that difficult actually.

The standard is based on a standard DNS data packet, but it sends out a packet that can be up to 512 octets in size in multicast on port 5535. IPv4 hosts will listen for these broadcasts at 224.0.0.252 or in the case of of IPv6 at FF02:0:0:0:0:0:1:3 .  Hosts will then respond and this information will be cached for use by the operating system allowing for fast name resolution.

The LLMNR cache will only be queried for information if a DNS query fails, and as mentioned above it should not be considered the primary form of name resolution but rather a complementary one. If one were to set the LLMNR cache with a higher precedence than the DNS cache, it could be used (inappropriately) as the primary resolution mechanism.

LLMNR is currently unable to propagate across routers, but it is interesting that in the actual RFC for LLMNR, there is considerable discussion with regard to enabling this in a wider, perhaps Internet level, fashion.

In Server 2008 (and presumably Vista/Windows 7) LLMNR can be disabled. I am not quite sure why anyone would want or need to do this, but should you find reason here is a link that will show you how it is done.

Anyway, I realize that this post was a little deep on the technical side, but I just wanted to highlight and perhaps promote this technology so that more people will make the switch to our new beautiful suite of stable, reliable and secure operating systems.

Cheers!

NTBackup for Server 2008 with Exchange

As the exploding popularity of our “Running NtBackup under Windows 7” would suggest, the emergence of our latest and greatest operating systems has also left a few holes that Microsoft has yet to plug.  As our readers have seen from our first article, it is very easy to get NtBackup running under windows 7, but more and more people are also realizing that there is a significant need for this on their Server 2008 and Server 2008 R2 boxes that are running exchange.

Currently, Microsoft does not include any product that adequately backs up exchange server on these platforms. The biggest issue with all of the schemes is the fact that logs are not cleared and these servers end up with a lot of wasted space from these.

Honestly, I don’t know when Microsoft plans on addressing this issue officially, but given the screaming we have heard, I would hope that it is soon.

Anyway, to get NTBackup working for exchange in this scenario is almost identical to our Windows 7 tutorial with a couple of small exceptions.

The process goes like this:

Copying the following binaries from a server 2003 install (C:\Windows\System32\) to a new location such as (C:\Program Files\NTBackup\):

• ntbackup.exe
• ntmsapi.dll
• vssapi.dll

Then, install the removable storage manager in server 2008 which can be found under the features menu in server manager.

Finally, go into an older server and copy esebcli2.dll from your server (C:\Program Files\Exchsrvr\Bin) and put it into your new location which in our case would be (C:\Program Files\NTBackup\):

Then, change the esebcli2 reg key from (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\BackupRestore\DLLPaths)

C:\Program Files\Micrsoft\Exchange Server\Bin\esebcli2.dll

to

C:\Program Files\NTBackup\esebcli2.dll.

Now go ahead and set up your exchange backup as a scheduled task just as you would have done in the past.

Please remember that this is more of a band-aid solution  and is totally unsupported by Microsoft. This will not work with tape drives, and it is very possible that future Microsoft service packs could break this functionality.  With that being said, it has been very solid in all of our testing thus far.

Cheers!

GPO Drive Mapping Issues

 

Apparently, mapping a drive using group policy and applied to a Windows Vista machine can result in users actually not being able to see their drives properly. While I won’t get into the reasons behind this too deeply, it is inherent in the security model that UAC relies on to function.

UAC breaks each successful logon into a split token with half of that being a standard user token and the other half being an elevated administrator token. When group policy maps drives, these are mapped under the elevated administrator token which results in the lower standard user token user being unable to see these drives as they have been theoretically mapped in a different session. 

Obviously, a simple fix would be to disable UAC, but anyone that is a loyal Slick IT reader knows our feelings on that.

The other solution is not entirely acceptable to me either as it could theoretically allow malware to redirect drive mappings, but for the time being it is the best fix we have.

Simply open regedit from the run line and modify the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections =(dword)1

I am not sure whether this problem affects Windows 7 clients, but I would guess that it does given the closeness in the UAC architecture of both Vista and Windows 7. If anyone can confirm this issue exists, please comment below!

Hope this helps!