Duplicate name on network warning in SCOM

Came across this lovely gem recently. Troubleshooting steps didn't really help, at all.

A duplicate name has been detected on the TCP network. The IP address ofthe machine that sent the message is in the data. Use nbtstat -n in acommand window to see which name is in the Conflict state.

Servers in this case were in the DMZ, weren't in a domain and definitely did not have duplicate names. They did have multiple network adapters, but that shouldn't have caused the issue. Finally realized, the systems had been converted (PtoV) into our virtual enviornment from physical.

Dropped to a command prompt and ran "set devmgr_show_nonpresent_devices=1" to ensure device manager would show all hidden devices. From there, I ran devmgmt.msc to open device manager and then from the toolbar, I selected the "Show hidden devices" option. Going through, the old network adapters were still in there. After removing the adapters and rebooting, the warning did not come back.

http://support.microsoft.com/kb/315539 explains how to show hidden devices in windows.

WMI Warnings Conquered

Had my final battle with WMI and am happy to say, I won. This time the issue was caused by agentless monitoring problems. I had followed the usual steps, starting with the encryption issue in the mof files, followed by updating WMI and then WSH. However, those steps did not solve the problem with my agentless systems constantly reporting back WMI errors on monitoring.

Here is the concoction I came up wtih that finally stopped the last of the warnings in the console.

These were Windows 2003 servers I was atempting to monitor. I started by adding both the SCOM action account to the DCOM group on the local server. I also added the SCOM management server computer account. I had noticed the server and action account were both showing up in the security logs on the local server I was trying to monitor.

Next, I tweaked my component services permissions to allow both the action and computer accounts to both the "Access Permissions" and "Launch and Activation Permissions" options under COM Security.

I installed "Remote DTC" as a windows feature and allowed remote clients to connect for network DTC access.

Finally, I added the action account and management server computer account with full permissions over the following registry key:
HKLM\Software\Microsoft\WBEM

Upon rebooting, I received no further WMI errors. I will post a more detailed, blow by blow accounting of all the things to use for troubleshooting WMI warnings in System Center.

WMI Errors Continued

Just when I thought I had cleared out all my WMI woes, they returned on a couple of systems where permissions had been adjusted.

The error this time was as follows:

Object enumeration failed
Query: 'SELECT StartMode, State FROM Win32_Service WHERE Name = 'MSSQL$RTC''
HRESULT: 0x800705af
Details: The paging file is too small for this operation to complete.

The system had effectively run out of memory to process WMI requests. This ended up being a WMI memory leak issue in Windows Server 2008 and required a hotfix as outlined in the following Microsoft KB article:

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

WMI / Workflow errors in SCOM

Came across a different batch of workflow errors that required the same solution as the ones previously posted. If you encounter errors like this in SCOM, time to break out scriptomatic and toubleshoot your WMI connections to the affected servers.

*************************************************************************************

Data was found in the output, but has been dropped because the Event Policy for the process started at 10:56:09 AM has detected errors.
The 'StdErr' policy expression:
\a+
matched the following output:
Error -2147217407:
Unable to open WMI Namespace 'winmgmts:\\servername\root\cimv2'. Check to see if the WMI service is enabled and running, and ensure this WMI namespace exists.

*************************************************************************************

Data was found in the output, but has been dropped because the Event Policy for the process started at 2:35:17 PM has detected errors.
The 'StdErr' policy expression:
\a+
matched the following output:
Error -2147217357: Shutting down
The class name 'Win32_Printer' could not be found. Please check to see if this is a valid WMI class name.

*************************************************************************************

WMI Warnings when Querying Services

If you've had SCOM running for a bit, you may have noticed a number of WMI warnings, similar to this:

Object enumeration failed

Query: 'SELECT Name FROM Win32_ServerFeature WHERE Name = "Print Services"
Query: 'SELECT Name FROM Win32_ServerFeature WHERE Name = "MSSQL$MGT"
Query: 'SELECT Name FROM Win32_ServerFeature WHERE Name = "CLusSvc"
Query: 'SELECT Name FROM Win32_ServerFeature WHERE Name = "MSSQL$RCT"

The following Microsoft article provides a foundation for one solution to this issue:
http://support.microsoft.com/kb/2590230

Basically, the Windows Management Instrumentation files (*.mof) have the encryption flag turned on. This is not necessarily the case for all servers. For example, out of 100 servers, 10 exhibited this behavior.

To check on the accessibility of wmi from a remote machine, I connected with the Scriptomatic tool, changing the "WMI Source" to the remote system. When I attempted to do so, the application would error out and a warning would be logged on the remote server as to the offending WMI class.

I had to walk through several classes, repeating the steps in the microsoft article each time. I found, in most cases, the encryption flag had to be set to false in the following files:

C:\Windows\System32\WBEM\win32_tpm.mof
C:\Windows\System32\WBEM\Tscfgwmi.mof
C:\Windows\System32\WBEM\ServiceModel.mof
C:\Windows\System32\WBEM\IISwmi.mof
C:\Windows\System32\InetSrv\WebAdministration.mof
C:\Windows\SysWow64\InetSrv\WebAdministration.mof

After setting the encryption flags to FALSE and recompiling the mof files, I was able to successfully connect to the remote system via Scriptomatic and consequently, the warnings subsided in SCOM as well.

In case the Microsoft Article disappears, the steps are as follows:

1. Open C:\Windows\system32\wbem\.mof for editing and set [RequiresEncryption(FALSE)]
2. Recompile the .mof file by running "mofcomp C:\Windows\system32\wbem\.mof"
3. Restart the winmgmt service

You may have to adjust security on those files in order to make changes in them. They are typically owned by the System or TrustedInstaller and not able to be directly written into.

Adding Red Hat Agents to SCOM 2007

Ok, ok... this is supposed to be all about SCOM 2012. Well, came across a situation with 2007 and there was enough complexity that I wanted to make sure I got it all in one place.

• Similar to the 2012 install, load the appropriate linux agent to the system and install the rpm package.


• Ensure you have the management packs installed in SCOM 2007, usually the Linux and Unix libraries along with the Linux flavors you wan to monitor.


• Now, attempt to discover the Linux computer, enable SSH discover and use the FQDN of the Linux system.


• You will likely receive a certificate signing error. If that is the case, check out the Microsoft Wiki entry on the issue:


• https://social.technet.microsoft.com/wiki/contents/articles/6203.aspx


• Run through the discovery and installation again.


• Things are likely to fail, again


• Now look at the article:


• http://operatingquadrant.com/2012/01/12/opsmgr-unixlinux-heartbeat-failures-after-applying-kb2585542/


• Alternatively, you can add the 32bit DWORD value:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ SendExtraRecord = 2


• The agent should pop into monitoring console at this point. If not, run the discover for a third time.


• Finally, check your ops manager event logs. You may be getting errors about the health service or workflow on the Linux system. Check out the following article for configuring cross platform runas accounts:


• http://technet.microsoft.com/en-us/library/dd788981.aspx

Windows 2008 Core Installation - Change Computer Name

Number of examples out there for how to change a computer name, however, the commands leave something out.

You will see examples of netdom renamecomputer /newname:**new computer name**

Give that a shot, you should see an error along the lines of "The parameter /NewName was unexpected"

The proper format of the command is as follows:

netdom renamecomputer **old computer name** /NewName: **new computer name**

An easy way in the core installation to get your computer name is simply run:
ipconfig /all or hostname