[mrbeatnik]

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!

[mrbeatnik]

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.

[Tripredacus]

What packages did you add into your winpe.wim?

[mrbeatnik]

Tripredacus, on Apr 7 2009, 04:52 PM, said:

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!

[mrbeatnik]

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.

[Tripredacus]

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.

[mrbeatnik]

Tripredacus, on Apr 8 2009, 01:56 PM, said:

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

[Tripredacus]

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?

[mrbeatnik]

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.

This post has been edited by mrbeatnik: 21 April 2009 - 07:18 AM

[Tripredacus]

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.

[mrbeatnik]

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!

This post has been edited by mrbeatnik: 21 April 2009 - 08:51 AM

[mrbeatnik]

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!

This post has been edited by mrbeatnik: 22 April 2009 - 08:43 AM

[mrbeatnik]

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!

[capnlars]

mrbeatnik, on Oct 31 2009, 05:47 AM, said:

.......
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

[mrbeatnik]

The script has been posted to the AutoIT forums:
http://www.autoitscr...howtopic=105570