Microsoft SharePoint Conference 2009: Day 2

A few highlights from today’s talks:

  • With SharePoint 2010, we no longer have a Shared Service Provider (SSP), instead we now have service application instead. All of the applications benefit from an internal load balancing scheme (fault tolerant round robin load balancing), meaning that as long as you start a service application on more than one server, you’re better protected from failure.  Oh, and yes, that goes for indexing as well!
  • The Service Application framework is extensible; this means you can write your own services to be hosted by SharePoint. These will, in turn, benefit from the internal load balancing scheme mentioned above.  Yes, you can also use a hardware load balancer and from what I gathered, even write your own load balancer!
  • All of your Service Application management can be done from PowerShell – if you don’t know PowerShell, now is going to be a very good time to learn…  If you want to have a look at the available applets, try the following in PowerShell:
    get-SPServiceApplication
    this will return the list of available commandlets.
  • You will be able to add delegated administrators for specific Service Applications. These delegated administrators will have their view of the Central Administration site trimmed to only those items they should see.
  • Claims based auth looks very interesting, and can be extended to allow 3rd party applications to provide additional claims.
  • SharePoint Designer 2010 rocks!

Guest NLB issues on Hyper-V (Windows Server 2008 R2)

One of the issues I’ve seen during our migration of virtual machines to our new Windows Server 2008 R2 Hyper-V cluster relates to network load balancing (NLB).  We have a number of NLB setups running which will need migrating in time.  My first test migration of a pair of NLB virtual machines (actually, technically a trio of servers making up a SharePoint farm) didn’t go as smoothly as I’d hoped.

The machines in question have been running on a Windows Server 2008 Hyper-V machine quite happily for some time.  I followed the procedure we’ve used to migrate other machines to our new Windows Server 2008 R2 Hyper-V cluster, connecting both network adaptors to the appropriate network when the import had completed.  When I looked at the network settings in the GUI, two network adaptors showed up and the configuration at first glance seemed okay.  When looking at the network configuration using ipconfig however, only the values for one network adaptor (the primary, i.e. non-NLB, adaptor) were shown, with the NLB adaptor missing in action.

In addition, NLB manager showed the following error when I tried to reconfigure the cluster:

adaptor misconfigured detail

The solution to the issue is actually simple; in the Hyper-V VM settings for the NLB network adaptor, turn on MAC address spoofing:

enable spoofing of MAC address

This immediately fixed the issues we were seeing with the NLB adaptor of the machines we were migrating.