Kevin Holman's System Center Blog

Configuring the SharePoint 2013 Management Pack

Kevin Holman — Tue, 14 May 2013 01:13:40 GMT

The management pack for SharePoint 2013 (including server and foundation) is available here:

http://www.microsoft.com/en-us/download/details.aspx?id=35590

As of this writing – the version on the download site is 15.0.4425.1000 however the ACTUAL version of the management packs are 15.0.4420.1017. I have no idea why we don’t make these match up.

First – import the MP’s:

As a best practice, also ensure you have imported and configured the Windows Server Operating System, SQL Server, and IIS management packs for your OS versions. Then – the SharePoint MP’s:

We will assume you have installed SharePoint 2013, and deployed an agent to these servers. When monitoring a farm, you need to ensure agents are deployed to all farm role computers, including the SQL database servers.

Next – I recommend you perform this step on your management server. We need to copy the configuration file “microsoft.sharepoint.foundation.library.mp.config” that shipped with the management pack files, to the following location:

C:\Program Files\System Center Management Packs

This MUST be placed in this specific location. You might have to create the directory if it does not exist. If you had previously configured SharePoint 2010 on this same server, you will see your SharePoint 2010 config file present, as seen in the graphic above.

Open the microsoft.sharepoint.foundation.library.mp.config file using NotePad, and find the section “<Association Account”

<Association Account="SharePoint Discovery/Monitoring Account" Type="Agent">
<Machine Name="" />
< /Association>

We need to create a RunAs account for the SharePoint 2013 MP to use. This RunAs account display name MUST match the “Association Account” in the config file. Here is where we need to have a quick discussion.

The SharePoint 2010 MP’s and config file use the SAME default name of “SharePoint Discovery/Monitoring Account”

If you are NOT monitoring SharePoint 2010, then you can continue and use the default name. If you ARE monitoring SharePoint 2010 already – then you have two choices.
If your CURRENT SharePoint monitoring RunAs account credential is also a Farm Admin in SharePoint 2013 – you can just use your existing RunAs Account and continue.
If you are monitoring SharePoint 2010 already, and you wish to use a DIFFERENT credential for monitoring SharePoint 2013, then you will need to modify the config file.

Honestly – the config files for SharePoint 2010 and 2013 should not have used the same default name for the RunAs account and the profile. I’m hoping they change this in future versions because it just makes everything harder to support.

At any rate – I was not able to get the 2013 MP to use a unique RunAs account… no matter what I did it was always using the SharePoint 2010 MP’s credential, even when it was not distributed to my SharePoint 2013 servers, which is bizarre. At this point I’d recommend using the same credential for all Farms if you are trying to monitor SharePoint 2013 and 2010. I continue to investigate this.

Next – I will create a new Run As account – with this EXACT name (unless it already exists)

Open the RunAs account we just created – and on the distribution tab – add in the servers that are part of the farm, or SQL servers that host farm databases:

At this point – I need to ensure that my RunAs account credential that I just used is a Farm Admin, and has full access to all SharePoint SQL servers/databases.

Next – we need to configure the SharePoint config file for the server names for our SharePoint 2013 and SQL servers. If you don’t edit the file with specific Farm Server and Database Server names, then SCOM will try and discover SharePoint 2013 on EVERY server in the management group. It is best to scope this down in advance. Open the file in NotePad, and under "Association Account” add a “Machine Name=” line for each server in your farm. For instance, my Farm consists of “shpt2.opsmgr.net” and “db1.opsmgr.net” so my file will look as follows:

<Association Account="SharePoint Discovery/Monitoring Account" Type="Agent">
<Machine Name="shpt2.opsmgr.net" />
<Machine Name="db1.opsmgr.net" />
< /Association>

Save and close the config file.

In the monitoring view – Expand Microsoft SharePoint > Administration and select the “Microsoft SharePoint Farm Group”

In the Tasks pane – run the task “Configure SharePoint Management Pack”

*** Note – if the task fails – or throws an error – try running it again a few times, or closing and opening the SCOM console – and running it again. If it continues to fail – investigate and ensure you have the config file on your management server, and you are running the console on the management server when calling the task.

You should see output similar to this:

Output
Load configuration file Microsoft.SharePoint.Foundation.Library.mp.config
Configure Microsoft.SharePoint.Foundation.Library version 15.0.4420.1017
Create override management pack Microsoft.SharePoint.Foundation.Library.Override
Account SharePoint Discovery/Monitoring Account is associated to DB1.opsmgr.net for Microsoft.SharePoint.AdminAccount
Account SharePoint Discovery/Monitoring Account is associated to SHPT2.opsmgr.net for Microsoft.SharePoint.AdminAccount
Allow DB1.opsmgr.net as a proxy
Allow SHPT2.opsmgr.net as a proxy
Create 'Enabled' property override with value true for Microsoft.SharePoint.2013.WSSInstallation.Discovery
Create 'SyncTime' configuration override with value 18:43 for Microsoft.SharePoint.2013.WSSInstallation.Discovery
Create 'IntervalSeconds' configuration override with value 28800 for Microsoft.SharePoint.2013.WSSInstallation.Discovery
Microsoft.SharePoint.2013.WSSInstallation.Discovery does not have configuration TimeoutSeconds
Create 'SyncTime' configuration override with value 18:45 for Microsoft.SharePoint.2013.SPFarm.Discovery
Create 'SyncTime' configuration override with value 18:51 for Microsoft.SharePoint.2013.SPService.Discovery
Create 'SyncTime' configuration override with value 18:57 for Microsoft.SharePoint.2013.SPSharedService.Discovery
Create 'SyncTime' configuration override with value 19:03 for Microsoft.SharePoint.2013.SPHARule.Discovery
Create 'SyncTime' configuration override with value 19:09 for Microsoft.SharePoint.2013.SPHARuleMonitor.Availability
Create 'SyncTime' configuration override with value 19:09 for Microsoft.SharePoint.2013.SPHARuleMonitor.Security
Create 'SyncTime' configuration override with value 19:09 for Microsoft.SharePoint.2013.SPHARuleMonitor.Performance
Create 'SyncTime' configuration override with value 19:09 for Microsoft.SharePoint.2013.SPHARuleMonitor.Configuration
Create 'SyncTime' configuration override with value 19:09 for Microsoft.SharePoint.2013.SPHARuleMonitor.Custom
Create 'SyncTime' configuration override with value 19:15 for Microsoft.SharePoint.2013.SPHARuleMonitor.SPServer.Availability
Create 'SyncTime' configuration override with value 19:15 for Microsoft.SharePoint.2013.SPHARuleMonitor.SPServer.Security
Create 'SyncTime' configuration override with value 19:15 for Microsoft.SharePoint.2013.SPHARuleMonitor.SPServer.Performance
Create 'SyncTime' configuration override with value 19:15 for Microsoft.SharePoint.2013.SPHARuleMonitor.SPServer.Configuration
Create 'SyncTime' configuration override with value 19:15 for Microsoft.SharePoint.2013.SPHARuleMonitor.SPServer.Custom
SharePoint management pack configuration completed successfully

This task is really a “discovery helper”. It will create the necessary RunAs profile associations to the RunAs account for each server, and it will enable agent proxy for each server, and will create some overrides to space out all the discoveries so they run in order, and can discover all Farm components as quickly as possible. From the time you run the task, to full Farm, Role, Server, and Service discovery, should be around 40 minutes.

After 40 minutes – check in the console and see if your Farm, Servers, and Services have all been discovered. If not – check in the “Unidentified machines view”. If your farm servers show up there, it is likely a permissions issue with your RunAs account, either on the Farm servers or on the SQL server. On the SharePoint servers, make sure this account can log in and execute the SharePoint command shell without errors.

Some good troubleshooting blogs on this topic:

http://thoughtsonopsmgr.blogspot.com/2013/04/sharepoint-server-2013-mp-useful-links.html

http://thoughtsonopsmgr.blogspot.nl/2013/04/troubleshooting-sharepoint-server-2013.html

http://thoughtsonopsmgr.blogspot.nl/2013/04/sharepoint-server-2013-mp-configure.html

Known issues:

There is a bug in the MP’s report deployment – you will see an alert about

Data Warehouse failed to deploy reports for a management pack to SQL Reporting Services Server. Failed to deploy reporting component to the SQL Server Reporting Services server. The operation will be retried.
Exception 'DeploymentException': Failed to deploy reports for management pack with version dependent id 'edf9e0b9-65aa-df29-6729-d16f0005e820'. Failed to deploy linked report 'Microsoft.SharePoint.Server_Performance_Report'. Failed to convert management pack element reference '$MPElement[Name="Microsoft.SharePoint.Foundation.2013.Responsetime"]$' to guid. Check if MP element referenced exists in the MP. An object of class ManagementPackElement with ID 75668869-f88c-31f3-d081-409da1f06f0f was not found.
One or more workflows were affected by this.
Workflow name: Microsoft.SystemCenter.DataWarehouse.Deployment.Report

See: http://thoughtsonopsmgr.blogspot.com/2013/05/bug-alert-sharepoint-server-2013-mp.html

Install SharePoint 2013 in a lab environment

Kevin Holman — Mon, 13 May 2013 17:57:31 GMT

This will be a basic walkthrough on installing SharePoint 2013. The TechNet documentation for the process is here: http://technet.microsoft.com/en-us/library/cc262957.aspx

Windows Server 2012 and SQL 2012 will be used. We already have an existing remote SQL 2012 server we will be using in this scenario.

Accounts:

OPSMGR\ShptSetup (user account that will log in and install or update SharePoint)
OPSMGR\ShptSvc (service account for the farm, database access account)
OPSMGR\SharePoint Admins (Group)

Add all the SharePoint accounts to the SharePoint Admins group. Technically for lowest priv the ShptSvc account does not need to be a SharePoint admin – as setup will grant necessary permissions to the SharePoint servers and Databases, however this is done for simplicity in a lab environment.

Install a new Windows Server 2012 computer. Join it to a domain. Add the DOMAIN\SharePoint Admins global group to the Local Administrators group.

Log on to the SharePoint server as DOMAIN\shptsetup

ShptSetup account must have the following rights: http://technet.microsoft.com/en-us/library/ee662513.aspx

local admin on all SharePoint servers
SQL Server login on the computer that runs SQL Server.
Member of the following SQL Server roles:

securityadmin fixed server role
dbcreator fixed server role

If you run Windows PowerShell cmdlets that affect a database, this account must be a member of the db_owner fixed database role for the database.
To make this process simple – if possible, just grant the shptsetup account to have SysAdmin role over the SQL instance for installation.

Run prerequisiteinstaller.exe from the SharePoint 2013 media.

This will install all the necessary pre-reqs needed for SharePoint 2013:

Once the prereqs are installed, reboot the server. When you log back in as DOMAIN\shptsetup, the installation of prereqs will complete.

Run setup.exe from the SharePoint 2013 media.

Input your product key.

Accept the license agreement

Choose Complete:

Click Install Now.

When complete – we can run the config wizard:

We want to create a new farm:

Provide a SQL server, and a SharePoint farm database access account:

The user account running setup needs access to the SQL server in order to create the SharePoint databases. The provided SharePoint Farm Account/Database Access account will get the required permissions automatically by setup.

Provide a passphrase:

Specify a port or accept the default:

Complete the wizard:

When complete – you should see:

This will kick off the central administration sire farm configuration wizard.

Answer the questions in the wizard, and create the first site collection.

OpsMgr: MP Update: New Base OS MP 6.0.7026.0

Kevin Holman — Thu, 09 May 2013 01:38:52 GMT

A new Base OS MP Version 6.0.7026.0 has shipped. This management pack includes updated MP’s for Windows 2003 through Windows 2012 operating systems. This updated MP will import into OpsMgr 2007 or 2012 management groups.

http://www.microsoft.com/en-us/download/details.aspx?id=9296

Ok – so what's new in this MP?

The April 2013 update (version 6.0.7026.0) of the Windows Server Operating System Management Pack contains the following changes:

Fixed a bug in Microsoft.Windows.Server.2008.Monitoring.mp where the performance information for Processor was not getting collected.
Made monitoring of Cluster Shared Volume consistent with monitoring of Logical Disks by adding performance collection rules. (“Cluster Shared Volume - Free space / MB”,”Cluster Shared Volume - Total size / MB”,”Cluster Shared Volume - Free space / %”,”Cluster Disk - Total size / MB”,”Cluster Disk - Free space / MB”,”Cluster Disk - Free space / %”)
Fixed bug in Microsoft.Windows.Server.ClusterSharedVolumeMonitoring.mp where the Cluster disks running on Windows Server 2008 (non R2) were not discovered.
Fixed bug 'Cluster Disk Free Space Percent' and Cluster Disk Free Space MB' monitors generate alerts with bad descriptions when the volume label of a cluster disk is empty.
Added feature to raise event when NTLM requests time out and customers are unable to use mailboxes, outlook stops responding, due to the low default value for Max Concurrent API registry Key (HLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters) , which is a ceiling for the maximum NTLM or Kerberos PAC password validations a server can take care of at a time. It uses the “Netlogon” performance counter to check for the issue.

These fixes address the majority of known issues discussed in my last article on the Base OS MP:

http://blogs.technet.com/b/kevinholman/archive/2012/09/27/opsmgr-mp-update-new-base-os-mp-6-0-6989-0-adds-support-for-monitoring-windows-server-2012-os-and-fixes-some-previous-issues.aspx

A note on Processor utilization monitoring and collection:

Distinct rules and monitors were created for Windows Server 2008, and 2008 R2. Server 2008 will monitor and collect “Processor\% Processor Time” while Server 2008 R2 will monitor and collect “Processor Information\% Processor Time”. Overrides were included in the MP to disable the “2008” rules and monitors for the 2008 R2 instances. If for some reason you prefer to collect and monitor "from “Processor” instead of “Processor Information”, for instance if this breaks some of you existing reports, it is very simple to just override those rules and monitors back to enabled. An unsuealed override will always trump a sealed override.

Known Issues in this MP:

1. The knowledge for the 2008 and 2008 R2 Total CPU Utilization Percentage is incorrect – the monitor was updated to a default value of 3 samples but the knowledge still reflects 5 samples. This is still an issue (no biggee) The 2012 monitors use 5 samples by default with correct knowledge.

2. There are now collection rules for Cluster disks and CSV for free space (MB), free space (%), and total size (MB), If you want performance reports on other perfmon objects that are available in perfmon but not included in our MP, such as disk latency, idle time, etc, you will need to create these. Since this can be complicated to get it right – I wrote an article on how to do this correctly, and offer a sample MP for download: http://blogs.technet.com/b/kevinholman/archive/2012/09/27/opsmgr-authoring-performance-collection-rules-for-cluster-disks-the-right-way.aspx

How to apply System Center 2012 SP1 Update Rollup 2 (UR2) to other System Center components

Kevin Holman — Fri, 12 Apr 2013 19:59:26 GMT

I recently did a deep dive on how to apply UR2 to System Center 2012 SP1 Operations Manager. http://blogs.technet.com/b/kevinholman/archive/2013/04/11/applying-update-rollup-2-ur2-to-opsmgr-2012-sp1.aspx

The following article covers some of the other System Center 2012 SP1 components, such as Orchestrator, App Controller, and Service Manager.

The KB article and download links are located at: http://support.microsoft.com/kb/2802159

Orchestrator 2012 SP1:

The simplest way to apply these updates to Orchestrator RunBook Servers and Runbook Designers would be using Windows Update, which can be controlled via WSUS or ConfigMgr since these are on the catalog.

Alternatively, you can download these and manually apply them. The catalog location for the Orchestrator UR2 update is: http://catalog.update.microsoft.com/v7/site/Search.aspx?q=2828193

The manual application is simple – download the CAB files, extract the MSP files, and then copy them to all your RunBook Servers, and any machine with the RunBook Designer installed. These MSP’s need to be applied via an *elevated* command prompt:

No success feedback is given. Check your application event log or do a quick file spot check:

App Controller 2012 SP1:

The simplest way to apply these updates to an App Controller server would be using Windows Update, which can be controlled via WSUS or ConfigMgr since these are on the catalog.

Alternatively, you can download these and manually apply them. The catalog location for the App Controller UR2 update is: http://catalog.update.microsoft.com/v7/site/Search.aspx?q=2815569

The manual application is simple – download the CAB files, extract the MSP files, and then copy them to all your App Controller Server. These MSP’s need to be applied via an *elevated* command prompt:

No success feedback is given. Check your application event log or do a quick file spot check:

Service Manager 2012 SP1:

The UR2 updates for Service Manager 2012 SP1 are not part of Windows Update. These are a separate download available here:

http://www.microsoft.com/en-us/download/details.aspx?id=38409

There are two files, one is x64 and the other x86. The x86 update would only be deployed if you were running 32 bit consoles somewhere, as the servers themselves are only 64bit.

I copy the x64 update file down to my SCSM Management server, and my Data Warehouse Management server. I will execute the update from an *elevated* command prompt:

This kicks off a self-extracting update with a UI. Agree to the license agreement and click “Install”

This will go through several steps, installing files, stopping and starting the SCSM services, configuring the database, then finalization. When complete, you will see a final dialogue:

You can do a quick file spot check to verify:

When complete – I move on to my Data Warehouse Management Server, and repeat.

Lastly – I need to update any consoles I have deployed on user desktops or terminal servers in my environment.

Applying Update Rollup 2 (UR2) to OpsMgr 2012 SP1

Kevin Holman — Thu, 11 Apr 2013 17:21:33 GMT

Update Rollup 2 (UR2) for OpsMgr 2012 SP1 has shipped. This post will be a simple walk-through of applying it. This hotfix is included on my Hotfix page for SCOM: http://blogs.technet.com/b/kevinholman/archive/2009/01/27/which-hotfixes-should-i-apply.aspx

Description and download location:

http://support.microsoft.com/kb/2802159

Description of fixes in this release:

The Web Console performance is very poor when a view is opened for the first time.
The alert links do not open in the Web Console after Service Pack 1 is applied for Operations Manager.
The Distributed Applications (DA) health state is incorrect in Diagram View.
The Details Widget does not display data when it is viewed by using the SharePoint webpart.
The renaming of the SCOM group in Group View will not work if the user language setting is not "English (United States)."
An alert description that includes multibyte UTF-8 characters is not displayed correctly in the Alert Properties view.
The Chinese (Taiwan) Web Console displays the following message even after the SilverlightClientConfiguration.exe program is run: Web Console Configuration Required.
The Application Performance Monitoring (APM) to IntelliTrace conversion is broken when alerts are generated from dynamic module events such as the Unity Container.
Connectivity issues to System Center services are fixed.
High CPU problems are experienced in Operations Manager UI.
Query processor runs out of internal resources and cannot produce a query plan when you open Dashboard views.
Path details are missing for "Objects by Performance."

Unix and Linux fixes:

The Solaris agent could run out of file descriptors when many multi-version file systems (MVFS) are mounted.
Logical and physical disks are not discoverable on AIX-based computers when a disk device file is contained in a subdirectory.
Rules and monitors that were created by using the UNIX/Linux Shell Command templates do not contain overridable ShellCommand and Timeout parameters.
Process monitors that were created by the UNIX/Linux Process Monitoring template cannot save in an existing management pack that has conflicting references to library management packs.
The Linux agent cannot install on a CentOS or Oracle Linux host by using FIPS version of OpenSSL 0.9.8.

This Update Rollup is also required if you want to use the new System Center Advisor Connector: http://blogs.technet.com/b/momteam/archive/2013/04/09/system-center-advisor-connector-for-operations-manager-preview.aspx

That’s a LOT. Looks like some very important ones as well…. so lets get this one tested in our labs!

Download the update:

You can get this update “partially” applied by using Windows Update. However, since there are manual steps involved, and a specific recommended order of operations, I don’t really recommend using Windows Update in general. It is certainly an option, however.

To download all of the updates, you will need to click the link in the KB above, which will launch the catalog for the individual downloads.

You’ll notice some of these updates are a LOT bigger than the previous ones in UR1.

I also notice there is now an update for the “Console” which is new from UR1. The original release of UR2 was missing the update for the Gateway, which is now included and available to make UR2 truly “cumulative”.

Add these to your “basket” then “view basket” and choose a download location.

Build a plan:

Following the KB – the installation plan looks something like this:

Install the update rollup package on the following server infrastructure:
- Management server or servers
- Gateway servers
- Reporting servers
- Web console server role computers
- Operations console role computers
Manually import the management packs.
Apply the agent update to manually installed agents, or push the installation from the Pending view in the Operations console.

***Note: One of the things you will notice – is that there is no update available for reporting servers. We will skip the reporting role.

My new list looks like:

Management servers
Gateway servers
Web console server role computers
Operations console Role Computers

Since I am monitoring Linux systems, I’ll need to add steps for that from the KB:

Download the updated management packs from the following Microsoft website:
(The Unix/Linux MP location isn't available, and the previous location hasn’t been updated yet. So this part is still under investigation as well. I will update this section when I clear this part up)
Install the management pack update package to extract the management pack files.
Import the following:
- The updated Microsoft.Unix.Library management pack (from the Microsoft.Unix.Library\2012 SP1 folder)
- The Microsoft.Unix.Process.Library management pack bundle
- The platform library management packs that are relevant to the Linux or UNIX platforms that you monitor in your environment

Seems simple enough, lets get started.

Install the update rollup package

On the catalog site, I add all the updates to my basket, and click View Basket, and Download.

Next I copy these files to a share that all my SCOM servers have access too. These are actually .CAB files, so I will need to extract the MSP’s from these CAB files.

Once I have the MSP files, I am ready to start applying the update to each server by role.

***Note: You MUST log on to each server role as a Local Administrator, SCOM Admin, AND your account must also have System Administrator (SA) role to the database instances that host your OpsMgr databases.

My first server is a management server, and the web console, and has the OpsMgr console installed, so I copy those update files locally, and execute them per the KB, from an elevated command prompt:

This launches a quick UI which applies the update. It will bounce the SCOM services as well. The update does not provide any feedback that it had success or failure. You can check the application log for the MsiInstaller events for that.

You can also spot check a couple DLL files for the file version attribute.

Next up – run the Web Console update:

This runs much faster. A quick file spot check:

Lastly – install the console update:

Well, this one required a reboot. The KB article instructed “If you do not want to restart the computer after you apply the console update, close the console before you apply the update for the console role.” However – my console was closed….. so you had better prepare that these files might be locked and require a reboot.

After the reboot – a quick file spot check:

I now move on to my additional management servers, applying the server update, then the console update. My additional management servers did not require a reboot after the console update.

Next, I update the gateways.

The update launches a UI and quickly finishes.

I do a spot-check to ensure the right files were dropped. First I will check the Agent update files in C:\Program Files\System Center Operations Manager\Gateway\AgentManagement\

Then I will spot check the DLL’s:

Manually import the management packs?

We have two updated MP’s to import (MAYBE!).

These MP bundles are only used for specific scenarios, such as Global Service Monitoring, or DevOps scenarios where you have integrated APM with TFS, etc. If you are not currently using these MP’s, there is no need to import or update them. The Intellitrace MP will actually fail to import of you are not using these, because of a dependency. I’d skip this MP import unless you already have these MP’s present in your environment.

Apply the agent update

Approve the pending updates in the Administration console for pushed agents. Manually apply the update for manually installed agents.

100% success rate.

Be sure to check the “Agents By Version” view to find any agents that did not get patched:

***Note! The agents behind a gateway are NOT placed into pending actions for an update. These agents will need to be “repaired” via the administration console, or use Windows Update. On my agents behind a GW – a repair worked perfectly.

Update Unix/Linux MPs

Next up – I download and extract the updated Linux MP’s for SCOM 2012 SP1 UR2

(The link in the KB article doesn’t work at the time of this writing – here is the correct link)

http://www.microsoft.com/en-us/download/details.aspx?id=29696

7.4.3507 is SCOM 2012 SP1.

7.4.4112.0 is SCOM 2012 SP1 with UR1.

7.4.4119.0 is SCOM 2012 SP1 with UR2.

Download the MSI and run it. It will extract the MP’s to C:\Program Files (x86)\System Center Management Packs\System Center 2012 MPs for UNIX and Linux (7.4.4199.0)

Import the files in the 2012 SP1 folder, and the following:

Microsoft.Unix.ConsoleLibrary.mp

Microsoft.Unix.Process.Library.mpb

Microsoft.Unix.ShellCommand.Library.mpb

Also add any platform specific MP’s for versions on Unix or Linux in your monitoring environment.

You will likely observe high CPU utilization of your management servers during these MP imports. Give it time to complete the process of the import and MPB deployments.

Next up – you would upgrade your agents on the Unix/Linux monitored agents. You can now do this straight from the console:

You can input credentials or use existing RunAs accounts if those have enough rights to perform this action.

Lastly – refer to the KB article for the UR1 update, as if you are a heavy user of Linux process monitoring using our template – additional steps are required to address the fixes. You must open, edit, and re-save any process templates that you had previously created in order to apply the fixes to each.

Now at this point, we would check the OpsMgr event logs on our management servers, check for any new or strange alerts coming in, and ensure that there are no issues after the update.

Known issues:

See the existing list of known issues documented in the KB article.

Additional:

1. Agents behind a Gateway will not be placed into pending management for an update. If you are using Windows Update/WSUS/SCCM to update your agents, then no steps are necessary, as they will receive the agent update automatically.

2. OM12 SP1 UR#2 Web Console Error: System.Reflection.ReflectionTypeLoadException: [ReflectionTypeLoad_LoadFailed] Savision has released updated versions of the Live Maps Summary Widget management packs that resolve this issue. The versions can be downloaded here. The download contains the following files:

Savision.LiveMaps.Presentation.SummaryWidget.Library.mpb (Version 1.2.1.0)
Savision.LiveMaps.Presentation.SummaryWidget.WebConsole.mpb (Version 1.2.1.3)

The problem should be fixed by importing the 2 management packs into your environment.

http://www.savision.com/resources/news/fix-om12-sp1-ur2-web-console

Publishing SCOM 2012 dashboards to SharePoint

Kevin Holman — Wed, 03 Apr 2013 02:19:08 GMT

One of the features in OpsMgr2012 is the ability to create rich dashboards, and then publish them to a SharePoint site.

This is covered in the product documentation here: http://technet.microsoft.com/en-us/library/hh212924.aspx

I recently ran into a problem setting this up for a customer – so thought I’d talk about that here for a moment.

First thing is to log on to the SharePoint 2012 server as a SharePoint Administrator, and copy the following two files from the SCOM setup media (\Setup\AMD64\SharePoint) to a local directory on the SharePoint server:

Next we will run C:\bin\shpt\install-OperationsManager-DashboardViewer.ps1 from an elevated SharePoint Management Shell:

But look what happened on mine:

PSsnapin Microsoft.SharePoint.PowerShell is loaded
Get-SPFarm : Microsoft SharePoint is not supported with version 4.0.30319.1 of
the Microsoft .Net Runtime.
At C:\bin\shpt\install-OperationsManager-DashboardViewer.ps1:74 char:9
+ $farm = Get-SPFarm
+         ~~~~~~~~~~
    + CategoryInfo          : InvalidData: (Microsoft.Share...SpCmdletGetFarm:
   SpCmdletGetFarm) [Get-SPFarm], PlatformNotSupportedException
    + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SpCmdletGetFarm

Cannot index into a null array.
At C:\bin\shpt\install-OperationsManager-DashboardViewer.ps1:75 char:1
+ $sol = $farm.Solutions[$solutionID]
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray

This error is caused because I installed Windows Management Framework (WMF) 3.0 on my server, which also upgrades PowerShell to 3.0.

The workaround for this – is to launch a Powershell 2.0 session – and then add the SharePoint snapin:

From an elevated command prompt – type:

powershell.exe -Version 2.0

Add-PSSnapin Microsoft.SharePoint.PowerShell

Now we can run the script with success:

Next up – we need to activate the web part.

On the SharePoint site – Site Actions > Site Settings > Site Collection Administration > Site Collection Features

Make sure the OpsMgr Dashboard Web Part is Active:

To add/configure a dashboard – open the SharePoint Central Administration site.

Site Actions > View All Site Content > Lists > click Operations Manager Web Console Environments

Add New Item > give the dashboard a title, and the URL of your SCOM web console:

Click Save.

Now we can add a dashboard to a page on SharePoint. On your SharePoint site page:

Site Actions > New Page

Give our new dashboard view a name, and click Create

Below “Editing tools” click Insert > Web Part

Select “Microsoft System Center” and select “Operations Manager Dashboard Viewer Web Part” and click Add.

On the upper right, click the down arrow and pick “Edit Web Part”

Choose the correct environment, paste in a URL from the web console for a dashboard, and give the page an appropriate title.

On the menu bar – click Save and Close.

Ready to go!

Additional reading and resources:

http://www.scom2k7.com/how-to-view-scom-2012-dashboards-in-sharepoint-2010/

http://blogs.technet.com/b/momteam/archive/2011/09/27/setting-up-the-operations-manager-web-part.aspx

http://thoughtsonopsmgr.blogspot.com/2013/03/om12-operations-manager-web-part.html

Applying CU1 to OpsMgr 2012 SP1

Kevin Holman — Wed, 03 Apr 2013 00:05:47 GMT

CU1 for OpsMgr has been released for some time now, this post will be a simple walk-through of applying it. This hotfix is included on my Hotfix page for SCOM: http://blogs.technet.com/b/kevinholman/archive/2009/01/27/which-hotfixes-should-i-apply.aspx

Marnix did a great posting on this topic as well, available here: http://thoughtsonopsmgr.blogspot.nl/2013/03/om12-sp1-update-rollup-1-manual.html

Description and download location:

http://support.microsoft.com/kb/2785682

To download all of the updates, you will need to click the link in the KB above, which will launch the catalog for the individual downloads:

Following the KB – the installation plan looks something like this:

Install the update rollup package on the following server infrastructure:
- Management server or servers
- Gateway servers
- Reporting servers
- Web console server role computers
- Operations console role computers
Manually import the management packs.
Apply the agent update to manually installed agents, or push the installation from the Pending view in the Operations console.

***Note: One of the things you will notice – is that there is no update available for consoles, or for reporting servers. So we will skip those roles as they are not applicable. My new list looks like:

Management servers
Gateway servers
Web console server role computers

Since I am monitoring Linux systems, I’ll need to add steps for that from the KB:

Download the updated management packs from the following Microsoft website:
System Center Monitoring Pack for UNIX and Linux Operating Systems

(http://www.microsoft.com/en-us/download/details.aspx?id=29696)
Install the management pack update package to extract the management pack files.
Import the following:
- The updated Microsoft.Unix.Library management pack (from the Microsoft.Unix.Library\2012 SP1 folder)
- The Microsoft.Process.Library management pack bundle
- The platform library management packs that are relevant to the Linux or UNIX platforms that you monitor in your environment
Import the updated management pack for each version of Linux or UNIX that you monitor in your environment.

Seems simple enough, lets get started.

Install the update rollup package

On the catalog site, I add all the updates to my basket, and click View Basket, and Download.

Next I copy these files to a share that all my SCOM servers have access too. These are actually .CAB files, so I will need to extract the MSP’s from these CAB files.

Once I have the MSP files, I am ready to start applying the update to each server by role.

My first server is a management server, and the web console, so I copy those two update files locally, and execute them per the KB, from an elevated command prompt:

You can also spot check a couple DLL files for the file version attribute.

Next up – run the Web Console update:

This runs much faster.

I move on to my additional management servers and gateways, and apply the MSP file from the elevated command prompt. No issues.

Manually import the management packs

The only MP to be updated with this CU1 for SP1 is located on your management servers, at

Only the AlertAttachment MPB should be updated. The KB article known issues states the other MP should not be imported. If you don’t use this MP already (Such as for Global Service Monitoring) then there is no need to install this update. If you ever do go back and enable/install Global Service Monitoring or any MP that requires this Alert Attachment MP – don’t forget to install this updated version! If not you will see issues with alert views in Dashboards, like console crashes or blank screens.

Apply the agent update

Approve the pending updates in the Administration console for pushed agents. Manually apply the update for manually installed agents.

100% success rate.

Be sure to check the “Agents By Version” view to find any agents that did not get patched:

Update Linux MPs

Next up – I download and extract the updated Linux MP’s for SCOM 2012 SP1 CU1. http://www.microsoft.com/en-us/download/details.aspx?id=29696

I open the console – and update these MP’s from disk

7.4.3507 is SCOM 2012 SP1. 7.4.4112.0 is SCOM 2012 SP1 with CU1.

Next up – you would upgrade your agents on the Linux monitored agents. You can now do this straight from the console:

In this case – there is no need, as the previous version of my agents were already updated.

Lastly – refer to the KB article for this update, as if you are a heavy user of Linux process monitoring using our template – additional steps are required to address the fixes.

All done!

Now at this point, we would check the OpsMgr event logs on our management servers, check for any new or strange alerts coming in, and ensure that there are no issues after the update.

Microsoft Assessment and Planning (MAP) Toolkit 8.0

Kevin Holman — Mon, 01 Apr 2013 22:16:39 GMT

For those that are unfamiliar, MAP is a tool from the solution accelerator team which provides inventory, assessment, and reporting that will help you assess your current IT infrastructure status and determine the right Microsoft technologies for your IT needs. environment. It can be a very valuable tool as it is agentless, and has the ability discover machines on your network that might be unknown, or not fully covered by your existing asset management solutions.

Resources:

Product page: http://technet.microsoft.com/en-us/solutionaccelerators/dd537566

Download: http://www.microsoft.com/en-us/download/details.aspx?&id=7826

Requirements to install:

Windows 7, Windows 8, Windows 8 Pro, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Vista Business, Windows Vista Enterprise, Windows Vista Ultimate

Installation:

Run the “Microsoft_Assessment_and_Planning_Toolkit_Setup.exe” program. To get started, click Next.

The first step is a pre-req checker. If any are not met you must correct these before continuing.

Accept the license agreement and click Next.

Accept or change the installation path, and click Next.

Select a choice for the Customer Experience Improvement Program, and click Next.

Click Install. When completed, click Finish to open the MAP toolkit.

Running MAP and collecting inventory for Windows Computers:

When the MAP toolkit opens for the first time – we must create a database to store our collected inventory. Give the DB a name, such as “MapData” and click OK to create the local DB.

In the left pane – click “Environment” and then select “Collect Inventory Data”.

Choose “Windows Computers” and click Next.

Choose to leverage Active Directory to discover from. Additionally you can leverage alternative methods to discover machines not found in AD. Click Next.

We must provide domain credentials that have rights to be able to query active directory. Input the data and click Next.

On the AD options, you can select the default to scan the entire domain, or if all servers are in known OU’s, you can select specific AD containers to search in. Click Next.

On the credentials page, we need to input a credential that has local administrator on all machines in the domain. This is required as MAP will connect to each machine and inventory details from WMI. For this purpose a domain administrator account works best, or a domain account that is a member of the local administrators group of each server in the domain. Click “Create” and input the credentials. You can input multiple credentials here and all will be attempted if one fails, however, this could extend the time required to run the inventory. When complete, click Next.

On the Credentials Order screen, you can change the order of multiple credentials if entered. Click Next. Click Finish.

Inventory will start immediately. Querying the data from AD will occur rather quickly. However, connecting to each server on the network via WMI will take considerable time., even days, depending on how large the environment. Allow this to complete, such as below:

Once this is complete – you will see the amount of success/failure between what was queried from AD, and what was actually reachable via WMI.

Once you are happy with the results of the inventory, you can run a “Generate Inventory Results Report” to create the spreadsheet output in your My Documents\MAP directory

Requirements to gather data:

MAP uses WMI to gather the inventory data. You need to ensure that the server/workstation that is running the MAP collection has access to all servers via any hardware firewalls, and if the servers are running Windows Firewall that exceptions allow the MAP workstation to contact all servers on those ports. Detailed information is available at: http://social.technet.microsoft.com/wiki/contents/articles/8657.map-prepare-the-environment-wmi.aspx

Gathering data from VMware:

This is covered at: http://social.technet.microsoft.com/wiki/contents/articles/12160.map-prepare-the-environment-vmware.aspx

In the inventory collection check the box for VMware:

Choose to manually provide a list of vCenter server names.

Provide credentials that have access to the vCenter servers:

Provide a list of server names that run vCenter :

Configure the properties of your vCenter servers:

Additional resources:

MAP Survival guide: http://social.technet.microsoft.com/wiki/contents/articles/1640.microsoft-assessment-and-planning-toolkit.aspx

MAP Blog: http://blogs.technet.com/b/mapblog/

System Center 2012 Operations Manager Unleashed is now available in paperback, kindle, nook, and PDF!

Kevin Holman — Tue, 12 Mar 2013 13:59:22 GMT

You can get the paperback book on Amazon:

http://www.amazon.com/gp/product/0672335913/ref=s9_simh_gw_p14_d0_i1?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-2&pf_rd_r=06KDNZB3VZVMSN0TWRJH&pf_rd_t=101&pf_rd_p=1389517282&pf_rd_i=507846

At long last the book is ready for shipping in paperback. It is also available on Nook (link), Kindle (link), and direct from the publisher in watermarked PDF (link)

I am proud to be the technical editor for this book. This was my first foray into editing, and I have scoured every page. There is a ton of new content and this book covers the depth of the product exceedingly well. They brought in a ton of accomplished authors and key consultants from around the globe to create this, and I highly recommend it for any SCOM admin.

HealthService restarts – still a challenge in OpsMgr 2012.

Kevin Holman — Thu, 21 Feb 2013 23:33:13 GMT

Way back in the day I wrote about this issue, where the SCOM agent in some cases can consume above typical resource levels of memory, handles, etc. When this occurs – we will restart the agent to kill any “runaway” processes. Read about this here:

http://blogs.technet.com/b/kevinholman/archive/2009/12/21/the-new-and-improved-guide-on-healthservice-restarts-aka-agents-bouncing-their-own-healthservice.aspx

One of the things I have noticed, is that on many of my servers, these thresholds are being breached on a regular basis – mostly due to the monitoringhost.exe processes needing to use more than the default of 300mb of RAM (private bytes).

The issue is, that you will likely have NO idea this is happening. We don’t generate any alerts for this by default – we simply “fix the problem” by creating a state change, then running a response script to bounce the agent. The bad part about this, is you could have agents in a constant restart loop.

In SCOM 2012 – I still recommend making the following changes via overrides: Open the “Operations Manager > Agent Details > Agents by Version” view in the console:

Open health explorer for one of the agents – and here is an example of an agent that has been bouncing on a regular basis:

On the 4 monitors highlighted above – I recommend enabling alerting – and disabling auto-close of the alert so you can take action on agents that need it:

Then – for any agents that need higher values – make the necessary adjustments via override:

As a refresher – this will be common on any monitored systems that discover a large number of instances – such as Exchange, DNS, SQL servers, SCVMM, etc.