The things that are better left unspoken : System Administration, Migration & Integration, Best Practices

Why rücksichtlos disabling IPv6 is a bad idea

Sander Berkouwer — Tue, 04 Jan 2011 18:40:00 GMT

Since Windows Vista, Microsoft has bundled and enabled IPv6 by default. This means Windows Vista, Windows 7 Windows Server 2008, Windows Server 2008 R2 (and all their derivate SKUs like Small Business Server) out of the box talk IPv6.

Note:
Server Core installations do not have IPv6 enabled by default and are the one notable exception.

The implementation chosen by Microsoft in these Operating Systems is a dual stack configuration. This means IPv6 exists besides IPv4.

Paul has blogged about his troubles with IPv6 and explained how to disable IPv6 in depth for Windows Server 2008 (and Windows Vista). Besides disabling IPv6 in the Network properties (also available through netsh) he walks through a series of firewall policies, registry values and network services ordering steps.

While most of these steps may be performed through Group Policy Policies and Group Policy Preferences, Paul didn’t mention these. (Converting the steps is easy) After reading the information in the blog post, you may have gotten the idea that disabling IPv6 throughout the network is a best practice and you need to go through your network to frantically disable IPv6 everywhere. The German people have a word for that kind of behavior: rücksichtlos. It roughly translates to English as ‘without looking back’.

I, however, recommend making these changes through Group Policy, so the changes can be easily reverted. I believe you’ll want to revert disabling IPv6 on your internal networks in the next two to three years.

Here are some of the reasons:

Dynamic short name resolution in the post-WINS era
Microsoft has deprecated WINS and introduced Global Names Zones (GNZs) and the Peer Name Routing Protocol (PNRP) for short name resolution. GNZs have some drawbacks (they need to be enabled per server, do not allow dynamic updates and records need to be created manually), where PNRP more resembles the dynamic nature of WINS short name resolution. PNRP requires IPv6. This makes phasing out WINS in a dynamic environment a matter of (re)enabling IPv6.
DirectAccess
Introduced with Windows 7 and Windows Server 2008 R2, DirectAccess allows corporate connectivity, transparent to the end-user. DirectAccess relies on IPv6 on the internal network. To access IPv4-only hosts, a NAT-PT device (like Microsoft’s Unified Access Gateway) is required. With $15 per connecting device (or user) through UAG, a business case is easily made to (re)enable IPv6 to hosts on the internal network that need to be accessible through DirectAccess.
Compliancy
In the near future, your company may be required to comply with regulations from governments, trade organizations or even business partners. September 28, 2010, already marked a step in that direction, when Vivek Kundra, the Federal Chief Information Officer (CIO), issued a directive to “expedite the operational deployment and use of IPv6”. This directive means US agencies need to support enterprise networks to operationally use native IPv6 (internet-facing applications) by the end of FY 2014.
Integrated security
In many secure networks, IPSec is used to isolate network traffic from eavesdropping. In the IPv4 world IPSec is bolted onto IPv4. In IPv6, IPSec is an integrated and mandatory component for IPv6. Therefore, when implementing a secure network, the logical choice is to work towards increased IPv6 traffic.
HomeGroup
While no self-respecting systems administrator will use the Windows 7 HomeGroup functionality for serious file sharing, if you want to use this functionality, you will need IPv6. HomeGroups rely on the Peer Name Resolution Protocol (PNRP) and as you read earlier, PNRP is an IPv6-only name resolution protocol. Serious admins, of course, will deploy Windows Server 2008 R2-based File servers with BranchCache and regularly back these up.

Of course, implementing IPv6 throughout the whole of the network isn’t an easy job. Many of you will run into the same walls Paul has run into. Working together with manufacturers, helps overcome these problems. Not just for your organization, but for everyone.

When you want to help improve IPv6 in Microsoft products, feel free to comment on the TechNet IPv6 blog or simply post a question or remark in the TechNet IPv6 Forum. Feel the need to share knowledge? Why not add to the IPv6 Survival Guide in the TechNet Wiki!

Active Directory Feature Requirements

Sander Berkouwer — Mon, 06 Dec 2010 10:12:35 GMT

Microsoft has included numerous features in Active Directory the last couple of years. Also, more and more technologies in products like Exchange Server, SharePoint Server and the Windows client (Windows Vista, Windows 7) have an Active Directory opt-in to store information in Active Directory.

All this bountiful integration, however, comes with a price. The price in the case of Active Directory comes in three guises:

Operating System (OS) on the Active Directory Domain Controllers (DCs)
Active Directory Domain Functional Level
Active Directory Forest Functional Level

The table below shows the dependencies Active Directory features, like Group Policy Preferences, the Active Directory Best Practices Analyzer and Read-only Domain Controllers, and Active Directory opt-in technologies, like BitLocker Recovery Key Storage and DirectAccess, have in regards to the list above:

Red Not Available, Orange Required Set, Green Available, Grey Depends

¹	This feature requires the Group Policy Preferences Client Side Extensions on Windows clients. When no Windows Server 2008-based Domain Controllers are in use, the Group Policy Preferences need to be management from a workstation with at least Windows Vista SP1.( Windows 7 recommended)
²	For Windows Server 2003 and Windows Server 2008-based Domain Controllers the Active Directory Management Gateway Service needs to be installed. When no Windows Server 2008 R2-based Domain Controllers are in use, the management features can be accessed from a Windows 7 management workstation.
³	Managed Service Accounts (MSAs) are virtual domain accounts that can be used on Windows 7 and Windows Server 2008 R2 in Active Directory environments running Windows Server 2003 and Windows Server 2008 Functional levels. Domains at the Windows Server 2008 R2 functional level provide native support for both automatic password management and SPN management
⁴	In environments with multiple Domain Controllers, this feature requires the Domain Controllers participating in this feature to be installed with at least Windows Server 2008.
⁵	Enabled by default when an Active Directory domain is first setup using a Windows Server 2008 Domain Controller. Workaround available for Windows Server 2003-based Active Directory environments. (More info)
⁶	Enabled by default when an Active Directory domain is first setup using a Windows Server 2008 Domain Controller with the Windows Server 2008 Domain Functional Level. Requires a Sysvol FRS to DFS-R migration when migrating from a Windows Server 2003 environment. (More info)
⁷	Requires the BitLockerTPMSchemaExtension.ldf schema extension on Domain Controllers running Windows Server 2003. Also, all Domain Controllers need to be running at least Windows Server 2003 with ServicePack 1. (More info)
⁸	Requires at least one domain controller and DNS server that is running Windows Server 2008 SP2+ or Windows Server 2008 R2. When UAG is used, DirectAccess can be deployed with DNS servers and domain controllers that are running Windows Server 2003 when NAT64 functionality is enabled.

SYSVOL FRS to DFS-R Migration Guide available

Sander Berkouwer — Thu, 03 Sep 2009 00:09:31 GMT

Microsoft has published a document titled “SYSVOL Replication Migration Guide: FRS to DFS Replication” to the Download server today. The 52-page 416KB weighing document outlines how to get from using File Replication Service (FRS) replication to Distributed File System Replication(DFS-R) for the SYSVOL folder. Since DFS-R offers more performance, scalability and reliability, migrating to DFS-R for SYSVOL is very beneficial, perhaps even a best practice...

You can download the Migration Guide here.

About SYSVOL and SYSVOL replication

Domain controllers use a special shared folder named SYSVOL to replicate logon scripts and Group Policy object files to other domain controllers. Windows 2000 Server and Windows Server 2003 use File Replication Service (FRS) to replicate SYSVOL, whereas Windows Server 2008 uses the newer DFS Replication (DFS-R) service when in domains that use the Windows Server 2008 domain functional level, and FRS for domains that run older domain functional levels.

To use DFS Replication to replicate the SYSVOL folder, you can either create a new domain that uses the Windows Server 2008 domain functional level, or you can use the procedure that is discussed in the Migration Guide to upgrade an existing domain and migrate replication to DFS Replication.

About the Migration Guide

The SYSVOL Replication Migration Guide details the steps to perform to migrate from FRS replication to DFS Replication. (DFS-R) The tool used is dfsrmig.exe, which guides system administrators through three states:

The Prepared state
The Prepared state configures the DFS Replication service to replicate a copy of the original SYSVOL folder. When all domain controllers reach the Prepared state, DFS Replication is properly configured and it has completed an initial synchronization. In the Prepared state, the replication of the SYSVOL shared folder still depends on the File Replication Service (FRS).
The Redirected state
In the Redirected state the live SYSVOL share (mapped to the old SYSVOL folder that FRS replicates) is mapped to the new copy of the SYSVOL folder, replicated by the DFS Replication service. From this point onward, SYSVOL replication depends on DFS Replication.
The Elimated state
At the end of the Elimated state, the FRS SYSVOL replica set and the old SYSVOL folder are deleted. Not only does SYSVOL replication depend on DFS Replication; all remnants of SYSVOL FRS replication are gone.

Of course the guide goes into detail on verifying states, verifying Active Directory health, rolling back failed steps, troubleshooting migration issues, transitioning management and of course contains a command reference for dfsrmig.exe.