You searched for analytics - Page 3 of 7

SCSM and Cireson User Accounts and Groups Checklist Worksheet

When installing Microsoft System Center Service Manager, there are a lot of things to consider to make sure the install goes well and will be easy to modify in the weeks, months and years to come.

In order to maintain a secure, stable and maintainable SCSM environment, it’s important that all required user accounts are set up with individual service accounts, long secure passwords, and only the necessary rights to get the job done.

Below is a checklist worksheet of the accounts and groups that would be needed for a typical installation of both SCSM and Cireson products. Each person installing SCSM and/or Cireson products may have a different setup, different app and a different number of environments, but this checklist should cover all the items needed (just remove the ones that are not relevant to your environment).

The environment column is for recording what environment the account is for. It is best practice to have a different service account for the same function across dev, test and production environments to ensure that changing the password in one does not impact the other environments.

Generic Name	New Account Name	Environment	Account Permissions & Use
SCSM Service Account		Prod Test Dev	Service Account (also used to install SM) Place in SCSM_Admins group Read rights to SCCM database if not using connector accounts (see below) Read rights to AD if not using connector accounts (see below) Add as Remote Desktop User for all servers Needs log on local rights to servers
Workflow Account		Prod Test Dev	Workflow Account with email address Place in SCSM_Admins group Verify time zone associated with this user Needs log on local rights to servers
SQL Reporting Account		Prod Test Dev	Reporting Account (SSRS) Will be entered during SQL and SM Install
Analysis Reporting Account		Prod Test Dev	Analysis Account (SSAS) Will be entered during SQL and SM Install
SQL Service Account		Prod Test Dev	SQL Service Account, only if SQL does not already exist. Otherwise, you can use current SQL service account. Place in scsm_Admins group Used during SQL install Needs log on local rights to servers
Exchange Connector Account		Prod Test Dev	Service account used to communicate with MS Exchange to read and send e-mails. Create an email account (mailbox) in Exchange for this account. Just use the default email address Place in scsm_Admins group Verify time zone associated with this user Create Exchange Rule that does not allow Auto Replies to go to this email account Give SCSM administrators ownership rights over this email account, and have them add the mailbox to their Outlook locally (give rights to regular user accounts- not admin accounts) Ensure it has a (spam) account for whatever system filters incoming emails Needs log on local rights to servers
AD Connector Account		Prod Test Dev	AD Connector Account Needs read rights to Active Directory
SCCM  Connector Account		Prod Test Dev	SCCM Connector Account Needs read rights to SCCM SQL database server and database
SCORCH Connector Account		Prod Test Dev	SCOrch Connector Account Needs read rights to SCOrch
SCOM Connector Account		Prod Test Dev	SCOM Connector Account Needs Advanced Operator rights in SCOM
SCORCH Service Account		Prod Test Dev	SCOrch service account No special rights required.
AppPool Account		Prod Test Dev	Cireson Portal App Pool account Needs to be a local administrator on Portal server Needs to be a member of the Service Manager Administrator role Needs to be a SysAdmin on the following databases ServiceManager ServiceManagement. Analytics. (Note: Default database names may be different in specific environments)
Cache Builder Account		Prod Test Dev	Cireson CacheBuilder account is responsible for keeping the SCSM and Cireson databases in sync. Needs to be a local administrator on Portal server. Needs to be a member of the Service Manager Administrator role. Needs to be a dbo on the following databases: ServiceManager. ServiceManagement. Analytics. (Note: Default database names may be different in specific environments)
Portal Installer Account	This is the admin user doing the install	Prod Test Dev	The admin account that will run the portal install on the SCSM Server. Needs to be a local administrator on the Portal Server. Needs to be a member of the Service Manager Administrator role. Needs to be Sysadmin on the SQL Instance that the portal will be installed in to.

* Ensure GPO is not going to pull users or groups off computers
* Ensure the service accounts are not in OUs or Groups that will restrict “Logon as a service”
* Ensure the service accounts are not in OUs or Groups that will restrict “Batch logon”
* Ensure the passwords will not be changed
* Ensure the passwords do not contain $ or ‘

There are also several user groups that are required for each of the items below:

Generic Name	Group Name	Group Details	Group Permissions & Use
All SCSM Administrators		Group that is used to contain all administrators of SCSM. This can include service and user accounts as well as computer accounts if needed.	Place in administrators' group on all servers This group of users must be in the same domain as Service Manager. Users from any other domain—even child domains—are not supported.
All SCSM Analysts		Group that is used to contain all users that are going to be editing Work Items.	Used for SM Security Roles and Cireson Apps
All SCSM Report Users		Group that is used to contain all users that require access to view SCSM Reports within the SCSM Console and SSRS.	Used to control access to SSRS reports within SM
All Analysts for each support group	scsm_SupportGroupName	Each support group requires a separate group to contain users to assign to each group within the SCSM system.	Will discuss names during the planning phase, after initial server installs Will hide all from Global Address List (GAL)

*Can use company naming convention for prefix  e.g. scsm_   scsm.  scsm- 

Thank You – Cased Dimensions Migration

You’ve Got Email

Please check your email for the next steps, including a live demo of the Cireson solutions.

Live Webinars

On-Demand Webinars

Watch previous ITSM, ITIL, and System Center webinars and videos.

WATCH NOW

Cireson Community

Connect and collaborate with industry thought leaders, System Center experts, customers, and Team Cireson.

JOIN THE CONVO

Training Courses

In person and virtual training courses to fit your needs, budget, and timeline.

START LEARNING

Consulting Services

Our Services Team is comprised of ITIL-certified experts with deep product and industry knowledge.

LEARN MORE

SCSM Service Requests, 3 Success Factors

As a consultant with Cireson, I am often engaged with customers regarding SCSM Service Requests. The first things we discuss during these engagements are the most important factors to be successful. In this article we will talk in depth about the following factors:

Not knowing where to start
Trying to do too much
Service Catalog navigation

Not Knowing Where to Start

Where do we start when it comes to SCSM Service Requests? Try starting out with a general request that can be used as a “catch all,” and then branch out. When using a general request, you need to establish a procedure to handle these process-less requests. This is often overlooked because the end goal is to surround each service request with process unique to that request type. Being more realistic, there will always be requests that don’t yet have this process established, and we don’t want them to fail because of a lack of procedure. For example, if a request comes in for something less-than-common, does the Service Desk know how to classify, prioritize, and assign the request? Perhaps you can establish a process based on the category/area of the request, or a related configuration item. Lacking process here can lead to Analysts delaying the completion and/or a failed Service Request.

Another great place to start is Incident/Ticket Reporting to identify common End User Requests. These requests tend to be “I need something” such as an application installed, a second monitor, access to a network share, whatever…

Once you identify the most common requests, consider each one and determine if there’s value in adding this to your service catalog. When determining value analyze from both an End User and IT perspective. By now you should have a list of request offerings to build, great, now prioritize which ones to build now and which ones to build down the road. I say some now and some later because you need to document the current process for each, improve existing process or for some develop the process.

Trying to Do Too Much

When dealing with a first time Service Catalog, it is extremely important to keep it simple. Keep everything as a manual process and continue to fine tune until you have proven success. Once you are happy with the manual process, you can then start to introduce some automation. There is nothing worse than spending weeks automating a process, just to figure out that everyone doesn’t agree on that process.

After you have a process solidified, think about your ROI when determining if automation is worthwhile. For example, if you only spend 5 minutes on a task each month, it’s probably not worth spending 2 weeks to automate. If you spend 5 minutes a day on something, you will recoup your automation cost much more quickly. For example, let’s say you have a few Service Requests that require the Affected User’s manager to approve before they can proceed. Your current manual process is for the Service Desk to look up this manager in Active Directory and add that individual as an approver. The entirety of this task could be automated via an Orchestrator runbook or Cireson PowerShell activity with relative ease. With analysts likely doing this look-up routinely, it wouldn’t take long to make this worthwhile. While its great to have everything automated, it’s always a measurement of cost versus value.

Service Catalog Navigation

Once again, the theme of today is to keep it simple! When determining the layout of your Service Catalog, you need to keep the end user experience in mind. If the end user can’t find it, then they definitely will not use it.

Try to keep navigation simple, and drill-down to requests with simplified categories. For example, don’t have 20+ choices to make right off the bat, and don’t have several choices that are similar, like “Desktop Request” and “Equipment Request.” Remember that Cireson Advanced Request Offerings offer conditional questions based on answers to previous questions. This means that you can cover several similar request types in a single form, such as “Laptop requests” and “Mobile Device requests.”

There are also scenarios where a general end user will not need access to a certain request offering. Fortunately, SCSM Service Requests can be scoped by Active Directory group using “Catalog Item Groups,” so you can hide offerings from some groups if not relevant. This is another method you can use to keep the choices relevant and focused.

Summary

In order to be successful with SCSM Service Requests, try to keep the above in mind. Use analytics and reporting to prioritize the Service Requests to build. Do not overlook generic Service Requests and branch out from there. For each request you design, once you have proven success with the manual approach, you can then start to introduce some automation. Don’t try to automate broken processes! As you build out different request types, don’t forget to take a step back and look at the overall design of the Service Catalog. Keep it simple and remember to think about it from the end user’s perspective.

Thank You – itnetx Migration