-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
P2P-Nathan repair validation errors #19
Changes from 8 commits
73a6de1
2ae603c
2b61606
de489db
b30ce3e
18c2585
ea83063
018e2be
37bfbfa
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,9 @@ | ||
### Introduction | ||
|
||
In OpsMgr, groups are frequently used when designing service level monitoring and dashboards. The group members' health rollup behaviours can be configured by creating various dependency monitors targeting against the group. | ||
|
||
When creating groups, only instance groups can be created within the OpsMgr console. Unlike computer groups, instance groups do not inherit any dependent monitors from their base class. Therefore when an instance group is created in the OpsMgr console, by default, the health state of the group is "Not monitored" (Uninitialized): | ||
|
||
[![SNAGHTML6ecbad9](http://blog.tyang.org/wp-content/uploads/2015/07/SNAGHTML6ecbad9_thumb.png "SNAGHTML6ecbad9")](http://blog.tyang.org/wp-content/uploads/2015/07/SNAGHTML6ecbad9.png) | ||
|
||
In order to configure group members to rollup health state to the group object (so the group can be used in dashboards), one or more dependency monitors must be created manually after the group has been created. This manual process can be time consuming. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,12 +1,13 @@ | ||
{ | ||
"ManagementPackSystemName": "OpsMgr.Group.Health.Rollup.Task", | ||
"ManagementPackDisplayName": "OpsMgr Group Health Rollup Configuration Task Management Pack", | ||
"URL": "https://blog.tyang.org/2015/07/28/opsmgr-group-health-rollup-configuration-task-management-pack/", | ||
"Version": "1.0.0.0", | ||
"Author": "Tao Yang", | ||
"IsFree": true, | ||
"Tags": [ | ||
"Tasks", | ||
"MVP" | ||
] | ||
"ManagementPackSystemName": "OpsMgr.Group.Health.Rollup.Task", | ||
"ManagementPackDisplayName": "OpsMgr Group Health Rollup Configuration Task Management Pack", | ||
"URL": "https://blog.tyang.org/2015/07/28/opsmgr-group-health-rollup-configuration-task-management-pack/", | ||
"Version": "1.0.0.0", | ||
"Author": "Tao Yang", | ||
"IsFree": true, | ||
"Description": "The “OpsMgr group health Rollup Configuration Task Management Pack” provides an agent task to create dependency monitors for the selected groups using OpsMgr SDK.", | ||
"Tags": [ | ||
"Tasks", | ||
"MVP" | ||
] | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -20,7 +20,6 @@ foreach ($packFile in $packFiles) { | |
$folderName = (Split-Path $packFile.psparentpath -Leaf) | ||
$folderPath = split-path $packFile.FullName | ||
$contents = Get-Content $packFile.FullName -Raw -ErrorAction SilentlyContinue | ||
$json = $contents | ConvertFrom-Json -ErrorAction SilentlyContinue | ||
|
||
Describe "$folderName" -Tag "$folderPath" { | ||
|
||
|
@@ -33,18 +32,21 @@ foreach ($packFile in $packFiles) { | |
|
||
It "Has a details.json" { | ||
$packFile.FullName | Should Exist | ||
$packFile.Name | Should BeExactly "details.json" | ||
} | ||
|
||
It "Has a Readme.md" { | ||
$readme = $packFile.FullName -replace $packFileName, 'README.md' | ||
$readme | Should Exist | ||
# Get-ChildItem is used as Get-Item returns the same case it is passed. | ||
(Get-ChildItem -Path $packFile.DirectoryName -Filter "readme.md").Name | Should BeExactly "ReadMe.md" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In AppVeyor and VSCode only the test name is surfaced - can you either update it to include this restriction or (preferably) create another test? Good unit testing practise is to only test a single thing with each test. (also, feel free to update my incorrectly cased file name above!) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To increase the readability of the output I'll change the test name to "Has a ReadMe.md (case-sensitive)", this should help a user that gets the error even through they have a README.md in the folder. |
||
} | ||
} | ||
|
||
Context 'details.json' { | ||
|
||
It "details.json is valid json" { | ||
{ $contents | ConvertFrom-Json } | Should Not Throw | ||
{$script:json = $contents | ConvertFrom-Json } | Should Not Throw | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This makes the tests order dependant (other tests will fail if this one isn't run first). The original call probably needs a try/catch wrapping it. |
||
} | ||
|
||
It "details.json has content" { | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
### Main features | ||
|
||
- **Discovery**: Registry discovery of main Operations Manager 2016 server roles -- the RMS Emulator, other additional Management Servers (MS) and Gateway Servers (GW). | ||
- **Monitoring**: Monitors the registry value of all discovered Operations Manager server roles for the current version of the Operations Manager installation. If the version is anything other than 2016, the monitor will go into warning state. | ||
- **Upgrade State of Operations Manager Management Group**: To provide a high-level summary of the upgrade state of the Operations Manager Management Group based on the upgrade state of its core components (not including agents). The core components consist of the RMS Emulator, all Management Server and Gateway Server roles discovered in the management group. | ||
- **Dashboards:** A visualization feature that allows the user to switch back and forth between a **Summary Dashboard** and an **Agent Detail Dashboard** to keep track of the overall upgrade state and health of the core components and Windows agents in the management group. | ||
- The **Summary Dashboard** displays all the core Operations Manager 2016 components or server roles discovered, the overall upgrade state of the management group, and a text and an instance detail widget to contextually display important recommendations and instance property values based on the core component selected. | ||
- The **Agent Detail Dashboard** displays the upgrade state, installation method, patch level, agent and computer health of all the Windows Agents in the management group. The **search feature** provides further filtering capabilities to allow the health and upgrade state of a specific agent and it's corresponding host server or computer to be identified and displayed.\ | ||
**Summary Dashboard**: | ||
|
||
![](https://i1.gallery.technet.s-msft.com/sample-management-pack-fd15caa7/image/file/160585/1/gallery01.jpg) |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,9 @@ | ||
### Overview | ||
|
||
The URL Genie Management Pack provides a fast and easy way to implement monitoring for a large numbers of URL instances from only a few instances up to many thousands! In addition there are some special features which allow monitoring sites which require client certificates in addition to pages that use forms-based authentication. With URLGenie you can easily configure monitoring for thousands of standard URL instances in less than a minute. | ||
|
||
The URL instances and their respective monitoring criteria get instantiated on any number of "watcher" nodes from one or more XML configuration files. Any managed Windows computer can be activated as a watcher node with a simple Console task during which the watcher nodes get configured with a path to where it should look for configuration files. There can exist any number of configuration files, each with any number of requests defined within. Typically the configuration files will be centrally located in a single shared network folder. A decent place for the shared configuration folder is on management server or the data warehouse server with all watcher nodes configured with the same shared folder path. This is the most simple and scalable configuration. | ||
|
||
There are standard monitors which target the http and https class types. Each individual monitor will alert with plenty of alert specific context information. This is significantly different than the Operations Manager standard Web Availability or Synthetic Transaction monitoring which will only alert on the rollup and contain no specific or useful alert context information. | ||
|
||
The standard monitors all support the various types of http authentication: *None*, *Basic*, *NTLM*, *Digest*, and*Negotiate*. In addition, there are special monitor types which can be enabled for URLs that require a client certificate or even for web sites that use forms-based authentication, a first for SCOM (to my knowledge)! |
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
install: | ||
- cinst pester | ||
|
||
build: false | ||
|
||
test_script: | ||
- ps: .\Update-Tests.ps1 | ||
- ps: $res = Invoke-Pester -Path ".\" -OutputFormat NUnitXml -OutputFile TestsResults.xml -PassThru | ||
- ps: (New-Object 'System.Net.WebClient').UploadFile("https://ci.appveyor.com/api/testresults/nunit/$($env:APPVEYOR_JOB_ID)", (Resolve-Path .\TestsResults.xml)) | ||
- ps: if ($res.FailedCount -gt 0) { throw "$($res.FailedCount) tests failed."} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In AppVeyor and VSCode only the test name is surfaced - can you either update it to include this restriction or (preferably) create another test? Good unit testing practise is to only test a single thing with each test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To increase the readability of the output I'll change the test name to "Has a details.json (case-sensitive)", this should help a user that gets the error even through they have a details.JSON in the folder.