Network and Storage Protocols

NetApp Returns Incorrect Server Info

Andy9999
3,444 Views

Hi Experts,

 

There is a problem with the info returned by NetApp Filers upon a NetServerGetInfo (Windows Networking API).

 

The server information returned by the API call should have the SV_TYPE_DOMAIN_MEMBER flag set in the sv101_type member of the returned structure, if the filer is joined to a domain, but it is never set.

 

You can reproduce the problem like this:

#include "stdafx.h"

#include <windows.h>

#include <lm.h>

main()

{

  SERVER_INFO_101* result;

  DWORD err;

 

   err=NetServerGetInfo(L"MyNetAppFilerName", 101, (LPBYTE) &result);

   printf("NetServerGetInfo call returned result %d\n", err);

}

 

The call always returns 0x9003 for the sv101_type field which corresponds to the following flags:

SV_TYPE_WORKSTATION
SV_TYPE_SERVER
SV_TYPE_SERVER_NT
SV_TYPE_NT

 

But never SV_TYPE_DOMAIN_MEMBER.

 

All storage appliances that I'm aware of are returning an incorrect result for this API, but NetApp could be the first appliance that actually returns the expected result, that a Windows server would return.

 

Here is more info on the NetServerGetInfo API: https://msdn.microsoft.com/en-us/library/windows/desktop/aa370624%28v=vs.85%29.aspx

 

And this is the documentation of the SERVER_INFO_101 result structure: https://msdn.microsoft.com/en-us/library/windows/desktop/aa370903%28v=vs.85%29.aspx

 

It should be possible to reproduce the problem with the sample code above, you may have to add the NetApi32.Lib library to successfully compile the example. If you receive error 5 (Access Denied) you may have to authenticate first, for example by connecting a network drive.

 

Fixing this problem, would increase compatibility of Filers with 3rd party applications.

 

It would be great to receive some kind of feedback from NetApp for this issue (or at least some Kudos).

 

Kind Regards,

Andy

1 REPLY 1

Darkstar
3,192 Views

So what real-world applications do you have that do not work with the current implementation as-is?

 

Changing something like this would require extensive compatibility testing with operating systems and network stacks going back as far as LAN Manager 3.0 for DOS, so unless you have a very compelling use (and are a very big customer, I guess Smiley Very Happy) I doubt that anything will be changed there. ESPECIALLY if the actual use-case turns out to be "I just want the result of this API call to be what Windows version X returns" instead of, say, "my application which is a multi-million-dollar SAP or CATIA installation, doesn't work with the current implementation" 😉

Public