SharePoint Architecture, part 3, Shared Services Providers (SSPs)

Parts one and two focused on the basic logical building blocks of SharePoint farms.

Back in part one, after misquoting the song “Old McDonald had a farm,” which we shall revisit when we return to the discussion of Microsoft SharePoint farm Shared Services providers, we started describing the SharePoint building blocks using a rendition of “There was an old lady who swallowed a fly.” Starting with items such as documents, folders, lists such as libraries, and finally sites, here is what we have thus far:

“There was an SP server who swallowed a site,
One for the Team, one for a Blog, one for a Wiki, whatever is right.
He swallowed the site to keep the library.
This one for documents, that one for wikis, another for tasks, yet another for KPIs. (pronounced kippees)
He swallowed the library as a holder of the folder.
Quite categorical, with items newer or older,
He swallowed the folder to hold the item.
I dunno why he swallowed that item,
Perhaps he likes ’em.”

The SharePoint site, or SPWeb as it is called in several of the management interfaces, can indeed contain of wealth of items of a plethora of types, organized into folders and libraries. Most deployments of SharePoint have more than one content. In fact, when you count in the management interfaces, it’s pretty safe to say that (nearly) every SharePoint deployment is comprised of several sites.

An SPWeb can be defined as a subsite beneath another site. A collection of sites is called a site collection (SPSite). A site collection always contains at least one site which serves as the root site within the collection.

“There was an SP server who swallowed a site collection,
Root URL, site name, and a good description
He swallowed the site collection to keep the site.”

Each site in a collection shares some common elements and has distinct configuration for others, ….

“There was an SP server who swallowed a web application,
With an IIS site, an AppPool, and a database all its own.
He swallowed the web app to host the site collection.”

Many people want to think of each SharePoint site as having it’s own database or table, however that is not the job of a site, and that is not even the job of a site collection, but lay within the domain of the web application (SPWebApplication). Each web application has its own application pool in IIS, and therefore a distinct IIS site. Furthermore, each SPWebApplication has its own SQL database for its SharePoint content.

Some people become confused by the fact that a SharePoint site is called an SPWeb, yet a site collection is called an SPSite, and it is a web app, SPWebApplication, which is associated with an IIS site. Keep in mind that these terms have evolved over the past ten years or so, and just remember the relationships in this hierarchy if it ever befuddles you.

There is one more level in the hierarchy of the SharePoint foundation before we finally get to the more advanced topic of shared services providers.

“There was an SP server who swallowed a farm.
Configuration, apps, and central admin too,
He swallowed the farm to host a web app or two, maybe a few.”

In reality, a single SharePoint server shouldn’t swallow a farm any more than an old woman should swallow a horse, but one or more servers make up a farm. The web front end, application services, and back-end databases of larger farms are typically spread across several servers for high availability, disaster recovery, performance, and scalability reasons. Although some organizations have more than one farm, a SharePoint farm is the largest building block in the infrastructure of a single SharePoint deployment.

When you’re not just using WSS 3.0 or SharePoint Foundation 2010, but the bigger more powerful MOSS 2007 or the full SP2010 includes another aspect of farms called Shared Services Providers — more on those in the next part.

Here’s a quick review of the foundation SharePoint logical infrastructure.
Farm
Web application
Site collection
Site
Library
Folder
Item (e.g. Document)

I hope that helps! Again, next time we’ll get into the beauties if Shared Services providers.

SharePoint Architecture, part 2, from site to farm

In part one, after misquoting the song “Old McDonald had a farm,” which we shall revisit when we return to the discussion of Microsoft SharePoint farm Shared Services providers, we started describing the SharePoint building blocks using a rendition of “There was an old lady who swallowed a fly.” Starting with items such as documents, folders, lists such as libraries, and finally sites, here is what we have thus far:

“There was an SP server who swallowed a site,
One for the Team, one for a Blog, one for a Wiki, whatever is right.
He swallowed the site to keep the library.
This one for documents, that one for wikis, another for tasks, yet another for KPIs. (pronounced kippees)
He swallowed the library as a holder of the folder.
Quite categorical, with items newer or older,
He swallowed the folder to hold the item.
I dunno why he swallowed that item,
Perhaps he likes ’em.”

The SharePoint site, or SPWeb as it is called in several of the management interfaces, can indeed contain of wealth of items of a plethora of types, organized into folders and libraries. Most deployments of SharePoint have more than one content. In fact, when you count in the management interfaces, it’s pretty safe to say that (nearly) every SharePoint deployment is comprised of several sites.

An SPWeb can be defined as a subsite beneath another site. A collection of sites is called a site collection (SPSite). A site collection always contains at least one site which serves as the root site within the collection.

“There was an SP server who swallowed a site collection,
Root URL, site name, and a good description
He swallowed the site collection to keep the site.”

Each site in a collection shares some common elements and has distinct configuration for others, ….

“There was an SP server who swallowed a web application,
With an IIS site, an AppPool, and a database all its own.
He swallowed the web app to host the site collection.”

Many people want to think of each SharePoint site as having it’s own database or table, however that is not the job of a site, and that is not even the job of a site collection, but lay within the domain of the web application (SPWebApplication). Each web application has its own application pool in IIS, and therefore a distinct IIS site. Furthermore, each SPWebApplication has its own SQL database for its SharePoint content.

Some people become confused by the fact that a SharePoint site is called an SPWeb, yet a site collection is called an SPSite, and it is a web app, SPWebApplication, which is associated with an IIS site. Keep in mind that these terms have evolved over the past ten years or so, and just remember the relationships in this hierarchy if it ever befuddles you.

There is one more level in the hierarchy of the SharePoint foundation before we finally get to the more advanced topic of shared services providers.

“There was an SP server who swallowed a farm.
Configuration, apps, and central admin too,
He swallowed the farm to host a web app or two, maybe a few.”

In reality, a single SharePoint server shouldn’t swallow a farm any more than an old woman should swallow a horse, but one or more servers make up a farm. The web front end, application services, and back-end databases of larger farms are typically spread across several servers for high availability, disaster recovery, performance, and scalability reasons. Although some organizations have more than one farm, a SharePoint farm is the largest building block in the infrastructure of a single SharePoint deployment.

When you’re not just using WSS 3.0 or SharePoint Foundation 2010, but the bigger more powerful MOSS 2007 or the full SP2010 includes another aspect of farms called Shared Services Providers — more on those in the next part.

Here’s a quick review of the foundation SharePoint logical infrastructure.
Farm
Web application
Site collection
Site
Library
Folder
Item (e.g. Document)

I hope that helps! Again, next time we’ll get into the beauties if Shared Services providers.

SharePoint Architecture, looking forward and back

“The SharePoint admin had a farm, E-I-E-I-O;
and on this farm she had some shared services, E-I-E-I-O.
With “User Profiles” here and “My Sites” there
Here an “Excel Services” there a “Business Data Catalog”
Everywhere a “Shared Search”
The SharePoint admin had a farm, with lots and lots of I/O!”

With SharePoint Server 2010 on the verge of release (Microsoft launch date is May 12, 2010), it is important to understand what’s new compared with Microsoft Office SharePoint Server 2007. Yet before rushing into the future, it can often be fruitful to look at the present state of things and a bit at the past in order to more smoothly navigate the future. Now is such a time.

One question people often ask me — usually in a SharePoint class and not so much on the street — is how the various architectural elements of SharePoint fit together, and there seems to be common confusion over where Shared Services fit into the anatomy. While it is tempting to just sing the “SharePoint admin had a farm” song, let’s first examine the relationship between some of SharePoint’s administrative building blocks. To do so, we’ll first refer to another song beside “Old McDonald had a farm.”

“There was an old lady who swallowed a fly” is an old song that teaches that you should never swallow a horse just because you have a close encounter with a musca domestica.

http://kids.niehs.nih.gov/lyrics/oldlady.htm

http://kids.niehs.nih.gov/lyrics/mcdonald.htm

The shared services of SharePoint Server 2010, and MOSS 2007 before it, build on the more fundamental hierarchy of administrative elements provided by SharePoint Foundation Server 2010 (think WSS 4.0) in the newer case, and Windows SharePoint Services 3.0 (WSS 3.0) in the case of MOSS 2007.

Following the tradition of the “there was an old lady” song, let’s look at the fundamental hierarchy from smallest to largest.

“There was an SP server who swallowed an item.
I dunno why he swallowed that item,
Perhaps he likes ’em.”

Whether the item is a document, an announcement, or any other type, let’s start at that level rather than exploring the more microscopic elements.

“There was an SP server who swallowed a folder,
Quite categorical, with items newer or older,
He swallowed the folder to hold the item.”

Folders are actually optional, but like in file systems, they can prove to be immensely handy for organizing large numbers of items. Creating a folder just to hold one item would usually be silly, going overboard, such as swallowing a spider to to get one fly.

“There was an SP server who swallowed a library,
This one for documents, that one for wikis, another for tasks, yet another for KPIs. (pronounced kippees)
He swallowed the library as a holder of the folder.”

Some of the types of libraries and lists which MOSS 2007 supports are:
Libraries: Document, Form, Wiki Page, Picture, Translation Management, Data Connection, Report, and Slide.
Communications: Announcements, Contacts, Discussion Board.
Tracking: Links, Calendar, Tasks, Project Tasks, Issue Tracking, Survey.
Custom Lists: Custom List, KPI List, and custom lists in Datasheet View, or lists created with columns imported from a spreadsheet.
Web Pages: Basic Page, Web Part Page

If you have management permissions for your part of the SharePoint deployment, you could navigate to Site Actions, Create to allow addition of such libraries and lists. One of the options provided under the Web Pages category beside Basic Page and Web Part Page is the ability to manage “Sites and Workspaces.”

In fact, the next element in the hierarchy is a site.

“There was an SP server who swallowed a site,
One for the Team, one for a Blog, one for a Wiki, whatever is right.
He swallowed the site to keep the library.”

It is typically at the level of a site where the tie-in to the underlying Internet Information Services (IIS) is evident. All libraries and lists, all folders and items within a site are stored in the same SharePoint content database. And the features of the site beyond the IIS definition are specified in the SharePoint configuration database. Yet there is far more to the SharePoint administrative hierarchy. Tune in next time when we go from sites to bigger and better things.

Disclaimer:
NOTE: The opinions expressed here are MY OWN and are not necessarily those of my employer, partners, customers, friends, or family. ALL content presented AS-IS, for entertainment purposes only with ABSOLUTELY NO WARRANTY expressed or implied.

Hyper-V Server Authorization, part 2

In part one, we reviewed a bit of background on authorization models including mandatory access control (MAC) and discretionary access control (DAC), and noted that classically speaking, Windows has largely been managed with a DAC model. There’s a new sheriff in town beside good ole DAC. Alongside the classic DAC is role-based access control (RBAC), which is used to govern access to certain services and resources. Permissions for services such as Hyper-V are controlled via RBAC. Users who need to administer the virtualization aspects of a particular virtual machine could be assigned a role which is granted the appropriate abilities.

Two of the graphical user interface (GUI) management tools for Hyper-V are the Hyper-V Manager (virtmgmt.msc) and System Center Virtual Machine Manager (VMM) 2008 R2. Management and usage control for Hyper-V, and therefore management using both of these tools use the RBAC Authorization Manager (AzMan) to adjust the management permissions for Hyper-V. The GUI management interface for AzMan is the MMC console AzMan.msc.

AzMan is used to manage sets of authorization configuration information called authorization stores. An authorization store for a particular application or service could either be stored in Active Directory or in a configuration file in extensible markup language (XML) format. By default, Hyper-V uses an authorization store in the file InitalStore.xml at the full path such as C:ProgramDataMicrosoftWindowsHyper-VInitialStore.xml. If you are managing the Hyper-V server with VMM 2008 R2, the authorization store file HyperVAuthStore.xml supersedes the InitialStore.xml. If you have access to the host server, you could query the registry value HKLMSOFTWAREMicrosoftWindows NTCurrentVersionVirtualizationStoreLocation, which reveals which authorization store AzMan is currently using. An example value would be:

msxml://C:ProgramDataMicrosoftWindowsHyper-VInitialStore.xml

Just what is in the authorization store? You could look at it within AzMan.msc. That’s the typical way if you have already set up networking between your ServerCore-based Hyper-V server and your management station. But remember that Hyper-V Server 2008 R2 has some shared heritage with release two of the full standard, enterprise, and datacenter editions of Windows Server 2008. In R2, Windows PowerShell is supported on ServerCore. How would we install it? The following command could be run in the server’s command prompt to install the .NET framework and PowerShell.

start /w ocsetup NetFx2-ServerCore;MicrosoftWindowsPowerShell

Once we have PowerShell installed, we can run it by typing powershell.exe (or without the .exe part) to run it. Then in PowerShell we can examine that InitialStore.xml authorization store for Hyper-V in a structured way rather than in raw XML notation in notepad.

$az = [XML](get-content InitialStore.xml)
$az.AzAdminManager.AzApplication

The first line here gets the contents of the authorization store and translates it using the XML parser. The second line just shows a few of the basic components of the authorization store. One of these components is the AzOperation list, which defines the permissions that AzMan can be used to assign.

$az.AzAdminManager.AzApplication.AzOperation | FT Name,Description -auto

This lists out the operations which can be delegated to people administering Hyper-V. While VMM 2008 R2 includes some PowerShell cmdlets for working with Hyper-V, these are not included with either Hyper-V Manager nor Hyper-V Server 2008 R2 itself. Even without such cmdlets, PowerShell can be used to help manage Hyper-V delegations, basic server setup, and with WMI even Hyper-V itself can be managed.

Hyper-V Server Authorization, part 1

“What is your name?” crowed the Bridge Keeper of the abyss in Monty Python and the Holy Grail. Invariably, the next question was “What is your quest?” Like the user name and domain name is typical username/password authentication systems, these should be easy, although some days I’ve typed my username or domain incorrectly, and sometimes people aren’t so clear on their quest. But that’s another story.

It is the next question and its answer which are possibly unique per person. In the aforementioned story, getting that wrong is simply disastrous, whether it be ambivalence of affinity to a frequency in the electromagnetic spectrum or ignorance of ornithological species differentiation in terms of unladen velocity. In the wonderful world of computing, the proper authentication is the critical precursor to specific authorization and accounting.

In terms of Windows authentication, the correct username and passphrase combination or smart card and PIN validation yield a user’s security access token (SAT). This token contains a user’s security identifier (SID), the SIDs of the groups they are a member of, some user rights (privileges), and other associated information. In recent versions of Windows (Vista, Server 2008, Seven, and Server 2008 R2) there could be a split token for administrative and non-administrative identities. Through this token obtained via authentication, all Windows authorization and accounting is derived.

That’s the prologue. Many services hosted on Windows have management and end user roles associated with them, along with assignments of abilities through permissions to different users and groups. Operating systems and devices classically offer discretionary access control (DAC) to resources. For example, the Windows registry, NTFS file system, and Active Directory (AD DS and AD LDS) all utilize security descriptors which include ownership, auditing, and permissions. The permissions for each value, file, or object area specified in thee security descriptors’ discretionary access control list (DACL).

Such permissions lists are “discretionary” in the sense that owners of resources, and other users who have been delegated with “take ownership” or “change permissions” permissions could potentially modify the initial security controls, including the permissions and auditing, which had been established for those resources. Therefore, the security of the system is at their discretion. This discretion is a violation the prime directive of another sort of access control called mandatory access control (MAC). As the name implies, the security controls in such a system are indeed mandatory. Everyone, including owners and delegates of resources must follow the security rules established by the central security authority without discretionary exception. Because many systems administrators, and of course resource owners and delegated administrators, want flexibility, DAC is far more commonly implemented than MAC. Again, Windows is primarily a DAC-based system.

In the story of the aforementioned bridge keeper, when King Arthur queried the bridgekeeper, it was shown that the bridgekeeper was subject to the same controls as everyone else, therefore that is an example of MAC not DAC – just in case you were wondering.

In the next part, we will actually focus on RBAC and Hyper-V.

Hyper-V Hysteria

“Off with his head,” cackled the Red Queen. Had the Red Queen of Alice in Wonderland been an IT admin, perhaps she would say this of every server which offended her as she played croquet in the data center. But then that would be “sever the server,” right?

What do servers need a graphical user interface for? Why would they need a keyboard or mouse? Why does a server even need to be a server?

Around the time Windows Server 2008 came out, Microsoft released a major replacement for their Virtual Server 2005 R2, namely a hypervisor based virtualization platform called Hyper-V. Many VMware customers, particularly those of ESX or ESXi, may be unlikely to switch to Hyper-V. But now this is starting to pick up some steam, and like a caterpillar evolving into a butterfly, a new incarnation of Hyper-V holds even more promise.

Now available as a standalone product with a free license, Microsoft Hyper-V Server 2008 R2 provides just the Hyper-V role without the extra baggage of other roles or the license costs of Microsoft Windows Server 2008 R2 in the Standard, Enterprise, or Datacenter editions. Note the lack of the name Windows in the title of this standalone Hyper-V product.

Hyper-V Server, in this standalone 2008 release two incarnation, is essentially a limited Windows Server 2008 R2 “Server Core” installation which is x64 based. No other roles and very few features can be installed directly on it. There are several implications and ramifications of this.

Firstly, if you are going to manage the Hyper-V Server(s) locally, you need to be aware that in Server Core installations like this, local graphical management tools are almost entirely out of the question. Certainly, the Microsoft Management Console (MMC) will not run locally on the Hyper-V Server. Luckily you have a command line and Windows Management Instrumentation (WMI). If you’re not into that kind of administrative joy, then just run the server headless and manage it from across the network. You’ll still want to configure basic networking and such using netsh, netdom, and related commands. Then go remote.

You could manage Hyper-V Server remotely using WMI with a number of tools, including wmic or PowerShell. Two other alternatives are a lightweight management tool which is useful for small deployments of one or a few Hyper-V based servers, and a heavyweight management product targeted at larger virtualization deployments, perhaps with both Hyper-V and VMware servers.

Let’s start light and go heavy. Hyper-V Manager (virtmgmt.msc) is a MMC snap-in which can be installed on Windows Vista or Windows 7. If you don’t already have this, download the appropriate version from Microsoft. Before you connect to your Hyper-V servers across the network from this graphical management interface, you will want to do a bit of preparation work of the server(s). Specifically, you can use Authorization Manager (AzMan) to adjust the management permissions for Hyper-V. Perhaps I’ll get into more details later. But remember one thing: Microsoft Hyper-V Server 2008 R2 and this Hyper-V Manager are both free, zero cost license downloads.

System Center Virtual Machine Manager (VMM) 2008 R2 is the more heavyweight approach. Yes, like other components of the System Center suite, VMM 2008 R2 must be licensed with money. For example, estimated enterprise pricing is $869 U.S. and $40 per hosted operating system, while workgroup edition pricing is estimated at $505 U.S. for five host servers. A trial edition is available. SQL Server is used on the backend, failover cluster, consolidation, migration, and management of mixed environments with both Hyper-V and VMware are just some of the aspects of this bigger scale management product.

If you’re we doing virtualization now or looking into it, take a look at this version of Hyper-V that is decoupled from the full Windows Server 2008 R2.