Fencer128

Hi, That's some good work with those scripts. However, there would be a problem with the scenario mentioned by Drakhan as he would need to run them before selecting the image he wants to deploy through RIS. This would mean executing the script during the RIS menu process, which I do not believe is possible. Cheers, Andy

Hi, That is a limitation of flat images (i.e. RISETUP) as opposed to binary (i.e. RIPREP, Ghost, etc). You would need to use a seperate method to install applications post-build. I use Microsoft SMS, though I appreciate this isn't available to everyone. Alternatively you can use packaged applications (e.g. something like those offered by RyanVM or similar) along with [GUIRunOnce] sttaements, or even a utility like WPI (have a look at it's forum on MSFN). RISult does not directly allow for the inclusion of applications in the build - but it can be used with a method such as those above to achieve the same result (as I do with SMS). Using a flat image also gives you the opportunity to decouple the applications from the build, which in my experience is the best method for scalability and ease of maintenance. Cheers, Andy

Hi, Given your criteria, I'm not sure how you'd go about it. You can't do much in the way of hardware detection from within the RIS menus - and judging by the variety of hardware you have to maintain you'll need: - many different drivers - much updating of said drivers I can only imagine that if you do come up with a solution it may be so complex as to negate it's usefulness (in that once again you may end up being quicker to just have a seperate image for each hardware type). Good luck, Andy

Hi Pete, Thanks - looks fine. Last 2 things to check: 1. The devices you want to install are definately supported by the DriverPacks (check Bashrat's forums). If you are unsure then please list the make/model of the hardware that does not install. 2. You are restarting the BINSVC after copying the completed RISult image to your RIS server? Cheers, Andy

Hi, I strongly suggest that you should check out Bashrat's DriverPacks: http://www.msfn.org/board/index.php?showforum=111 I administrate a *single* RISETUP image for approximately 2000 machines of varying age, make and model (Dell, Viglen, RM, Compaq, Sony, Toshiba, etc). I use RISult, RyanVM's update packs and Bashrat's DriverPacks to make a single universal RISETUP image. Good luck, Andy

Hi Pete, Again that looks fine... I'm assuming that that's the structure before you run RISult. If you have the time could you post something similar showing the structure in the RIS_Install folder after running RISult? Could you confirm whether only some non-native drivers are getting installed, or no non-native drivers at all? Thanks, Andy

Hi, I'm not sure what you mean exactly? Could you please elaborate? The i386 folder is "created" automatically when you execute a RIPREP or RISETUP solution on a RIS server. Cheers, Andy

Hi, I'm afraid this isn't much help - but I believe your problem is caused by an application you've included with your RIPREP image. I've only seen such issues with RIPREP (and not RISETUP) images. I don't have a specific fix expcept to advise you that in future you should consider one of the following solutions: 1. Use RISETUP images. 2. Use Ghost (or Ghost like, i.e. Acronis) binary images, but *not* RIPREP. Sorry this is not of much help to your current predicament. I would advise that you set up a test domain so that in future you can diagnose these problems before they go live on your production domain. Good luck, Andy

Hi Bashrat, What are your thoughts on having a policy of linking new driver files for download via their "official" links only. I'm sometimes wary of new drivers that are posted via a third-party website - especially when they simultaneously haven't appeared on the manufacturer's site. I do realise that you have a policy of not incorporating beta releases, with good reason. If it were a "policy" to provide only direct, manufacturer/OEM links then most issues with whether the drivers are "official", non-beta, etc. could be put to rest (providing people followed the rules ). Also, this way any beta drivers that may be posted could have a seperate <beta> argument in the topic description field, so as to clearly show that the are not ready for inclusion in the DriverPacks. More so, it would cut down on the time required for those of us who manually update our own DriverPacks for test/completeness between official releases to trawl the internet checking the status of such drivers. Apologies if the above is already so, but I couldn't find information posted on this exact topic. Thoughts? Andy

Hi, If you only have one system to play with, then I vote: This is by far the easiest way to check the build. Straight-forward and no potential headaches. Good luck, Andy

Hi, The "D" folder is created by Bashrat's scripts to house some DriverPack files. It is not a direct creation of RISult and is necessary in order for successful install of drivers (so needs to be there). Your posted files seem fine. You are correct in assuming that commenting out/deleting the [GUIRunOnce] "Command11 =" line in the SIF file will achieve the effect outlined in my previous posts. Can I check that you are copying all of the required DriverPacks to "DriverPacks_Store" and leaving them in their compressed .7z state? Can I also check that you have copied the "DriverPacks_BASE.exe" file to "Common\BTS"? Are you using the latest release of "RISult" and "DriverPack_BASE" (I notice that you are using an old version of Ryan's Update Pack)? RISult will *not* work correctly with the newest DriverPack_BASE unless you are using the current version. Without the above files the drivers will not install. If you have done the above then I'm currently at a loss as to why it's not working as it should. Cheers, Andy

Hi, Yes and no. The instructions are correct, however sometimes not all hardware plays ball and your system will not build properly or you might not get all drivers (or even wrong drivers) installed. Admittedly this is a less common scenario than not, but just because you (think) you followed the instructions correctly it is no absolute guarantee it will build fine. It just depends on how important the system you want to rebuild is. Can you afford the time to manually rebuild if necessary? Cheers, Andy

Hi, Could you have a look at your completed build and let me know whether the files mentioned in the error messages, along with the "C:\D" folder exist? If not then the messages can be safely ignored. The reason they appear if because a run once log on script is executing, making sure that these files have been deleted. Occasionally Bashrat's scripts, which should handle this, fail to clean those files properly and so I added a further script to make sure they definately get removed. If all your systems are having these messages and the files are indeed deleted, then feel free to delete the last "command =" line under the "[GUIRunOnce]" section of your SIF file, before running the RIS build, as this will stop the script executing. With regard to my earlier question and your previous error, yes, could you please state exactly how you built your RIS image (nlite, any manual file edits, etc.) as you should definately get your drivers installed. Cheers, Andy

Hi, Could you please post the *exact* procedure you went through to produce your build? It seems to me that something else has occured other than a vanilla XP SP2 disk just running through RISult. The error you specify is something that no-one else has yet produced and I wonder what is different with your build. Cheers, Andy

Hi, In the "Images" folder on your RIS server you will need to create a new folder if you haven't already done so (e.g. "My_Build"). Inside this folder you should place the i386 and $OEM$ folders from the "RIS_Install" folder on the machine hosting RISult. I suggest that you have a read on Microsoft's site concerning RIS and RISETUP if you're unfamiliar with them, as there's a fair amount to learn outside of RISult. Good luck, Andy

Hi, I like prestaging too - but we've found it too time consuming for the number of machines we're administrating, not to mention the problems associated with building, distributing and tracking so many prestaged machines when a new order arrives (100 machines or there abouts). As such, my boss has decided pre-staging is not the way to go for us and so we resort to the method above. In an ideal world though, I think prestaging is the best way. Cheers, Andy

Hi, That's an odd one. Could you post your SIF file (minus licence keys, etc) for us to have a look at? Cheers, Andy

Hi, Nice script. We run a utility before any rebuild that removes any exisiting AD account and/or SMS record (if you use SMS). We then run RIS and use a highly customised menu system to navigate through our complex schema to the end OU we want the system built in. This is the most resilient way we have found to deal with the "existing account" issue. Cheers, Andy

Hi, I've not noticed this behaviour - are you sure it's down to RISult? Could you post some more details (how you make your build, your SIF file, etc). Please make sure to remove any licence keys, names, etc. Cheers, Andy

Hi, Now updated to V5 Cheers, Andy

Hi, Check out the Unattended RIS forum on this site. Also, see my signature for a link to my RISult tool. Alternatively, check out AutoRIS by RogueSpear. These should give you what you need. Good luck, Andy

Hi, Hmmm - seems I read your post too fast! I assumed you were getting errors concerning mass storage drivers (ql2100.sys I think relates to a fibre channel adapter) because you were using the MassStorage pack. If that's not the case then I suggest you post the steps you went through to make the CD. You may have made some mistake that's easily noticable. Cheers, Andy

@quotee Have a look at Bashrat's signature Andy

Hi, I've had similar problems. Can you please confirm that it works when the password is unencrypted? Regards, Andy PS - I would clear the password from your post if indeed it is the real one