Lanman resource is simply the virtual hostname resource. Similar to the Network Name resource in a Microsoft cluster, it assigns a virtual hostname to the virtual IP that is specified in the Ip resource. If you desire your fileshare to be accessed using a virtual hostname, you will need a lanman resource in the Fileshare service group. Without it, when you failover between your cluster nodes, your fileshare can only be accessed using the virtual IP or the physical hostname where it is currently online.

In terms of setup, it needs to be specified with the virtual hostname, IP resource name at least to probe. Question mark on it means it's not probed. Not probed = configuration error of the resource in most cases. Such as a typo or an empty field which needs to be filled. When creating the lanman resource, all the bolded fields needs to be filled or it will not probe. Also, Lanman need to depend on the IP resource. So it should be NIC > IP > LANMAN > FILESHARE on the left side. (vmdg and mountv is fine as is)

Ok, im pretty sure, there is no typo in the resource. Whats the next step to troubleshoot this problem?
I imported the two *.cf files to the test environment, changed all settings and the lanman resource failed again.

is it the best way to open a support case?

You'll need to contact technical support to open a case. You can find information at: http://www.symantec.com/business/support/index.jsp

Best,
Kimberley

ok, thanks for the information.

Hi Sigi

Before you log a case - can you try removing the underscore character (_) from the VirtualName attribute on the Lanman?

Also, can you manually link the dependency correctly? Lanman as parent, dependent on child IP. Fileshare dependent on Lanman

Thanks
Darren

I dont think that the underscore is a problem, many other resource on other servers do not have any troubles with it.
If i link the resource with the fileshare and the ip resource, the "sorting" is odd.

Maybe thats a hint to the problem..?

Thanks

Lanman should be above the IP not below. (As I said above, it goes in order as below)

FileShare
 |
Lanman
 |
IP
 |
NIC

In regards to the underscore, Darrent meant it for the virtual host name, not the actual resource name.
As seen from your log snippet, I can see that you are using "Sharename_xxxx" for your virtual name.
Try something without an underscore as underscore is not a legal character for a hostname.

If it still doesn't probe, maybe you can take a screenshot of the properties view of your lanman resource?
(the section where you typed in the virtual hostname and Ip resource name etc to see how it's configured)

ok now it looks like this
And i changed the Virtual Name

2009/08/12 16:05:00 VCS DBG_21 V-16-50-0 Lanman:APPLP_Lanman:monitor:*** Start of debug information dump for troubleshooting ***
 LibLogger.cpp:VLibThreadLogQueue::Dump[206]
2009/08/12 16:05:00 VCS DBG_21 V-16-50-0 Lanman:APPLP_Lanman:monitor:Listing resource (APPLP_Lanman) attributes:
 LanmanAgent.cpp:CLanmanAttributes::Parse[2693]
2009/08/12 16:05:00 VCS DBG_21 V-16-50-0 Lanman:APPLP_Lanman:monitor:m_VirtualName = Servername.Domain.com
 LanmanAgent.cpp:CLanmanAttributes::Parse[2707]
2009/08/12 16:05:00 VCS DBG_21 V-16-50-0 Lanman:APPLP_Lanman:monitor:m_IsMultiNet = 0
 LanmanAgent.cpp:CLanmanAttributes::Parse[2718]
2009/08/12 16:05:00 VCS DBG_21 V-16-50-0 Lanman:APPLP_Lanman:monitor:ipAddress = xxx.xx.xx.xx, 0x414815AC
 LanmanAgent.cpp:CLanmanAttributes::Parse[2743]
2009/08/12 16:05:00 VCS DBG_21 V-16-50-0 Lanman:APPLP_Lanman:monitor:subnetMask = 255.255.255.0, 0x00FFFFFF
 LanmanAgent.cpp:CLanmanAttributes::Parse[2767]
2009/08/12 16:05:00 VCS DBG_21 V-16-50-0 Lanman:APPLP_Lanman:monitor:*** End of debug information dump for troubleshooting ***
 LibLogger.cpp:VLibThreadLogQueue::Dump[217]
2009/08/12 16:05:48 VCS DBG_21 V-16-50-0 Lanman:APPLP_Lanman:monitor:*** Start of debug information dump for troubleshooting ***
 LibLogger.cpp:VLibThreadLogQueue::Dump[206]
2009/08/12 16:05:48 VCS DBG_21 V-16-50-0 Lanman:APPLP_Lanman:monitor:Listing resource (APPLP_Lanman) attributes:
 LanmanAgent.cpp:CLanmanAttributes::Parse[2693]
2009/08/12 16:05:48 VCS DBG_21 V-16-50-0 Lanman:APPLP_Lanman:monitor:m_VirtualName = Servername.Domain.com
 LanmanAgent.cpp:CLanmanAttributes::Parse[2707]
2009/08/12 16:05:48 VCS DBG_21 V-16-50-0 Lanman:APPLP_Lanman:monitor:m_IsMultiNet = 0
 LanmanAgent.cpp:CLanmanAttributes::Parse[2718]
2009/08/12 16:05:48 VCS DBG_21 V-16-50-0 Lanman:APPLP_Lanman:monitor:ipAddress = xxx.xx.xx.xx, 0x414815AC
 LanmanAgent.cpp:CLanmanAttributes::Parse[2743]
2009/08/12 16:05:48 VCS DBG_21 V-16-50-0 Lanman:APPLP_Lanman:monitor:subnetMask = 255.255.255.0, 0x00FFFFFF
 LanmanAgent.cpp:CLanmanAttributes::Parse[2767]
2009/08/12 16:05:48 VCS DBG_21 V-16-50-0 Lanman:APPLP_Lanman:monitor:*** End of debug information dump for troubleshooting ***
 LibLogger.cpp:VLibThreadLogQueue::Dump[217]

Dependancies now look correct. =) With regards to Lanman not probing.
Lanman requires only 2 attributes for it to function by default. They are:

VirtualName = VHOSTNAME (this needs to be under 16 characters, do not put .domain.com at the end)
IPResName = Name of IP resource (For you, it should be XXXX_IP)

If these 2 are typed in correct, I see no reason for it to not probe unless some other parameters were changed.
Let me know how you go after changing these two to correct values. (assuming they are not correct for now)

Siji

Please check whether your types.cf got properly updated or not, you can compare the current file with the backup taken by VCS during installation (in the dir C:\Documents and Settings\All Users\Application Data\Veritas\cluster server\vpibackup )

Your problem can cause if 5.0 types.cf file is not replaced by the 5.1 types.cf file, because Symantec changes only few agent types in each upgrade and it could be LANMAN for your bad luck !! :-)

Regards
Habeeb