Objective

Introduction

Performance, as it pertains to System Center Operatio= ns Manager 2007, is measured by the user experience while working in the operations console. Performance can also be measured as a function of alert latency, the time elapsed from when a condition is detected which requires= the generation of an alert and the actual time the alert appears in the consol= e.

Imagine a situation where alert latency is performing= as expected, even exceeding operational performance requirements. Additionall= y, notifications are being generated and received in near real-time. If the operational console is performing poorly: refresh rates excessively slow, creation, modification and rendering of views also excessively slow; then = now how to you describe the performance of the management group?

At the end of the day, the user experience in the ope= rations console is the most important facet of performance in Operations Manager 2= 007. No matter how perfect the functionality of the management group, its value= is destabilized if users can=92t seamlessly navigate in the operations console.

The most common solution for ensuring performance in = the operations console is to engineer the optimal infrastructure to host the management group. This primarily centers on the SQL 2005 database hosting = the OperationsManager database and secondarily the RMS.

Assumptions

Maximizing performance with User Roles is only effect= ive if all other infrastructure components are optimally configured. Be sure to r= esolve any resource deficiencies prior to implementing User Roles. The improvemen= t in performance through the implementation of User Roles is terrific but only = if there are no existing resource issues.

How It Works

The left side of the equation must equal the right si= de of the equation. Traditionally, ensuring performance in a management group wo= uld be accomplished by adding more resources to the management group. However,= what if you could reduce the resource requirement of the management group witho= ut reducing the functional requirements? One technique for achieving this is through the implementation of User Roles; maximizing the efficiency of the operations console by authoring surgical scopes to only display the exact objects required by a user. The default operations console returns all obj= ects defined by all management packs. In an enterprise environment the resource= hit on the OperationsManager database is expansive. User Roles are used to def= ine explicit views and are associated with their login. A user, regardless of = where they login would always receive their view. This includes the web console too.=A0 The roles would be authore= d to contain only the objects and views required by that person=92s technical r= ole. So an Active Directory SME would have an entirely different view than an Exch= ange SME. By removing all ancillary views and objects, non-essential data, the resource requirements are drastically reduced thus requiring less power resulting in improved performance in the operations console. This is illus= trated by a resource triangle.

Figure 1: Resource T= riangle

Planning

Before deploying User Roles, it is vital to have an administrative plan[3] in place. Simply, this is document describing who does what in Operations Man= ager 2007. The objective is to explicitly describe the role and responsibility = of the IT administrators, those who will be using the operations console, then translating into a specific set of Views and Tasks, necessary to allow the= m to fulfill their monitoring and diagnostic duties. This will provide all information necessary to author the appropriate User Role. Lastly, deploy = the User Role via the web console if there is no reduction in functionality. <= /p>

Profiles

System Center Operations Manager 2007 comes with seve= ral built-in profiles. The most common is the administrator profile which is typically generously used in most environments. This profile should be res= erved for as few IT administrators as possible. The operations model I tend to f= avor in large environments is that of a centrally managed Management Group. A s= ingle person / team (OpsMgr Administrato= rs) are responsible for the Management Group. They are responsible for everyth= ing pertaining to Administration, Authoring, Monitoring and Reporting. They ar= e the only persons with Operations Manager Administrator privileges. The other u= sers to access the operations console / web console are subject matter experts = (SMEs). The SMEs then work with the OpsMgr Administrators to ensure management pac= ks are deployed and performing properly, all custom reports are created corre= ctly and lastly, all views are authored and functioning correctly. As I noted a= bove, unless there is a piece of functionality needed in the Operations Console = and not available in the web console, all SME should leverage the web console.=

Scenario

The scenario described below is simple but provides t= he framework to build any User Role to meet even the most demanding administrators. This scenario will demonstrate how to create a USER Role f= or an Active Directory SME whose primary responsibility is to monitor their enti= re Active Directory environment.

In Operations Manager 2007, views, like other monitor= ing objects, are contained in Management Packs. If a view is contained in a se= aled Management Pack, you can open the properties of the view but you cannot sa= ve any changes to it. Instead, you can change the display options of the view= and then save it as a personalized view. So before serving up views with User Roles, the views must first be created.

1.&= nbsp; Create a new management pack to contain all authored views. You have much flexibility. You can create one management p= ack for all views served up through User Roles or perhaps, one management pack= per User Role. This all depends on the administration model decided upon. For = the purpose of this document, I created a single management aptly named User R= oles. After its creation, you will see a new folder in Monitoring.

2.&= nbsp; Create a new folder under User Roles named Active Directory Support.

3.&= nbsp; Insert / create all desired views. You can = use the views in the Microsoft Windows Active Directory management pack to get started. In OpsMgr 2007 SP1, you can now Copy / Paste various objects, including views, from one sealed management pack to an unsealed management pack.

In addition, the user can create his or her own views= by going to My Workspace.

4.&= nbsp; Now that the desired view has been created,= it now must be added to a custom User Role. For this demonstration, the User = Role will be named =91Active Directory Support=92.

5.&= nbsp; Create a new Global Group named Active Dire= ctory Support. It will contain all domain users who will have access to this User Role.

6.&= nbsp; In the operations console, go to Administra= tion / Security / User Role. Right-click User Role and select New User Role / Operator

7.&= nbsp; Add the global group created in step 5 and = name the User Role

8.&= nbsp; Click Next, deselect all Groups. Select AD = Doman Controller Group

9.&= nbsp; Click Next, select which Tasks, if any, the= User Role has access to.

10.= Select Views:

11.= Click Create

So now, when any domain user, who is a member of the = global group =91Active Directory Support=92 launches the Operations Console, they= will be presented with:

The above is simply a sample and can be modified as n= eeded.

Conclusion

User Roles are instrumental in maximizing performance= . In addition to reducing the performance impact of the operations console, they also provide a concise view of all objects only applicable to a users=92 technical role. They will enjoy a speedy console while not being distracte= d by any ancillary views, alerts or events.