SCOM: Using PowerShell to update SMTP server address in SMTP notification Channels
I’ve been asked a question on how to bulk update SMTP server addresses in SMTP notification channels using PowerShell.
Here’s the script to run in OpsMgr Command Shell:
$newSMTP = <name of your new SMTP server>
$SMTPChannels = Get-NotificationAction |Where-Object {$_.Name –imatch “smtp”}
Foreach ($item in $SMTPChannels)
{
$item.Endpoint.PrimaryServer.Address = $newSMTP
$item.Endpoint.update()
}
Run 64-bit PowerShell via SCCM 2007 Advertisement
A colleague came across a problem today. He could run a SCDPM PowerShell script from PowerShell console successfully but could not run it when packaged it in SCCM.
We soon found out it’s because SCCM 2007 is a 32-bit app and DPM PowerShell snapin is only available for 64-bit PowerShell because we could not run the script from a 32-bit PowerShell console.
When a 32-bit application tries to access %WinDir%\system32, Windows redirects it to %WinDir%\SysWOW64. In order for the 32-bit app to access %WinDir%\System32 folder, we have to use %Windir%\sysnative.
So, we set the command line of the program in SCCM package to “%WinDir%\Sysnative\WindowsPowerShell\V1.0\Powershell.exe” –noprofile .\PowerShellScript.ps1 as that’s where the 64-bit version of PowerShell is and the SCCM advertisement ran successfully on the client.
More reading regarding to file system redirection here: http://support.microsoft.com/kb/942589
SCOM Management Pack: Detecting USB Storage Device Connect and Disconnect Events
There was a requirement at work that people need to be notified when a USB storage device (USB key or portable USB hard disks) is connected or disconnected from SCOM monitored Windows computers.
So I wrote a 2 very simple alert generating rules to detect USB Mass Storage Device creation and deletion WMI event. I set both rules to run every 60 seconds so within 60 seconds of the event, an Information alert is generated in SCOM:
Alert for USB Storage Device Connection Event:
Alert for USB Storage Device Removal Event:
I have also created a dynamic group called Virtual Windows Computers in the MP so I can disable both rules for virtual machines. This is how I defined the group:
Please note this Virtual Machine discovery only detects virtual machines running on Microsoft’s virtual host platform. If you open System Center Internal Library MP in MPViewer and check the Raw XML for discovery “Discover if Windows Computer is a Virtual Machine”, you’ll see it the WQL:
So if you have non-Microsoft virtual machines (i.e. VMware) in your environment and you want to disable these 2 rules for those virtual machines, you will need to modify my group or create your own group in my management pack.
Download: USB Storage Device Detection Management Pack
Extend ConfigMgr Hardware Inventory to capture OpsMgr configurations
Download: MOF Extension for OpsMgr Configurations
I’ve been wanting to do this for a while now and finally found some spare time for it. I want to be able to target OpsMgr (SCOM) agents and servers in ConfigMgr (SCCM) in a more granular way (i.e. all OpsMgr agents that are reporting to a OpsMgr Management Server, or all OpsMgr agents within a OpsMgr management group or All OpsMgr management servers)
Therefore, I created these extensions for configuration.mof and sms_def.mof so OpsMgr settings are captured as part of ConfigMgr client hardware inventory.
Once loaded in to ConfigMgr and after clients have retrieved new policy and performed hardware inventory, you will be able to see this in Resource Explorer:
For OpsMgr Agents:
For OpsMgr Servers:
Note: As always, make sure backup both mof files before editing them. once saved, monitor dataldr.log to make sure they are successfully compiled.
Please refer to my previous blog if you decide to remove this mof extention from your ConfigMgr environment.
More Reading about ConfigMgr Hinv (Hardware Inventory):
Technet: About MOF Files Used by Hardware Inventory
Technet Blog: How to Extend Your Hardware Inventory Using the SMS_DEF.MOF File
Collection Query Samples:
All OpsMgr agents in Management Group TYANG:
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_CUSTOM_OPSMGR_2007_AGENT_SETTING_2_0 on SMS_G_System_CUSTOM_OPSMGR_2007_AGENT_SETTING_2_0.ResourceId = SMS_R_System.ResourceId where SMS_G_System_CUSTOM_OPSMGR_2007_AGENT_SETTING_2_0.ManagementGroup = "TYANG"
All OpsMgr agents managed by OpsMgr Management Server SCOM02:
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_CUSTOM_OPSMGR_2007_AGENT_SETTING_2_0 on SMS_G_System_CUSTOM_OPSMGR_2007_AGENT_SETTING_2_0.ResourceId = SMS_R_System.ResourceId where SMS_G_System_CUSTOM_OPSMGR_2007_AGENT_SETTING_2_0.ManagementServer = "SCOM02.corp.tyang.org"
All OpsMgr Management Servers:
select * from SMS_R_System inner join SMS_G_System_CUSTOM_OPSMGR_2007_SERVER_SETTING_2_0 on SMS_G_System_CUSTOM_OPSMGR_2007_SERVER_SETTING_2_0.ResourceId = SMS_R_System.ResourceId where SMS_G_System_CUSTOM_OPSMGR_2007_SERVER_SETTING_2_0.IsServer = 1
Clean Up Old Hardware Inventory Data
In SCCM, after removing WMI classes that are no longer required from configuration.mof and sms_def.mof, the inventory data still exists in few places.
If you decide to clean them up, MyITForum.com has a great WIKI page for SCCM hardware inventory which talked about different ways to clean up hardware inventory data.
I have tried the free SiteSweeper tool from SCCMExpert.com which was mentioned in the WIKI page. It’s easy to use and you can remove multiple classes from site database at once:
Other than removing the data from site databases throughout the hierarchy, the WMI class which you defined in the configuration.mof still exists in the client. I didn’t bother to look further to find tools/utilities to delete WMI classes, but simple found a sample vbscript from MSDN to modify WMI classes, and modified a little bit:
DeleteWMIClass.vbs:
wbemCimtypeString = 8 ' String datatype
Set objSWbemService = GetObject("Winmgmts:root\cimv2")
Set objClass = objSWbemService.Get()
objClass.Path_.Class = "<name of WMI class you wish to delete>"
' Remove the new class and instance from the repository
objClass.Delete_()
If Err <> 0 Then
WScript.Echo Err.Number & " " & Err.Description
Else
WScript.Echo "Delete succeeded"
End If
' Release SwbemServices object
Set objSWbemService = Nothing
To modify it, specify the WMI class you wish to delete on line 4. If the WMI class is not located in root\CIMV2 namespace, change line 2 as well.
I created a package in SCCM and advertised it to all systems.
Note: When you create the program, make sure you use the syntax “Cscript DeleteWMIClass.vbs” so the output is redirected to command prompt rather than a message box.
Error 80041001 in InventoryAgent.log after mof files modifications
I’ve been playing with SCCM mof files this weekend. After I’ve extended configuration.mof and sms_def.mof files to inventory a registry key during hardware inventory, I noticed below error logged in InventoryAgent.log on SCCM client:
Unknown error encountered processing an instance of class <name of the WMI class>: 80041001
I checked the SCCM client, the WMI class was created correctly, but the inventory data was not loaded in the SCCM database therefore I could not view it in Resource Manager.
After gone through both configuration.mof and sms_def.mof many times made sure they are 100% correct, I found this error is actually caused by a bug in SCCM 2007.
Because the SCCM client I’m using for testing is a Windows 2008 R2 machine (therefore 64 bit) and the issue with 64 bit client is documented here.
Also, while I was playing with mof files, I found this awesome tool called RegKeyToMOF. The current version is v3.0 and can be found here. It supports SMS 2003, SCCM 2007 and SCCM 2012 Beta 2.
it automatically generates mof extensions for you when you select the registry key that you want to inventory:
If you are planning to use this tool to generate the configuration.mof and sms_def.mof extensions, please make sure you tick “Enable 64bits (for Regkeys not written in Wow6432Node)” if you have 64-bit SCCM clients in your environment (nowadays, I can’t imagine that you don’t!). This is also what above mentioned KB article suggested.
Adding New Network Devices to SCOM Using PowerShell
Last week, I needed to write a PowerShell script to add iSCSI SAN devices into SCOM 2007 as network devices. I thought the script would be very straight forward, until I realised there is a limitation using SCOM PowerShell snap-in.
To explain it, let me firstly go through how to do this in SCOM console and then I’ll compare this process with using SCOM PowerShell cmdlets.
So, to add a new network device using SCOM console, it’s pretty easy:
1. Launch Discovery Wizard and choose “Network Devices”
2. Enter the network device information
3. Select the device from discovery result and choose a proxy agent for this network device
Please note the default proxy agent is set to the management server from previous step. it can be changed by click on Change button
It lists all possible proxy agents. There are 3 management servers in my test environment, SCOM01 is my RMS, SCOM02 is a management server and SCOMGW01 is a gateway server located in another untrusted forest. I have highlighted these 3 servers, notice the icon for management servers is different than other normal agents.
4. continue on and complete the rest steps of the wizard.
Now, let’s look at how to do this in PowerShell:
1. Get Network Device monitoring class
$networkdeviceclass = get-monitoringclass -name 'System.NetworkDevice'
2. Create a new DeviceDiscoveryConfiguration object
$dc = new-devicediscoveryconfiguration -monitoringclass $networkdeviceclass –fromipaddress “192.168.1.253” -toipaddress “192.168.1.253”
3. Define SNMP community string
$encoding = new-object System.Text.UnicodeEncoding
$encodedCommunityString = $encoding.GetBytes("tyang")
$dc.ReadOnlyCommunity = [System.Convert]::ToBase64String($encodedCommunityString)
4. Default SNMP version is 2, if the network device requires version 1, set the device discovery configuration to use SNMP version 1:
$dc.snmpversion = 1
5. Define the management server to be used in the discovery
$NWDeviceMS = Get-ManagementServer | Where-object {$_.displayname –ieq “SCOM02.corp.tyang.org”}
6. Start discovery using the management server defined in step 5
$DiscoveryResult = Start-Discovery -managementserver $NWDeviceMS -DeviceDiscoveryConfiguration $dc
7. If discovery is successful, add the device into SCOM.
if ($discoveryresult.monitoringtaskresults[0].status -ieq "succeeded")
{
#code to add the device into SCOM
}
Well, here’s the issue:
if you use the Add-RemotelyManagedDevice cmdlet, you have to use a SCOM AGENT as the proxy agent. You CANNOT choose a management server as the proxy agent for the network devices you are about to add.
The management server is not an agent, get-agent cmdlet does not return management servers:
And if I use the management server in Add-RemotelyManagedDevice cmdlet, it will fail:
Basically, object type mismatch…
So, if we want to use a management server as the proxy agent for network devices, we CANNOT use Add-RemotelyManagedDevice cmdlet. It is a limitation in SCOM PowerShell snap-in. Instead, There is a method in the management server object called “InsertRemotelymanagedDevices”:
we have to use this method to add network devices. Therefore, the script for step 7 should be:
if ($discoveryresult.monitoringtaskresults[0].status -ieq "succeeded")
{
$NWDeviceMS.InsertRemotelyManagedDevices($DiscoveryResult.custommonitoringobjects)
}
8. Check result:
As you can see, the device has been successfully added.
Event ID 29104 on SCOM RMS cluster
First of all, apologies for not been able to blog for over a month. I changed jobs. I started my new job 4 weeks ago, with all the things going on, I couldn’t find time to sit down and write blog articles. I am now working in a large “System Center Shop” which consists of SCCM, SCOM, SCVMM, Opalis, SCDPM and Hyper-V that spread over Australia national wide. so hopefully, my future blogs will have posts related to other System Center products as I get my hands on these products, not just SCCM and SCOM.
Anyways, in the last couple of days, I noticed on the 2-Node RMS cluster at work, when RMS is running on Node B, Event ID 29104 is logged in Operations Manager event log:
“OpsMgr Config Service failed to send the dirty state notifications to the dirty OpsMgr Health Services. This may be happening because the Root OpsMgr Health Service is not running.”
This event was only generated when RMS was running on Node B, also, when Node B was the active node, RMS health state was greyed out in SCOM console. If I fail over RMS to Node A, everything is fine.
After spent some time troubleshooting the issue, I have found there are some registry keys mismatch between 2 nodes, they are under HKLM\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Server Management Groups\<Management Group Name>\
On node B, “IsRootHealthService” is set to 0, Node A is set to “1”
Also on node B, there is a set of sub keys “Parent Health Services”. this set of keys should not exist in RMS:
So, to fix the issue, I firstly failed over RMS to node A, then changed “IsRootHealthService” on node B to “1” and deleted “Parent Health Services” key from node B. After that, I failed RMS back to node B, the 29104 events were no longer been logged and the RMS health state is not grey anymore.
Again, I did not consult Microsoft on this one, please take a back up of the registry keys before you change it and I am not responsible for any damages it may cause.
PowerShell script to backup unsealed SCOM MPs
Not sure if anyone has written this before. I have written this simple script to backup all unsealed management packs.
I have scheduled it to run daily on RMS via Windows Task Scheduler.
How does it work:
- Backup unsealed MPs to a local folder.
- Delete older backups from local folder
- robocopy backup from local folder to a remote location using purge option (Anything that not exist from source will be deleted from destination. Therefore old backups are deleted from remote folder as well.)
Preparing the script:
Modify line 21-23 to suit your environment
$backuproot – local folder where MPs are backed up to.
$remoteLocation – Remote location where backups are robocopied to.
$daysToKeep – retention period
Finally, make sure you the account scheduled task runs under has appropriate rights in SCOM.
Download the script HERE.
“Orphaned” Maintenance Windows for SCCM clients
Last week, in my SCCM test environment, I noticed there are several maintenance windows applied to clients that I had no idea where were they come from.
Symptoms:
When using SCCM Client Center, it shows this particular client (MGMT01) has 3 maintenance windows (service window) assigned to it:
PolicySpy from ConfigMgr 2007 Toolkit also shows the same:
The problem is, there should ONLY be 1 maintenance window for this client:
and actually, there is ONLY 1 maintenance window in total in my entire environment:
I ran “SELECT * from v_ServiceWindow” against the site database and there is only 1 row returned.
Background:
Sometime last year, I installed a new central site called “CEN” and set the existing primary site “TAO” as the child site.
The only legitimate maintenance window in my SCCM hierarchy should be the one showed above in the database, it is created for a collection I created called “All Windows Server 2008 R2 Systems (CEN0000E)” on central site “CEN”.
I suspect I might have created 2 maintenance windows for the 2 built-in collections “All Systems” (SMS00001)” and “All Windows Server Systems (SMS000DS)” on site “TAO” before I configured “TAO” as child primary under “CEN”. but it has been too long and I couldn’t remember it.
Troubleshooting:
1. I tried to reset SCCM clients policies using PolicySpy, it did not help. these maintenance windows came back after machine policy retrieval and evaluation and it is logged in PolicyEvaluator.log:
Updating policy CCM_Policy_Policy4.PolicyID=”SMS00001-{bf9d2dba-eb0a-412f-9147-82f12b4f136a}”,PolicySource=”SMS:TAO”,PolicyVersion=”1.00″ PolicyAgent_PolicyEvaluator 16/08/2011 8:23:41 AM 3624 (0x0E28)
Applying policy SMS00001-{bf9d2dba-eb0a-412f-9147-82f12b4f136a} PolicyAgent_PolicyEvaluator 16/08/2011 8:23:41 AM 3624 (0x0E28)
2. Since I cannot modify the built-in collections from the child primary sites because they also exist in parent sites, and it is only a test environment, I removed parent-child relationship between CEN and TAO and waited overnight, then checked maintenance windows settings for SMS00001 and SMS000DS on TAO, there are no maintenance windows created for these 2 collections. So this step did not help me resolving the issue.
3. I then had a look at the policy table in both CEN and TAO site databases trying to find the policy for these orphaned maintenance windows using the policyID showed in PolicySpy:
I ran “SELECT * FROM Policy where PolicyID LIKE ‘SMS%’” on both site databases, “CEN” database returned nothing and “TAO” has returned 2 rows and the policyIDs match the ones for orphaned maintenance windows:
I deleted these 2 rows from Policy table:
delete FROM Policy where PolicyID = 'SMS00001-{bf9d2dba-eb0a-412f-9147-82f12b4f136a}'
delete FROM Policy where PolicyID = 'SMS000DS-{4fe54281-f3f1-4b9f-9d9e-d1eb12b4a87e}'
and from PolicyAssignment table:
delete FROM PolicyAssignment where PolicyID = 'SMS00001-{bf9d2dba-eb0a-412f-9147-82f12b4f136a}'
delete FROM PolicyAssignment where PolicyID = 'SMS000DS-{4fe54281-f3f1-4b9f-9d9e-d1eb12b4a87e}'
Then restarted SMS_EXECUTIVE and SMS_SITE_COMPONENT_MANAGER services on TAO site server (also the MP). – Not sure if this is required, I did it anyway.
Finally, I reset SCCM client policy via PolicySpy and initiated “Machine Policy Retrieval and Evaluation Cycle”
Once evaluation is completed, SCCM Client Center is showing the correct maintenance windows setting:
Since I need to do this to all SCCM clients (because SMS00001 = “All Systems” collection), I’ll create a software package with a batch file as program:
WMIC /Namespace:\\root\ccm path SMS_Client CALL ResetPolicy 1 /NOINTERACTIVE WMIC /Namespace:\\root\ccm path SMS_Client CALL RequestMachinePolicy 1 /NOINTERACTIVE
Disclaimer: The purpose of this post is only to document the steps I have taken to resolve this particular issue in my TEST environment. I did not consult with any other parties (including Microsoft) during troubleshooting. Even though I have not seen any negative impacts after I implemented this change in my test environment, I am not responsible for any damages it may cause in other SCCM environments.