Archive for November 2010


SharePoint 2010 Farm on Hyper-V

We’ve looked at the SharePoint 2010 install and some virtualization of our demo\dev environment but we’ve never hosted a multi-server farm on in Hyper-V. We may not finish this but let’s see if we can get a domain built and intstall a two-server farm on one Hyper-V host with 8Gb RAM.

First, our new best friend, Matt, covers the hardware and software requirements pretty well here. Some of the cool things he tells us is that we ought to be okay with less than 6Gb RAM and 100 Gb ROM.

Then we’ve also got this great PowerPoint from our new best Czechoslovakian friend, Michael, here. Michael outline the multi-farm options nicely. His RAM specs total about 30Gb but he’s building a production farm. Maybe we can trim those to fit on our skimpy little 8Gb.

So, like you know we like, starting from scratch, we have:

  • Dell PowerEdge T310.
  • QC Xeon 2.5 Ghz Processor.
  • 8Gb RAM
  • 2×232 Gb Harddrives
  • Windows 2008 R2 x64.

A couple of interesting points here:

  • We’ve enabled remote acces on the System Properties Remote tab. This will let up use our router’s port forwarding page to forward RDP traffic from the internet to our host using the RDP port 3389. Now, we can RDP from anywhere on the internet (even you) by using our IP address in the RDP Computer field. Sure, this is a threat vector but we’re not putting anything out here we don’t want to give away, except the damm HP printer driver I had to hack out of their install file.
  • The Windows Firewall is On Public and Private.
  • Our host is a member of our local work group.
  • IE Enhanced Security is Off.
  • The server is running the Application Server, File Services, Hyper-V, and Web Server roles.
  • We’ve installed MagicISO which will run on our x64 host. After it’s installed, you simply right click on the start bar tray icon and select mount and point it to the Win2k8 .iso file.

Building the Domain Contoller:

We open the Hyper-V Manager and click on the New link in the Actions panel on the left. Then, using the wizard, we set the following:

We install our VM files on a separate drive from our OS and then give it 512 Mb RAM. The Windows Server 2008 specs are here.  This says that 512 Mb RAM is the minimum for the server. Since this will only support our domain controller tasks, we’ll make it the minimum.

We connect the server to the LAN by selecting the Local Area Connection – Virtual Network option.

We give it a hard drive and provide 15 Gb disk space and tell it to create a hard drive.

Then, we tell it to boot to the .iso file mounted on our MagicDisk drive.

The wizard will complete and then you can start the VM in the Hyper-V Manager. When it starts it will be loading Windows. In the interest of conserving resources, we select the Server 2008 R2 Standard Full Installation.

Now, it turns out, we could have selected the Server Core Installation. When that is installed, you don’t get a desktop but simply a command prompt on top of blank blue wallpaper. Our new best friend, Daniel, has a great explanation of this process here. To avoid having to learn a bunch of new command line details, let’s forego this option for now, perhaps to revisit it in the near future.

Once the desktop appears, we get the Initial Configuration Tasks page. We can activate Windows and set the time zone. Then we can skip Networking and Computer Name for a second and go to Enable Updates. This will currently upload and install 55 updates and require a restart. It will take several minutes.

Now, looking at Networking, I have to wonder why they used the gerund and not just the noun, “network.” Regardless, we can go back to Daniel’s site,, where he explains many of the domain controller\active directory issues pretty clearly.

First there’s the network configuration. On the Initial Configuration Tasks we click Configure Networking. The Network Connections folder opens and shows us our LAN connection. We right click and select Properties. Then we select the IPv4 item and click the Properties button.

Here, we give the server a static IP address on the LAN and point it to our router as a default gateway. At this point, we can browse to internet sites. Doing so, we see we want to kill the IE Enhanced Security Mode by opening Server Manager and clicking on the link in the Security Information section. We aslo want to go ahead and rename our new server something intuitive instead of the gobbledygook default name. It’s best to do this before setting up Active Directory so you can avoid some more gobbledygook in some silly dialog boxes later.

Next, on Initial Configuration Tasks, we click on the Add Roles link. On the Server Roles tab, we’ll check the AD Domain Services option. This will tell us we need to install the .Net Framework 3.5.1 Features. We click through the wizard to install.

Now, when we open Server Manager, we can see that the Active Directory Domain Services link has a red X icon beside it. When we click on that link, we get to the ADDS page with an i icon and a link to run dcpromo.exe.

This will open the ADDS Installation Wizard. We forego the advanced mode installation and click through to select a new domain in a new forest. We enter the fully qualified domain name. We set the Forest Functional Level to Server 2008 R2 eschewing the option to later add down rev domain controllers.

The wizard will finish by installing the services and then report that no DNS was found and offer to install it. It will warn about creating a delegation but we can ignore that and click Yes. If gives us file locations that are fine and then wants a restore password. We get a summary and the wizard installs DNS and begs for a reboot.

Once we reboot, we enable remote desktop in Server Manager. We can close the Hyper-V VM window and RDP to the IP address. We can also add our new domain name to our host file using the IP address and that will let us RDP to the domain name.

The Database Server:

For the database server, the Windows install is a repeat of the domain controller except we give it 2,560 Mb RAM and a 60 Gb hard drive. When Windows comes up, we configure networking by giving it an IP address but then pointing DNS back to the domain controller’s IP address. At this point, the browser should connect to the internet.

Then we click on Provide computer name and domain. We rename the computer and tell it we want to join our new domain. This will require us to enter the password we used for the administrator on the domain controller. We get a Welcome to the Domain dialog and then have to reboot.

When we try to log back in, we can see that our Domain\Administrator user can log into the new database server. This is the first real evidence that our domain is working. We can then go on with the updates and provide for remote access.

On the Hyper-V host, we work our MagicDisk to unmount the Windows Server DVD and then mount the SQL Server DVD. Then we go back to our new server and run Setup.exe.

A dialog box complains that we have to enable the .NET Framework Core role. It looks like it will add the role for us. We click OK and then, after a moment, we get the SQL Server Installation Center. On the Planning tab, there’s a semester’s worth of reading. On the Installation tab, we click New Installation

The SQL Server 2008 R2 Setup wizard opens and tells me it’s checking for Setup Support Rules. We pass seven and fail none. So far, so good. We click OK.

It wants a product key. You’re on your own here.

I accept the terms and it rolls to the Setup Support Files page. We click Install.

Once this guy runs, we get another scorecard. We’ve passed 10, failed 0 and have one warning about our firewall. Hmmm…

Well, no problem, the dialog box refers us to this page at MSDN where it talks about firewall configuration. Then we get some help from our new best friend, Ashsish, here.

What we ought to be able to do is follow these steps and then rerun our Setup Support Rules and get the warning to go away. Let’s see.

We run Firewall.cpl. Click on the Allow a program…link. We get the Allow Programs dialog. We click Add another program… and see that only the SQL Server Installation Center option is available. Domainis checked so we click OK  and rerun the Setup Support Rules. Still we get the error.

The MSDN page suggest running WF.msc and adding an inbound rule for port 1433 using TCP. Done. We still get the error.

Looking at the error in detail, it’s simply warning about the firewall, not reporting that a specific SQL Server action is not working. So, I’m going to back both of my mods out and proceed with the SQL Server install. Back on the Setup Support Rules wizard, we click Next.

We get the Setup Role page. Since we don’t want just the default service accounts, we’re going to select the SQL Server Feature Installation option. Then we’re going to create our service account on our domain controller as noted in the Service Account section below.

On the Features Selection tab, we select everything except Books Online and SQL Server Replication. We get a check that we passed six and ignored eighteen. Whatever.

We’re rolling with the default installation on Instance Configuration. Disk space requirements check out okay.

On Service Configuration we’re going to select the Use the same name… and then use our SVC_SQLServer account. Odd, here is won’t take the format so I revert the the Domain\SVC_SQLServer.

On the Database Engine tab, we select Mixed Mode and enter a password for the sa account. We also add the current user who is our domain adminstrator, and our DB Server’s local administrator. That’s three users plus an sa account.

We add the same three users to the Analysis Services Configuration tab.

We check the Install the SharePoint integrated mode default configuration option on the Reporting Services Configuration tab.

Let’s pass on the error reporting. We get a 6-0-2 on the Installation Configuration Rules, skipping only the instance name and the SQL Server 2000 installation action, whatever that is.

It says we’re Ready to Install. Let’s  take a snapshot first and then find out.

While it’s running, I go to the domain controller and try to ping the db server; request time out. This is apparently a firewall issue as noted by our new best freind, Jeff, here. Sometimes it’s great to get a simple answer to a simple question. Ping, both ways, is good.

@Success!!! Your SQL Server 2008 R2 installation completed successfully.

We go back to the installation page and it suggest we check for updates; there are none.

It also tells us that the sample databases are not installed but are available here from CodePlex. We’ll need some sample data so let’s take care of this straightaway. I’m going get the 2008 Adventure Works executable but I’m going to download it to my host box first and then install it by mapping a drive from my DB server to the host. The instructions on COdePlax say you have to activate FILESTREAM and it provides instructions. There’s also alot of noise about the database installer being flakey. When I see flakey ahead, I like to get a snapshot so we’re good where we are now so we’ll get a snapshot and then, if we really get any flakiness, we’ll rollback. The executable extracts files and opens an install wizard. We select only the AW LT 2008 and click install. It runs, completes and then, in SSMS, we can see the top 1000 rows of the customer table.

No, in order to leverage the SQL Server Reporting Services for SharePoint we may have to come back and install SharePoint on this server but we’ll wait to figure that out. We should at least be able to go ahead and create our web server.

SharePoint Server

We’re going to call this our web server, our index server and also a server for all our applications.

For the SharePoint server, the Windows install is a repeat of the others except we give it  1,536 Mb RAM and a 40 Gb hard drive. Just like the DB server, when Windows comes up, we configure networking by giving it an IP address but then pointing DNS back to the domain controller’s IP address.  At this point, the browser should connect to the internet.

We’re going to need some service accounts and I’m tracking them below; we’ll create them on the domain controller as we encounter the need.

So, we mount the SharePoint install disk on our host, open that drive on the web server desktop and click Install software prerequisites. We accept the agreement and it’s off to the races.

During the install, we get a failure to download the SQL Server Native Client. It suggests we try again and, this time, it works fine. We get told to restart.

When it comes back up, the install finishes and we get an Installation Complete reward.

We take a snapshot here and then start the install again, this time selecting Install SharePoint Server. We enter the product key, accept the terms, select Server Farm and Complete and then click Install Now.

It runs for a couple of minutes and then tells us to run the configuration wizard. We click through the wizard and opt to create a new farm. We ID our database server and our database access account. Here, we need to be sure to use the <domain>\<user name> format for the acocunt name.

Now, this returns a Cannot Connect error. When we turn off the Windows Firewall on the web server and database server, the connection is completed no problem. Hmmm…

Now, we got some help here from MSDN and from here from our new best friend, Tristan, at But this robot is no firewall\security expert and the details are daunting. So, after a review, we open port 1433, outbound on the web server and inbound on the db server using the Firewall application in the control panel’s Advanced properties. @Success.

So we need a Passphrase. It’s kind of a farm admission gate. I know it’s used in the event you need to recover from the database level. No problem.

Then we encounter the Central Admin web application configuration page and we run into Kerberos authentication. I also like to always use the same port number. Also, we can note in the More Information page that changing the CA port number is only supported using the Configuration Wizard but my guess is there’s a PowerShell command that will get it done for us.

Now, at one time we were experts at configuring Kerberos for MOSS 2007. It was a bitch running some silly command line gobbledygood and some peculiar computer configs in Active Directory. My hope is that there’s some new technology and knowledge available for 2010.

So, our first options is on MSDN here. On the domain contoller, we run ADSIEdit.msc.  We connect to our local domain and drill down to the SQL Server Service Account properties. This opens a properties dialog box with an attributes edits and servicePrincipalName is one of these attributes. We click edit and get a Multi-valued String Editor.

Now, of course, the MSDN article is using generic names for all these objects and most are easily translated to our install. However one that may be be difficult to recognize the the service name. MSDN uses MSSQLSvc while, on our DB server, our SQL Server service is named MSSQLSERVER. That matters because our SPNs format is:

<Service Name>\<Host>:<Port Number>

And, you may recall, hosts must be identified both as standalone and fully qualified. Thus our SPNs for the SQL Server Serivce Account are:


Then the confirmation for this is to install the SQL Server Client Tools on the web server and try to open the database on the DB server. Unmount, mount, run, pass, product key, agree, install Setup Support files, pass. Then SQL Server Feature Installation and check Management Tools – Basic. Pass, next, next, pass, ready, install, close.

Now we can open SQL Server Management Studio from our Start menu and connect to our database server. @Success. The MSDN article says to look at the SQL Server’s Security Event Log but it says look for an event ID = 540. What we find is an event ID 4624 that says An account was successfully logged on and then tells us our Logon Process and Authentication Package was Kerberos. Woot!

That covers the Database server. Now, for the SharePoint web apps, we have to do a little planning. First, we have a service account for DB access. We also need service accounts for our applications pools. So aside from central admin that will use the DBAccess account for an application pool, we want three applications, so we’ll have three application pools with three application pool IDs. :

  • Portal – A publishing site: – Domain\SVC_SPPortalAppPool
  • Home – A team site: – Domain\SVC_SPHomeAppPool
  • My Sites: – Domain\SVC_SPMySiteAppPool

Now, remember:

  • We’ll have SPNs for standalone and for fully qualifed host headers
  • We have alternative access mappings that include the host headers as well as the web server computer name, WebServer, which we’ll point to our Portal app or Central Admin depending on port number. Likewise our raw IP address will point to either Portal or Central Admin depending on port numer. In all, we need fourteen SPNs not counting the two we created for SQL Server:

We’ll add these to the Domain\SVC_SPDBAccess account:


We’ll add these to the Domain\SVC_SPPortalAppPool account:


We’ll add these to the Domain\SVC_SPHomeAppPool account:


We’ll add these to the Domain\SVC_SPMySiteAppPool account:


My guess is that we’ll have to duplicate alot of this when it’s time to register our certificates and run our apps through https and use port 443 and then again when we deploy a bunch of applications with their own service account.

Anyway, we’re going back in ADSIEdit and finding our accounts and adding our SPNs just like we did before for the database server.Then we continue through the install wizard and it counts x of 10 tasks. # 3 took a few minutes but the rest was pretty quick and we get a Configuration Successful scooby snack. Rooby roo!!

We get the Initial Farm Configuration Wizard and an option to Help Make SharePoint Better.

I’m taking a snapshot.

I agree to send my install info to Microsoft and continue\start with the wizard.

First, I tell all the services to use a new managed account, Domain\SVC_SPServices. Don’t tell but I’m using the same password.

Then I give my new portal a name and description, tell it to use the http://HostName/ root URL and then the publishing portal template. Iget a This Completes the Farm Configuration Wizard page with a bunch of service applications listed. I click Finish and land on the Central Administration homepage. I enter my portal URL and I land on the Adventure Works homepage with all my favorite dorks.

I go back to Central Admin and, on the Application Management page, I click Configure alternate access mappings.

Here, I enter my host headers:

  • Portal
  • CentralAdmin


Firewall Settings

Our new best friend, Michael, provides a full detail of the necessary firewall settings here.


  • 1433 inbound TCP

Web Server:

  • 1433 Outbound TCP

Service Accounts

On the domain controller, we create the following accounts. Except for Password Never Expires, we’ve noted any non-default settings:

  • Database Engine Service Account – Domain\SVC_SQLServer. Logs in the MSSQLSERVER service.
  • SharePoint Database Access Account – Domain\SVC_SPDBAccess. This account must be added as DBCreator and SecurityAdmin in SQL Server Management Studio by right clicking on the Security node and selecting New Login. Create the new login and then, on the Server Roles tab, check the two roles.
  • SharePoint Services Account – Domain\SVC_SPServices. This account will be assigned to the SharePoint services during the configuration wizard that is kicked off after the Central Administration website is created.
  • Portal Application Pool – Domain\SVC_SPPortalAppPool: Portal is a web application for a publishing site.
  • Home Application Pool – Domain\SVC_SPHomeAppPool: Home is a web application for team sites.
  • My Site Application Pool – Domain\SVC_SPMySiteAppPool: MySite is a web application for My Sites.

 That’s a pretty good effort for a robot on Friday. We’ll get to the other servers, next.