How to prevent a virtual network adapter from being shown in NIC Teaming on Windows Server 2012?

Hi,

I’m looking for a configuration option similar to NFC_HIDE which can hide a virtual adapter but only for NIC Teaming.

Adapter should stay visible in Network Configuration and fully operational.

Thanks!

Are you saying you only want to hide your adapter from the Teaming facility?

I don’t quite get the objective.

All the NCF_* flags are document and recently Mr. Tippet clarified on this list how NCF_HIDDEN and the PnP visibility flags interact (or don’t as the case may be) to achieve display or non-display of the ‘device’ and ‘interface’ associated with an NDIS NIC.

See http://www.osronline.com/showThread.cfm?link=268504

Good Luck,
Dave Cattley

Sent from Mail for Windows 10

Correct! A virtual adapter should be hidden only from the Teaming facility since the virtual adapter is already a 3-rd party teaming solution.

The only hint from MS is “DO NOT mix elements of 3rd-party teaming solutions with elements of Microsoft’s NIC Teaming solution.”

My goal is to provide a dummy user protection to avoid such a mix.

From: Dave Cattley [mailto:xxxxx@msn.com]
Sent: 22 September 2015 01:41
To: Wieslaw Kubala; Windows System Software Devs Interest List
Subject: RE: [ntdev] How to prevent a virtual network adapter from being shown in NIC Teaming on Windows Server 2012?

Are you saying you only want to hide your adapter from the Teaming facility?

I don’t quite get the objective.

All the NCF_* flags are document and recently Mr. Tippet clarified on this list how NCF_HIDDEN and the PnP visibility flags interact (or don’t as the case may be) to achieve display or non-display of the ‘device’ and ‘interface’ associated with an NDIS NIC.

See http://www.osronline.com/showThread.cfm?link=268504

Good Luck,

Dave Cattley

Sent from Mailhttp: for Windows 10</http:>

I’m not sure what the status of NDIS binding class directives are in Win10 but at one time you might have been able to use UpperExclude to tell NETCFG to *not* bind your adapter to certain elements (like the teaming IM driver). I have to admit I don’t know if that actually ever worked having never done it. LowerExclude definitely did work.

Sorry, I don’t have anything more to give as a hint. The entire Network Installer has been re-written and I think we as a community have lots to re-learn about the new state of affairs.

Good Luck,
Dave Cattley

>The entire Network
Installer has been re-written and I think we as a community have lots to
re-learn about the new state of affairs.

The new Network Install Engine does work in strange ways. MS is working diligently with us to find out why our Win7 IM driver does not install on Win10.

Larry C

>> The entire Network

> Installer has been re-written and I think we as a community have lots to
> re-learn about the new state of affairs.

The new Network Install Engine does work in strange ways. MS is working
diligently with us to find out why our Win7 IM driver does not install on Win10.

I believe this may be relevant to my interests as well. I just inherited a network filter driver and my first task is trying to figure out why it doesn’t install on Windows 10. From my investigations so far I’m finding that the INetCfg and INetCfgClassSetup are behaving very strangely. Mostly by returning undocumented error codes which are of no help in debugging.

The original (unanswered) post that led me to this list, http://www.osronline.com/showThread.cfm?link=269218 just happened to have the exact same error code I was seeing with INetCfgClassSetup::Install().

Anyway, I don’t want to thread-jack. I need to gather more information before I can pose a more intelligent question but so far it seems to only be the Enterprise version of Win10 that we’re seeing issues with.

>Mostly by returning undocumented error codes
That is what we are also seeing, along with needed Registry entries not there at a particular point of the install when the entries were there for Win7.
I suggest you open a case with MS through SysDev. The more drivers that fail that are given to MS may help them track down the gremlins.

Larry C

Thanks Larry, I’ll do that. I’m still trying to verify that we’re not doing something wrong because there are some situations where we can install the driver manually through the network properties of the interface but not through our installation tool.