-
- Lurker
- Posts: 2
- Liked: never
- Joined: Dec 02, 2011 8:06 am
- Full Name: Josef Fucik
- Contact:
LsaSrv event 6037 - target name HOST/.
Hello,
we recently implemented nworks MP 5.7 and everything works fine. We only have one issue - after installation of the MP into SCOM 2007 R2 following events started to appear in the system log of all hosts with SCOM agents installed (W2K8R2), not limited only to nworks Collector:
"The program svchost.exe, with the assigned process ID 1234, could not authenticate locally by using the target name HOST/.. The target name used is not valid. A traget name should refer to one of the local computer names, for example, the DNS host name.
Try a different target name.
Source: LsaSrv
EventID: 6037
Level: Warning
..."
The warnings appear regularly about every 4 hours. When uninstalling the nworks MP the events disappear. We checked SPNs and found nothing unusual. How to prevent this?
we recently implemented nworks MP 5.7 and everything works fine. We only have one issue - after installation of the MP into SCOM 2007 R2 following events started to appear in the system log of all hosts with SCOM agents installed (W2K8R2), not limited only to nworks Collector:
"The program svchost.exe, with the assigned process ID 1234, could not authenticate locally by using the target name HOST/.. The target name used is not valid. A traget name should refer to one of the local computer names, for example, the DNS host name.
Try a different target name.
Source: LsaSrv
EventID: 6037
Level: Warning
..."
The warnings appear regularly about every 4 hours. When uninstalling the nworks MP the events disappear. We checked SPNs and found nothing unusual. How to prevent this?
-
- Novice
- Posts: 5
- Liked: never
- Joined: Sep 24, 2010 8:19 am
- Full Name: Mark Edwards
- Contact:
Re: LsaSrv event 6037 - target name HOST/.
I have also seen exactly the same issue in previous versions as well.
I originally logged a call with MS but they traced it to one of the nworks discoveries.
Doesnt seem to have any impact other then flaging this error constantly.
I originally logged a call with MS but they traced it to one of the nworks discoveries.
Doesnt seem to have any impact other then flaging this error constantly.
-
- VP, Product Management
- Posts: 1497
- Liked: 383 times
- Joined: Jan 01, 2006 1:01 am
- Contact:
Re: LsaSrv event 6037 - target name HOST/.
Hi Guys,
We have not seen this here.
We do have a new discovery in nworks 5.7 that runs in all SCOM Agents; this is checking whether each Agent is actually running inside a VMware VM (by looking in the registry for VMware BIOS details). If the agent is running in VMware, we create an object 'VMware Virtual Machine' that we use for a further discovery target, to create the relationship between the VM and the Agent running inside.
Are you running those discoveries? Are they successful? (first discovery is enabled by default; second is disabled by default)
For full details see Operations Guide starting page 13 'VM and Ops Mgr Agent integration'
Regarding the error, we have not seen this in QA. Possibly an issue with the Action Account permissions when trying to read the registry?
We have not seen this here.
We do have a new discovery in nworks 5.7 that runs in all SCOM Agents; this is checking whether each Agent is actually running inside a VMware VM (by looking in the registry for VMware BIOS details). If the agent is running in VMware, we create an object 'VMware Virtual Machine' that we use for a further discovery target, to create the relationship between the VM and the Agent running inside.
Are you running those discoveries? Are they successful? (first discovery is enabled by default; second is disabled by default)
For full details see Operations Guide starting page 13 'VM and Ops Mgr Agent integration'
Regarding the error, we have not seen this in QA. Possibly an issue with the Action Account permissions when trying to read the registry?
-
- Novice
- Posts: 5
- Liked: never
- Joined: Sep 24, 2010 8:19 am
- Full Name: Mark Edwards
- Contact:
Re: LsaSrv event 6037 - target name HOST/.
Hi Alec
Im running 5.6 and see this error.
It only occurs on Windows 2008 R2 servers.
There are 2 discoveries targetted at all Windows Servers - 'Discover nworks Enterprise Manager Server' and 'Discover nworks Collectors' these run every 4 hours and that coincides with the error seen.
When speaking to MS they seemed to indicate the issue was with using a dot in the discovery <ComputerName>.</ComputerName> rather than <ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
This is reflected in the Lsasrv error seen on the 2008 R2 servers regarding 'HOST/.'
Not sure if that helps ?
Im running 5.6 and see this error.
It only occurs on Windows 2008 R2 servers.
There are 2 discoveries targetted at all Windows Servers - 'Discover nworks Enterprise Manager Server' and 'Discover nworks Collectors' these run every 4 hours and that coincides with the error seen.
When speaking to MS they seemed to indicate the issue was with using a dot in the discovery <ComputerName>.</ComputerName> rather than <ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
This is reflected in the Lsasrv error seen on the 2008 R2 servers regarding 'HOST/.'
Not sure if that helps ?
-
- Novice
- Posts: 8
- Liked: never
- Joined: Dec 23, 2011 12:53 pm
- Full Name: Steve Burkett
- Contact:
Re: LsaSrv event 6037 - target name HOST/.
We're seeing this on our Windows 2008 R2 VM's being monitored with an evaluation version of nWorks 5.7 MP, we've got both discoveries enabled. Will have a go with ProcMon if I get time to try and figure out if its a Registry perms issue.
-
- VP, Product Management
- Posts: 1497
- Liked: 383 times
- Joined: Jan 01, 2006 1:01 am
- Contact:
Re: LsaSrv event 6037 - target name HOST/.
Thanks all,
OK, we will try to repro here. The use of '.' instead of full path to NetworkName$ should be supported by SCOM agent, '.' should resolve to 'local computer'. However possibly new security in Win2008 R2 has some objection - or maybe action account permissons to the registry....is the agent Action Account a FULL administrator of the server?
Thanks,
Alec
OK, we will try to repro here. The use of '.' instead of full path to NetworkName$ should be supported by SCOM agent, '.' should resolve to 'local computer'. However possibly new security in Win2008 R2 has some objection - or maybe action account permissons to the registry....is the agent Action Account a FULL administrator of the server?
Thanks,
Alec
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Dec 02, 2011 8:06 am
- Full Name: Josef Fucik
- Contact:
Re: LsaSrv event 6037 - target name HOST/.
Hi Alec,
the action account run as Local System.
the action account run as Local System.
-
- Novice
- Posts: 8
- Liked: never
- Joined: Dec 23, 2011 12:53 pm
- Full Name: Steve Burkett
- Contact:
Re: LsaSrv event 6037 - target name HOST/.
Local System here as well.
-
- Novice
- Posts: 5
- Liked: never
- Joined: Sep 24, 2010 8:19 am
- Full Name: Mark Edwards
- Contact:
Re: LsaSrv event 6037 - target name HOST/.
Hi Alec, any luck reproducing the issue ?
-
- VP, Product Management
- Posts: 1497
- Liked: 383 times
- Joined: Jan 01, 2006 1:01 am
- Contact:
Re: LsaSrv event 6037 - target name HOST/.
Hi Mark, and all,
we can (occasionally) reproduce this issue, yes. After deeper analysis, and input from Microsoft, we've established that this error is informational only - there is no actual failure (our discovery still works fine). This error is just from some interaction of SCOM agent processes with the windows subsystem.
So, we will look to address this in a future update (we can modify our discovery so the error is not generated) - however this error does not indicate any problem in the current MP, and can be safely ignored.
Cheers
Alec
we can (occasionally) reproduce this issue, yes. After deeper analysis, and input from Microsoft, we've established that this error is informational only - there is no actual failure (our discovery still works fine). This error is just from some interaction of SCOM agent processes with the windows subsystem.
So, we will look to address this in a future update (we can modify our discovery so the error is not generated) - however this error does not indicate any problem in the current MP, and can be safely ignored.
Cheers
Alec
Who is online
Users browsing this forum: No registered users and 1 guest