Fencer128

Hi, Here's a break down of what I've found. Maybe it can help diagnose what's going on? Having integrated both RyanVM and BTS packs into a Win XP Pro SP2 distro and then built a machine with the resultant image, the PC contains the following files: C:\Windows\system32\drivers\hdaudbus.sys [5.10.1.5103] C:\Windows\system32\drivers\hdaudio.sys [5.10.1.5103] C:\Windows\system32\hdaprop.dll [5.10.1.5103] C:\Windows\system32\hdashcut.exe [5.10.1.5103] C:\Windows\system32\hdaudres.dll [5.10.1.5103] C:\Windows\inf\hdaudbus.inf [5.10.00.5010] C:\Windows\inf\hdaudio.inf [5.10.00.5010] C:\Windows\Driver Cache\i386\driver.cab (contains portcls.sys [5.1.2600.2637]) These are the only HDA related files present on the disk. Incidentally, driver.cab is also the only file within C:\Windows\Driver Cache\i386 and i386 is the only object within C:\Windows\Driver Cache. If I the install KB888111 (which will get HDA working) then in addition to the above, I'm left with: C:\Windows\system32\drivers\portcls.sys [5.1.2600.1364] C:\Windows\Driver Cache\portcls.sys [5.1.2600.1364] Would you expect BTS integrations to place portcls.sys in C:\Windows\system32\drivers (and also possibly C:\Windows\Driver Cache) rather than only in driver.cab? EDIT: I made a new install and then extracted portcls.sys from C:\Windows\Driver Cache\i386\driver.cab to C:\Windows\system32\drivers. I then ran "detect hardware changes" through device manager and everything worked fine !!! So, it seems for whatever reason, the portcls.sys is not being copied to C:\Windows\system32\drivers at build time. This is why I believe HDA is still not working correctly. Maybe it's related to the associated .cat file not being present - or maybe that's just a red herring? Do you have any ideas about the above or how to rework the integration (if indeed I'm correct)? Cheers, Andy

Hi, Let me elaborate on Dave's comments. The following files ARE present in i386 after RyanVM has integrated: hdaprop.dl_ hdashcut.ex_ hdaudbus.in_ hdaudbus.sy_ hdaudio.in_ hdaudio.sy_ hdaudres.dl_ They are also present after current BTS files have integrated. portcls.sys is NOT present in i386 after RyanVM has integrated. If the current BTS packs are used it is present AFTER they have also been integrated. Using current BTS files there are duplicate entries, as described previously, in WINNT.SIF and DOSNET.INF. I guess that means, for the time being at least, that unless the path/process is modified, there's no point in having the following statement: %IE% I386\portcls.sys DEL /Q I386\portcls.sys I don't know much about the specifics of how KB888111 works, but I wonder that given the problems I'm having with it, if placing portcls.sys in i386 is "incorrect"? I'll test a build tomorrow that has it in the driver.cab but not i386 (I'll delete the i386 copy) and report what difference it makes (if any). If this doesn't work then I'll try it vice-versa and report. I hope that helps clarify the situation Cheers, Andy

Should be on first post ! He must of accidentally removed it... Cheers, Andy

Hi Bashrat, I'm a little confused. Do you mean that even if identical entries have already been placed into both files, fedit will add another set OR do you mean that if identical entries already exist, a duplicate set will not be created. I always thought it worked as per the former. Both sets of entires in both files are lower case, so distsinguishing in terms of case shouldn't make a difference, if I understand this correctly. Thanks for you input Andy EDIT: Should just say, I fixed the detection of KB888111 issue in RUN_ME.cmd myself, though the realtek drivers *still* failed to install correctly. I don't know whether this is a hotfix or a driver issue, though I suspect it's a poor realtek driver!

Interesting... I do have those files in i386. I wonder why you don't? (or maybe why I do?!) Incidentally, I have that Realtek chip on everyone of my new boxes which is why I'm so keen to resolve this! Cheers, Andy EDIT: Just realised I'm checking after RyanVM and BTS integration is complete. Let me just run RyanVM and get back to you... EDIT2: Files are definately in i386.

Hi Bashrat, Here are the command lines I currently use to remove the duplicate entries . Hopefully you should be able to get the information you require from them: REM Cleaning duplicate entries from DOSNET.INF and TXTSETUP.SIF "%FEDITALL%" -REM -ONCE -F "%RISI386%\DOSNET.INF" -S Files -L "d1,hdaudres.dll" >> "%LOGALL%" "%FEDITALL%" -REM -ONCE -F "%RISI386%\DOSNET.INF" -S Files -L "d1,hdaudio.sys" >> "%LOGALL%" "%FEDITALL%" -REM -ONCE -F "%RISI386%\DOSNET.INF" -S Files -L "d1,hdaudio.inf" >> "%LOGALL%" "%FEDITALL%" -REM -ONCE -F "%RISI386%\DOSNET.INF" -S Files -L "d1,hdaudbus.sys" >> "%LOGALL%" "%FEDITALL%" -REM -ONCE -F "%RISI386%\DOSNET.INF" -S Files -L "d1,hdaudbus.inf" >> "%LOGALL%" "%FEDITALL%" -REM -ONCE -F "%RISI386%\DOSNET.INF" -S Files -L "d1,hdashcut.exe" >> "%LOGALL%" "%FEDITALL%" -REM -ONCE -F "%RISI386%\DOSNET.INF" -S Files -L "d1,hdaprop.dll" >> "%LOGALL%" "%FEDITALL%" -REM -ONCE -F "%RISI386%\TXTSETUP.SIF" -S SourceDisksFiles -L "hdaudres.dll = 100,,,,,,,2,0,0" >> "%LOGALL%" "%FEDITALL%" -REM -ONCE -F "%RISI386%\TXTSETUP.SIF" -S SourceDisksFiles -L "hdaudio.sys = 100,,,,,,,4,0,0" >> "%LOGALL%" "%FEDITALL%" -REM -ONCE -F "%RISI386%\TXTSETUP.SIF" -S SourceDisksFiles -L "hdaudio.inf = 100,,,,,,,20,0,0" >> "%LOGALL%" "%FEDITALL%" -REM -ONCE -F "%RISI386%\TXTSETUP.SIF" -S SourceDisksFiles -L "hdaudbus.sys = 100,,,,,,,4,0,0" >> "%LOGALL%" "%FEDITALL%" -REM -ONCE -F "%RISI386%\TXTSETUP.SIF" -S SourceDisksFiles -L "hdaudbus.inf = 100,,,,,,,20,0,0" >> "%LOGALL%" "%FEDITALL%" -REM -ONCE -F "%RISI386%\TXTSETUP.SIF" -S SourceDisksFiles -L "hdashcut.exe = 100,,,,,,,2,0,0" >> "%LOGALL%" "%FEDITALL%" -REM -ONCE -F "%RISI386%\TXTSETUP.SIF" -S SourceDisksFiles -L "hdaprop.dll = 100,,,,,,,2,0,0" >> "%LOGALL%" Cheers, Andy

Hi, Currently the only outstanding issue I have when integrating RyanVM and BTS packs is that HDA drivers are not correctly applied. This appears to stem from KB888111 as reinstalling the hotfix and then reloading the drivers gets everything working. Given this, I would be very keen to find out more about KB888111 detection issues in RUN_ME.cmd. I'll have a look myself too. EDIT: The solution seems to be one of two options: 1. Change the KB888111 detection from I386\svcpack\hdaudio.sy_ to I386\hdaudio.sy_ 2. Wait for next RyanVM pack and revert to detection through I386\svcpack\KB888111.cat It should also be noted that even when the detection has been configured correctly, duplicate entries still appear in DOSNET.inf and WINNT.sif Cheers, Andy

Hi, I'm not sure what the issue is, but I wrote RISult to deal with risetup.exe file sets, as opposed to riprep images. There may be a problem with RISult, but I suspect if you've built a "master" PC using a RIS image created via RISult (and that works ok for you), and then used riprep on it to create an image - the problem lies with one or more of the following: 1. The changes made by riprep 2. Slightly differing hardware on different machines 3. The known issues in RyanVM and/or BTS base packs Please let me know if you get any further forward with this. Thanks, Andy

I'm sure you'll manage to work it in soon enough. The real question - as you've mentioned above - is how are things going to change with BTS driverpack BASE. It could make things a lot easier, or it could become a much bigger problem in the short term. I personally need to rebuild a RIS image on a monthly basis (I guess you need a quick turnaround too) so I'm hoping it will be a nice, smooth transition to code for. Cheers , Andy

Hi Dave, This looks very good. I'm sure it will progress quickly. There's nothing like a little competition to get speed up development... I'll have to go and re-code in VBasic now to get a GUI and ini file capability! Cheers, Andy

Hi, Glad to hear it works ok for you . I've corrected the sif file problem so if you redownload everything should be fine. Thanks, Andy

Hi Everyone, RISult has been updated to v1.0.4. Please see initial post/included changelog for more details. More importantly, *** INSTRUCTIONS *** now included! Cheers, Andy

Hi Bâshrat, I was wondering if I could suggest some future feature requests for your BASE pack? I wonder if you could at some point make the BASE pack RIS aware? By RIS aware I mean have a variable (much like choosing the method) that could be set to"CD" or "RIS" in BTS_DPs_auto.cmd and then having two slightly different processes that could occur to integrate the driver packs into the Windows source files. Obviously you already have the CD side of the integration well in hand, but from the point of view of RIS there a few suggestions I would like to make (please don't take this as in any way a criticism, these are not major points and I know that you plan to work on this at some point in the future anyway ) 1. Allow for the integration to run without PAUSE or user confirmation events in RUNME.cmd. 2. Allow for the integration to not have to convert file name case (I believe this is unecessary for RIS as the file names are not upper case as in the CD file set, but I could be missing the point). 3. Allow the statements in presetup.cmd to be configured to not search for CD drives and to look to local folders instead. 4. Allow for user configuration of the destination directories for files located in "D" and "OEM" (RogueSpear's RIS guide uses a good alternative structure for this). I realise that some of the above requests would require a lot more work and testing than others , and if I can be of any help I am glad to offer my time. I also know that you may be wanting to move from batch code to a compiled executable in the future, and so I'm making these suggestions known now to give you time to consider them, should you wish to do so. Thank you and please let me know if you have any questions/suggestions of your own (I'm sure you do!) I would also like to make you aware that RogueSpear has more than a few ideas on this, so should you wish to ahead with anything, it would be well worth consulting with him too. Cheers, Andy

Hi Everyone, RISult has been updated to v1.0.3. Please see initial post/included changelog for more details. Cheers, Andy

Hi Dave, I like the idea of populating both fields - as opposed to just the registry key for the local PC. EDIT: [ We currently pre-stage our accounts by selecting an OU from a drop-down list at build time in the RIS menu.] I'm actually talking rubbish here We don't pre-stage the accounts at all! So, doing it from our asset register aseems like a good idea (see below). It's amazing how if you check first-hand, you often find that what people had told you they *thought* was true, was actually completely the opposite! Now, as you suggest (I think!) we could run a script on the information we've recieved from our suppliers to pre-stage all of the accounts at once, and then build the PCs via RIS without creating the accounts. I'll need to look into how this will affect our distribution process - Thanks for the idea though. One other thing to mention is that we've now decided to bar code our asset tags. What I've proposed is to pre-populate a table with the MAC address and OEM serial numbers of the PCs. When the units are unpacked asset labels will be attached and the asset number and OEM serial number will be scanned via bar code reader. This will create an entry in the table for the asset number next to the corresponding OEM serial number (and hence MAC address). At build time the GUIRunOnce section will run a VBS to read the asset tag value from the table (stored in an accessible network share) that is held against it's MAC address, and create the necessary registry entry to populate the "Computer Description" field. This way we can use our sequential asset labels out of sequence if need be as the asset number is only assigned to the PCs serial number/MAC address at the time at which we stick on the label and scan the codes. I hope that makes sense! Cheers again, Andy

Well, it looks as if I might be able to pursue the idea of reading the asset tag from a pre-populated table. Our suppliers send us a list of MAC addresses with every order. We can create a table from this and assign sequential asset tag numbers to it. After build we can then run a VBS file from GUIRunOnce to read the value from the table and populate the computer description. All we then have to do manually is to stick the correct label on. It does depend on us keeping an accurate list someweher, but you can't have everything! Thanks, Andy

Hi Dave, No problem . I know that the value I need doesn't exist in the BIOS because of a couple of reasons: 1. We affix an asset tag sticker to every unit we get in. It consists of a 5 digit number that is sequential and in no way related to any aspect of the PC. This is the number I need to manually enter at build time. 2. We generally use PCs by a UK OEM called "RM (Research Machines)". They supply a lot of units specifically to HE/Schools/etc. and do not deal in the private sector. We chose them because of the good discount through bulk purchase that they offer, the quality of their product and most importantly because they give great next day on-site support for hardware. We've been burned in the past by other companies *terrible* support - specifically Dell. They currently supply us with units based on the Intel 915GUX platform. We do use the MAC address to create the host name automaticallly. This makes it possible for us to pre-stage AD accounts via RIS - and indeed we do this so that OU selection occurs during RIS menu selection. Now, I agree that basing the asset tag on the MAC address makes a lot of sense because it allows for a lot of automation. Unfortunately, the management don't necessarily share this vierw and (currently at least) we're stuck with labels. Your idea about an asset tag - MAC address table is interesting. Our management are always trying to push the idea of an "Asset Register" that lists all PC details (inc. MAC address) against the asset tag we affix. Unfortunately, even though this is a good idea, it never seems to get off of the ground for a few reasons beyond our control (mostly politics). We have migrated to SMS in the last 18 months and are currently making a new effort to compile an accurate list from WMI queries, but I'm not holding my breath. For reference, we have ~ 2000 desktops to manage. So, now I hope it's a little clearer why I (possibly) need to go through the ordeal of passing variables, creating files, etc rather than simply reading values from memory through WMI. If you have any other suggestions please let me know. Cheers, Andy

Thanks Dave. Any ideas you have would be appreciated. I don't know whether you missed where I mentioned that the asset tag in question is a label, and not a BIOS value? As such, it cannot be entered by using WMI to query a system value. It needs to be entered via a custom RIS osc file. From there stems my problem. Thanks, Andy

Hi there sausage eater!? I'll give it a go and let you know. Thanks for your help, Andy ps - If you have any example files to hand, it would be appreciated.

Hi Everyone, I have a small problem that someone may be able to help me with. Where I work we like to set the "Computer Description" field to display the asset tag (a label we affix) of the PC. Currently our build process is RIS/SMS-based and fully automated. The *only* reason we need to log onto a PC before it is deployed to a staff desk is to set the above field. I am able to create a custom osc file for RIS that allows me to create the variable %ASSET%. Unfortunately, I can't then find a way to add that variable as a REG_SZ vlaue to the registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\srvcomment Initially I tried running a REG command through GUIRunOnce, but of course, after the first reboot the %ASSET% variable will be lost. I then decided to write the variable to a .reg file that I could then import via REGEDIT /S. However, I do not know how to achieve this within the sif file. If anyone knows how to go about doing this, or has a better idea I've not thought of, I'd be very grateful if they let me know. Thanks, Andy

Hi, This is a question for the mods. Would it please be possible to move the following topic: http://www.msfn.org/board/index.php?showtopic=57010 From its current location to: Unattended Windows Discussion & Support -> Unattended Windows -> Unattended RIS Installation? The topic relates to a utility (RISult) that works in a similar way to the V2 of RogueSpear's guide. Given the fact that it will be of use to many people because of the ability to automate the integration of BTS and RyanVM driverpacks with RIS, would it be possible to sticky it up by RogueSpear's guide? Initially I posted it in Bashrat's forum, but I've subsequently realised that it would be better served to host it as described above. It should see more traffic there and therefore hopefully get more people using it. Please let me know what you think either way. Thanks, Andy

Hi Dave, Thanks for the information. I have access to the hotfix and cat file, but assumed that the cat file was not required in this instance. I guess this is not the case. I will hold out for the next update to Ryan's pack before pursuing this any further then. Regards, Andy

Hi everyone, I'm currently having an "issue" with: RyanVM 1.3.1 pack BTS driver packs (all) Intel 915GUX M/B (with o/b Realtek HDA) I'm using the latest BTS base pack and still having problems with HDA/KB888111. Having completed the build the PC shows an outstanding "PCI device" in the device manager with "!". Previously I assumed this was to do with the conflict between RyanVM/BTS packs when installing KB888111. I tried to update the driver manually to fix this problem but Windows returned "No suitable driver found". The only way out is to reinstall 888111 and then update the driver. I therefore imagine it is something concerning the 888111 hotfix? If anyone has a similar experience or an explaination/fix I would be very grateful. If any further information is required I will be happy to supply it. Thanks, Andy

Hi everyone, RISult has been updated to v1.0.2. Please see initial post for details. Changelog now also included in downloaded zip file. Have fun , Andy

Hi, I had a quick thought. You're using a Broadcom NIC and the RIS image (well mine anyway) has 2 broadcom sys files within it by default. If you've copied the latest Broadcom drivers to the i386 folder and restarted the binlsvc service then you could possibly be having a problem with the new broadcom inf file associating with the old (and therefore wrong) sys file. I had a similar experience with Intel NICs this week causing a hang at "Setup is starting Windows" and the fix was to remove the default Intel sys files. The files you'd need to remove are: bcm4e5.sys bcm42xx5.sys Note: I don't know if they've now changed, but you used to need to edit Broadcom inf files to get them working under text mode RIS setup. The instructions for editing them can be found here on Broadcom's site under "No. 79": http://www.broadcom.com/drivers/faq_drivers.php Cheers, Andy