Well, then I am curious what you did to make it work. I've tried to install/uninstall/re-install Intel Teaming now at least a dozen time on the Fall Creators 1709 update, but I cannot get it to work. The software appears to install all right, but when I try to create a Team in inevitably fails with a dialog box "Creation Team Failed". I suppose I must have something peculiar in the configuration of my system, but I sure can't find it.
I managed to get 22.7.1 to work on 1709 after umpteen attempts although I still don't understand why I got it to work. When looking at the Network Adapter properties I noticed there was still an Intel Advanced Network Services protocol option, despite having uninstalled ANS. I then went to uninstall that particular protocol option. Furthermore I realised that my attempts to install ANS were done withr my local user name account (with Administrator rights) as opposed to the Administrator account itself. For my "real" user account I have the Documents folder mapped to a network drive, and I have seen more installation programs not liking that (not Intel ANS though, as I am confident I have always installed that under my personal local account with admin privileges). In any case, I switched to the Administrator account, installed 22.7.1 and voila, it went fine, and I could create a team. So I am off to the races now.
I don't know whether others can replicate similar approaches, but 22.7.1 does not appear to be completely broken on 1709 - it looks more like some bugs in the installation process that don't quite jive with a changes 1709 networking environment.
OK, different issue than most here lately, but you guys are probably closely related to what I am experiencing so might have some input.
On my previous laptop (older versions of everything) I had an 802.1Q trunk with several VLANs on it. I was able to create the VLANs in the driver config and it would create the additional interfaces in windows (all good). I could then startup Wireshark and select each "~sub" interface as expected. I also could select the "~base" interface of just the Ethernet and I would be able to capture all the traffic going to and from the hardware NIC on all VLANS. No IPs configured on any interface. This was great because I would startup different VMs and assign each to a VLAN and run tools and I could see all traffic in one place and keep a CYA pcap of what I had done.
New laptop, latest driver, latest OS, latest Wireshark.
Configure the VLANs in the driver config, windows creates the interfaces, they work. However, Wireshark doesn't see the interfaces (even if I refresh the interfaces), any not sub or base. Now after I create the reg to monitor mode =1 key and reboot, I can see the sub interfaces (but can't send of course) but not the base. I put the reg setting to 0 and reboot, still can't see the base in Wireshark, I remove the VLANs and get an IP on the base and now I can see it. Also, adding VLANs doesn't show up until a reboot.
So long story short if someone else sees this, is some sort of combination of setting the reg key on and off, having the NIC in non 802.1Q mode, and rebooting after adding VLANs will get you to what I was looking for.
Others, any idea on what is going on?
Has anyone experienced this?
Intel, just want you to know of this use scenario to make sure it doesn't get killed later and if you could figure out what went wonky currently, that would be great.
I've changed the adapter, using latest version of the 22.x drivers and I still get BSODs when I disable the teaming.
I've the issue as after the pc goes to sleep every other time (probably after the second sleep/wakeup) the network is limited and the team has a 169. address.
I've checked on the switch and the team appear "not active" in that situation.
When I disable the team to try to recoved the IP I get the BSOD.
Usually a bad_pool_caller... very very bad
Finally figured out a way to get this to work after several failures with 1709. I am NOT using teaming, only VLANs. Here's the steps I took:
My goal was to get the system back to a 'more default' state -- i.e., the Intel NIC using Microsoft-provided drivers, then upgrade to 1709 again.
- Reverted to 1703
- Removed all VLAN virtual adapters
- Reset the NIC to be a "normal" interface (no ANS usage).
- Ran through the steps Intel provides here to rip out ANS/ProSet manually.
- Renamed C:\Program Files\Intel\Wired Networking to something else (just in case).
- In Device Manager, uninstalled the Intel NIC - selecting the "delete drivers" checkbox.
- Reboot. Verify Microsoft driver present on NIC when system comes back up, and verify no issues with networking.
- Update to 1709.
- Verify system OK, everything functioning.
- Went to install 22.10 drivers -- it thinks they're still installed, selected "Remove".
- Install 22.10 drivers. Reboot (even though it doesn't ask / isn't required).
- Verify system OK, everything functioning, Intel NIC driver present.
- Configured VLAN virtual adapters as normal. Test operation.
The strangest thing I encountered in all of this is that among the problems I encountered when upgrading to 1709 with the ANS in place is that the 'Network Setup Service' gets stuck in a "Starting" state. This made it extremely difficult to troubleshoot when upgrading to build 1709 with existing ANS as it prevents NIC properties from loading in both ncpa.cpl and device manager. Did not see any mention of that issue in various searches.
Hope this helps.
I updated from 1607 to 1709... big mistake, totally screwed up networking, reverted back, uninstalled and removed everything networking, AV and virtualbox for good measure.
Upgraded again to 1709, and now trying to get Intel I219-LM to do my VLANs again, but it won't, it creates them but they're disabled and won't enable them, it's that old chestnut again. Tried the latest driver download, 22.10 it doesn't help.
"Help me Carl_Wilson, you're my only hope!"
Update: Ok, so I updated the driver, but didn't install/reinstall/update? the Intel Software after the OS update, did that and it takes slightly longer to create a vlan (an indication it's actually doing something now), and I have enabled VLAN virtual nics, strangely the original adaptor one is enabled, I thought that used to be disable, but maybe I'm remembering wrong.
Either way, glad it's back up and working again... 2-3 days lost productivity though.
I was running a nearly 2 year old build of windows 10 to retain my vlan support. Just yesterday I followed the same procedure Matt laid out and it's working perfect for me on 1709 with a I218-V nic. Thanks for the tips.
I'll be sure to check this thread in the future before upgrading to make sure its safe