Little WOL issue
-
Hi,
I think I've found a little bug with the WOL implementation/I would like to suggest a little improvement :).
I'm currently testing veyom for a classroom where PCs have two network interfaces. The classroom data are imported from our Microsoft AD. I have configured a script to add all MAC-addresses from our DHCP server to a AD-attribute (extensionData). The AD shows me the data as follows.
If I now try to wake those PCs, only the first MAC address in this attribute gets a magic packet send. All other MAC addresses get ignored:
In addition it seems that the AD stores the different MAC addresses in descending order. Therefore the WOL works only, if the LAN interface has the higher MAC address.Would it be possible to extend Veyon to send magic packets to all MAC addresses stored in AD? If so can I help somewhere?
-
Hi,
I think I've found a little bug with the WOL implementation/I would like to suggest a little improvement :).
I'm currently testing veyom for a classroom where PCs have two network interfaces. The classroom data are imported from our Microsoft AD. I have configured a script to add all MAC-addresses from our DHCP server to a AD-attribute (extensionData). The AD shows me the data as follows.
If I now try to wake those PCs, only the first MAC address in this attribute gets a magic packet send. All other MAC addresses get ignored:
In addition it seems that the AD stores the different MAC addresses in descending order. Therefore the WOL works only, if the LAN interface has the higher MAC address.Would it be possible to extend Veyon to send magic packets to all MAC addresses stored in AD? If so can I help somewhere?
-
No: I'm getting the MAC-Adresses from our DHCP server for the import into the AD. Ad I have only the machine name I cannot distinguish between wired and wireless IPs. Therefore sometimes I have two MAC addresses.
AD doesn’t normally store MAC address info.
You could pull the IP from DHCP and query each machine directly using the Win32_NetworkAdapter class to determine the adapter’s NetConnectionID. Probably best to use a GP startup script though so you obtain the MAC address at power on.
Have the script populate the AD attribute only if the connection ID is Ethernet and not Wi-Fi.
As a test use Notepad to create a .vbs file with the following code:
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_NetworkAdapter")For Each objItem in colItems
If objItem.NetConnectionID <> "" Then
Wscript.Echo "Name: " & objItem.Name
Wscript.Echo "Description: " & objItem.Description
Wscript.Echo "AdapterType: " & objItem.AdapterType
Wscript.Echo "MACAddress: " & objItem.MACAddress
Wscript.Echo "NetConnectionID: " & objItem.NetConnectionID
End If
NextDouble-click to run the .vbs file.
-
AD doesn’t normally store MAC address info.
You could pull the IP from DHCP and query each machine directly using the Win32_NetworkAdapter class to determine the adapter’s NetConnectionID. Probably best to use a GP startup script though so you obtain the MAC address at power on.
Have the script populate the AD attribute only if the connection ID is Ethernet and not Wi-Fi.
As a test use Notepad to create a .vbs file with the following code:
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_NetworkAdapter")For Each objItem in colItems
If objItem.NetConnectionID <> "" Then
Wscript.Echo "Name: " & objItem.Name
Wscript.Echo "Description: " & objItem.Description
Wscript.Echo "AdapterType: " & objItem.AdapterType
Wscript.Echo "MACAddress: " & objItem.MACAddress
Wscript.Echo "NetConnectionID: " & objItem.NetConnectionID
End If
NextDouble-click to run the .vbs file.
Hi,
at first: thank you for sharing your ideas.
I've run the script but the there is no markable difference between wired, wireless or e.g. Blutooth or VM-Networks:e.g.:
Name: Intel(R) Ethernet Connection (2) I219-LM
Description: Intel(R) Ethernet Connection (2) I219-LM
AdapterType: Ethernet 802.3
MACAddress: D8:9E:F3:...
NetConnectionID: EthernetName: Realtek PCIe GbE Family Controller
Description: Realtek PCIe GbE Family Controller
AdapterType: Ethernet 802.3
MACAddress: 00:13:3B:...
NetConnectionID: Ethernet 2Name: Realtek PCIe GbE Family Controller
Description: Realtek PCIe GbE Family Controller
AdapterType:
MACAddress:
NetConnectionID: Ethernet 3Name: Intel(R) Wireless-AC 9260 160MHz
Description: Intel(R) Wireless-AC 9260 160MHz
AdapterType: Ethernet 802.3
MACAddress: B4:6B:FC:...
NetConnectionID: WLANName: PANGP Virtual Ethernet Adapter #2
Description: PANGP Virtual Ethernet Adapter
AdapterType: Ethernet 802.3
MACAddress: 02:50:41:...
NetConnectionID: Ethernet 4Name: Bluetooth Device (Personal Area Network)
Description: Bluetooth Device (Personal Area Network)
AdapterType: Ethernet 802.3
MACAddress: B4:6B:FC:...
NetConnectionID: Bluetooth-NetzwerkverbindungI tried by myself using this script (this is powershell):
$leases = Get-DhcpServerv4Lease -ScopeId 192.168.100.0;
Foreach ($lease in $leases)
{
Get-AdObject -LdapFilter ("(dNSHostName="+($lease.HostName)+")") | Set-ADObject -add @{"extensionData"=($lease.ClientID)}
}I run this script every night on our Domain-Controller which is also our DHCP server. For PCs which have/had more than one interface on our DHCP-Server I get the issue described above.
-
Hi,
at first: thank you for sharing your ideas.
I've run the script but the there is no markable difference between wired, wireless or e.g. Blutooth or VM-Networks:e.g.:
Name: Intel(R) Ethernet Connection (2) I219-LM
Description: Intel(R) Ethernet Connection (2) I219-LM
AdapterType: Ethernet 802.3
MACAddress: D8:9E:F3:...
NetConnectionID: EthernetName: Realtek PCIe GbE Family Controller
Description: Realtek PCIe GbE Family Controller
AdapterType: Ethernet 802.3
MACAddress: 00:13:3B:...
NetConnectionID: Ethernet 2Name: Realtek PCIe GbE Family Controller
Description: Realtek PCIe GbE Family Controller
AdapterType:
MACAddress:
NetConnectionID: Ethernet 3Name: Intel(R) Wireless-AC 9260 160MHz
Description: Intel(R) Wireless-AC 9260 160MHz
AdapterType: Ethernet 802.3
MACAddress: B4:6B:FC:...
NetConnectionID: WLANName: PANGP Virtual Ethernet Adapter #2
Description: PANGP Virtual Ethernet Adapter
AdapterType: Ethernet 802.3
MACAddress: 02:50:41:...
NetConnectionID: Ethernet 4Name: Bluetooth Device (Personal Area Network)
Description: Bluetooth Device (Personal Area Network)
AdapterType: Ethernet 802.3
MACAddress: B4:6B:FC:...
NetConnectionID: Bluetooth-NetzwerkverbindungI tried by myself using this script (this is powershell):
$leases = Get-DhcpServerv4Lease -ScopeId 192.168.100.0;
Foreach ($lease in $leases)
{
Get-AdObject -LdapFilter ("(dNSHostName="+($lease.HostName)+")") | Set-ADObject -add @{"extensionData"=($lease.ClientID)}
}I run this script every night on our Domain-Controller which is also our DHCP server. For PCs which have/had more than one interface on our DHCP-Server I get the issue described above.
If I remember correctly VMs will likely not show Wi-Fi.
The machine you referenced seems to have two wired and one wireless network interfaces.
If I understand correctly you wish to have the AD attribute ‘extensionData’ populated with the MAC address of the wired connection only. This information is being pulled from DHCP but the problem is more than one MAC address is being retrieved and for WoL purposes you would prefer receiving only the MAC address for the wired interface.
As a workaround you suggested the developer accommodate your situation by modifying Veyon to broadcast WoL packets for all MAC addresses stored in LDAP/AD.
My suggestion is to not use DHCP but instead a GP startup script that stores the MAC address of each computer interface having a NetConnectionID of ‘Ethernet’ into the ‘extensionData’ attribute of the machine account. This way you get the single MAC address you require for Wake-on-LAN.
If you’re using a multi-homed setup across networks or VLANs then things get more complicated.
-
If I remember correctly VMs will likely not show Wi-Fi.
The machine you referenced seems to have two wired and one wireless network interfaces.
If I understand correctly you wish to have the AD attribute ‘extensionData’ populated with the MAC address of the wired connection only. This information is being pulled from DHCP but the problem is more than one MAC address is being retrieved and for WoL purposes you would prefer receiving only the MAC address for the wired interface.
As a workaround you suggested the developer accommodate your situation by modifying Veyon to broadcast WoL packets for all MAC addresses stored in LDAP/AD.
My suggestion is to not use DHCP but instead a GP startup script that stores the MAC address of each computer interface having a NetConnectionID of ‘Ethernet’ into the ‘extensionData’ attribute of the machine account. This way you get the single MAC address you require for Wake-on-LAN.
If you’re using a multi-homed setup across networks or VLANs then things get more complicated.
If I remember correctly VMs will likely not show Wi-F
Unfortunately this is not correct for at least VirtualBox interfaces.
As a workaround you suggested the developer accommodate your situation by modifying Veyon to broadcast WoL packets for all MAC addresses stored in LDAP/AD.
My suggestion is to not use DHCP but instead a GP startup script that stores the MAC address of each computer interface having a NetConnectionID of ‘Ethernet’ into the ‘extensionData’ attribute of the machine account. This way you get the single MAC address you require for Wake-on-LAN.
I had this ides, as I was not sure if this is an easy-to-implement feature or if this requires more work.
I usually try to avoid using startup scripts as more and more scripts slow down the system-startup and I try to have the systems as fast as I can. Therefore I had the idea of asking our DHCP server.
Another scenario I came across is that some docking stations we are currently using have a different mac to the inbuild lan-port of our laptops. In this scenario I need to find a way to differenciate between the dock and the internal lan-port and additionally have to determine for which connection I require WOL-functionality more.I use a multi-homed environment but that's a thing the login-script must deal with.
Thank you for your support.
-
If I remember correctly VMs will likely not show Wi-F
Unfortunately this is not correct for at least VirtualBox interfaces.
As a workaround you suggested the developer accommodate your situation by modifying Veyon to broadcast WoL packets for all MAC addresses stored in LDAP/AD.
My suggestion is to not use DHCP but instead a GP startup script that stores the MAC address of each computer interface having a NetConnectionID of ‘Ethernet’ into the ‘extensionData’ attribute of the machine account. This way you get the single MAC address you require for Wake-on-LAN.
I had this ides, as I was not sure if this is an easy-to-implement feature or if this requires more work.
I usually try to avoid using startup scripts as more and more scripts slow down the system-startup and I try to have the systems as fast as I can. Therefore I had the idea of asking our DHCP server.
Another scenario I came across is that some docking stations we are currently using have a different mac to the inbuild lan-port of our laptops. In this scenario I need to find a way to differenciate between the dock and the internal lan-port and additionally have to determine for which connection I require WOL-functionality more.I use a multi-homed environment but that's a thing the login-script must deal with.
Thank you for your support.
I believe VMWare by default uses a NetConnectionID different from ‘WiFi’, it depends on how the VM is networked. For that matter the connection ID could be set manually as is sometimes done for the MAC address. For scripting purposes you would want to find the connection name being used or set a name of your own.
Newer port extenders (USB-C) often provide network support and will have their own MAC address. Vendors are providing BIOS updates that allow overriding the dock MAC address with a system specific MAC address. As long as the PCs and docks are from the same manufacturer you stand a good chance of providing a single MAC address to the network irrespective of the extender being connected.
I assume you make use of Group Policy processing so extracting the preferred MAC address does not need to be implemented as a startup script. This could be done by a GP scheduled task or an immediate task at the set refresh interval. This could also be accomplished by “tapping” an existing scheduled task running a common script from a shared network folder.
-
I believe VMWare by default uses a NetConnectionID different from ‘WiFi’, it depends on how the VM is networked. For that matter the connection ID could be set manually as is sometimes done for the MAC address. For scripting purposes you would want to find the connection name being used or set a name of your own.
Newer port extenders (USB-C) often provide network support and will have their own MAC address. Vendors are providing BIOS updates that allow overriding the dock MAC address with a system specific MAC address. As long as the PCs and docks are from the same manufacturer you stand a good chance of providing a single MAC address to the network irrespective of the extender being connected.
I assume you make use of Group Policy processing so extracting the preferred MAC address does not need to be implemented as a startup script. This could be done by a GP scheduled task or an immediate task at the set refresh interval. This could also be accomplished by “tapping” an existing scheduled task running a common script from a shared network folder.