Jump to content

Query DHCP from command line


mrbeatnik

Recommended Posts

Hi all.

I'm having trouble querying DHCP server from Windows PE.

Specifically I am trying to query the hostname we have stored in option 12 of the reservation in DHCP.

I can query it on XP using netsh dhcp server if I copy the dhcpmon.dll file from Server 2003.

I just add helper dhcpmon.dll and I can then run netsh dhcp server commands.

I think it also works with Windows 7 / Vista if I use the Server 2008 dhcpmon.dll in the same way.

I just can't get it to work from Windows PE.

For some reason, I can't add the helper.

I'm using both Win 7 and Server 2008 R2 boot.wim and the 2008 R2 dhcpmon.dll in my tests.

I suspect some other components are missing to be able to add the helper - would anyone have an idea what they could be?

Also I have tried using a script that uses dhcpsapi.dll to do the query.

Again, this works fine on XP and Win 7 etc, but not on PE.

It complains, first, of DSAUTH.dll not being present... I added this in but it couldn't initialise the dll. I couldn't regsvr32 it either.

I feel there may be a common component missing for either solution to work.

SO... Does anyone either have any ideas of how to resolve one of the above issues, or another way to query option 12 DHCP from PE?

Again, using Server 2008 R2 and Windows 7 boot.wim, so that's likely to be PE 2.1/3.0, but I haven't checked the versions. Away from work right now, but if you need some more info will supply it as soon as.

Thanks!

Link to comment
Share on other sites


Ok,

So I can get my result (querying option 12) by running PSEXEC from PE and invoking the netsh dhcp server on another machine (in my test Server 2008 R2 with dhcpmon.dll)... however, PSEXEC is slow to create the service remotely, and I'm unsure what would happen if 10 machines attempt to run PSEXEC on one server before multicast begins...

Would still prefer netsh running from Win PE correctly, so I know it's early days from my OP, but if anyone has any suggestions...

Thanks.

Link to comment
Share on other sites

What packages did you add into your winpe.wim?

None yet!

I should really add them all in and work backwards perhaps.

Just using the basic boot.wim that would initiate the multicast - just breaking out with shift-F10 and running netsh commands from prompt. Trying to add in helper dll from prompt. I have used a winpe.win from WAIK too which is pretty stripped of course.

So I'll try adding all components in and see if that gets me anywhere.

In the mean time any thoughts as to what components I should put in? Ideally I want to keep the wim as lean as possible to make a fast boot.

Cheers!

Link to comment
Share on other sites

Added in all packages from WinPE_OCs dir.

Here is an output of packages now in my wim:

Deployment Image Servicing and Management tool
Version: 6.1.7000.0

Image Version: 6.1.7000.0

Packages listing:

Package Identity : Microsoft-Windows-WinPE-LanguagePack-Package~31bf3856ad364e35~x86~en-US~6.1.7000.0
State : Install Pending
Release Type : Language Pack
Install Time :

Package Identity : Microsoft-Windows-WinPE-Package~31bf3856ad364e35~x86~~6.1.7000.0
State : Install Pending
Release Type : Foundation
Install Time :

Package Identity : WinPE-HTA-Package~31bf3856ad364e35~x86~~6.1.7000.0
State : Install Pending
Release Type : Feature Pack
Install Time :

Package Identity : WinPE-LegacySetup-Package~31bf3856ad364e35~x86~~6.1.7000.0
State : Install Pending
Release Type : Feature Pack
Install Time :

Package Identity : WinPE-MDAC-Package~31bf3856ad364e35~x86~~6.1.7000.0
State : Install Pending
Release Type : Feature Pack
Install Time :

Package Identity : WinPE-Scripting-Package~31bf3856ad364e35~x86~en-US~6.1.7000.0
State : Install Pending
Release Type : Language Pack
Install Time :

Package Identity : WinPE-Scripting-Package~31bf3856ad364e35~x86~~6.1.7000.0
State : Install Pending
Release Type : Feature Pack
Install Time :

Package Identity : WinPE-Setup-Client-Package~31bf3856ad364e35~x86~~6.1.7000.0
State : Install Pending
Release Type : Feature Pack
Install Time :

Package Identity : WinPE-Setup-Package~31bf3856ad364e35~x86~~6.1.7000.0
State : Install Pending
Release Type : Feature Pack
Install Time :

Package Identity : WinPE-Setup-Server-Package~31bf3856ad364e35~x86~~6.1.7000.0
State : Install Pending
Release Type : Feature Pack
Install Time :

Package Identity : WinPE-SRT-Package~31bf3856ad364e35~x86~en-US~6.1.7000.0
State : Install Pending
Release Type : Language Pack
Install Time :

Package Identity : WinPE-SRT-Package~31bf3856ad364e35~x86~~6.1.7000.0
State : Install Pending
Release Type : Feature Pack
Install Time :

Package Identity : WinPE-WDS-Tools-Package~31bf3856ad364e35~x86~en-US~6.1.7000.0
State : Install Pending
Release Type : Language Pack
Install Time :

Package Identity : WinPE-WDS-Tools-Package~31bf3856ad364e35~x86~~6.1.7000.0
State : Install Pending
Release Type : Feature Pack
Install Time :

Package Identity : WinPE-WMI-Package~31bf3856ad364e35~x86~en-US~6.1.7000.0
State : Install Pending
Release Type : Language Pack
Install Time :

Package Identity : WinPE-WMI-Package~31bf3856ad364e35~x86~~6.1.7000.0
State : Install Pending
Release Type : Feature Pack
Install Time :

The operation completed successfully.

Still cannot add in dhcpmon.dll through netsh. :angry:

Link to comment
Share on other sites

OK a couple of things to try. Obviously there is a peice missing, and it is likely a dependency.

1. Make sure you are using the files to match your PE type. If using a 32bit PE, use the netsh and dhcpmon.dll from a 32bit Vista machine.

2. On a Vista PC, use Procmon and run your command. Make note of any additional files it is reading, including registry entries.

3. Run depends on netsh and dhcpmon.dll. You may be missing a dependency.

I have done very little with getting the PE to do things that aren't documented, but this is always a starting point for me.

Link to comment
Share on other sites

  • 2 weeks later...
OK a couple of things to try. Obviously there is a peice missing, and it is likely a dependency.

1. Make sure you are using the files to match your PE type. If using a 32bit PE, use the netsh and dhcpmon.dll from a 32bit Vista machine.

2. On a Vista PC, use Procmon and run your command. Make note of any additional files it is reading, including registry entries.

3. Run depends on netsh and dhcpmon.dll. You may be missing a dependency.

I have done very little with getting the PE to do things that aren't documented, but this is always a starting point for me.

Thanks for the info, and sorry for the delay in getting back...

1) I used a 32-bit DHCPMON.dll (From Server 2008) and tried in Vista and 7 32-bit - all ok. Would still not work in PE. Only registry reference is the dhcpmon.dll being created (this does happen in PE).

2) Used Procman. Access as follows:

c:\windows\system32\dhcpsapi.dll
c:\windows\system32\samcli.dll
c:\windows\system32\dsauth.dll

Copied these file to system32 on PE and still no joy. Could not regsvr32 any of these files.

3) Any other suggestions on how to check the dependencies?

I am using a basic winpe.wim, breaking out to the shell and copying the files over.

I'm really tearing my hair out with this one. I really can't see what is missing.

Output of netsh show helper on PE shows:

Helper GUID							 DLL Filename  Command
-------------------------------------- ------------ -------
{6DC31EC5-3583-4901-9E28-37C28113656A} DHCPCMONITOR.DLL dhcpclient
{0705ECA1-7AAC-11D2-89DC-006008B0E5B9} IFMON.DLL interface
{1C151866-F35B-4780-8CD2-E1924E9F03E1} NETIOHLP.DLL 6to4
{725588AC-7A11-4220-A121-C92C915E8B73} NETIOHLP.DLL ipv4
{500F32FD-7064-476B-8FD6-2171EA46428F} NETIOHLP.DLL ipv6
{90E1CBE1-01D9-4174-BB4D-EB97F3F6150D} NETIOHLP.DLL 6to4
{90E1CBE1-01D9-4174-BB4D-EB97F3F6150D} NETIOHLP.DLL isatap
{1C151866-F35B-4780-8CD2-E1924E9F03E1} NETIOHLP.DLL isatap
{1C151866-F35B-4780-8CD2-E1924E9F03E1} NETIOHLP.DLL portproxy
{78197B47-2BEF-49CA-ACEB-D8816371BAA8} NETIOHLP.DLL tcp
{1C151866-F35B-4780-8CD2-E1924E9F03E1} NETIOHLP.DLL teredo
{931852E2-597D-40B9-B927-55FFC81A6104} NETIOHLP.DLL netio
{0705ECA2-7AAC-11D2-89DC-006008B0E5B9} RASMONTR.DLL ras
{42E3CC21-098C-11D3-8C4D-00104BCA495B} RASMONTR.DLL aaaa
{16DD6BF2-C782-456B-9FB8-2E12449B80EE} RASMONTR.DLL demanddial
{90FE6CFC-B6A2-463B-AA12-25E615EC3C66} RASMONTR.DLL diagnostics
{13D12A78-D0FB-11D2-9B76-00104BCA495B} RASMONTR.DLL ip
{36B3EF76-94C1-460F-BD6F-DF0178D90EAC} RASMONTR.DLL ipv6
{B2C0EEF4-CCE5-4F55-934E-ABF60F3DCF56} WSHELPER.DLL winsock

Windows 7 (where the dhcpmon.dll works) shows:

Helper GUID							 DLL Filename  Command
-------------------------------------- ------------ -------
{02BC1F81-D927-4EC5-8CBC-8DD65E3E38E8} AUTHFWCFG.DLL advfirewall
{FB10CBCA-5430-46CE-B732-079B4E23BE24} AUTHFWCFG.DLL consec
{35342B49-83B4-4FCC-A90D-278533D5BEA2} AUTHFWCFG.DLL firewall
{4BD827F7-1E83-462D-B893-F33A80C5DE1D} AUTHFWCFG.DLL mainmode
{4D0FEFCB-8C3E-4CDE-B39B-325933727297} AUTHFWCFG.DLL monitor
{A31CB05A-1213-4F4E-B420-0EE908B896CB} PEERDISTSH.DLL branchcache
{00770721-44EA-11D5-93BA-00B0D022DD1F} HNETMON.DLL bridge
{0F7412F0-80FC-11D2-BE57-00C04FC3357A} C:\DHCPMON.DLL dhcp
{6DC31EC5-3583-4901-9E28-37C28113656A} DHCPCMONITOR.DLL dhcpclient
{8A6D23B3-0AF2-4101-BC6E-8114B325FE17} NETIOHLP.DLL dnsclient
{8B3A0D7F-1F30-4402-B753-C4B2C7607C97} FWCFG.DLL firewall
{44F3288B-DBFF-4B31-A86E-633F50D706B3} NSHHTTP.DLL http
{0705ECA1-7AAC-11D2-89DC-006008B0E5B9} IFMON.DLL interface
{1C151866-F35B-4780-8CD2-E1924E9F03E1} NETIOHLP.DLL 6to4
{1C151866-F35B-4780-8CD2-E1924E9F03E1} NETIOHLP.DLL connectivityplatform
{97C192DB-A774-43E6-BE78-1FABD795EEAB} NETIOHLP.DLL httpstunnel
{725588AC-7A11-4220-A121-C92C915E8B73} NETIOHLP.DLL ipv4
{500F32FD-7064-476B-8FD6-2171EA46428F} NETIOHLP.DLL ipv6
{90E1CBE1-01D9-4174-BB4D-EB97F3F6150D} NETIOHLP.DLL 6to4
{90E1CBE1-01D9-4174-BB4D-EB97F3F6150D} NETIOHLP.DLL isatap
{1C151866-F35B-4780-8CD2-E1924E9F03E1} NETIOHLP.DLL isatap
{1C151866-F35B-4780-8CD2-E1924E9F03E1} NETIOHLP.DLL portproxy
{78197B47-2BEF-49CA-ACEB-D8816371BAA8} NETIOHLP.DLL tcp
{1C151866-F35B-4780-8CD2-E1924E9F03E1} NETIOHLP.DLL teredo
{F7E0BC27-BA6E-4145-A123-012F1922F3F1} NSHIPSEC.DLL ipsec
{F7E0BC29-BA6E-4145-A123-012F1922F3F1} NSHIPSEC.DLL dynamic
{F7E0BC28-BA6E-4145-A123-012F1922F3F1} NSHIPSEC.DLL static
{1D8240C7-48B9-47CC-9E40-4F7A0A390E71} DOT3CFG.DLL lan
{B341E8BA-13AA-4E08-8CF1-A6F2D8B0C229} NETIOHLP.DLL namespace
{00B399EA-447F-4B19-8393-F9D71D7760F9} NAPMONTR.DLL nap
{3F8A1180-FF5D-4B5B-934C-D08DFFBC9CBC} NAPMONTR.DLL client
{B123BAAA-79E9-49FD-AB2C-E87C56CE4CFF} NAPMONTR.DLL hra
{931852E2-597D-40B9-B927-55FFC81A6104} NETIOHLP.DLL netio
{B7BE4347-E851-4EEC-BC65-B0C0E87B86E3} P2PNETSH.DLL p2p
{9E0D63D7-4644-476B-9DAC-D62F96E08376} P2PNETSH.DLL collab
{6ED05238-F6A3-F801-967A-5CAD6F6CAC56} P2PNETSH.DLL contact
{E35A9D1F-61E8-4CF5-A46C-0F715A9303B8} P2PNETSH.DLL group
{9AA625FC-7E31-4679-B5B5-DFC67A3510AB} P2PNETSH.DLL database
{FBFC037E-D455-4B8D-80A5-B379002DBCAD} P2PNETSH.DLL idmgr
{9E0D63D6-4644-476B-9DAC-D64F96E01376} P2PNETSH.DLL pnrp
{1DD4935A-E587-4D16-AE27-14E40385AB12} P2PNETSH.DLL cloud
{AD1D76C9-434B-48E0-9D2C-31FA93D9635A} P2PNETSH.DLL diagnostics
{6EC05238-F6A3-4801-967A-5C9D6F6CAC50} P2PNETSH.DLL peer
{0705ECA2-7AAC-11D2-89DC-006008B0E5B9} RASMONTR.DLL ras
{42E3CC21-098C-11D3-8C4D-00104BCA495B} RASMONTR.DLL aaaa
{90FE6CFC-B6A2-463B-AA12-25E615EC3C66} RASMONTR.DLL diagnostics
{13D12A78-D0FB-11D2-9B76-00104BCA495B} RASMONTR.DLL ip
{36B3EF76-94C1-460F-BD6F-DF0178D90EAC} RASMONTR.DLL ipv6
{592852F7-5F6F-470B-9097-C5D33B612975} RPCNSH.DLL rpc
{C07E293F-9531-4426-8E5C-D7EBBA50F693} RPCNSH.DLL filter
{D3E9D893-852F-4E22-B05D-99293065773D} NETTRACE.DLL trace
{C100BECD-D33A-4A4B-BF23-BBEF4663D017} WCNNETSH.DLL wcn
{3BB6DA1D-AC0C-4972-AC05-B22F49DEA9B6} NSHWFP.DLL wfp
{0BFDC146-56A3-4311-A7D5-7D9953F8326E} WHHELPER.DLL winhttp
{B2C0EEF4-CCE5-4F55-934E-ABF60F3DCF56} WSHELPER.DLL winsock
{D424E730-1DB7-4287-8C9B-0774F5AD0576} WLANCFG.DLL wlan
{B572D5F3-E15B-4501-84F2-6626F762AFB1} WWANCFG.DLL wwan

Link to comment
Share on other sites

I want to step back a minute now, presuming this isn't related to your other thread. I want to understand what you are trying to accomplish.

Tell me if I am wrong.

When you boot your MININT, it uses a reserved IP address. After loading the PE, you want the MININT to query for its specific hostname that the server has stored for that IP address. But why does it need this information?

Link to comment
Share on other sites

We store the HOSTNAME information on OPTION 12 of DHCP.

This is queried and inserted into sysprep.inf under the COMPUTERNAME section.

This ensures the computer is named correctly when setup runs without having to pre-register an object in AD.

This is how we currently work:

Using Ghost (16 bit) to deliver image.

We have a 16 bit bootp app that queries OPTION 12 and modifies sysprep.inf with no problems. This app wont work in PE.

We need to change to 32-bit (ready for Vista/7 updates) and don't want to purchase on Ghost32 when we have WDS under our select acgreement :).

We could have a script that does add object to AD (and names it) when item is crated in DHCP (all server side without client interaction), but I am not a fan of this.

I would rather not add pre-registration to AD as it may be there for some time before a technician actually images a PC:

Would rather do a domain join when computer is active... but want to keep the automated naming process.

So, summary:

Get computer name and add to sysprep.inf (unnattend.xml) automatically without having to pre-register object in AD.

Edited by mrbeatnik
Link to comment
Share on other sites

I did some testing. I concur that the MININT cannot see the option 12 information. However, it can see the Option 15 information. I set a reservation on my server and added Option 15. After getting an IP, the string I typed in appeared under the Connection Specific DNS Suffix in ipconfig. I also tested to make sure that the MININT was capable of accessing the domain resources via hostname and this also worked.

I also noticed that when you make the reservation, the name you type in for it changes once the computer boots to PXE. It changes to its MININT name that the PE generates as the hostname/computer name. If you rename the reservation name to COMPUTERNAME.DOMAIN and reboot the machine to PXE it may do the above instead.

I'm not sure which it was because I unwittingly did both options without testing them independently.

Link to comment
Share on other sites

Thanks for assisting Tripredacus...

Very kind to give some time up on this.

Unfortunately we already use Option 15 for domain name suffix (i.e., no hostname in there, just the domain suffix pure - mydomain.com)

DHCP does indeed take the name from the client - i.e. boot to PE and a minint-xxxxxxx name appears in DHCP, which is expected. This happens in full Windows also (if client hostname is different to that specified in DHCP then client will overwrite DHCP reserved name).

Option 15 is a nice idea, just a shame we need it and use it already for something else...

Thanks.

PS:

As a side note, Linux has no problem at all querying option 12.

I really don't know why Windows has such a hard time!

Edited by mrbeatnik
Link to comment
Share on other sites

Ok...

Interesting this.

I managed to get dhcpmon.dll loaded OK!

I used the Win Server 2003 version, not the 2008 version - previously I had been looking at compatible versions (i.e. 2008 for Vista SP 1 PE, 2008 R2 for Win 7 PE). I never looked at 2003 version on there, and hadn't played with XP PE.

I had to also copy dhcpsapi.dll and dsauth.dll into the system32 directory.

However, there is still an issue....!

Going to post the issue in another post as it may benefit others who have a similar question.

Thanks!

Edited by mrbeatnik
Link to comment
Share on other sites

  • 6 months later...

Sorry to bump this thread since it's quite a few months old...

Just thought I would update anyone who is trying to do something similar (probably not many)!

Unfortunately I could not get NETSH or any other inbuilt windows command to do the job, due to domain permission restrictions and lack of "runas" or "secondary logon" service in PE.

However, I managed to create an AutoIT script to retreive OPTION12 from DHCP.

Option 12 (and other options) are sent when a BOOTP request is sent to the router on the subnet - and doesn't require any permissions at all. We have both DHCP and BOOTP enabled on our DHCP servers, so BOOTP being enabled is probably a requirement.

This means we have a centralised area where we can manage computer hostnames - in DHCP:

We add the hostname to OPTION 12.

This is collected using my AutoIT script before imaging where the technician confirms it is correct.

This is put into a text file until after imaging where a script will modify sysprep.inf (XP) with the correct name.

Anyway, thanks for the input in this thread. It took some time to get there, but I have a solution!

Link to comment
Share on other sites

  • 2 weeks later...
.......

However, I managed to create an AutoIT script to retreive OPTION12 from DHCP.

Option 12 (and other options) are sent when a BOOTP request is sent to the router on the subnet - and doesn't require any permissions at all. We have both DHCP and BOOTP enabled on our DHCP servers, so BOOTP being enabled is probably a requirement.

........

Could you please post your AutoIt script to retreive option 12?

Thanks

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...