I get this question so often it deserves a blog entry of its own. First, let’s get a common definition of what is meant by “multitenancy” or “managed service provider”. Typically this question refers to a managed service provider using a single instance of Service Manager to support multiple “customers” where these customers are typically different companies. Further, in these situations Customer A company must not be allowed to see Customer B company’s information and vice versa while the managed service provider can see everyone’s data.
Short Answer: Service Manager 2010 was not specifically designed for “multitenancy”, but depending on your requirements you can make it work.
Before you get into reading the Long Answer, you may want to take a quick tour through the product architecture blog series if you haven’t already - latest entry which has links to all the previous entries.
The following is a list of requirements that are typical in a managed service provider scenario and how things stand with regards to Service Manager 2010.
Physically Separate the Data
Some customers of managed service providers or even government regulations require that data for each customer must be placed in a physically separate database. Typically it can be on the same server but it must be in at least a separate database.
Service Manager stores all data for a given management group in a single ServiceManager database. If your customers require data to be physically separated, you will need to install one Service Manager management group per customer.
You can roll up data from multiple Service Manager management groups (up to 5 is tested/supported, but there is no technical prevention in place to go higher) to a centralized data warehouse which customers do not have access to.
Allow Customer Users to Access Service Manager
Whether customers are accessing Service Manager via the Self-Service Portal or via the main Service Manager console the calling user must be able to be authenticated by the account the Data Access Service is running as on the management server they are connecting to.
You can give users this kind of access only if you have a trusted relationship between the domain the management server is in and the customer user’s domain. Typically this would involve cross-forest trust. You might be able to accomplish this with Active Directory Federation Services, but we have not specifically tested it.
The other way you can achieve this is by giving customer users domain credentials on your domain and allowing them to use RRAS/VPN.
Allow Customer Users to Remotely Access Service Manager
Typically customer users need to be able to access Service Manager from outside of the managed service providers internal network. There are essentially two main user interfaces for Service Manager – the main console and the self-service portal/analyst portal. The portals are ASP.Net web sites that use Windows integrated authentication which means they will use the Windows account that is running the browser process for authentication. The self-service portal does not support Forms Based Authentication (think of how Outlook Web Access works) so remotely accessing the Service Manager portals while you are running the browser process as something other than a trusted credential is not possible. The main console connects to the Data Access Service using a client-side assembly library we call “the SDK”. When a connection is made to the Data Access Service the account running the process must be able to be authenticated by the Data Access Service. Again – here we don’t provide a way to provide credentials at connection time so the console process must be launched by an account that can be authenticated.
Even if you could get by the credential authentication issue, there is the issue of connectivity. Conceivably, you could put a management server or a portal web server in an Internet-facing zone and let people try to connect over the Internet. This is not a scenario that we have tested and I don’t know that we would really recommend that from a security perspective. It’s probably better to rely on RRAS/VPN.
Logically Separating the Data
We discussed physically separating the data above and that is only achievable by creating multiple installs of Service Manager. It is possible to separate data in a single management group by customer using user roles. You need to be VERY careful here and test things out thoroughly before granting customers access to the production environment. Basically, what you need to do is:
One thing to keep in mind here is that it is not possible to scope enumeration value hierarchy options using user roles. For example, the same incident classification list will always be shown to all users on the incident form regardless of which user role they are in. Don’t put customer-identifiable information such as a customer name, location, address, etc. in these drop downs.
Another thing to keep in mind is that out of the box the special AD group ‘Authenticated Users’ is put into the End User user role. This grants all users very broad read-only access out of the box. You should remove Authenticated Users from this user role if you are going to lock down security in this scenario.
The data warehouse data cannot be scoped by user roles in SCSM 2010. All report users have access to all report data. The way to keep reporting locked down and also the way to deliver reports to customers in a managed service provider scenario is to create Linked Reports. These Linked Reports should have parameters set which display the data for only a particular customer. You can then grant customer users access to just their Linked Reports. Even better – you can add a subscription to their reports so the report is periodically emailed to them, put on a file share, or posted on SharePoint. This is a great way to give customers read only access to Service Manager data. The data warehouse data mart is updated every 60 minutes or so (by default).
Getting Customer Data into the Service Manager CMDB
Out of the box Service Manager has connectors for AD, SCCM, and SCOM. It also has a “CSV Connector” which allows you to manually insert data into the CMDB. Using the SDK API you can create other kinds of connectors. Here is an example of creating a connector using the Import-SCSMInstance PowerShell cmdlet which ultimately using the SDK API.
Any of these kinds of connectors are going to require that the account that the connector process is running as to be able to be authenticated by the Data Access Service and the remote data source. Further, it is going to require network connectivity between the two. There are many combinations here, but needless to say this is tricky. You might be better off periodically importing data into Service Manager manually or using the PowerShell example above.
In theory, you could use Remote Operations Manager to get SCE to report up data from multiple customers to a central SCOM site and then connect SCOM to SCSM. Somebody let me know if you try this and it works!
Also, from what I understand you can manage SCCM clients over the Internet at customer sites from a central site in certain cases. If you have a set up like this then you could connect SCSM to just the top-tier central SCCM site. Also, one of our MCS consultants, Tomaz Cebul, had a good idea. If your customer has SCCM deployed, but you cannot connect SCSM to it directly, you could take a backup of the customers SCCM DB and restore it on your corporate network and connect Service Manager up to the restored backup. Service Manager queries the database directly so you dont need a complete install of SCCM to set up the connector.
If you have a trusted Active Directory forest with your customer, you could also use the AD connector to sync in users, computers, groups, and printers.
Depending on your requirements Service Manger can be used in a managed service provider scenario. Please also see the attached presentation I have given in the past for more information. The presentation outlines six possible managed service provider scenarios and how they can be implemented with Service Manager including the limitations where applicable.
Please leave comments if there are any other specific questions and I’ll update this post with answers as appropriate. Feel free to share your experiences using Service Manager in this way and to add any requirements that I may have missed. We are certainly looking for opportunities to support these scenarios even better in future versions of Service Manager!
Follow me on twitter! (http://twitter.com/radtravis)
I knew given enough time and smart people working on the problems people would start to figure out ways to work around some of these technology and design limitations. I'll index those here for people's reference:
How about _two way_ communication with other systems like CMDB's?
There is always talk about importing data on couple of different ways, but no words about exporting.
And what about if you have two way connector in use for 3rd party ticketing and would still like to get the alert data also to SCSM... for lets say future possibilities :)
Can you use Active Directory Lightweight Directory Services with Service Manager?
Keep watching the blog. We have some things coming up about getting data out of Service Manager.
We havent tested it with Lightweight.
Do you have any additional information on how to logically seperate customer data. From what I understand from your entry some XML editing is required as well as extending the Service Manager Model.
Check out this blog post:
Could you please provide more information on how to create a customised incident form that can be bound to a particular Customer in a multi tenancy (MSP)environment. Many thanks.
Have you seen this?
"Service Manager 2010 was not specifically designed for “multitenancy”, but depending on your requirements you can make it work." Is this still the case with SCSM 2012?