mrbeatnik

Perfect. I was just missing the DLLs. Of course I would just assume the MDAC package would supply them... Thanks for reference. The INF file was really handy for the registration of the files. Thanks again!

Hi folks. I am trying to query AD from Windows PE 3 (based on Windows 7). My script works in Win 7 and XP, but I am aware there are issues with PE so need to modify the script. I am aware that HTA cannot query with ADO, so I am just running a stand alone script. I have added the Winpe-MDAC component to winpe (I also have HTA,WMI,WSH components as well). I have also disabled the firewall, just in case... Here is what I have (names changed to protect the innocent). username = "myname" DOMAIN = "myDCNAME/DC=subdomain,DC=domain,DC=com" Set ADConn = CreateObject("ADODB.Connection") ADConn.Provider = "ADSDSOObject" ADConn.Properties("User ID") = "mydomain\myadreadableuser" ADConn.Properties("Password") = "mypass" AdConn.Properties("Encrypt Password") = true ADConn.Open "ADs Provider" query = "<LDAP://" & DOMAIN & ">;(&(objectclass=user)(sAMAccountName=" & username & "));distinguishedName;subtree" Set ADrs = ADConn.Execute(cstr(query)) IF NOT ADrs.EOF Then WScript.Echo ADrs("distinguishedName") End If So I get the error 80040E37 on the execution of the code. Any suggestions why this wont work? How can I check that I have all needed components? [EDIT REASON : Added Solved to title!]

The script has been posted to the AutoIT forums: http://www.autoitscript.com/forum/index.php?showtopic=105570

Hi again all. I'm finding it quite difficult to get a list of command line programs to use within a custom WinPE (3.0) boot.wim. In particular, I can't seem to find info on how to query a WDS server to see specific information. For example, I would like to: 1 - Query the server to find out what Multicast names are available for me. 2 - (Display the multicast info to the user for them to choose) 3 - Start a multicast session of their choice. I would expect 1 and 3 would have to be command line driven (through vbs or whatever method I choose). If number 1 got the details to a text file, I could display them to the user in a HTA for number 2. Does anyone know if number 1 is possible? Nnumber 3 is using the following code, but I would like to be able to fill in the namespace and sourcefile dynamically from PE: wdsmcast /progress /verbose /Transfer-file /server:myserver /namespace:WDS:"my group/mywim.wim/1" /username:domain/user /sourcefile:"images\my group\mywim.wim" /destinationfile:c:\install.wim I only have a WDS server and not a transport server. Thanks ===EDIT=== Modified post to make quesiton a little clearer - hopefully!

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!

Don't you love when you answer your own quesitons? Of course, if I had not have posted here, I wouldn't have gone on the route to find the answer probably! OK, so my deployment from BDD has an unattend.txt. In here I have: [Unattended] ComputerType = "Advanced Configuration and Power Interface (ACPI) PC", Retail http://support.microsoft.com/kb/155197 So quick look at Txtsetup.sif in my deployment: [Computer] acpiapic_mp = "ACPI Multiprocessor PC",files.none acpiapic_up = "ACPI Uniprocessor PC",files.none acpipic_up = "Advanced Configuration and Power Interface (ACPI) PC",files.none syspro_mp = "Compaq SystemPro Multiprocessor or 100% Compatible",files.none mps_up = "MPS Uniprocessor PC",files.none mps_mp = "MPS Multiprocessor PC",files.none e_isa_up = "Standard PC",files.none 486c_up = "Standard PC with C-Step i486",files.none So the line means it is forcing the install as acpipic_up - uniprocessor (this type of PC allows changing the hal pre-minisetup after sysprep, but will force UP hence WDS sees the sysprep capture as UP - this was great in our older environment where we would do just that - point to UP or MP in minisetup). I am about to comment the line out of unattend.txt which should force the XP setup to detect the HAL, which should see it as MP. Hopefully that will resolve the issue - I will post back later to confirm (this will take a little time). Hoe my ramblings help someone. +++++++++++++++++++++++++++ Yep, this fixed the issue of course. Cheers for reading!

Hmmn, OK... Only one processor shows in taskmanager for my XP install. Both cores are showing in device manager. The COMPUTER info in Device Manager does not say Multiprocessor (it doesn't say Uniprocessor either, just ACPI (but hardware IDs show UP info). So, BDD installed this machine as UP instead of MP. This has become a different problem all of a sudden! (Time for topic change?) Anyone know why my unattended BDD deploy of SP3 is installing UP on a MP then? I've picked BDD deployment setup from someone who has left the team, but never seen this problem before (we didn't use WDS before). Thanks

Hi all, I think this might be the right area... I can't see a specific WDS area. I have a problem where a captured image is seen as UP, even though it is done on a MP machine. I install Windows XP SP3 on a PC. The PC is a Core2Duo. I sysprep the machine. I boot up to WDS PXE and choose the Capture Image WIM. I successfully capture the Sysprepped image and add it to a group on the WDS server. When I go to the WDS server console to check the properties for that image, it says ACPIPIC_UP. Ok... maybe something is disabled in my capture PC when I did sysprep and it thinks its a UP PC. (Note this shouldn't be the case as Core Multiplexing in the BIOS is enabled) So, using the same capture PC, I boot to WDS PXE to the BOOT.WIM so that I can image the PC with the captured WIM I just took. I cannot see the captured WIM. The BOOT image is obviously seeing the PC as a MP machine.... so why did sysprep decide that it's a UP machine? Any advice? Thanks

Using a different packet sniffer (IPTools), I changed the mode to NDIS and managed to see packets RAW mode doesn't seem to see them... Is this a limitation in PE, or are you aware of a way around this? Is there any technical information on this at all?

Hi again. Using wireshark on the router, I can see that packets are being sent to my WinPE machine that is connected to the network with a valid IP address through DHCP. It communicates with WDS fine. However, the packets are not being received by certain software I am using. I tried running PaketMon as this is lite and thought PE could handle it, but it shows no packets coming in at all on the machine itself. I have stopped the firewall that PE runs, just in case it was interfering. I am using the Windows 7 boot.wim and install.wim to get to PE interface, and shift-F10ing out to try these methods. Does anyone have any ideas as to why apps are not picking up packets? Of course, the apps work in XP fine, with the same packets. Thanks

Hmmmn, although Microsoft says that the scope overriding is not how it should work. The reservation level options should actually override the server scope options, which isn't happening. http://technet.microsoft.com/en-us/library...705(WS.10).aspx Well, in any case I am ok just now, but still strange why that is happening. This is definately not a PE topic anymore

Hey Tri, Fixed it! Problem was a little obscure I guess. We set Server scope options (which point to our existing PXE), which in turn applies the options to all reservations on all subnets on that particular DHCP server. I tried to change the scope options 66/67 on an individual reservation - which appears to work from the MMC, but really the server scope options are still overriding this, even though the reservation does not show the server option any more. d'oh! Thanks anyway!

No joy there... Had tried various combinations of the filename, just in case The \ at the beginning of the ROM name doesn't solve this issue.

Hey all. Ok, so a PE forum but a WDS connection question. Tri, I understand if you move the thread to a more appropriate area! Wasn't sure where best to post. So I have WDS setup on our live server now in native mode (Win 2008 R2 x64). I have modified option 66/67 on the DHCP server for the reservation of one machine I am testing at the moment. (66 = IP address of WDS, 67 = boot\x86\wdsnbp.com) WDS is setup to accept all clients at the moment (no approval required). I have a boot.wim ready. I boot up the PC and PXE boot and.... it doesn't boot. PXE-E53: No boot filename received. Now normally we have a RIS server (still up and running) configured through the scope for options 66/67. This works fine of course.... so I'm unsure where the problem is here. Client is on subnet 103. DHCP is on subnet 222. WDS is on subnet 250. Any help is of course appreciated!!

Hi again! Should be an easy one... I have a boot.wim from WDS. Normally this would load from PXE and then allow you to authenticate and choose a image to multicast. I tried using WAIK to create an ISO of this, so that I would hopefully get the same option from DVD, but when I load the ISO it starts the Windows 7 installation! How can I take the boot.wim and get it to work the same way on an ISO? I would like it to connect to the WDS server. I tried: copype.cmd x86 c:\PE\winpe_x86 Replaced all instances of winpe.wim and boot.wim in this new directory with my wim from the WDS server (I renamed it appropriately). oscdimg -n -bc:\PE\winpe_x86\etfsboot.com c:\PE\winpe_x86\ISO c:\PE\winpe_x86\winpe_x86.iso Thanks.

Thanks for the rpely (as usual!!), but it didn't work Did: net use y: \\192.168.0.1\c$ /user:domain\administrator It maps the drive OK, but still tries to launch the application (local) in the context of the local user regardless. If I move the app to the new share, then it strill tries to launch in the local context, but on the remote drive... So either way the command tries to run as a local user, and the function gets an access denied because it needs to be run as a domain user...

OK, added in runas.exe from Windows 7 (into PE 3.0) and the error doesn't appear. However, the command doesn't seem to process correctly - nothing seems to happen. > runas > runas /user:administrator notepad Enter the password for administrator:

Hmmmn, I don't know what, but I must have got the command slightly wrong. This works: > sc create "SecLogon" binPath= "x:\WINDOWS\System32\svchost.exe -k netsvcs" Seems to start and be running. However, the next issue is RunAs.exe. Again I copied from XP, but RunAs gives an error: The procedure entry point NetpGetDomainName could not be located in the dynamic link library NETAPI32.dll Thanks!

I need to run an application that will access the network - and this needs to be run as a user on the domain. Using PE 2.1 / 3.0 (Vista SP1 / Win 7) Naturally the minint admin does not have domain access. I can't run runas because the secondary logon doesn't exist. PSEXEC wont run locally presumabley for the same reason. I'm unsure if I can get the secondary logon service installed and started in PE, but this sounds like the way to go. Would anyone have any guidelines on how to do this? What files to copy across and what commands to initiate? I have tried copying seclogon.dll and sc.exe and using the command: > sc create seclogon binPath= "x:\WINDOWS\System32\svchost.exe -k netsvcs" start= auto DisplayName= "Seconday Logon"Unfortunately this just shows the help text from sc, with all the possible parameters - it doesn't seem to process the command at all (no error or success message). I also tried exporting the seclogon registry entry for the service and importing directly, but no joy (note I exported from Win XP - need to try with Win 7, but I'm not holding my breath there...) Also, trying to start the service with the imported hive doesn't work... > sc start seclogon [SC] StartService FAILED 1083: The executable program that this service is configured to run in does not implement the service. > net start seclogon System error 1083 has occurred. The executable program that this service is configured to run in does not implement the service. Otherwise there may be another way forward? Any suggestions anyone? Thanks!

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!

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!

Currently we only have pxe as optional boot (i.e. hit F12). When booting to RIS you are asked to auth, and can then start an image immediately witout any special work. We have over 4000 machines. Labs are imaged at a time by technicians when required... it's extra work to add exceptions as and when they need it. Instead a technician can just go PXE, authenticate and the rest of the work goes automatically. WDS will let me authenticate a bit further through the boot.wim (when I am about to select image) and that would have to do. More than likely I can script it (AutoIT etc) to begin with to ask for user/pass and authenticate to the WDS share - this should hopefully hold when I need to select an image. Again, it's no big deal really - just wanted to make sure I wasn't missing something before I go and write something that should already be working... Thanks for all the info Tripredacus!

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.

Working in an educational environment, we don't want students to be able to PXE and start an image. We have various scripts after mini setup to install certain items over the network depending on lab (machine name). Authentication is required to stop students from doing this to a computer and perhaps interupting classes etc. Authentication at the very beginning of a sequence makes sense... we can lock down the WIMs which will ask for authentication later on through the sequence... it would be much better (IMO) if auth was asked for at the beginning... It's not a huge problem, just a little untidy IMO. Wasn't sure if there is something I was missing when comparing to RIS, which does do what I want. Shame they simply removed it the initial auth.

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