Enabling wireless on Windows Server 2008 - and eventually allowing Hyper-V guests to use it

A lot of you may probably ask why the need to enable wireless on a server operating system. Well, if you're like me who runs a server operating system on a laptop for testing purposes, there's a thousand and one reason why you would like to have it enabled. Now, since my Windows XP work-machine is now a virtual machine, I would need to have the wireless on my laptop enabled and working with Windows Server 2008. For this, you would need to install the Wireless LAN Service feature in Windows Server 2008. This article provides a detailed step-by-step procedure on enabling wireless on your Windows Server 2008. You just need to make sure that you have the appropriate Windows Server 2008 drivers for your wireless adapter or it won't work.

But my dilemma didn't stop there. I obviously don't want to access the internet via the Windows Server 2008 platform. That's what my Windows XP virtual machine is for. So what I did was to add an Internal virtual network using Hyper-V's Virtual Network Manager. This will create another network adapter on the host operating system - in this case, Windows Server 2008. I've renamed this WiFi-Guest-Bridge. Next, I've added a network adapter on the Hyper-V guest and mapped it to this virtual network. Once, I've done both of these, I've bridged the wireless network adapter and the WiFi-Guest-Bridge network adapter, thereby, providing wireless connectivity to my Hyper-V guest.

Keith Combs provided a step-by-step procedure (with screenshots) on how to configure wireless networking with Hyper-V guests in his blog

It is very important to name your network adapters accordingly as Windows does a real good job of using a generic naming convention (i.e. Local Area Network x) which adds confusion especially if you are dealing with a ton of virtual networks from within a single Hyper-V (or other virtualization) platform

Connecting HyperV guests to the local network even before installing Integration Services

So, I have finally had my hands on Microsoft Hyper-V. I've installed Windows Server 2008 with Hyper-V role on my laptop for creating virtual machines. I've decided to virtualize my Windows XP work-machine so that I won't have to worry about backups in case it got corrupted. What I had in mind was to simply create a virtual machine with all the work-related applications installed and create a network folder that maps to my host operating system's local drive, making it easy to backup - just backup the VM once for the base image and regularly backup the folder containing my files. Unfortunately, in order for you to take full advantage of networking and all sorts of stuff in Hyper-V guests, you need to install Integration Services. This, however, requires Service Pack 2 or higher on Windows XP machines. There are a few ways to install Service Pack 2 or higher on a Windows XP virtual machine running on Hyper-V: install using a CD, a USB drive or a network drive. I am not about to embark on any of the first two options since I try to avoid creating CDs for patches and service packs to save on disks (not to mention saving the environment a few non-biodegradable materials) whereas USB devices are not supported on Hyper-V, something that a lot of customers have been asking for. That leaves me with the network drive option. The solution: add a legacy network adapter. A legacy network adapter emulates the physical network adapter of the host operating system, thereby, not needing virtual machine drivers for the guest operating system. That is all I need to know to get Windows XP Service Pack 2 and higher installed on my virtual machine. I've added a legacy network adapter on my virtual machine and set it to the same IP subnet as that of my host and I have a virtual network between my host and my guest. This TechNet article describes configuring networking on Hyper-V

After managing to install Windows XP Service Pack 3, I can now install Hyper-V Integration Services and work on the usual networking stuff using the Hyper-V emulators and drivers. Since I no longer need the legacy network adapter, I removed it immediately after installing the service pack as I now have the option to add network adapters that can be recognized by the guest operating system.

You can read more about Hyper-V Integration Services from this article

Blank space between startup parameters

I was trying to figure out why my startup trace flags don't work. While it is mentioned in this Microsoft TechNet article about using semi-colons to separate one startup parameter from another, nothing was mentioned about the leading blank space in between defining the parameters. SQL Server MVP Erland Sommarskog recommended removing the leading blank spaces in between the trace flags and parameters like the one in the example below

-dC:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\master.mdf;-eC:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\ERRORLOG;-lC:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\mastlog.ldf;-T1204;-T1222;-T845;-T1262;-T2330

The best way to check if your trace flags are actually enabled during startup is to run the DBCC TRACESTATUS command or, as Erland suggested, looking at your SQL Server error log and note whether the trace flags are aligned with the other SQL Server parameters like the one below. Notice how aligned the startup parameters are (you can see that the - symbol are all aligned). A mere leading blank space would definitely cause them not to work.

2009-11-05 10:49:36.010 Server Registry startup parameters:
2009-11-05 10:49:36.010 Server -dC:\Program Files\Microsoft SQL Server\MSSQL\DATA\master.mdf
2009-11-05 10:49:36.010 Server -eC:\Program Files\Microsoft SQL Server\MSSQL\LOG\ERRORLOG
2009-11-05 10:49:36.010 Server -lC:\Program Files\Microsoft SQL Server\MSSQL\DATA\mastlog.ldf
2009-11-05 10:49:36.010 Server -T1204
2009-11-05 10:49:36.010 Server -T1222
2009-11-05 10:49:36.010 Server -T845
2009-11-05 10:49:36.010 Server -T1262
2009-11-05 10:49:36.010 Server -T2330

NT AUTHORITY\NETWORK SERVICE account in SharePoint Content Database

I have had the opportunity to assist a WIndows SBS MVP migrating Windows SharePoint Services 3.0 databases from SQL Server 2005 to SQL Server 2008 in a Windows SBS 2008 environment. He was following the steps outlined in this Microsoft TechNet article to move the content databases and configure them from inside SharePoint Central Administration when he hit a wall and couldn't move forward. When he was at the point where he is already pointing to the new content database, SharePoint started throwing an error. My first instinct was that it has something to do with permissions but I need to capture some activity before even doing anything. Apparently, SQL Profiler is not installed. I opted to change the Authentication mode from Windows to Mixed mode just so I can use a SQL Server login with the SharePoint configuration. After creating a SQL Server login for SharePoint to use, everything was back to normal. While I wasn't comfortable with using Mixed Mode authentication for SharePoint, I dug deeper to see what Windows account was being used thru the Application Pool from within IIS. It appears to be NT AUTHORITY\NETWORK SYSTEM - the default account when you install Windows SharePoint Services 3.0 in the same server as the SQL Server (this is a common setup with Windows SBS). What I did was to add the NT AUTHORITY\NETWORK SYSTEM account in SQL Server using the CREATE LOGIN command (you won't be able to do this in Management Studio as the account is not exposed) and, then, assign the db_owner role in the content database.

I went back to the SharePoint Central Administration after that to switch the configuration of the content database from using a SQL Server login to using Windows authentication. That did the trick.

Note that if you are moving your SharePoint databases from SQL Server 2005 to SQL Server 2008, whether within Windows SBS or a full blown Windows Server system, make sure you check the logins as they need to be moved as well for the SharePoint application to work. You can even use the transfer SQL Server logins script from Microsoft to do this