I’ve had some questions around installing and configuring Service Level Dashboard 2.0 recently, and decided to supplement our official documentation with a more visual step by step article.
Before diving into the installation steps, I think it’s imperative to cover some of the more vague points that are not addressed in the guide, like where to host the SLD components, and accounts required for installation and configuration.
This is the first installment of a two-part series. Part 2 of the series can be found here, where I document my installation experience with plenty of screenshots.
Where to install WSS 3.0?
There is no guidance around this in the SLD documentation. However, you can find some guidance by reading up on the WSS documentation, and you’ll learn that there are many options once you put it together with your Operations Manager deployment.
Virtualized – Installing WSS 3.0 on a virtualized server is supported, and WSS 3.0 is an excellent virtualization candidate. This would be an ideal placement for WSS.
Collocate with Management Server – Installing WSS 3.0 on a Management Server is an option, but consider the performance impact and any security policies you might have in place. Since WSS does require IIS and various open ports, this may or may not be the best option for you. In smaller environments where the Management Server is not loaded (less than 1000 agents) and not virtualized (or at least has plenty of resources available if it is), collocating here might work well for you.
Collocate with RMS – Same concepts and principals apply here as with the Management Server role, but special consideration should be taken in regards to load and performance, as we all know that the RMS is the heart of Operations Manager and we don’t want to add load if it were already near capacity.
Collocate with Gateway Server – Collocating the Gateway Role on some other application is popular. I’ve seen Gateway Roles installed on other types of servers, like IIS, and do very well. Consider the possibility of a performance bottleneck and especially any security policies that might inhibit installation and access to the Data Warehouse. Since this is a Gateway Role, network boundaries and open ports are the inherent issue here. In smaller environments where the Gateway Server is not loaded (less than 50-100 agents) and not virtualized (or at least has plenty of resources available if it is), collocating here might work well for you.
Standalone – Sure! I don’t see this happening much these days for such an ideal virtualization candidate. But if you happen to have a lightweight server you can spin up, by all means use it for WSS.
Collocate with Report Server – Installing WSS 3.0 on a Report Server makes sense, since this computer is already serving up HTTP requests and likely provisioned for that purpose. However, I’m cautious to make any supportability statement here because I haven’t tested a WSS installation on a Report Server role, and we all know the security related intricacies this role has on the hosted site. I’ll have to update this part once I have a better answer.
Where to install the WSS databases?
There is no guidance around this in the SLD documentation. But if we read up on the WSS documentation, we’ll learn that the WSS config and content databases can be hosted just about anywhere that is accessible by the WSS application. The only requirement is that the WSS databases need to be installed on a SQL Server instance. This isn’t a WSS requirement. It is a Service Level Dashboard requirement.
Locally – Installing the WSS databases locally on the WSS server is fine, if you have the SQL Server licenses to do so.
Existing SQL Instance – This is ideal and probably the option most customers will use, since this option will require no additional SQL Server installation and licensing. Also, since these databases generally produce a relatively low volume of activity and do not have crazy IO patterns like that of an OLTP database, there aren’t many performance considerations here.
Data Warehouse SQL Instance – Since all the data generated to draw the SLD dashboard is from the Data Warehouse, and the fact that the SLD config and content databases will produce similar IO patterns as the Data Warehouse, I think it’s safe to consider hosting the WSS databases on the same SQL Instance as the Data Warehouse.
Operations Manager SQL Instance – Since the WSS config and content databases do not produce the same IO patterns as the operations database, and the fact that we certainly do not want to use any resources for anything other than the operations database (even if WSS and SLD are relatively lightweight), I tend to move away from any ideas of hosting any other databases here. The only time I would consider hosting these databases here is if the server hosting this SQL Instance is operating well within performance thresholds and the Operations Manager deployment is running at “steady state” (e.g., you’re not expanding with more agents or management packs in the future). Learning whether this server is operating within performance thresholds can only be found through a proper performance assessment. If you’re considering hosting these databases here, have a “Plan B” if you find that console and management group performance degrades when SLD goes into production and more dashboards are being creating for your internal customers.
What accounts to use?
The SLD documentation is lacking information about what accounts are required to install and configure WSS. It also eludes to using some Operations Manager account for the application pool identity, when in fact this does not necessarily need to be an account associate to any Operations Manager User Role or Run As Account.
Reading through the WSS 3.0 resources, I have determined that we need two domain accounts created for our new WSS and SLD installation. A WSS Config Service account and a WSS Content Pool Service account. These are regular user accounts that should be created in Active Directory before installing WSS. These accounts should not be a member of any security groups or added to Operations Manager, and they should be treated as a service account.
So now that we understand the many options for where WSS and its databases will be located, as well as the accounts required to make it all work, we can begin the installation and configuration steps. I’ll cover this in part 2 of this series.