HMC 4.5 and Windows SharePoint Services 3.0 SP1

  • [アーティクル]

Introduction 

Those who know the history of HMC, will probably remember that it has a humble beginning, it started with Hosted Exchange as the core. Eventually, as some of the other products become more matured and calls for more communication and collaboration tools, it evolves into HMC where it allows service providers to offer more than just Hosted Exchange but also allow them to complete their offerings with Windows SharePoint Services Hosting, Hosted Office Communication Server and etc.

The word 'Hosted' or 'Hosting' somehow seems to mean 'complicated' to many people and HMC to a lot of people is like a black box. The fact is, there is really nothing difficult about it. It sounded difficult because not many has experience in configuring a product to cater for hosting or multi-tenant environment.

Here, I intend to highlight a couple of areas on a very high-level to clarify how and what HMC 4.5 has introduced to allow multi-tenancy for Windows SharePoint Services (WSS) 3.0.

What is multi-tenancy and what does it mean to WSS?

From Wikipedia, "Multitenancy refers to a principle in software architecture where a single instance of the software runs on a software-as-a-service (SaaS) vendor's servers, serving multiple client organizations (tenants). "

In the context of WSS, it means a single instance of WSS infrastructure will be able to cater for multiple companies, organizations or tenants (note: I tends to use these 3 words interchangeably). If you read through the HMC 4.5 help file, you will find that the minimal necessary configuration for WSS 3.0 Hosting in HMC 4.5 only requires following Windows SharePoint Services 3.0 servers:

· One front-end Web server.

· One database server on a Microsoft SQL Server 2005 cluster.

Of course, the above does not mean it will be sufficient to cater for your hosting needs but it is not the purpose of this blog to discuss about scalability here. The question here is, "How can host multiple companies in the same infrastructure and at the same time ensuring that they are completed isolated?"

From a very high level, here is what HMC intends to achieve,

· Site Isolation - Each company should only be allowed to see and access their own site. It must able to cater for different domain-named sites, such as https://sharepoint.alpineskihouse.com, https://teamsite.contoso.com instead of everyone having a common site name like https://www.serviceprovider.com/sites/\<sitename>

· Site Administration Isolation - Each company should only be allowed to manage their own site

· User Isolation - Each company should only see their own users.

With the objectives above, let's take a closer look.

What is HMC doing to WSS for Hosting?

At a high level, nothing (Hooray, I can stop writing now!). Unlike with Hosted Exchange where HMC introduces various tweaking to make things work, WSS 3.0 is actually reasonably well designed in this aspect. All the features and functions are readily available in WSS to cater for multi-tenancy. All HMC really need to do is to make the right call to create the SharePoint sites.

I wish Exchange can be as easy as that too. Of course, to be fair to Exchange, it has more infrastructure challenges to address and also it needs to address some legacy behaviour of Outlook Clients too.

(1) Site Isolation

HMC uses the host header mode to create Windows SharePoint Services site collections. This mode allows the creation of multiple domain-named sites for customers using Windows SharePoint Services in a single Web application. Examples of domain-named sites include:

https://sharepoint.fabrikam.com

https://teamsite.fabrikam.com

https://www.alpineskihouse.com

https://sharepoint.betterbuy.ca

With this mode, as long as the DNS is configured correctly and the users are using the specified URL, the appropriate site will be returned.

HTTPS for host-named site collections

I should note that the above is all HTTP. HTTS may be a little bit different because a certificate has to be applied to an IIS Web site. Therefore, HTTPS can only be configured at the Web application level in Windows SharePoint Services 3.0.

In hosting scenarios, hosters can configure a single Web application with HTTPS and then create multiple host-named site collections within that Web application. Each Web site is technically sharing a single certificate. If the requirement is to apply a unique certificate for each site, the hoster has to create multiple Web applications. Web applications are not as scalable as site collections in Windows SharePoint Services 3.0.

Now, the hosters can also acquire a wildcard certificate and then use a host-named site collection URL policy that matches that wildcard certificate. For example, if a hoster acquires a *.consolidatedmessenger.com wildcard certificate, the hoster has to generate host-named site collection URLs such as https://alpineskihouse.consolidatedmessenger.com, https://tailspin.consolidatedmessenger.com, and so on, to enable these sites to pass browser SSL validation.

(2) Site Administration Isolation

Typically, service providers provide a site collection to a customer, and the customer administrator is given the role of "site collection administrator." This means the customer administrator can manage the permissions directly from the SharePoint sites and the administrator should have the Full Control permission level on all Web sites within a site collection.

The isolation is done by default based the user logon, nothing is required to be done by HMC over here.

(3) User Isolation

In the multi-tenant environment, one of the most important requirements is privacy. Access of any information by users of another company is absolutely not acceptable. In the context of WSS, the good news is that the access to the content is well governed by the site permissions and if you are to create the site correctly, granting permissions to only the users in your company, you should be fine.

There is one area in WSS that is exposed, which is the PeoplePicker. For those who has followed HMC for a while, probably remember WSS 3.0 (RTM)'s PeoplePicker does not function very well in multi-tenancy environment. If you follow the HMC 4.0 Deployment guide, WSS 3.0 will expose all the users in the environment. Here are some reference,

Adding Users to WSS 3.0 Site in HMC 4.0 Exposes Users in All Organizations

https://blogs.msdn.com/jasonjoh/archive/2007/09/11/adding-users-to-wss-3-0-site-in-hmc-4-0-exposes-users-in-all-organizations.aspx

Note: I should I also highlight that Jason's method has to be reverted once you have deployed the following hotfix. Specifically, the SharePoint_AppID should be added back as a member of the Windows-based Hosting Service Accounts group

The Peoplepicker function may not be fully implemented when you use Windows SharePoint Services 3.0 Service Pack 1 together with Microsoft Solution for Hosted Messaging and Collaboration (HMC) 4.0

https://support.microsoft.com/kb/949629

 

(The above hotfix is also included in Description of Update Rollup 1 for the Hosted SharePoint services in Hosted Messaging and Collaboration 4.0, https://support.microsoft.com/default.aspx/kb/952075/en-us)

The PeoplePicker function was fixed n WSS 3.0 SP1 but to fix it, the PeoplePicker function needs a way to properly scope the user list so that it will only display the users in the specific organization, this is where UserAccountDirectoryPath and ServiceAccountDirectoryPath comes in. That's the reason why when you install the above hotfix, you have to run steps to set theserviceAccountDirectoryPaths and also PeoplePickerUpdateSites.xml to update all the sites with the necessary UserAccountDirectoryPath.

SetSiteUserAccountDirectoryPath and PeoplePicker-ServiceAccountDirectoryPaths were introduced only in WSS 3.0 SP1

Setsiteuseraccountdirectorypath: Stsadm operation

https://technet.microsoft.com/en-us/library/cc263328.aspx

Peoplepicker-serviceaccountdirectorypaths

https://technet.microsoft.com/en-us/library/cc263012.aspx

With the above, the PeoplePicker should work correctly. Here are a few points you should take note,

1. Application Pool Account for the web application is used to Query Active Directory

2. Service Account is used when we used People Picker in Central Administration

3. When we check names in People Picker, LDAP query is executed to resolve the user name from the Active Directory based on the Directory Path.

That's why if you remove SharePoint_AppID as the member of the Windows-based Hosting Service Accounts group after the hotfix, and where all the sites have been updated with the appropriate UserAccountDirectoryPath, you may have a problem.

Anything else?

While it seems straightforward that WSS can pretty much work on its own in the multi-tenancy environment, there are a few areas I like to cover in this blog to give a better picture of the relationship between HMC and WSS.

(1) MPS SharePoint Admin Web Services

When you walk through the HMC 4.5 Deployment, you may notice that you have to deploy a MPS (Microsoft Provisioning Server) SharePoint Admin Web Services on the WSS frontend server. The Web Services is installed on the Central Administration web site. This service has nothing to do with the working of the WSS. This web services is used and called by MPS engine. If this is not installed, the SharePoint MPS procedures may not work correctly.

(2) Accounts Used

3 Accounts were created during the HMC 4.5 Hosted WSS deployment. SharePoint_AppID (SharePoint service account), SharePointSrchSvc (search service account) and SharePointSrchCrl (search crawler account).

All the web application runs on SharePoint_AppID.

During the configuration of the MPS component, you also need to grant MPSSharePointAccts as the Farm Administrator and also as the local Administrator of the WSS servers and MPSPrivAcct-xxxxx with full control of the SharePoint Web Application. Do take note that, this is important as MPSPrivAcct-xxxxx is the account being used to create SharePoint sites during the provisioning.

(3) Where does HMC store the SharePoint site information for each tenant?

Lastly, let me just briefly discuss where HMC store the SharePoint site information and the tenants' SharePoint Plan and resource information.

HMC Stores SharePoint Site information in Active Directory

HMC stores the SharePoint Site information belonging to each tenant right under the Services container in each HMC Tenant OU, such as the following,

· fabrikam.com (domain)

o Hosting (Hosting OU)

§ consolidatedmessenger (HMC Reseller)

· alpineskihouse (HMC Tenant)

o _Private

§ Services

· SharePointSites

o AlpineSkiHouse Site 1

In that "AlpineSkiHouse Site 1" container you may find multiple objects (Contact objects are used) named like the following (you can find the information in the DisplayName attribute),

 

· siteGUID

· siteOwner

· siteType

· subSiteGUID

· target

HMC Resource Management in MPS SQL Databases

While the Active Directory keeps all the SharePoint site information, the MPS SQL databases serve to keep track of the resource information, such as how many SharePoint site and sub site can each tenant has.

So, here you go, this is a very high level overview of the HMC 4.5 and Windows SharePoint Services 3.0 SP1.

Comments