| Profil de OperationsOperations ManagerBlogListes |  Outils  Aide |
|
27/05/2007 Access to ACS ReportsBy default and design, there is no access to the ACS reports from the Operations console. This prevents OpsMgr Administrators from viewing reports that fall under the purview of auditors. This setting is maintained with the following configuration:
Due to your company's requirements, there may be a need to change this. Perhaps you don't want to have to implement a separate Report Server for ACS. In this scenario, ACS uses the same Report Server as OpsMgr, but there is separation between administrators and auditors using that same Report Server, with no audit report access to the administrators. Audit reports appear in the Operations console (all reports in the OpsMgr Report Server appear in the Reporting node of the console whether they are OpsMgr reports are not), but cannot be run from the Operations Console, only from Report Manager. This scenario retains security separation and simply leverages the same Report Server to conserve SQL Reporting Services asset deployments. The following settings are used:
A third scenario would be for the Operations console to allow access to the reports (versus simply displaying them since they are on the same Report Server). You might need to do this if you have a very small company that does not have a separate auditor's role. Note that this approach is NOT recommended or supported by Microsoft, as it defeats the whole purpose of having a separate Audit Control System!
This material was developed by our System Center Operations Manager 2007 Unleashed co-author John Joyner, and is discussed in detail in that book (which is currently being written). Look for a chapter on Monitoring Audit Collection Services! 26/05/2007 Using PowerShell to import/export management packsIn MOM 2000 and MOM 2005, Microsoft provided the ManagementModuleUtil tool as a means to import and export management packs in a batch mode. This tool no longer exists, but there are cmdlets in PowerShell that allow you to do just that.
Importing Management Packs using PowerShellYou can import a management pack with the install-managementpack cmdlet. The following example imports an information worker management pack that was included on the Operations Manager installation media. The syntax would be:
install-managementpack -filepath Z:\Microsoft.Informationworker.Commonlibrary.mp
You can put this in a batch file and import multiple MPs this way. The error checking provided by the Operations console import function is not available, but it can be a faster approach for a bulk import of management packs.
Exporting Management Packs using PowerShellThe export process is a little more interesting. Microsoft gives a syntax example that exports all unsealed management packs to the root of the C:\ drive:
$mps = get-managementpack | where-object ($ .Sealed -eq $false)
foreach($mp in $mps)
{
export-managementpack -managementpack $mp -path "C:\"
}
That's nice, but you have to run this from within the OpsMgr Command Shell.
We can put that code in a batch script which you can run from the standard PowerShell environment per the following example. Be sure the path you will be exporting to already exists. You will also have to provide the name of the RMS as a parameter (or hardcode it in the script):
param ($ServerName)
add-psssnapin
"Microsoft.EnterpriseManagement.OperationsManager.Client":
set-location "OperationsManagerMonitoring::";
new-managementGroupConnection -ConnectionString:$ServerName;
set-location $ServerName;
$mps = get-managementpack | where-object ($ .Sealed -eq $false)
foreach($mp in $mps)
{
export-managementpack -managementpack $mp -path "C:\backups"
}
Save this in a file with a PS1 extension so it is executable by PowerShell. We'll name our script file exportMP.ps1 and save it to a directory on the RMS named c:\Backups.
Now, the final step is to put this in a batch file. The batch file contains the following syntax:
%systemroot%\system32\windowspowershell\v1.0\powershell.exe c:\backups\exportMP.ps1 -ServerName:<rootmanagementserver>
where you specify the name of the RMS for the <rootmanagementserver> parameter.
We can put this file also in our c:\backups directory on the RMS and it runs like a champ!
Other thoughts:
You can also export SEALED management packs, which the Operations console does not allow you to do. The following code will export all management packs, both sealed and unsealed:
$all_mps = get-managementpack
foreach($mp in $all_mps)
{
export-managementpack -managementpack $mp -path "C:\backups"
} Thanks to Maarten Goet for providing us with this example.
You could also export only sealed mangement packs by changing the selection criteria in the first export example to ($ .Sealed -eq $true)
Why would you want to export sealed management packs - other than to look at them? To incorporate new reports you want to add to an existing management pack, for example. We write about this in more detail in our forthcoming book, System Center Operations Manager 2007 Unleashed. 24/05/2007 OpsMgr 2007 Agent Deployment FootprintPurpose:We decided to test the impact of an installed agent on a managed machine. The following are results from tests performed to determine the impacts on the processor, network, disk, and memory on a client system monitoried by Operations Manager 2007.
Our test environment ran on two different virtual servers running on two different guest operating systems (details regarding the test environment are at the end of this blog entry).
Please note that these tests were performed on low-end server configurations so that the maximum impact on the systems should be able to drawn from this, e.g. a worst-case scenario. Higher-grade systems should be less impacted than these particular systems were.
The installation ran on the two systems for between 3 and 3 1/2 minutes. We stopped gathering statistics when the agent listed as successfully deployed from the Management Server. During installation we noted the following ranges of impacts on the system:
Processor: 29-37% increase during installation
Disk: 18-19 additional pages per second
Disk: 154 MB data (%programfiles%\System Center Operations Manager 2007)
Network: 11 MB data sent to the system during installation
Memory: 22 MB less available memory
After the installation was complete, the performance counters gather prior to the installation were compared to those gathered after installation. The results indicate what should be the worst-case impact of the agent on the system.
Processor: 3-4%
Disk: 0.5 additonal pages per second
Disk: 156 MB data (%programfiles%\System Center Operations Manager 2007)
Network: .5-.6 MB/min additional traffic
Memory: 11 MB less available memory Testing environment specifications:To test the impacts of both the deployment itself and the agent functionality after installing the agent, we took a total of three sets of performance counters (from perfmon and netmon). One was prior to installation to provide the baseline, one during installaton and the last after installation was complete.
Host Operating System #1 running on a dual processor 1ghz system with 2GB memory. Host OS running only Virtual Server 2005 R2.
Guest Opeating System #1 running within Virtual Server 2005 R2 with 1GB memory.
Host Operating System #2 running on a single processor 1.5ghz system with 2GB memory. Host operating system running only Virtual PC 2007.
Guest Operating System #2 running within Virtual PC 2007 with 1GB memory.
Both guest OS running Windows Server 2003 without either a domain controller or Exchange installed on the system.
The Operations Manager 2007 environment is running on a Root Management Server separate from the Operations Database Server, and has all currently available management packs loaded. 19/05/2007 Book ReviewWindows IT Pro recently reviewed our Microsoft Operations Manager 2005 Unleashed book! Here's a link to the review:
17/05/2007 Fixing a failed OpsMgr 2007 Reporting installationHere's some more fun regarding OpsMgr 2007 reporting.
During a recent installation we forgot to do a double-check that the reporting piece of SQL Server 2005 was installed prior to installing the Operations Manager components. Unfortunately this was compounded (we were in a hurry to finish installation!) without verifying that we could browse to http://localhost/Reports.
After installing the reporting components, we opened the Operations console and received an error about getting to the reports. Trying to debug, we could not access http:localhost/Reports on the SQL Reporting Server - it showed "Service Unavailable." Same error with localhost/ReportServer.
Digging deeper, it was determined that the application pool was crashing and would stop, and then the Service Unavailable condition occured. A variety of ways were tried to get it online - including IISReset, ResetSRS, and even changing the application pool to run as a Network Service. Nothing worked. The following steps may be overkill, but this is what we did to get Reporting functional:
09/05/2007 Tips to get OpsMgr Reporting to install properlyActually, this is more about a prereq for getting OpsMgr to install - that being the SQL Server 2005 Reporting Services. There are several things to watch for that can give you problems, not only with OpsMgr reporting, but also System Center Essentials reporting, as our new co-author John Joyner discovered.
|
|
|
