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:
- Create queues of work items – figure out a way to subdivide incidents, change requests, problems, etc. by customer, but you need to do this in a way which does not expose the list of all the customers to the customers. One suggestion would be to create queues based on the related Affected User’s domain property (note: this can only be done by creating queues over type projections which can only be done in XML not in the UI – I’ll post more info on this later). Another way would be to extend the Service Manager model with a new Work Item class enumeration (aka “list”) property called Customer ID. The values in this enumeration hierarchy should be non-identifiable such as a customer number instead of using the customers names.
- Create groups of configuration items – figure out a way to subdivide configuration items. My suggestion here would be to create groups of computers by domain. You could also create groups of specific CIs – for some classes of CIs like business services that might be more appropriate. Again here you could add a CI property here which uses the same enum hierarchy as above. Make sure you create groups of user objects too (users are CIs in the model)! Otherwise customers will be able to see each others users.
- Create user roles for customer users – assign the queues and groups created above and assign customer users.
- Create user roles for the managed service provider users which have global scope of work items and configuration items and assign users from the managed service provider company.
- Test, test, test – log in as users in different customers and roles to make sure that only the data that should be visible/editable is visible and editable. Keep in mind that you must log a user out of Windows and back in after changing that user’s permissions in Service Manager before the updated permissions will take effect.
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! (https://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:
- Creating multiple self-service portals with different branding on a single web server: http://www.braindumpblog.co.uk/?p=36
- Using queues/groups based on type projections so that user roles can be scoped by things like affected user’s company, location, etc: http://blogs.technet.com/b/servicemanager/archive/2010/05/25/creating-queues-and-groups-using-type-projections.aspx