Nice work by J. Greg using the Agent Maintenance Mode MP to do Automatic Maintenance Mode after Windows Update
Tuesday 8 December 2009
Wednesday 25 November 2009
Permissions Required for Agent Maintenance Mode
I had a few emails regarding the Agent Maintenance Mode not working for some. It appears that there are a few reasons for this not to work correctly:
1. System Center Essentials 2010 that uses Opsmgr 2007 R2 but they have still don’t include the powershell support (Thanks to Bjorn Axell for this info)
2. The Default Action Account on the RMS must be a member of the Operations Manager Administrators Group. If you configured the action account by using Local System or a user that is not part of the Operations Manager Administrators Group, the script will not work.
This is a standard configuration for several MPs including the Opeartions Manager MP and the Active Directory MP.
1. System Center Essentials 2010 that uses Opsmgr 2007 R2 but they have still don’t include the powershell support (Thanks to Bjorn Axell for this info)
2. The Default Action Account on the RMS must be a member of the Operations Manager Administrators Group. If you configured the action account by using Local System or a user that is not part of the Operations Manager Administrators Group, the script will not work.
This is a standard configuration for several MPs including the Opeartions Manager MP and the Active Directory MP.
Wednesday 18 November 2009
New Agent Maintenance Mode
Here is a new version of the Agent Maintenance Mode MP. This version is only for OpsMgr R2 as it leverages the new powershell modules only available in R2.
--Update--
Read this post if this is not working for you -Permissions Required for Agent Maintenance Mode
The readme has also been updated with this info
----
To recap on this solution:
It allows you to start Maintenance Mode from an monitored server using just a vbscript. Using this requires absolutely no permissions in Operations Manager. All of the components required to have this function are part of a standard OS with an agent installed. It works through Gateways so can be used in firewalled or untrusted environments.
The MaintMode.vbs writes an event to the event log that indicates the length of time Maintenance Mode should remain on. This is picked up by the management pack and processed on the RMS to turn on Maintenance Mode for that server. The on time can be specified in days, hours or minutes.
Download here
The zip file contains a Readme with more information and usage instructions.
Highligh of changes in this version:
Management Pack Changes
* Added Powershell modules in MP (R2 feature) to replace scripts on RMS. Some logic reworking in scripts
* Support for Server 2008
* Fixed ON/Off logic to not put Health Service and Health Service Watcher in to Maint Mode as R2 puts HS and HSW in to MM automatically
• Added Maint Mode event collection rules
• Added Schedule Maint Mode text file option at C:\MaintenanceModeSchedule.txt - origional by Steve Rachui - http://blogs.msdn.com/steverac/archive/2008/12/09/maintenance-mode-by-config-file.aspx
* Disables discovery on RMS as Maintenance Mode should not be used on RMS
MaintMode.vbs
* Now logs the username in the event log of who turned it on: “Maintenance Mode: ON for 6 hour(s): 360 . Turned on by domain\user”
* Adds registry markers to indcate current status under HKLM/Software/OpsMgr/Maintenance Mode. Can be used by patching tools.
* Added STATUS option that reads current status from registry.
--Update--
Read this post if this is not working for you -Permissions Required for Agent Maintenance Mode
The readme has also been updated with this info
----
To recap on this solution:
It allows you to start Maintenance Mode from an monitored server using just a vbscript. Using this requires absolutely no permissions in Operations Manager. All of the components required to have this function are part of a standard OS with an agent installed. It works through Gateways so can be used in firewalled or untrusted environments.
The MaintMode.vbs writes an event to the event log that indicates the length of time Maintenance Mode should remain on. This is picked up by the management pack and processed on the RMS to turn on Maintenance Mode for that server. The on time can be specified in days, hours or minutes.
Download here
The zip file contains a Readme with more information and usage instructions.
Highligh of changes in this version:
Management Pack Changes
* Added Powershell modules in MP (R2 feature) to replace scripts on RMS. Some logic reworking in scripts
* Support for Server 2008
* Fixed ON/Off logic to not put Health Service and Health Service Watcher in to Maint Mode as R2 puts HS and HSW in to MM automatically
• Added Maint Mode event collection rules
• Added Schedule Maint Mode text file option at C:\MaintenanceModeSchedule.txt - origional by Steve Rachui - http://blogs.msdn.com/steverac/archive/2008/12/09/maintenance-mode-by-config-file.aspx
* Disables discovery on RMS as Maintenance Mode should not be used on RMS
MaintMode.vbs
* Now logs the username in the event log of who turned it on: “Maintenance Mode: ON for 6 hour(s): 360 . Turned on by domain\user”
* Adds registry markers to indcate current status under HKLM/Software/OpsMgr/Maintenance Mode. Can be used by patching tools.
* Added STATUS option that reads current status from registry.
Tuesday 25 August 2009
Port Monitoring from a text file
This is another solution on how to make something that requires permissions and experience in OspMgr available to everyone to use. Teach a man to fish and all that.
These two Management packs will allow any user you specify using simple NTFS permissions to add port monitoring for a server, network device etc.
Usage
Download and Import the 2 management packs:
On each management server a discovery in the AgentlessAvailabilty MP will create a text file C:\AgentlessMonitoring\resource.txt
You can add entries to this file in the format:
{name or IP address}, port - (comma seperated)
If no port is specified it will default to port 445.
Use the hash # at the start of a line to insert a comment.
The discovery runs every 1 hour. After the discovery runs any entries in the file will then display in the console under the standard Synthetic Transaction folder
Each entry will be checked every 10 minutes.
These MPs simply reuse the existing Port Monitoring template so there is a full range of specific alerts, health states and associated Knowledge articles
To make this so that anyone can use it simply share the C:\AgentlessMonitoring folder giving write permissions to those who need it
Technical Details
The sealed Custom.PortMonitoring.Library is essentially the Port Monitoring template with the module types having any specific information promoted to class properties. The discovery in the unselaed Custom.Infra.AgentlessAvailabilty MP then creates class instances with the necessary properties.
You can leverage the sealed MP from other management packs to add port monitoring. All it takes is writing a discovery.
These two Management packs will allow any user you specify using simple NTFS permissions to add port monitoring for a server, network device etc.
Usage
Download and Import the 2 management packs:
On each management server a discovery in the AgentlessAvailabilty MP will create a text file C:\AgentlessMonitoring\resource.txt
You can add entries to this file in the format:
{name or IP address}, port
If no port is specified it will default to port 445.
Use the hash # at the start of a line to insert a comment.
The discovery runs every 1 hour. After the discovery runs any entries in the file will then display in the console under the standard Synthetic Transaction folder
Each entry will be checked every 10 minutes.
These MPs simply reuse the existing Port Monitoring template so there is a full range of specific alerts, health states and associated Knowledge articles
To make this so that anyone can use it simply share the C:\AgentlessMonitoring folder giving write permissions to those who need it
Technical Details
The sealed Custom.PortMonitoring.Library is essentially the Port Monitoring template with the module types having any specific information promoted to class properties. The discovery in the unselaed Custom.Infra.AgentlessAvailabilty MP then creates class instances with the necessary properties.
You can leverage the sealed MP from other management packs to add port monitoring. All it takes is writing a discovery.
Friday 17 April 2009
How to upgrade or apply a hotfix to a Clustered RMS
We have had a some difficulties over the months trying to apply hotfixes to any clustered Root Management Server. The hotfix installers try and stop the 3 OpsMgr services, apply the hotfix and them restart the services. These steps result in some unexpected behavior on a Clustered RMS.
What I have seen is that after the hotfix installer stops the RMS services the Cluster Service will try and restart them again.
This results in either the services running on the node you are trying to patch or the RMS resource group failing over. If the RMS fails over then, when the hotfix tries to restart the services after it has completed, it either times out or you have the RMS services running on both Cluster nodes. It it restarts the service on the node you are trying to patch the install will fail as the files are in use.
Here are some steps that can avoid these issues:
1. In Cluster Administrator ensure the RMS resource group is on the node you are patching. Then Pause the Node you are not patching. Simply right Click on the node and select Pause. This stops the resource group failing over to the other node.
2. Set the 3 RMS services not to restart automatically. Selecting each service, right Click and select Properties. On the Advanced tab set it to "Do not restart"
3. Apply the hotfix to the current node
4. When the hotfix has completed reset the services to restart automatically and resume the other node.
Repeat this to apply the patch to the second node.
This process also worked for me in upgrading a clustered lab environment to the Release Candidate of R2
What I have seen is that after the hotfix installer stops the RMS services the Cluster Service will try and restart them again.
This results in either the services running on the node you are trying to patch or the RMS resource group failing over. If the RMS fails over then, when the hotfix tries to restart the services after it has completed, it either times out or you have the RMS services running on both Cluster nodes. It it restarts the service on the node you are trying to patch the install will fail as the files are in use.
Here are some steps that can avoid these issues:
1. In Cluster Administrator ensure the RMS resource group is on the node you are patching. Then Pause the Node you are not patching. Simply right Click on the node and select Pause. This stops the resource group failing over to the other node.
2. Set the 3 RMS services not to restart automatically. Selecting each service, right Click and select Properties. On the Advanced tab set it to "Do not restart"
3. Apply the hotfix to the current node
4. When the hotfix has completed reset the services to restart automatically and resume the other node.
Repeat this to apply the patch to the second node.
This process also worked for me in upgrading a clustered lab environment to the Release Candidate of R2
Subscribe to:
Posts (Atom)