Service Manager Database Tour & Useful Queries

http://blogs.technet.com/b/servicemanager/archive/2009/12/31/service-manager-database-tour-useful-queries.aspx#3414058

Inserting links to Review/Manual Activities in notifications.

http://blogs.technet.com/b/servicemanager/archive/2010/01/28/inserting-links-to-review-manual-activities-in-notifications.aspx#3391004

Strange issues with the SCSM Mangement Server

I sometimes find strange issues with the SCSM management server. For example, my connectors have not synchronized in several days. Performing a manual synchronization does nothing. When I look in the event log, there are no errors, but there is a sync start/end immediately.

I have found that a restart of all the SCSM services will clear this up. If services restarts do not work, a server restart usually does work.

Create Recurring Change Requests

http://www.scsm.se/?p=239

All work Items assigned to me

http://blogs.technet.com/b/servicemanager/archive/2010/09/28/all-work-items-assigned-to-me-view.aspx#3386613

Export all unsealed MPs

http://www.scsm.se/?p=227

Here’s a little powershell script that I use for exporting all unsealed MPs. It’s really useful to run once in a while so you have a backup of all unsealed MPs. The script will create a new folder with the current date and store all MPs in that folder. Change the $OutPutDir variable to a folder of your choice. [powershell] Add-PSSnapin SMCMDLetSnapIn $OutPutDir = “C:\Unsealed MPs\” $UnsealedMPs = Get-SCSMManagementPack | ?{ ! $_.Sealed } $CurrentDate = Get-Date $CurrentDate = $CurrentDate.ToShortDateString() $CompletePath = ($OutPutDir + $CurrentDate) if ( ! (test-path $CompletePath)) { $output = New-Item -Type Directory -Name $CurrentDate -Path $OutPutDir } $UnsealedMPs | %{ ” Exporting: {0}” -f $_.Name $_ | Export-SCSMManagementPack -directory “$CompletePath” } [/powershell]

SharePoint Surveys with SCSM

http://blogs.technet.com/b/servicemanager/archive/2009/12/08/incident-resolution-satisfaction-surveys-on-sharepoint.aspx

SCSM Portal is Slow - I got a suggestion from Travis Wright

I got some more information from one of our devs today.  Try this:

• Open IIS
• Select the Application Pools view
• Select the SM_AppPool application pool (unless your portal is using a different app pool for some reason)
• Click the Advanced Settings... link in the Actions pane on the right (or in the context menu)
• Scroll down to the bottom to the Recycling section
• Change the Regular Time Interval (minutes) option to 0 (never recycle)

That will make sure the portal doesnt just recycle the app pool and require a rebuild just because a certain amount of time has passed.

SLA Management

http://blogs.litware.se/?p=749

http://blogs.technet.com/b/servicemanager/archive/2009/12/08/incident-resolution-satisfaction-surveys-on-sharepoint.aspx

http://blogs.technet.com/b/servicemanager/archive/2009/12/08/incident-resolution-satisfaction-surveys-on-sharepoint.aspx

A few SCSM Customizatin links

Incident Resolution Satisfaction Surveys on SharePoint
Automatically Sending Notifications to Reviewers
Inserting links to Review/Manual Activities in notifications

Enabling Users to Take Action from Email Using Web Pages/Web Services

http://blogs.technet.com/b/servicemanager/archive/2011/01/25/enabling-users-to-take-action-from-email-using-web-pages-web-services.aspx#3383712

Travis Wright [MSFT] 

25 Jan 2011 2:22 PM 

• 4

This is a guest blog post from a Microsoft Consulting Services Senior Consultant – Andreas Rynes.  He has become a Service Manager expert lately and has come up with a really innovative solution I wanted to share with you all.  The scenario that Andreas writes about in this blog post is a way to enable an end user to receive an email notification when his incident is resolved and then to click a link to either reactivate or close the incident.  The link passes the work item ID on the query string and the web page the user is directed to by clicking on the link either updates the incident status to closed or active depending on the link the user clicked.  The exciting thing about this is not just this particular solution but the pattern which can be followed to enable many other types of scenarios for SCSM.  Some other scenarios I could see working with this pattern are: change request approval/reject, going to a web page to provide additional information about an incident, viewing the status of a change request, etc. 

This solution is similar to some of these that we have already published if you are interested in looking at other examples of doing this kind of thing:

Incident Resolution Satisfaction Surveys on SharePoint

Automatically Sending Notifications to Reviewers

Inserting links to Review/Manual Activities in notifications

Thanks for writing this up Andreas and sharing with the community!

====================================================================================================================

During a SCSM session with my customer, while we gathering requirements for their implementation of SCSM, they asked me for the following requirement: whenever an incident is resolved by an analyst the affected end user should be notified with an email. This is nothing special and can be done easily with SCSM workflow features out of the box. So I thought: “yes, of course”, but then they continue with their requirements, that this email should include an option to close or reactivate an incident. The idea behind that requirement is that the end user is the one that can decide if the topic described within the incident was resolved or needs further attention by an analyst.

So the solution is not that complex, but it needs some very different parts to fulfill the requirement. First you need to use the SDK from Service Manager to define methods to close and activate an incident, the second part is the mail template, which can be defined within the Service Manager console and the third part is the workflow that triggers the notification, also managed within the console.

Part I – Visual Studio

1) First I’ve created a solution within Visual Studio. I’ve decided to create a Web Service to implement the functionality for the simple reason that a web service gives you the flexibility to use it both from a web and rich client application.

Start Visual Studio, click on File – New – Web Site … and choose ASP.NET Web Service and give it a meaningful name like SCSMIncidentService

VS creates a template for a asmx web service with three important files called service.cs, service.asmx and a web.config file. I won’t go into detail about SOA architecture or web services and how to implement that within Visual Studio. So I just mention all the details needed for this specific solution.

1) Now go on and remove the already generated first web method “HelloWorld” and implement the SCSM functionality.

2) After that you need to add references to the SDK, for that switch to the Solution Explorer, click on the right mouse button at the project and choose Add Referenceand go to the tab Browse and go to the Service Manager installation folder (normally on C:\Program Files\Microsoft System Center\Service Manager 2010\SDK Binaries and choose all three files there.

3) Then add these using statements in the service.cs file by adding the following lines at the very top:

using Microsoft.EnterpriseManagement;

using Microsoft.EnterpriseManagement.Configuration;

using Microsoft.EnterpriseManagement.Common;

You can also add another namespace, System.Configuration (as shown in the screenshot). I’ll describe later why we could use this one as well.

4) We first start implementing a constructor for the service that initiates all the required classes like the ManagementGroup with either an FQDN or localhost (I’m hosting that service on the same server as the Service Manager Data Access Service) of the Service Manager.

In the second line you’ll see the usage of ConfigurationSettings.AppSettings, which is why we add the System.Configuration namespace to the service. This uses the AppSettings section of the web.config file to gather the Version and PublicKeyToken for the Management Pack. The advantage of using the web.config is that you don’t have to hardcode those values in the code and with every change you would have to re-compile it everytime. If you put those values in the web.config you can just change the xml file.

Then we need the ManagementPack for the Incident class and the enumeration of the status of incidents. We put all these in the constructor of the service class.

5) Then we are going forward to implement the two web methods, I’ve called them CloseIncident and ActivateIncident. Those methods accept the ID from the incident (e.g. IR10) and a string for the current user, who called the method. That mechanism is needed to avoid closing or activating incidents by accident from other users (I’ll describe that feature in a moment). Both methods call another private method called UpdateIncident. That method does the real work and accepts three parameters - those two from the Webmethods and another one that defines if the incident needs to be closed or activated.

6) UpdateIncident has some more lines, but not that much. It initiates another MP that hosts a TypeProjection. This is required to get the Affected User (as this is not part of the Incident class, but is a relationship to a user instance) to compare it with the actual user (we’ll get the user from the security principial context of the webpage).

From that MP we initiate the TypeProjection and with the help of a criteria string that defines the search criteria for the TypeProjection (in this case the incident class is the seed of the TypeProjection) we can use GetObjectProjectionReader to receive the specific incident. If the incident with the specified ID was not found then the method return false. If there is a record found we use a ManagementPackRelationship instance to get the Affected User. Then we compare it with the activeUser string and make sure that the incident is not closed already (because from an ITIL process view a closed incident should not be re-activated again).

The real work is done within two lines of code, set the status to the string that is passed in the UpdateIncident method (close or active) and overwrite the instance.

7) The last thing we need to clarify for the service is the CreateIncidentCriteriaXml method that just returns the criteria that is needed to receive the correct incident. For that we just use a simple expression that uses the ID attribute of the WorkItem as the left part and the searchString as the right part and the equal operator.

So with that, we’ve finished the service.

8) You would be able to test that asmx service already, just press F5. You will get an interface in the browser to test your two webmethod.

Next, we need to create two aspx websites that calls the service and give the user some sort of feedback, if the call was successful or not.

After adding those aspx webpages to your solution go and add a method to each of both, one for activateIncident and one for closeIncident. There are two parameters that we need to get to call the service, the ID of the incident and the name of the current user. For the first parameter we just crawl the QueryString (so we have to set the ID in the URL in the email template later) and for the current user we call the WindowsIdentity.GetCurrent() method. Then initiate the service and call one method per each aspx webpage.

9) After that you’re absolutely free to design the webpage and customize it that it fits your needs and UI definitions and requirements. In my case I’ve just added some positive text if the method returns 0 or some negative text for the value 1.

Part II – eMail Template

Now it’s time to create the email template

Before you create the email template, the second part of our solution, it’s time to configure the notification channels within the SCSM console. Go to Administration – Notifications – Channels and choose the e-Mail Notification Channel and double click it or click on Properties in the task pane. There you need to configure your SMTP server, a return email address and enable the e-mail notification.

After that click on the templates within Administration – Notifications to create your new template.

i) General

Give the template a name and describe it. The most important part on that first page of the wizard is to choose the correct target class, which is Incident in this case and put it in your own management pack.

ii) Template Design

In the Template Design tab you can design your mail, if it’s old-style text email or a HTML formatted mail, the mail subject and the body. For me, I’ve decided to generate an HTML-formatted mail with some fancy stuff like images and different font-styles. The result could looks like this or even better if you like:

You can define your own CSS styles and arrange the text and images where you want them to be. The best way it works for me was using an editor outside of the console and create the entire look and feel there. Then the HTML source can just be copy/pasted into Service Manager’s notification template wizard textbox.

You can see more information about how to create notification templates in this blog post:

http://blogs.technet.com/servicemanager/archive/2009/09/28/creating-notification-templates-in-system-center-service-manager.aspx

The most importing thing is the URL of those two hyperlinks, as we defined two webpages we need to use those and add the incident ID with ?ID=IR10 (we need to replace that in the console with dynamic data from the incident)

Then just paste the complete HTML code to the console template wizard and replace the dynamic text parts with those items from the incident instance with theInsert… button (don’t try to just type the value in – that won’t work. Use the Insert… button).

From there you can choose the attributes from the incident and related entities, which are then placed within the template (both body and subject field). For example you have to replace the URL with <a href="http://atssm/ServiceManagerSample/CloseIncident.aspx?ID=$Context/Property[Type='CustomSystem_WorkItem_Library!System.WorkItem']/Id$">Incident wieder eröffnen</a> (Please note that you have to customize the URL to your own webserver and webapplication!)

The result looks like the screenshot below:

After that you’re done with the template, just click on Next for the Summary tab and finish the wizard.

Part III – Workflow

Now we have the web services/site pages and the email template, now we need the workflow that triggers the entire solution.

Open the console and go to the workflow configuration view that can be found under Administration – Workflow – Configuration. There are some already defined workflow configurations that can be used and we go with the Incident Event Workflow Configuration. After selecting that entry click on Properties in the task pane.

Now you can setup a new workflow that runs whenever an Incident is updated or created.

So click on Add and fill out the Workflow Information that are asked, take care to choose “When an incident is updated” in our case and choose also the correct Management Pack (it makes sense to choose the same as for the template, so that the solution is built in one single MP). And of course, enabling the workflow with the checkbox makes a lot of sense here J

Now we have to define the criteria when the workflow should be triggered. For now we just said whenever an incident is updates (which would be true, if someone just updates a description or any other field on the incident form). So we need to define that this should run only if the Status is changed to Resolved.

So keep the “Changed from” empty as this is not important to us, but add the Status in the “Changed To” tab and enter resolved to the textbox next to it.

So now it’s time to tell the workflow configuration what to do, when it is triggered. In our solution we’d like to Select People to Notify. So in the specific tab make sure the checkbox Enable notification is set and choose Affected User in the ComboBox and choose the new created mail template a couple of minutes before. And don’t forget to click the Add button (I did this from time to time J).

After that setup we are all set and done. Finish the wizard and see if the window for the Incident Event Workflows is updated with your new workflow definition.

Now it’s time to test the complete solution by resolving an incident in the console. Make sure that you have an incident that has an Affected User filled out and that this user has an email-address in the Active Directory and in the Service Manager database, otherwise there will no email be generated. If that’s a test lab environment like it was in my case, you can enter an email address in the CMBD on the user entity form, but make sure that you disable the AD Connector for a test, as it might overwrite the email-address with a blank value again J

In my template, I’m using also the Resolution Category and Comments from the analyst, so I put some more or less useful text in those fields and resolve the incident.

A couple of seconds later the email is generated and showing the correct values from the incident and the option to close or re-activate the incident with a simple click on the specific link.

The user gets a response that his/her incident was closed now (or re-activated) with the HTML page I designed before.

The source files for this solution are attached.

 EMailIncidentSample.zip

Fill Incidents using only the Keyboard

This video will show you how to use the keyboard to quickly fill out forms without using the mouse.  Service Manager provides a couple of custom form controls designed to make data entry faster and easier: 1) the User Picker control and 2) the List Picker control.  In this video I’ll show you how to select items in those controls faster by using just the keyboard and not using the mouse.  Note: this video is done using the SP1 build of SCSM 2010 which is slightly different (improved). http://www.youtube.com/watch?v=1R7FxV8ZybE

Service Manager Performance

Excerpt from the MS website: http://technet.microsoft.com/en-us/library/ff461124.aspx
Updated: December 1, 2010
Applies To: System Center Service Manager 2010

Performance for Service Manager server roles and features are affected by different factors. Generally, there are three areas where positive and negative performance is most noticeable in Service Manager:

• Service Manager console responsiveness. This is the length of time it takes from the moment you take some sort of action in the console until it completes.
  
• Data insertion time for connectors. This is how long it takes for Service Manager to import data when a connector synchronizes.
  
• Workflow completion time. This is the length of time it takes for workflows to automatically apply some kind of action.
  

Connector Performance

Connector initial synchronization can take a significant amount of time, for example 8-12 hours for a large initial synchronization with System Center Configuration Manager. As a connector synchronizes initially, you can expect performance to suffer for all Service Manager server roles and processes during this time. This occurs because of the way that data is inserted sequentially into the Service Manager database, which is a SQL Server database. Although you cannot hasten the connector’s initial synchronization process, you can plan for the initial synchronization and to ensure that the synchronization process completes well before Service Manager is put into production.
Once the initial synchronization is complete, Service Manager continues synchronizing the differences, which does not have a measurable impact on performance.

Workflow Performance

Workflows are automatic processes that occur and include sending e-mail notifications, the next step of a change request activating, and automatically applying a template.

• Normally, workflows start and finish within 1 minute. When Service Manager server roles are under a heavy workload, workflows do not complete as quickly as normal.
  
• Additionally, when you create new workflows, such as a new notification subscription, additional load is placed on the system. As the number of new workflows that you create increases, the time it takes for each one to run also increases.
  

When the system is under a heavy load, if for example a large number of new incidents are being created and each incident generates many workflows, then performance might be negatively affected.
If you plan to create a large number of workflows, one possible solution to help improve performance is to use the ManagmentHostKeepAlive management pack that is included in the Service Manager release media.

• You need to manually copy the two files from the source directory into the Service Manager installation directory, and then import the management pack files.
  
• Importing these management pack files can greatly increase workflow processing responsiveness where almost all workflows process within 1 minute.
  
• However, importing this management pack gives higher priority to workflow processing and can lead to slower Service Manager console response in some cases so you should test its impact before deployment in a production environment.
  

Groups, Queues, and User Roles Impact on performance

You should plan for groups and user roles early. Often, people create groups to make sure users have access to specified groups only. For example, in one scenario you might want to create a subset of incidents such as incidents that affect computers used by human resource personnel. In this scenario, you might want only specific personnel to be able to view or modify the group of sensitive servers. Then, to enable this type for access you would need to create a group for all users and a group for sensitive computers, and then ensure that a security role has access to both the All Users and the Sensitive Servers groups. Inevitably, creating a group containing all users results in performance impact because Service Manager frequently checks to determine if there are changes to the group. This check occurs once every 30 seconds, by default. For a very large group, checking for the changes creates a heavy load on the system and may slow down response time considerably.
Solution 1: You can manually specify how often Service Manager checks for group changes by modifying a registry key. For example, if you change the group check frequency from 30 seconds to 10 minutes, you will significantly increase performance.

Caution
Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

To manually specify the group change check interval

1. Run regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.
2. Create a new DWORD value named GroupCalcPollingIntervalMilliseconds.
3. For its value, specify the interval in milliseconds. The result is multiplied by 6. For example, to set the interval to 10 minutes, type 1000000.
4. Restart the System Center Management service.

Solution 2: You can use a Windows PowerShell script to add objects of a type, such as “Users”, to a user role. Essentially, an analyst logged on in this role can access all objects that have a type equal to “User”. If you use this method, you eliminate the need for a very large group (“All Users”) and the expensive check that Service Manager performs to determine this group membership. On the Service Manager management server, you can run the following Windows PowerShell script to set add “user” type to a role “RoleName”. You will need to modify this example script for your environment.

To run a Windows PowerShell script to add objects to a user role

• Modify as needed and then run the following script.

Copy Code

#
# Insert a "type" scope in a role
# Syntax:
#   AddTypeToRoleScope -server "put_server_name_here" -RoleName "put display name of the role here" -TypeToAdd "put display name of the type to add to scope here"
#
# Note:  This is a simple demonstration script without error checking. 
# 
 
# set script parameter defaults
param ([String]$Server = "localhost", [String]$RoleName="My Analyst Role", [String]$TypeToAdd="User")
 
 
$a = [reflection.assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.Core")
 
$m = new-object Microsoft.EnterpriseManagement.EnterpriseManagementGroup $Server 
 
# Get Type object
#   Note:  If you need to get a list of all available classes related to (for example) “User”,   use this command:
#               $m.EntityTypes.GetClasses() | ?{ $_.Name -like '*user*'} | %{ $_.Name}
#
$type = $m.EntityTypes.GetClasses() | ?{ $_.DisplayName -eq $TypeToAdd}
 
# Get role object, and insert the type GUID into scope
$role = $m.Security.GetUserRoles()  | ?{ $_.DisplayName -eq $RoleName}
$role.Scope.Objects.Add($type.Id)   
$role.Update()
 
# 
# Get the value from the database again and validate it is there
if ( $role.scope.objects.Contains($type.Id) ) {
    write-host *** Successfully set the scope for role `" $role.DisplayName`" and it now contains all instances of $type.DisplayName `( $type.Name `)
} else {
    write-host "There was an error trying to insert the scope into the role."
}

View Performance

When creating views, plan on using “typical” classes in the system whenever possible. Most object classes, for example Incident Management, have two types: “typical” and “advanced”. The typical object type contains simple references to a small subset of data related to an item. The advanced type contains many complex references to data related to an item. Typical types are simple projections, advanced types are complex projections. Most advanced object types are used to populate different fields in forms that you would not normally want to see displayed in a view. Whenever you create a view based on an advanced object type and when you open the view, Service Manager queries the database and a large amount of data is read. However, very little of the retrieved data is actually displayed or used.
If you have performance problems with the views you’ve defined and you’ve used advanced object types in views, you should switch to using typical types. Or alternatively, you can create your own projection types that contain only the data you need to base a view upon. Refer to the Creating Views That Use Related Property Criteria (Type Projections) : Software Views Example blog post (http://go.microsoft.com/fwlink/?LinkId=184819) blog entry on the SCSM Engineering Team Blog.

Service Manager Database Performance

Performance of the Service Manager database is directly affected by various factors including the number of concurrent Service Manager consoles reading or writing data, the group change check interval, and data inserted by connectors. More information is available in this document. Here are a few key points.

• You should have a minimum of 8 GB of RAM for the management server that hosts the Service Manager database in order to have acceptable response time in typical scenarios.
  
• You should have at least 4 CPU cores on the computer hosting the Service Manager database.
  
• You can achieve better database performance by segregating log files and data files to separate physical disks, if possible. You can achieve further benefits by moving your tempdb on a different physical RAID drive than that of the Service Manager database. Use a RAID 1+0 disk system to host your Service Manager database, if possible.
  
• Performance can be negatively impacted if the Service Manager database is created with a smaller size and set to autogrow especially by small increments.
  

Refer to the Service Manager Sizing Helper tool included in the Service Manager job aids documentation set (http://go.microsoft.com/fwlink/?LinkId=186291) to help assess the size of the database and create the database with a size closer to the final size, this will help performance by reducing the amount of times the database has to autogrow.
Similarly all the other best practices that are applicable to a high performing database are applicable, as well. For example if you could take advantage of a superior disk sub system, you could benefit from splitting up the groups of tables on respective filegroups and moving them to a different physical drives.

Service Manager Management Server Performance

Performance of the Service Manager management server is primarily affected by the number of active concurrent Service Manager consoles. Because all Service Manager roles interact with the management server, you should consider adding additional management servers if you plan to have a large number of concurrent consoles. You should have a minimum of 8 GB of RAM for the management server. You should have at least 8 CPU cores per management server, assuming you have 10-12 active consoles per CPU core, for a total of 80-100 consoles per management server.

Service Manager Console Performance

Performance of the Service Manager console is primarily affected by the number of forms your analysts typically have open and the amount of data retrieved by views. You should have a minimum of 2 GB of RAM for the computer where the Service Manager console is installed. If you have views that retrieve a large amount of data, you will need additional RAM. You should have at least a dual-core CPU for the computer where the Service Manager console is installed. Because the Service Manager console is an end user application, we recommended that you restart it if you see excessive resource consumption – the Service Manager console aggressively caches information in memory, which can contribute to overall memory usage.

Service Manager Data Warehouse Database Performance

Performance of the data warehouse is directly affected by various factors including the number of concurrent Service Manager management servers sending data, volume of data stored or the data retention period, rate of data change, and the ETL frequency. The amount of data stored in the data warehouse increases over time. Ensuring that you archive unnecessary data is important. Additionally, you can achieve better performance by segregating log files and data files to separate physical disks. Similarly you can achieve better throughput by putting the tempdb on a different physical disk than the other databases. Lastly, you can benefit by placing the three different databases on their respective physical disks, as well. Use a RAID 1+0 disk system to host your data warehouse, if possible. You should generally have a minimum of 8 GB of RAM for the computer where the data warehouse databases are installed, you will benefit from more memory on the SQL Server that hosts the data warehouse and even more so if the Datamart and Repository databases are on the same server. However, if you have 4,000 or fewer computers, then 4 GB is sufficient. You should have at least 8 CPU cores in the computer where the data warehouse database is installed. Additional cores will help both ETL and report performance.
Performance can be negatively impacted if all the databases in the system are created with a smaller size and set to autogrow especially by small increments. Refer to the Service Manager Sizing Helper tool included in the Service Manager job aids documentation set (http://go.microsoft.com/fwlink/?LinkId=186291) to assess the size of the database and create the database with a size closer to the final size, which will help performance by reducing the amount of times the database has to autogrow.
Similarly all the other best practices that are applicable to a high performing database are applicable, as well. For example if you could take advantage of a superior disk sub system, you could benefit from splitting up the groups of tables on respective filegroups and moving them to a different physical drives.

Service Manager Data Warehouse Server Performance

Performance of the data warehouse server is affected by the number of Service Manager management servers that are registered to the data warehouse and by the size of your deployment. You should generally have a minimum of 4 GB of RAM for the data warehouse server; however you’ll benefit by having additional memory up to 8 GB of RAM for advanced deployment scenarios where more than one Service Manager management server inserts data into data warehouse. If you must tradeoff performance, your highest priority should be for memory for the SQL Server. You should have at least 4 CPU cores to prevent performance problems. The data warehouse server is mostly stateless and it is unlikely to pose an I/O problem, so it should not present a performance problem.

Self Service Portal Performance

The Self-Service Portal is designed for easy access to incident filing and software self-provisioning. It is not designed to handle thousands on users simultaneously using it. When complete, more thorough performance guidelines for the Self-Service Portal will be published.
Performance testing for the Self-Service Portal was focused on typical “Monday morning” scenarios. Specifically, to ensure that on Monday morning hundreds of users can log in within the span of 5-10 minutes and open incidents with acceptable (less than 4-5 seconds) response times. This goal was achieved with the minimum hardware recommended in this document.

Workflow Performance - Management Packs on the media to help Performance

Workflow Performance

Workflows are automatic processes that occur and include sending e-mail notifications, the next step of a change request activating, and automatically applying a template.

• Normally, workflows start and finish within 1 minute. When Service Manager server roles are under a heavy workload, workflows do not complete as quickly as normal.
  
• Additionally, when you create new workflows, such as a new notification subscription, additional load is placed on the system. As the number of new workflows that you create increases, the time it takes for each one to run also increases.
  

When the system is under a heavy load, if for example a large number of new incidents are being created and each incident generates many workflows, then performance might be negatively affected.
If you plan to create a large number of workflows, one possible solution to help improve performance is to use the ManagmentHostKeepAlive management pack that is included in the Service Manager release media.

• You need to manually copy the two files from the source directory into the Service Manager installation directory, and then import the management pack files.
  
• Importing these management pack files can greatly increase workflow processing responsiveness where almost all workflows process within 1 minute.
  
• However, importing this management pack gives higher priority to workflow processing and can lead to slower Service Manager console response in some cases so you should test its impact before deployment in a production environment.
  

Additional Cmdlets from CodePlex - Very Useful

http://smlets.codeplex.com/

List of the Service Manager Cmdlets

http://technet.microsoft.com/en-us/library/ff460963.aspx

E-mail user from Service Manager Console - SCSM Engineering Team Blog - Site Home - TechNet Blogs

Very Useful Time saver for Analysts

E-mail user from Service Manager Console - SCSM Engineering Team Blog - Site Home - TechNet Blogs

When trying the "Request Software" link on the end user portal, you get the message "Unable to load portal ActiveX Control.

Problem: When trying the "Request Software" link on the end user portal, you get the message "Unable to load portal ActiveX Control."

Resolution: Install the PortalClient.msi file located on the Installation media. When you install the media, you receive no notifications, but that is OK. It still worked. Try to request software again.

Most users will use the self-service portal to request software. Create a package in SCCM to deploy the package to all workstations so users never see this error.

SCSM Command Shell

Unlike Operations Manager and Exchange 2010, the Service Manager command shell is not simply a shortcut. However, you can add the Service Manager command shell to PowerShell. The below is a clip taken from a TechNet article.

To add the Service Manager Windows PowerShell snap-in to a PowerShell session

1. On the computer that you run Windows PowerShell on, for example, the computer that hosts the Service Manager or data warehouse management server, on the taskbar, click Start, point to Programs, point to Windows PowerShell 1.0, right-click Windows PowerShell, and then click Run as administrator.
2. In the Windows PowerShell window, type the following commands:

• Set-ExecutionPolicy RemoteSigned
• Add-PSSnapIn SMCmdletSnapIn