DiscoverDHCPFailoverServerWatcher2 012 script fails

I keep getting PowerShell Script failed to run alert for DiscoverDHCPFailoverServerWatcher2012 script after importing DHCP management pack for WS2012 R2. Does anybody have any ideas about how to fix this one?

running scom 2012 r2 with all recent updates installed; dhcp server is ws2012 r2

Alert details below:

The PowerShell script failed with below
exception

System.Management.Automation.RuntimeException: You cannot call
a method on a null-valued expression.At line:128 char:5
+
$ObjDHCPFailoverWatcher.AddProperty($ScopeId, $FailOvObj.Scope ...
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at
CallSite.Target(Closure , CallSite , Object )
at
System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0
arg0)
at CallSite.Target(Closure , CallSite , Object )
at
System.Management.Automation.Interpreter.DynamicInstruction`2.Run(InterpretedFrame
frame)
at
System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame
frame)




Script Name:
DiscoverDHCPFailoverServerWatcher2012


One or more workflows were
affected by this.

Workflow name:
Microsoft.Windows.DHCPServer.2012.R2.FailoverServerWatcher.Discovery


Instance ID:
{33ABA8E1-DDD0-F8B9-7458-637B394

March 20th, 2014 9:18pm

Hi,

Do you have DHCP failover deployed?

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

Regards,

Yan Li

Free Windows Admin Tool Kit Click here and download it now
March 24th, 2014 8:37am

Yes, DHCP role is installed on that server and DHCP failover is configured.
March 24th, 2014 10:23am

We are getting the same error message. We have DHCP failover deployed with Windows Server 2012 and SCOM 2012 R2.
Free Windows Admin Tool Kit Click here and download it now
June 23rd, 2014 9:05am

Hi Jasse,

I have the same issue and i am investigating. Do you have the correct amount of instances in for the "Microsoft Windows DHCP 2012" class? You can goto monitoring --> Discovered Inventory --> Change target Type...

Select this class and see if the servers are the correct ones.

regards,

Marthijn.

July 7th, 2014 2:33pm

I did some investigation and in my case i have one DCHP server that seems to be discovered twice.
In one case the class instance is with capital letters and i have all the properties like BOOTP enabled and bindings Aware found.

In the other case where the same server is discoverd and displayed with small letters no properties are found.

The discovery script DiscoverDHCPFailoverServerWatcher2012 is targetted again the class where those two are instances in. The script expects some values but does not have them at this point and gives the error.

At this point i am still looking for a reason why this server is discovered twice. I will keep this post updated.

regards,

Marthijn.


Free Windows Admin Tool Kit Click here and download it now
July 8th, 2014 7:55am

I was able to remove the orphaned object but still have the same script failure.
Looks like i am looking in the wrong direction.

More investigation needs to be done...

Regards,

Marthijn.

July 8th, 2014 9:37am

Hi,

So some more investigation pointed out there is something wrong with the ScopeId property which is defined the script "DiscoverDHCPFailoverServerWatcher2012". This script is defined in the "DHCP 2012 R2 Failover Server Relationships Discovery Data Source" discovery rule.

The discovery class is Microsoft Windows DHCP Server 2012 R2 Failover Relationship.

Now when i look at the discoverd instance is can see a wrong value for the Scope ID: System.Object[]

I need to find out why this is here.
When i unseal the management pack and look for the script that is executed for this discovery rule i cut/paste the script and look at line 128 (This is where the error occurs, see the alert details):

$ObjDHCPFailoverWatcher.AddProperty($ScopeId,               $FailOvObj.ScopeId.ToString())

The Scope Id is an IP adres and in my opinion something goed wrong with the ToString option.

I will check this with Microsoft and try to find out if this is a bug.

Regards,

Marthijn.


Free Windows Admin Tool Kit Click here and download it now
July 10th, 2014 12:00pm

Hi Gleb,

I had some contact with Microsoft and the problem in my environment was that to many failover partners (that did not exist) where in place.

This can be checked by running this PowerSjhell command Get-DhcpServerv4Failover -ComputerName <your DHCP Server>

With one server i got three entries on which the "State" was: CommunicationInterrupted
The ScopeId was empty too on those two entries. This explains why the discovery does not run properly.

I fixed this by removing the two entries via PowerShell:

Remove-DhcpServerv4Failover -Name <wrong entry name> -Force

After this i flushed the agents on both my DHCP servers. The discovery does not fail anymore.

Best regards,

Marthijn

July 28th, 2014 10:39am

Hi Gleb,

I had some contact with Microsoft and the problem in my environment was that to many failover partners (that did not exist) where in place.

This can be checked by running this PowerSjhell command Get-DhcpServerv4Failover -ComputerName <your DHCP Server>

With one server i got three entries on which the "State" was: CommunicationInterrupted
The ScopeId was empty too on those two entries. This explains why the discovery does not run properly.

I fixed this by removing the two entries via PowerShell:

Remove-DhcpServerv4Failover -Name <wrong entry name> -Force

After this i flushed the agents on both my DHCP servers. The discovery does not fail anymore.

Best regards,

Marthijn

Free Windows Admin Tool Kit Click here and download it now
July 28th, 2014 10:39am

Hi Marthijn,

We had the same error in SCOM.

We had one replication relationship from one server to the other with for the scopes, which was working fine. But there was also a replication defined without any scopes in it. So the SCOM monitor stopped on a null-valued expression. Maybe the monitor should first check if there are any scopes in the replication-relationship, before filling the variable, so the script continues normally.

Regards,

Andre

July 10th, 2015 5:53am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics