A common paradigm in the technology field is, “If you’re not using it, uninstall or disable it.”   While that can be an excellent way to reduce the surface area of a system by removing components that you don’t need and may never use, there are going to be times when that paradigm doesn’t turn out to be the right decision.   An excellent example of that is IPv6.  Nearly every week when I’m onsite with a customer, the topic of “what should they do about IPv6” comes up, and I end up saying the same thing time and time again.   I’ve been saying it so much that I’ve previously written the remaining contents of this post as a document that I’ll give out as a reference whenever the topic has come up.   So finally, I decided to post it so that more people can benefit from the information and take corrective actions in their systems before my phone rings at 3AM and I find myself getting on an airplane.

On the properties of the NICs, removing the checkbox binding the IPv6 protocol to the network interface should not be cleared as it will cause IPv6 to become unbound from the network interface.   In addition, the Link-Layer Topology Discovery Mapper I/O Driver and Link-Layer Topology Discovery Responder protocols should also not be uninstalled from the systems.   While this is often done with the desired effect being to disable IPv6 on the systems, this behavior does not have that effect on the systems.   This action only unbinds the IPv6 protocol from the physical network interface while still leaving it enabled within the Operating System, which continues to attempt to utilize IPv6 for communications and can experience unexpected and unpredictable behavior without IPv6 bound to a physical network interface.   Link Layer Topology Discovery provides device discovery via the data-link layer to determine the topology of the subnet.   While the results obtained from LLTD is similar to those obtained via the ARP protocol, LLTD provides additional information.

Versions of the Windows operating system beginning with Windows Vista prefer the use of IPv6 over IPv4.   However, if IPv6 is not utilized within the network infrastructure, leaving IPv6 enabled on the systems will not have an impact on internet communications, web browsing, etc. as the NIC would only be configured with a Link Local address, which is a non-routable address and can only communicate with systems on its same subnet, bounded by a router.   IPv6 is an integral part of the operating system and several Windows components rely on it.   IPv6 should be left enabled.   While KB 929852 describes the use of the DisabledComponents registry key to disable specific IPv6 components, most environments should leave all IPv6 components enabled.   The tunnel interfaces can be disabled while leaving the native IPv6 components enabled by using a value of 0x1 for the registry key, however, as discussed below, blocking the tunneling protocol at the point of network egress will be a more effective way to prevent the tunneling interfaces from establishing connections with their particular relay on the Internet.

The checkbox binding IPv6 to the network interface should remain checked on all systems running Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, and any future version of the Windows operating system.

Another type of IPv6 address that may be present on the systems are either 6to4 or Teredo addresses.   These are tunneling protocols that are used to allow for connection to an IPv6 network over an IPv4 routing infrastructure.   These 6to4 and Teredo addresses are routable addresses and will be registered in DNS.   

When the IPv4 address is in the public IPv4 range, a 6to4 adapter would be leveraged to communicate to IPv6 over an IPv4 infrastructure.   This is done via IP Protocol 41 and will be calculated without any external network connectivity.  Systems with a 6to4 address will be able to communicate to other systems within your IPv4 network that also have 6to4 addresses, but do not use this address to communicate to external IPv6 resources as the default 6to4 server utilized by Windows systems is only a 6to4 Server and not also a 6to4 Relay.  The easiest solution to prevent the establishment of 6to4 connections is to either set the DisabledComponents registry key or leverage the netsh.exe command to disable the 6to4 adapter.   (http://en.wikipedia.org/wiki/6to4)

When the IPv4 address is in the private IPv4 ranges and when 6to4 is unavailable when a system is in a public IPv4 range, a Teredo adapter would be leveraged to communicate to IPv6 over an IPv4 infrastructure.   This is done via UDP packets at port 3544 to the Teredo server teredo.ipv6.microsoft.com.  Systems with a Teredo address will be able to communicate to other systems within your IPv4 network that also have Teredo addresses, but do not use this address to communicate to external IPv6 resources as the default Teredo server utilized by Windows systems is only a Teredo Server and not also a Teredo Relay.  The easiest solution to prevent the establishment of Teredo connections from the internal network is to block UDP 3544 at the point of network egress.  (http://en.wikipedia.org/wiki/Teredo_tunneling  &  http://tools.ietf.org/html/rfc4380)

The 6to4 & Teredo adapters can also be disabled by running the following from an elevated command prompt:
netsh int 6to4 set state state=disabled
netsh int teredo set state type=disabled

The MSPress book Understanding IPv6 (Second Edition) is a great read for learning more about IPv6.  

Additional Resources:
Disabling IPv6 Doesn't Help, by Sean Siler, IPv6 Program Manager
http://blogs.technet.com/ipv6/archive/2007/11/08/disabling-ipv6-doesn-t-help.aspx

Development and Deployment of IPv6: Good for Internet, Technology
http://technet.microsoft.com/en-us/library/bb726954.aspx

Link Layer Topology Discovery Protocol Specification
http://www.microsoft.com/whdc/connect/Rally/LLTD-spec.mspx

929852 - How to disable certain Internet Protocol version 6 (IPv6) components in Windows Vista, Windows 7 and Windows Server 2008
http://support.microsoft.com/kb/929852

IPv6 Blog
http://blogs.technet.com/ipv6

IPv6 for Microsoft Windows: Frequently Asked Questions
http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx

The Cable Guy - Support for IPv6 in Windows Server 2008 R2 and Windows 7
http://technet.microsoft.com/en-us/magazine/2009.07.cableguy.aspx

While teaching the Windows Server 2008 Directory Services workshop this week a student asked me, “How can I grant access to the DNS MMC to a user that I don’t want to put into the DNS Admins group because I only want them to be able to view the contents of the zones?”   He mentioned that he had been looking for this solution off and on for about a year or so.    As it turns out, I’ve been asked a similar question by a few other customers in the past.   To help make it easier for others to find this same solution, I figured that it would be a good topic for a blog post.

DISCLAIMER:   This information is provided as-is with no warrantee expressed or implied.   To the best of my knowledge, the techniques included are not endorsed by the product group and nor supported by Microsoft.

Traditionally, to grant a user the ability to use the DNS Management MMC (DNSMgmt.msc) to view a Windows DNS server, the user had to be a member of an elevated group such as DNS Admins, Domain Admins, or Enterprise Admins.   The following steps will discuss how to grant access via the DNS Management MMC to a user that is not a member of these groups, nor has any elevated rights on the domain controllers with which DNS is installed.   These steps have not been validated against a DNS server that is not a domain controller.

I began by creating a user named Joe User (JLOLAB1\JoeUser) and granted the user rights to logon to a member server via RDP.   This member server has the DNS Management MMC already installed.   When Joe User launches the MMC and attempts to connect to the Domain Controller, he receives the error “Access is Denied” as illustrated below:

Clicking Yes brings me the MMC:

As you can see, he is unable to see any information about the DNS Server.

To allow this user the ability to access the DNS Server, I created a group that I called “DNS MMC Read” and placed the user into this group.   I then performed a logoff/logon and verified with “whoami /groups” that the user contains “DNS MMC Read” in its token.

At this point I begin the process of granting access to the MMC to this non-admin user.  

1. I open the DNS Management MMC as a Domain Admin user.
2. Right-click the server name and click “Properties”.
3. Move to the “Security” tab.
4. Click “Add” and enter in the group name “DNS MMC Read” and click “OK” to close the account selection window.
5. You will then observe that the group now has the checkbox “Read” selected.  
6. Click “OK” to close the Properties window.

What happened in the background is that it granted this group Read permissions onto the object CN=MicrosoftDNS,CN=System,DC=lab1,DC=jlo:

Now when JoeUser connects with the DNS Management MMC he sees the following:

This non-admin user is able to view the contents of the Forward and Reverse Lookup Zones.   He is able to view the properties of the server, but receives an “Access is Denied” error when attempting to change those settings.   He also receives an “Access is Denied” error while trying to view the Event Logs of the DNS server.    These “Access is Denied” errors are expected because the user only has read access to the zones, but not any additional permissions to the server.

I hope you found this post informative and can assist you with managing your DNS infrastructure.

(NOTE: IP Addresses changed to protect the innocent)

I was onsite with a customer recently who asked me a question:

“What is 2002:836b:0F1E::836b:0F1E and why am I seeing it?”

I explained that this is a 6to4 address and is automatically assigned to the client because they use a globally routable IPv4 range for their IPv4 address range. I pull up calc.exe and in a couple of moments ask if the IPv4 address of his system was 131.107.15.30. After having a brief shocked look, his response was:

“But wait, I’ve looked at KB 929852 and it says that I can disable IPv6 by unchecking the checkbox for IPv6 on the properties of the NIC. So why am I seeing an IPv6 address?”

“Of course,” I say, “but how close did you read 929852?” We pull up the KB and look at the start of the “More Information” section (included below):

IPv6 can be disabled either through the DisabledComponents registry value or through the check box for the Internet Protocol Version 6 (TCP/IPv6) component in the list of items on the Networking tab for the properties of connections in the Network Connections folder. The following figure shows an example.



The DisabledComponents registry key affects all interfaces on the host. However, the check box on the Networking tab affects only the specific interface. The DisabledComponents registry value does not affect the state of the check box. Therefore, even if the DisabledComponents registry key is set to disable IPv6, the check box in the Networking tab for each interface can still be checked. This is expected behavior.

There is one very fine point often overlooked in that second paragraph, it is the second sentence: “However, the check box on the Networking tab affects only the specific interface.” (emphasis mine) What is meant by “affects only the specific interface” is exactly what it says, it unbinds IPv6 from ONLY that particular interface, leaving IPv6 enabled within the IP stack. The result of this is that for systems with a non-Private IPv4 address, a 6to4 address will still be assigned to the system. It also means that other aspects of IPv6 are still enabled and running within the system.

So if your end goal of clearing the checkbox was to disable IPv6 across the entire system, you did not meet your goal. Don’t believe me? Run “netstat –ano” from an elevated command prompt and you’ll see your system listening to the unspecified IPv6 address (::). If you insist that you must disable IPv6, use the DisabledComponents registry key as defined in KB 929852. However, as the KB article says, “We (Microsoft) do not recommend disabling IPv6.”

After this discussion as to why he needed to use DisabledComponents instead of just clearing the checkbox, he asks me how I knew what his IP address was. I explained that the 6to4 address is of the format 2002:WWXX:YYZZ::WWXX:YYZZ where WW, XX, YY, ZZ are the hex representations of the octets of his IPv4 address. We looked back at calc.exe and changed it to “Programmer” under the View menu. This allows us to select Hex and enter 8b, clicking on the Decimal (Dec) radio button displays that the decimal value of 0x83 is 131. Repeating this, we determined that 0x6b is 107, 0F is 15, and 0x1E is 30. So 131.107.15.30 would be 2002:836B:0F1E::836B:0F1E.

This got us back to the discussions about how they can prevent 6to4 Addresses from being generated on their systems. There are 4 methods which could be used to disable IPv6 on their systems: The DisabledComponents key with a value of 0x1, The DisabledComponents key with a value of 0xffffffff, Group Policy, or manually via use of the netsh command. We discussed the pros & cons of these methods. Setting DisabledComponents to 0x1 will disable all tunneling adapters (ISATAP, 6to4, Teredo, IP-HTTPS) on the system, but leave the system capable of leveraging Native IPv6 addressing once they begin deploying it within their infrastructure; setting DisabledComponents to a value of 0xffffffff will disable all of IPv6 on the systems (except for the loopback adapter), but will have to be changed to 0x1 or deleted when they begin an IPv6 deployment within their infrastructure; Group Policy allows for any of the tunneling adapters to be disabled independent of the others and provides the most flexibility for the future of their infrastructure; Utilizing netsh to disable 6to4 would be a manual process which would not easily scale across multiple systems and would be a manual process to re-enable in the future.

We setup a GPO so that they could begin testing the behavior of their systems with 6to4 being disabled via GPO. The setting we defined in the GPO was “6to4 State” with a value of “Disabled”. We then re-selected the IPv6 checkbox on the properties of the NIC on the system we targeted the GPO to. The setting was located under:

Computer Configuration –> Policies –> Administrative Settings –> Network –> TCPIP Settings –> IPv6 Transition Technologies

As illustrated above, the state of the other Transition Technologies can also be controlled via GPO.

After this GPO applied to the computer, the computer was behaving as they had originally intended them to be behaving; there was no 6to4 Address present. Because we had replaced the IPv6 checkbox on the properties of the NIC, the system did have a Link Local Address (one which begins FE80::/64), but these are not routable addresses and do not register in DNS.

If you MUST insist on disabling portions or all of IPv6, consider either using Group Policy to disable the individual Transition Technologies which you wish to have disabled or leverage a value of 0x1 for the DisabledComponents key to disable all Transition Technologies. NOTE: Avoid deploying a value of 0x1 to mobile workstations if they will be leveraging DirectAccess as this will prevent them from having the ability to connect to the DirectAccess server as they would have leveraged these tunneling mechanisms for that connection; if it is only the 6to4 Addresses which are of a concern while on the corporate network, then disable only these adapters via GPO to these clients so that they can still leverage ISATAP, Teredo, and IP-HTTPS to connect to DirectAccess. If you MUST insist on disabling ALL of IPv6, then use 0xffffffff for DisabledComponents; the same caveat for mobile workstations attempting to leverage DirectAccess applies here as well.

The customer then asked me what can they do to prevent visiting computers which are on their network from being able to connect to DirectAccess servers from their own networks. We discussed how the connections to a DirectAccess server will connect to their own DirectAccess server via IPv6 and that they would require either a Native IPv6 address or a Transition Address to connect to their DirectAccess infrastructure. Since the customer’s network isn’t yet providing Native IPv6 addresses, they only have to worry about people leveraging Transition Technologies. Both ISATAP and 6to4 utilize IP Protocol 41 to encapsulate the IPv6 packets as payload of the IPv4 packets, so blocking outbound IP Protocol 41 at their network egress points will prevent ISATAP and 6to4 connections originating from their network. Teredo utilize UDP packets at port 3544, so blocking outbound UDP 3544 packets will block Teredo traffic from originating from their network. IP-HTTPS encapsulates the IPv6 packet as SSL encrypted payload of HTTPS packets (port 443), since their network allows for unfiltered outbound SSL traffic, IP-HTTPS connections could originate from their network. We discussed utilizing things such as either a separate VLAN for guests/vendors which doesn’t route to the corporate network and leveraging IPsec within their corporate network to provide domain isolation as some possible methods of protecting the internal network from unmanaged computers (but that sort of planning is another topic for another day).

Before I left, the customer asked me how they’ll be able to re-check the IPv6 checkbox on their systems once they’ve deployed a GPO with their desired settings for IPv6. This was one of those times when I did not have good news to give a customer. There is no programmatic way that I know of to directly determine the value of the checkbox and no programmatic way to toggle the value of the checkbox. They will be manually placing the checkbox back over time as they connect to systems and update their system images to no longer have the checkbox unchecked.

While I did include this link on one of my previous posts, I’m including it again because I’ve seen many questions asking about Microsoft products and their support for IPv6. Here is the link to the Common Engineering Criteria:

Microsoft Common Engineering Criteria Overview
http://www.microsoft.com/CEC/en/us/cec-overview.aspx#data-ipv6

Microsoft Common Engineering Criteria Scorecards (IPv6 Support is under "Data Center and Enterprise Readiness")
http://www.microsoft.com/CEC/en/us/cec-scorecards.aspx?display=tech#

When I was younger, I heard a phrase “The cobbler’s children have no shoes” and similar things which implied that frequently, people within a particular industry are less likely to want to utilize their skills as home when they’re not working.    I was reminded of this a few weeks ago while I was on vacation.   I logged onto my work computer and noticed that I was unable to connect to work via DirectAccess.   Upon further investigation, I noticed that the IP Helper Service wasn’t running and that there did not appear to be any settings for DirectAccess present on the computer.  

“No Problem,” I thought, I’ll just connect via VPN, run “klist –li 0x3e7 purge” to flush my computer’s Kerberos tokens, and refresh GPOs via “gpupdate /force”.   Instead of success, I see the following:

Since I was able to accomplish what I needed over VPN and wanted to get back to not working, I decided to just leave the computer connected over VPN, cross my fingers, and look back on it in a few days.   Things always work better after being left alone, right?   The next day, I rebooted and tried again, but saw the same message.   This left me with a difficult decision, spend vacation time troubleshooting my own computer, or turn it off and deal with it later.   I turned it off.

A few days later, I powered on the computer again and found that things hadn’t changed yet.   I connected via VPN and tried another “GPUPDATE /force”, and found that things were still no different.   This time I had some time that I could spend on troubleshooting the problem and decided to take a look.   In the Event Logs, I see an SCECLI 1704 telling me that the GPOs applied successfully.  

Frustrated that I’m getting an error in one window while another tells me that everything is fine, I do what anyone troubleshooting while on vacation does…I powered off the computer and went back to not working.

A couple of days later, I powered on the laptop and found the symptoms had not yet changed.   This time, I decided that I needed to fix the problem.   I opened up a browser and went to bing.com so that I could do a search for the error.   Between the first three results, I was able to find my solution.   I found two hits to TechNet articles which described the same message, but had a variable listed where mine had “LocalGPO”, and I also did not have the event log entries that they referred to.   Those entries were:

http://technet.microsoft.com/en-us/library/dd392577(v=ws.10).aspx
http://technet.microsoft.com/en-us/library/dd392529(WS.10).aspx

The other link was more helpful and contained the exact error, including that the problem was with “LocalGPO”.   That post was: 

It directed me to the file registry.pol under C:\Windows\System32\GroupPolicy.    I looked into that directory and found the following:

Since I was using an elevated command prompt, I tried a rename of the registry.pol file followed by re-applying of the GPOs:

Finally, the GPOs applied successfully.   I was then able to start the IP Helper service and it stayed running.   I looked and saw that my computer was now connected to work via DirectAccess. 

So after trying the tried and true troubleshooting techniques of rebooting and ignoring the problem, I was finally able to do a web search and had my answer in just a few minutes.  Maybe I should have started with that.   Maybe next time.   But spending time troubleshooting computers at home, even work computers, is just not how I wanted to spend my time-off.   The old adage is true:   The Cobbler’s children have no shoes.

One of the great things about the Premier Field Engineering group at Microsoft is that we have a fairly aggressive hardware refresh cycle for our engineers in the US.   To keep us with a solid experience as road warriors, our laptops are refreshed approximately every 2-years.   When luck is on our side, we can even manage to get a refresh a couple of months early.   

This was the situation for me this time around, my previous laptop hits its 2-year mark in December of this year, but I was pleasantly surprised when in early October I get an e-mail letting me know that I was due for a refresh and to please reply back to the e-mail and let them know which of the 5 models to choose from that I had decided on.   My first reaction was, “But my current laptop is working out fine for me, well OK, the battery is past its shelf-life and can’t hold a charge as long as it used to, but other than that, it is still rock solid.”   For about 2 weeks I held off on replying because I was still happy with my current machine.   But then I realized that Microsoft is little different than any other corporation and that if I didn’t utilize the allocated budget for my laptop within the quarter it was budgeted for, I’d likely be using my current laptop for quite awhile.    So I chose the HP EliteBook 8530w from the list of choices that are available to my team.   It arrived on Friday afternoon.

My first task after unpacking it was to burn a Windows 7 x64 ISO file to a DVD so that I could do the install.    My current machine is running the x86 installation of Windows 7 and I had decided that the next time I installed the OS on my laptop, I’d give x64 a shot.   Much to my surprise, the early refresh allowed me a chance to do this.   Last week I had finally gotten around to updating my Hyper-V host with Windows Server 2008 R2 and had been pleasantly surprised to find that fully functional color print drivers for my HP Color LaserJet 2840 were included in-box, so I knew that going with x64 for my laptop would still allow me to print in color while at home.   That printer was a big splurge for me a couple of years ago and the lack of x64 drivers had been holding me at x86 for quite awhile to avoid turning it from a nice networked Printer/FAX/Scanner into a giant paperweight.   While onsite with customers, I find many of them making the same x86 decision on their print servers for the same reasons; lack of x64 drivers for some printer models.  

So as evening approaches, my son & I are watching Star Wars – Episode I and as he drifts towards sleep I head upstairs to grab the laptop and the DVD I burned.   I boot to the DVD and begin the install while the cast is still on Coruscant, by the time they’re back on Naboo, the install is finished.   Enough of the major hardware devices had in-box drivers, and by the end of my visit to Microsoft Update, I had nearly all of the rest.   The only 2 devices that didn’t have drivers after that were the media card reader and the hard drive shock protection device.   But both of those were easy to get.   I was happy that the wireless drivers were in-box because the docking station was on back-order and I was doing the install without a wired connection.   Even the SmartCard reader worked fine.   We have the option of logging into our workstations with the SmartCard on the back of our badges, and I’ve gotten in the habit over the past year of doing that instead of using my username/password.  

Once the OS was installed, I downloaded Forefront Client Security and the VPN software so that I could connect to work and join the domain.   I installed the Office 2010 Technical Preview, Streets & Trips 2010, and a few other applications that I use for work.  I configured BitLocker and set it to leverage the TPM chip + a PIN.   Nearly everything is working as well or better than it did on my old x86 Windows 7 laptop.   While I didn’t install it that first night, I’ve also installed Windows XP Mode so that I could install the software to allow for network scanning using my LaserJet 2840.   The Vista version of the software did not consistently function as expected on the x86 installation of Windows 7 and I had previously resorted to this method for being able to scan receipts when I get back from customer visits.   And they do not yet have x64 drivers, so XP Mode provides me with the ability to continue to benefit from running x64 Windows 7 while still utilizing applications that work best under older versions of Windows.    I leverage Microsoft Office 2007 and the Microsoft Document Imaging application from Office to do my scanning from within XP Mode.

With the exception of XP Mode, I had finished the installation of the software on Friday night before going to bed.   On Saturday evening after my son went to bed I was able to give the new installation its first real test of practical use…Writing the ADRAP report from my visit earlier in the week.   While I had heard from other engineers that they had experienced no issues running the tools for this under x64, I didn’t want to get too comfortable with the installation if I was going to then have to re-format and re-install with x86.    I was thrilled to see that with the x64 OS and the x64 installation of Office 2010, I was able to complete my reports for the customer without any issues.   It was because of that success that I took the time this morning to complete the move-in process by installing XP Mode and configuring that VM.

As I said at the beginning, I’m still happy with my previous laptop.   That Lenovo T61P w/4GB of RAM has served me well.   I’m now debating on if I will keep it as x86 Windows 7 or if I will install Windows Server 2008 R2 and use it as a mobile Hyper-V host.   I may utilize Boot From VHD and have it do both.  But I see another 2-years of good experiences ahead of me with this HP 8530w.   It looks like I’m 3 for 4 on work-issued laptops that have gotten a thumbs-up by me; my original Toshiba M1 that I was issued in March ‘04 ran great and I almost didn’t want to replace it (but its video card has no Vista drivers), another model which I was less thrilled with, the T61P which couldn’t come fast enough to replace its predecessor, and now my 8530w.