I've been running Windows Server 2008 x64 on the server hosting this blog since September, and I've got a couple of thoughts on running 64-bit. I didn't plan to install 64-bit in the first place, but I had problems getting Win2k8 CTP 32-bit to install back then, so I tried 64-bit, which worked, and ended up with that. I've kept upgrading it, most recently to RTM last Sunday.

For some reason, that screwed up the network drivers for my MS Virtual Server machines, leaving them with no network. That combined with setting up a RAID1 volume for the OS on the server, made me reinstall the whole server instead of troubleshooting the drivers. And when I had the chance, I made the switch back to 32-bit.

So, why did I switch back to 32-bit?

First, I don't have more than 3 GBs of RAM on this server, so I don't really need 64-bit except for the "coolness" of running 64-bit.

Second, I've has some issues with application compatibility.
First out was DasBlog, the open source .NET blog engine behind this blog. They're using a date picker tool that didn't support 64-bit, which broke the admin interface. I was able to fix it by browsing forums, googling a bit and downloading the 64-bit version of the date picker. Not too hard, but still, it didn't work out of the box.

Number two was a bit bigger. I'm using SourceGear Vault (which is a very good tool, btw), as my source control system. It turns out that they support 64-bit (with IIS in 32-bit mode, I should say), but not on Windows Server 2008/Vista/IIS7. So I had no other choice than setting up a 32-bit Virtual Server just for this.

I haven't experienced number three first hand myself, but I know that (at least a couple of months ago) the SharePoint Server SDK was only available for 32-bit, whcih makes development a bit hard if you're running 64-bit.

Finally, it should be mentioned that I haven't had a single 64-bit driver issue, so things are going the right way.

So, my conclusion is: Unless you have more than 3 GBs of RAM, 64 bit is (apart from the "X-factor" of running 64 bit) little but just one more item on the list of possible causes if something's not working. I don't know about you, but I'd like to keep that list as short at possible.

While we could do the same thing in IIS6, IIS7 introduced a much more convenient way to create self-signed SSL certificates for your web sites, as described by ScottGu on his blog. However, there is one problem with the way IIS7 does this: No matter what you do (as far as I know), the certificate will be created with the local computer network name as the CN, Common Name (the site name) in the certificate. The Common Name should match the web site's DNS address to be valid, and often the DNS name is different from the computer name. This site's DNS name is for instance hansolav.net, while the name of the server hosting the site is LABBETUSS2008.

If your certificate CN does not match the web site address, most browsers will tell the users that you have a foobar SSL setup (even more foobar than not having a certificate from a trusted authority), and some (the newest version of FireFox, among others, I think) will completely refuse to open your site.

The good thing is that there's a way to fix it, and that is reverting to the way we had to do this in IIS6; using SelfSSL.exe from the IIS6 Resource Kit Tools. Below are the steps to to this:

1. Download and install the IIS6 Resource Kit Tools from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=56FC92EE-A71A-4C73-B628-ADE629C89499&displaylang=en
   Note: I don't know if the Resource Kit will install on Vista or Windows Server 2008, I had the Resource Kit installed on a Windows 2003 box and just copied SelfSSL.exe.
2. Look up the site ID of the web site you want to enable for SSL by selecting the "Sites" node in the tree in IIS7 Manager.
3. Run SelfSSL /N:CN=<your web site address (no http://)> /V:<how many days the certificate should be valid> /S:<site ID from above> [/P:<port, if not 443>]
4. Test your site.

Note2: It is possible that you will need to install the IIS6 compatibilty components for IIS7 in order for this to work - I don't know. You install them from the Add/Remove Windows Components dialog, or the Web Server Role configuation in Windows Server 2008.

Does anyone else know of an easier way to do this? I searched a bit without finding anything. What about adding an option to choose the CN in the "Create Certificate wizard", IIS7 team?

Vista SP1 RC and Windows Server 2008 RC1 is now available to MSDN subscribers! Vista SP1 will also be available as a public download from Microsoft sometime next week.

I downloaded and installed Vista SP1 yesterday, and everything went smooth. I haven't noticed much difference yet, but I haven't looked much either.

I also downloaded Windows Server 2008 RC1 and upgraded the server hosting this site (from RC0). I had some trouble initially, because the RC1 upgrade is blocked if you have SharePoint installed (probably due to the fact that they have removed the SP role from Windows and are providing it as a separate download). I had SharePoint installed, but the server Role had disappeared, so I couldn't uninstall it! After some thinking I solved it by getting the separate SharePoint download, which offered me an uninstall option when I ran it.

Below is a screenshot of my potentially risky remote upgrade of the server hosting this site. It's the second time I've upgraded it successfully over Remote Desktop, so it seems to work

...does not work, it looks like.

I upgraded my installation (hosting this site) of Windows Server 2008 from Beta 3 (June CTP) to RC0 today - over remote desktop! My server is located in a locked server room, so I wanted to try a remote upgrade before asking for the key, and it went well. I extracted the ISO onto the hard drive, started the installation from remote desktop and selected the upgrade option. It turns out that the Windows setup doesn't (luckily) show any dialogs where you have to click next during the upgrade. I had a continuous ping trace running and observed the server going up and down a few times, before it completed the installation and enabled incoming remote desktop connections again. Pretty cool!

But, back to the title. Everything worked well after the upgrade, except SQL Server 2008 July CTP. I kept getting error messages from Management Studio when connecting saying "No process is on the other end of pipe", and this led me into thinking that I had a certificate problem. See this blog post.

But, it turns out that this wasn't the issue. The issue is that Windows Server 2008 RC0 ships with a version of SQL Native Client that is newer than what the SQL Server 2008 July CTP supports, so it just doesn't work. This thread says it will be addressed in the next SQL Server CTP. Until then you have two options:

• Use Management Studio 2008 from another machine to administer SQL Server. This will probably still give you problems if you run SharePoint on the same server, at least my SharePoint installation gets the "No process in end of pipe"-error
• Install SQL Server 2005

For now, I'm going with SQL Server 2005 while I'm waiting for the next CTP of SQL Server 2008. I read somewhere that it is expected in the next one to two weeks. It will probably contain lots of new stuff, like spatial data support, Intellisense in Management Studio and so on. Looking forward to it!

Any of you tried that? Well, if you have, you probably encountered some interesting behavior. At least I did.

I'm developing a web application here on the SQL Server Team @ Microsoft that needs to run in an application pool that runs with the identity of a domain user account. The application also uses Windows Integrated Authentication.
For some reason I was not able to access the website from any other place than the local machine, even though I am an admin on the machine. I just kept getting login-boxes, which is equivalent to access denied. After three login attempts it resulted in "HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials."

When using Integrated Authentication, IIS is by default configured with two authentication methods: Negotiate (Kerberos) and NTLM, with Negotiate as the primary that is tried first. After burning off a few hours trying to figure this out, I found that in my setup, Kerberos authentication fails, and IIS will not let you access the web site. The same is also true if run the App Pool as a local user, and the server running IIS are not using a WINS or DNS name. It looks like the easiest solution is to disable Kerberos and force IIS to use NTLM. See the MS TechNet article below for how to do that. The blog link below describes another solution to this problem which may be preferable.

So now it works, thanks to these links:

http://dallas.sark.com/SarkBlog/cboland/archive/2005/11/28/2267.aspx

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/7258232a-5e16-4a83-b76e-11e07c3f2615.mspx?mfr=true

We are doing a development project in C# in school now, and in we are (of course ) using a build server with CruiseControl .NET for continuous integration of the project. While we (the developers) and the build server are located on the university network, the test server is located in a local company's intranet. To make the build process really nifty, I decided to make it deploy the finished build right onto the test server. To do that I had to set up a VPN connection from the build server and into the company network. And this is were the fun starts.

So I went straight for it to test it - created a new VPN connection, typed in the user name and password and clicked connect. Without clearing out the "Use default gateway on remote network" checkbox. Through remote desktop. Guess what happened? Yup, the server disappeared from the internet and my RDP-connection froze. Did I mention that the server is located in a locked room, to which I don't have the key?

Then the fun started - trying to get hold of the key. After about an hour I got hold of the key and disconnected the VPN-connection.

Please clear this box before connecting to VPN from a remote server.

Later I configured the VPN connection using Routing and Remote Access (RRAS), which is a much better way of doing it...