In this blog post on IPv6, I’m going to cover:
- Configuring Servers (like Exchange, SharePoint, Web) with IPv6
- Best Practices on Naming IPv6 Servers
This is the sixth technical blog post on configuring IPv6 in a Windows networking environment. My previous posts include:http://www.networkworld.com/community/blog/ipv6-addressing-subnets-private-addresseshttp://www.networkworld.com/community/node/71252 http://www.networkworld.com/community/blog/setting-dhcpv6-dynamically-issue-ipv6-address http://www.networkworld.com/community/blog/configuring-microsoft-active-directory-suppor http://www.networkworld.com/community/blog/configuring-ipv6-routing-through-ipv4-microso
Basic understanding of IPv6 addressing, and acquiring an IPv6 address block
Configuring Static IPv6 addresses on Windows 2008 R2 servers, Windows 7 workstations, and configuring DNS
Setting up DHCPv6 to Dynamically Issue IPv6 Addresses in a Network
Configuring Active Directory to Support IPv6
Configuring IPv6 Routing through IPv4
In this posting, I’m focusing on application servers, like Exchange, SharePoint, Web servers, and the like.
Configuring Servers (like Exchange, SharePoint, Web) with IPv6
For the past 3-4 years, those of you who have configured Exchange 2007, Exchange 2010, SharePoint 2010 have run into quirks with IPv6, and up until now, for most IT Pros, the whole IPv6 thing was a bit of a mystery. We’ve known IPv6 was there on our Windows 2008 servers, we didn’t configure it, yet it was showing some IP address, and when there’s something going on with our network that we don’t understand, we just disable it. And that’s been the problem with Exchange 2007 and 2010 is that Microsoft has keyed services and dependencies on the IPv6 adapter port, so for those who disabled IPv6 would get errors like “MSExchangeTransport failed to reach status ‘Running’ on this server” or other odd Exchange errors. And when you searched TechNet for the fix, you would find that you would have to enable IPv6 and reboot the server and the problem went away, so that’s what most people did.
Now, the IPv6 address that you were getting (since you didn’t statically address your server with IPv6, nor had a working DHCPv6 server on your network) is what is called a Stateless Autoconfigured IPv6 address, randomly assigned to the adapter, but dependent on how your routers are configured in your environment, you may actually find that when you try to ping something over IPv6 (ie: ping xxxx -6), you get a communications error. I cover this in my blog post on DHCPv6, about Stateless Autoconfiguration, implementing otherconfig=true on routers, or manually setting router configurations. You can use this Stateless address, or better yet, actually get an official block of IPv6 addresses and statically configure (or dynamically configure using DHCP Reservations) your servers so you are managing your IPv6 addresses, address allocation, and configuration states.
So now that you know how to set actual IPv6 addresses to use (from my previous blog posts) and you know how to either statically (or dynamically) address servers and systems, you’ll now have Exchange 2007, Exchange 2010, SharePoint 2010, Web Servers, etc coming up with real routable, usable, pingable, http:-able addresses.
Which by the way, something I forgot to note in my blog post on DHCPv6 is that the minute you put in a DHCPv6 server and activate it, ALL IPv6 devices on the network that weren’t configured in the past (sitting on Dynamic DHCPv6 settings) will grab an IPv6 address from that first DHCPv6 server you setup. That’s good and bad, if you are reading and implementing IPv6 blog post by blog post, and you have enabled DHCPv6 in your production environment from my blog post 2-3 posts ago, you may find that ALL of your hosts now have a DHCPv6 issued actual IP address on the systems! The good thing about it, you are now “done”, all your systems have been addressed, and you are all set.
But if you really want to statically address your servers with IPv6 addresses, then you can go back to the systems and give them static IP addresses… After you staticly address your servers (see my blog post on Static addressing servers with IPv6 for more info), you can run IPConfig /RegisterDNS on the systems so that their new IPv6 address shows up in your DNS propertly.
That’s pretty much it on server configuration for IPv6. Servers will get IPv6 addresses from DHCPv6 unless you statically address the servers before setting up DHCPv6. Once the systems have an IPv6 address, you can ping the servers, http:// or https:// the IPv6 addresses on the servers.
Best Practices on Naming IPv6 ServersSo the next question people ask is whether they should give their servers dual names, so that a server has an IPv4 name and an IPv6 name. The answer really is “it depends”. By default, DNS will pull the name of the server and associate that name with both an IPv4 and IPv6 address. And Windows 7 client systems with IPv6 configured and working will first attempt to access a server using IPv6, then through Teredo, 6to4, and IP-HTTPS, and if it can’t access via an IPv6 method, it’ll access the system using IPv4. So from that basis, leaving the server name the same is a good fallback so that your users will know just 1 name of a server (ie: owa.companyabc.com, or sharepoint.companyabc.com) and the client system will walk through the process of connecting to the system with IPv6 and then fallback to IPv4.
There are times when you would want to give your server a specific IPv6 name so that you would make a DNS setting that differs whether a connection is IPv4 or IPv6 based. Remember by default, users will connect by IPv6 and then fallback to IPv4, so if the server has both an IPv6 or IPv4 address, just because you change the DNS name of the single server, users will connect to the server either as IPv6 or as IPv4. This is a good thing in normal practice so that you can support either configuration.
But if you want to leverage the security and connectivity capabilities of IPv6, then having a “frontend” server running IPv6 and another frontend server running IPv4 setup to similar “backend” data (ie: Exchange backend, or SharePoint backend) will provide you isolated IPv6 or IPv4 traffic based on the frontend server you point the user to. With IPv6, not only do you get a new IP addressing scheme, but actually IPv6 embeds IP Security (IPSec) encryption built into the every day transmission of data. For organizations looking to provide policy-based end to end encryption of content, IPv6 communications through something like Microsoft DirectAccess provides that type of functionality both inside and outside of the network.
An IPv6 connected user session can be identified when they are inside the network, allowing access to all content on a server, whereas the same user might have limited access to protected content when they are remote, as opposed to an IPv4 connected user that in this scenario would be blocked from accessing any content when remote because the remote user’s session state, end to end encryption, and policy-based access control is not assured (you can set all of this through policy).
With this in mind, we have helped organizations implement SharePoint with separate server infrastructures where SP.companyabc.com hit servers that were only available inside the network, but SPv6.companyabc.com hit IPv6 SharePoint servers that allowed a handful of users to gain remote access to content even when the users were remote. To setup this configuration, simply setup the backend (SQL) with both IPv4 and IPv6, and setup two separate SharePoint servers with one running just IPv4, and another running just IPv6, with separate DNS names for the different servers.
As for naming of the servers running IPv6, there are no defacto standards. Google is providing ipv6.google.com, Facebook is providing www.v6.facebook.com. To not make a URL too lenghtly (like ipv6.sharepoint.companyabc.com), just adding 6 or v6 to a normal URL provides users commonality of naming, so OWAv6.companyabc.com, SPv6.companyabc.com, CRMv6.companyabc.com, and the like.
http://www.microsoft.com/migration. Microsoft has a series of migration guides and migration tools that help you move content from older platforms to newer platforms, and maintain security and configuration states. The file migration tool they provide allows you to point to an old Windows 2003 file server, it grabs all of the files off the server, and moves the files, shares, ACL (security permissions), everything over to a brand new Windows 2008 R2 server making it really easy to get to Windows 2008 R2 for applications. Same with DHCP migrations, if you want to migrate DHCP off an old Windows 2003 (or possibly 2008) server to a DHCP server running Windows 2008 R2, there’s a migration tool up on that link that’ll move not only DHCP scopes across, but also moves over leases so that you can easily get from an old DHCP to a new DHCP with minimal (or no) interruption of service.
So that’s it on configuring applications for IPv6, there’s not much to it, and in fact for many organizations that may have put in a DHCPv6 server into their environment, they may have ended up with IPv6 on all of their servers after that task. Servers that are running on Windows 2003 should be upgraded to Windows 2008 R2 so that the latest IPv6 support is available for the systems. If you have Microsoft-based servers like File/Print servers, DHCP servers, or the like that you want to move from Windows 2003 or Windows 2008 to Windows 2008 R2, or you have physical servers on older Windows server platforms that you want to make virtual servers on Windows 2008 R2, take a look at
My next blog post will be titled “Planning Your Cutover to IPv6 for your Microsoft Windows Environment” where I’m going to provide the common business process of getting IPv6 implemented in a Microsoft Windows environment, from architecture, through setup, through final configuration. Basically a chicken and the egg approach where you can organize your migration strategy to an IPv6 environment.