...
The first thought that came to mind: since we're running several Linux servers already on IPv6-only, would it be possible to run a Windows server also exclusively on IPv6?
Last year my intern Joris Claassen has proved that it was possible to run a basic VMware VSphere cluster on IPv6 only, and that included a Windows box as well. So things look bright.
...
To manage the server, Remote Desktop Protocol (RDP) is used, which supports IPv6 without any configuration.
...
Microsoft Update
Unfortunately the Microsoft Update servers are also available only on IPv4 
.
I set-up a dual-stack limiting HTTP proxy server, and added a number of regular expressions to allow Windows updates to happen.
According to Microsoft, Windows 8 will use IPv6, if available, to download Windows Updates. They will works with Content Delivery Networks (CDNs) to extend IPv6 support later. So at this time, for Windows Server 2008 R2, the update servers are accessible only through IPv4.
As a solution I set-up a dual-stack limiting HTTP proxy server, and added a number of regular expressions to allow Microsoft Updates to happen.
Details of the Details of the proxy and the Windows configuration process are described on a separate page.page.
As can be seen from the lists, several other URLs also need whitelisting, such as CRLs and OCSPs.
Windows Activation
Same story here. Activating Windows is done by several HTTP POSTs to URLs in the go.microsoft.com domain, which is not (yet) accessible through IPv6:
http://go.microsoft.com/fwlink/?LinkID=88342 | Processor Certificate URL |
| http://go.microsoft.com/fwlink/?LinkID=88343 | Machine Certificate URL |
| http://go.microsoft.com/fwlink/?LinkID=88345 | Use License URL |
| http://go.microsoft.com/fwlink/?LinkID=88344 | Product Key Certificate URL |
Since the proxy server was already in place, I just needed to add this domain to the proxy whitelist, and then the Windows activation succeeded.
As can be seen from the lists, several other URLs also need whitelisting, such as CRLs and OCSPs.
Secunia CSI
This tool monitors installed software for vulnerabilities. We have the corporate version CSI 6. This is a service that registers itself at Secunia to download patch lists, upload results, etc.
...
There is a nice and very clear PDF that explains SQL AnyWhere networking essentials. According to this document, SQL AnyWhere supports IPv6 from version 10, which is from date back to 2006. Version The docs for version 11 and 12 support it explicitlystate is even more explicitly with some examples. These docs came in handy because they list some special all the connection options that , which I needed.
Since we only have one instance of SQL Anywhere, which is running in a different network than the clients, I figured it didn't make much sense to implement the broadcast/multicast stuff that is needed for properly implement the service discovery. Instead , I hardcoded the server FQDN, which worked fine. After opening up TCP port 2638 the software worked 
...
After copying the PFX file to the Windows server, I ran mmc and added the Certificates snap-in. When it asked for who to manage certificates, I selected the "Local System" account, because I was running the snap-in as Administratorthat's what the SQL Server was configured to run as.
Expand: Console Root -> Certificates (Local Computer) -> Personal.
...
Since we now have a nice server certificate in the Windows Certificate Store, I figured I might as well use it to secure more services that run of off this machine. The most obvious service is of course the channel by which the machine is managed: Remote Desktop Protocol (RDP). Based on the docs, RDP does support SSL (TLS1.0). The installed certificate can be configured with the Remote Desktop Session Host Configuration. While at it, I also selected to only use SSL (TLS 1.0), and High Encryption level:
...
With the FreeTDS library now support supporting IPv6 connections, I went to the Nagios Exchange and picked check_mssql_health, which can do rather elaborate checks on all sort sorts of SQL Server properties.
...
Now that the server has an SSL certificate, it should be monitored so that we the admins get a warning when it is about to expire in about 3 years. The way I usually do this is by using a Nagios plugin to monitor a service that uses the certificate, and then pick the certificate expiration option of the plugin. For example the check_smtp plugin has this option:
...
Connecting to SQL Server on port 1433 does not do anythingyielded nothing, the handshake wasn't establisched, so that's a dead end for now. Connecting Connecting to RDP on port 3389 however happens with a nice TLS 1.0 handshake
...