nwarren

I've been using nLite for a couple of years now, and thought I'd mention how I've adapted my use of it to make building multiple nLite'd CDs rather more simple... The basic process uses a batch file to do the following steps - I'll use XP32 as my example, but this works for XP64 and all versions of W2K3: Create a new 'source' XP folder from a set of master folders (updates/refreshes folder if it already exists) Copy additional files for $OEM$ folder to source folder Copy specific build settings files from build settings folder to nlite\presets folder Run nLite Copy updated settings files back to build settings folder (saves them for next time!) Build ISO With my process I've found that I can build an increasingly customised version of XP always being able to revert back to the last version if something goes wrong. A few more details: Naming scheme - this is incredibly important as it makes it much more simple. For example, to create a build of Windows XP Pro, SP2, volume license key for my work PC I create and run a batch file called work.wxpp.sp2.vlk.b1.cmd. For Windows Server 2003, I might use work.w2k3.r2ee.vlk.b1.cmd (R2 Entrerprise Edition). I use b1, b2 etc to denote my 'production builds' and z1, z2 etc to denote my 'in development builds'. The contents of this WXPP batch file are as follows: ------ @echo off bin\nlite.cmd %~n0 wxpp.sp2.vlk $OEM$.work ------ nlite.cmd is the main batch file that does all the hardwork. %~n0 returns the file name (no extension) of the running batch file. wxpp.sp2.vlk is the folder name of the Windows source. $OEM$.work is the folder name of any extra files I want to copy down to the build CD. The contents of the nlite.cmd file are: ------ @echo off set source=\u9.windows.org.disks\%2 set target=\u99.tmp\%1 rem set robocopy variables... set rcopy=bin\robocopy.exe set rcparams=/zb /r:3 /w:3 rem goto makecd rem copy o/s source files to tmp build folder... %rcopy% %source% %target% %rcparams% /mir /XD docs dotnetfx support valueadd rem copy $OEM$ files to tmp build folder... if "%3"=="" goto nLiteSettings %rcopy% %3 %target%\$OEM$ %rcparams% /s :nLiteSettings rem copy build settings to master nLite settings folder if exist "nlite\presets\last session (*.ini" del "nlite\presets\last session (*.ini" copy "settings\%1%.nlite.ini" "nlite\nlite.ini" copy "settings\%1%.last session.ini" "nlite\presets\last session.ini" copy "settings\%1%.last session_u.ini" "nlite\presets\last session_u.ini" rem run nLite start/wait nlite\nlite.exe rem copy modified build settings from master nLite settings folder copy "nlite\nlite.ini" "settings\%1%.nlite.ini" copy "nlite\presets\last session.ini" "settings\%1%.last session.ini" copy "nlite\presets\last session_u.ini" "settings\%1%.last session_u.ini" rem copy version info to root of build CD... %rcopy% .\ %target% /if "build specs.doc" %rcparams% %rcopy% .\ %target%\$OEM$\$1 /if "build specs.doc" %rcparams% echo Build Version is %1 > %target%\#%1.txt echo Build Version is %1 > %target%\$OEM$\$1\#%1.txt :makecd rem make ISO... bin\cdimage.exe -bbin\boot.bin -o -m -h -n -l %target% \u0.final.disk.iso\%1.iso ------ It's probably worth discussing my folder structure at this stage. I've designed this so that all the temporary files and final ISOs are separated from the main 'data' files which makes backing up a little more straightforward! \u0.final.disk.iso (holds the final ISO build files) \u2.nlite (holds the build batch files and various sub-folders) -- home.wxph.sp2.oem.b1.cmd (home build for XP Home, SP2, OEM edition) -- work.wxpp.sp2.vlk.b1.cmd (work build for XP Pro, SP2, volume license edition) -- work.wxpp.sp2.vlk.z1.cmd (test build for XP Pro, SP2, volume license edition) -- work.wxpp.sp2.vlk.z2.cmd (test build for XP Pro, SP2, volume license edition) -- work.wxpp.sp2.vlk.z3.cmd (test build for XP Pro, SP2, volume license edition) -- work.wxpp.sp2.vlk.z4.cmd (test build for XP Pro, SP2, volume license edition) --\$OEM$.nick ($OEM$ folder for my personal builds) ----\$1 ------\common ('common' folder that is copied to the root of %SystemDrive% - holds various files I use on every PC) --\$OEM$.work ($OEM$ folder for my work builds) --\bin (folder that contains files relevant to this semi-automated build process) ---- boot.bin (floppy boot image file needed to create bootable CD) ---- cdimage.exe (executable for creating bootable CD) ---- nlite.cmd (batch file listed above) ---- robocopy.exe (used to do the various bits of file copying) --\nlite (extracted files for nLite application) ----nlite.ini (application settings file - this is updated/replaced by my process) ----\Lang (standard nLite sub-folder) ----\Presets (standard nLite sub-folder - this is where most of the settings are stored ) ------Last Session.ini (first build settings file - this is updated/replaced by my process) ------Last Session_u.ini (second build settings file - this is updated/replaced by my process) --\settings (folder that contains all my 'master' settings files) ----work.wxpp.sp2.vlk.b1.Last Session.ini ----work.wxpp.sp2.vlk.b1.Last Session_u.ini ----work.wxpp.sp2.vlk.b1.nlite.ini ----home.wxph.sp2.vlk.b1.Last Session.ini ----home.wxph.sp2.vlk.b1.Last Session_u.ini ----home.wxph.sp2.vlk.b1.nlite.ini ----work.wxpp.sp2.vlk.z1.Last Session.ini ----work.wxpp.sp2.vlk.z1.Last Session_u.ini ----work.wxpp.sp2.vlk.z1.nlite.ini \u9.drivers (folder containing drivers to be integrated using nLite) --\XP32 (drivers for 32bit version of XP) --\XP64 (drivers for 64bit version of XP) \u9.addonpacks (any addonpacks to be integrated during nLite build) \u9.updatepacks (any RyanVM updatepacks to be integrated during nLite build) \u9.windows.org.disks (folder containing extracted ISOs of original Windows installations) --\wxph.sp2.oem --\wxph.sp2.retail --\wxpp.sp2.vlk --\wxpp64.sp2.vlk --\w2k3.r2ee.vlk --\w2k3.r2se.vlk \u9.tmp (folder for containing all temoporary files created as part of the build process) So as you can see, for data back up purposes, the only folder that 'needs' to be backed up is the \u2.nlite folder So what actually happens...section by section through the batch process: create a variable called 'source' pointing to the correct Windows version folder in the \u9.windows.org.disks folder - in this case it would be \u9.windows.org.disks\wxpp.sp2.vlk create a variable called 'target' pointing to a temp 'build' folder - in this case it would be \u9.tmp\work.wxpp.sp2.vlk.b1 set up the robocopy variables including standard parameters Copy the Windows installation files from source to target - using '/mir' in Robocopy creates an image, so that if the target folder already exists, Robocopy returns it to being an exact mirror image of the source folder - when constantly rebuilding a particular build number, this can save several minutes over copying the entire Windows folder afresh. Copy the the $OEM$ files to the target folder Remove all old nLite settings files from the Presets folder - this is optional but just keeps it tidy! Copy the specific nLite settings files for the build to the Presets folder (if they exist - if it's a new build number, this does nothing) Run nLite, holding this batch file open until it completes After nLite has finished customising the target folder, copy the settings files back to the master store, naming them according to the full build title Copy some build version info to the root of the build CD - I have a build specs doc that lists detailed info about each of my builds Build the ISO - using cdimage.exe I cna build the ISO with the right build name in the u0.final.disk.iso folder. nLite can build the ISO as well, but then the batch file would have to find the file, move and rename it. So the end result of all of this, is that if I want to create a new build all I do is: Create a new build batch file - eg home.wxph.sp2.retail.b1.cmd Edit this file to point to the correct source version (ie wxph.sp2.retail) and include any $OEM$ files I want Run the new batch file - it creates all the necessary folders and runs nLite Skip through the nLite options making any necessary changes Click on the nLite Build button Burn the resultant ISO to CD (after testing in VMWare Workstation!!) If I want to speed up the nLite configuration process, I can copy some existing settings files in to the Presets folder, or create a separately named copy in my master 'Settings' folder Things I still have to do: Update the nLite.cmd so that it can extract the Windows version from the batch file name passed as parameter 1 Update the nLite.cmd so that I can include the $OEM$ folder name in the batch file name passed as parameter 1 Update the nLite.cmd so that it builds point versions of the resultant ISO - eg work.wxpp.sp2.vlk.b1.v1.iso, work.wxpp.sp2.vlk.b1.v2.iso - that way I can keep all the build versions until I know I can get rid of them Buy a bigger hard disk I hope this is helpful - it certainly works for me. Also, I'm not a developer, so it may be there are much better ways to do some of this - please let me down nicely if I'm being a plank Thanks, Nick

Thanks Kel - I'd already seen the specific WPI CABs that you've created - I was hoping it might be possible for WPI to support all the existing CABs that lots of other people have created, without needing to re-write them all? Nick

I've tried checking to see if this already exists, and can't see it...how about adding support for cab file addons as integrated by RVM Integrator - it would be really useful to post-install some of these? The Cab files have quite a lot of info in them, including exe name, description, version and www URL which could all be picked out natively by WPI and added in to the appropriate WPI installation item fields? Thanks, Nick

This summarises the SWPATH changes better than my code can http://www.msfn.org/board/lofiversion/index.php/t50910.html

All environment variables is also useful, but the thread I recommended above uses the extra bits of code in generate.js to create a variable with the root folder path for the WPI implementation being run. If you run your installations from the "install" folder under the WPI path, then the commandlines simply use %SWPATH%\install\application.name.etc. SWPATH could be made available by creating an environment variable when running WPI thorugh a batch file, then your new environment variable code could retrieve this, but I'd argue that the root folder of the WPI.hta executable is a variable that is valuable to be exposed by WPI itself, and it's only such a few lines of code. That's a rather long winded way of saying I'd like my cake and eat it please - can we have both internal exposure of SWPATH and exposure of all the environment variables!!! Thanks, Nick

Not had a whole lot of feedback on this - anyone got anything to say? Or is it not a good idea? Thanks, Nick

This modification to the generate.js file might help you in the right direction: http://www.msfn.org/board/lofiversion/index.php/t50910.html (search for SWPATH if that link doesn't work) The only problem would be that you need to re-edit the generate.js files each time a new release is made. Unless kelsenellenelvian would be kind enough to add it it to the permanent code? PLEASE!!!!

Thanks - fixed it. I wasn't stripping off the '[' & ']' on the ORDR column import, so it was sorting in text order not number order.

Just uploaded v0.3 to my intial post. This includes masses of changes, including adding in all the fields that are currently listed in config.js. I've also written a routine for formatting the header content of the spreadsheet, so you should be able to change the column order without it permanently affecting the header layout (it updates next time you press any buttons or change to another sheet. I've also added several sort options. My next major plan is to see if I can add in a form to the bottom of the header which displays all the variables in a selected row in a view that's more easy to edit...this is rapidly becoming soemhting that would be better written in VB or something, but it's proving useful and could be considered a prototype for a proper application!! Looking forward to your evaluation comments Nick

I'd be tempted to try adding in the fully qualified path to the MST file in the command line?

Can you give me an example of what you have in the Excel cell and how it should be listed in config.js? I'll have a look at it - I've done nothing with processing the CMD lines, but was looking at automatically replacing '\' with '\\' -perhaps I also need to do something with quotes?

Thanks - initially I was doing this for myself, so only included the fields that I'm currently using (which doesn't include the reg before/after fields and several others). As you think it's a worthwhile approach, I'll update it with the extra fields - my main concern was that it was a stupid idea and a waste of my time, but if it's not, then I'll play a little more My other concern about adding all the fields is that it will make the Excel table quite wide and more difficult to view - I kinda think there must be a better approach than Excel, but I'm not imaginative enough to see what it is...in the meantime I'll work with Excel A couple of other enhancements I'm thinking of doing: Add a backup option so when the current config is exported, the original config is renamed instead of just over-written Modify the code, so people can change the order of the columns to suit their needs without it screwing up the code Adding in drop downs on some of the cells using ranges defined on the Ranges worksheet I'm happy for any other suggestions to come as well? Thanks, Nick

Forgive me asking, but have you changed the path to your config.js in cell B3? To test this app, I'd suggest copying your config.js to another folder and testing on the copy - just set the value of B3 to the folder name where the copy is. Config.js is the hardcoded filename at present in case you've changed it? Also, you do need to enable macros in Excel - yeah? Let me know how you get on - in the meantime, I'll add some error checking to the import routine, then at least you might get a message!! Thanks, Nick

All I've been using WPI for a few months now and love it. But.....I've been frustrated when managing the config.js file. I might be missing something here, but either you edit it in WPI or through a text editor? With the former, there's no option to cut&paste etc, with the latter there's no drop downs or simple record entry. Plus, with either option it's difficult to see all your apps in one simple screen and identify (and modify) the install order etc. So I've been playing and came up with the following proof of concept Excel application. Please review this entirely at your own risk and note the following: It doesn't yet implement all the config.js variables, just the ones I use currently It makes some assumptions about whether WPI will work without some of the variables being defined (eg picture height width)!! I've done minimal error checking or data validation in the code There's a few bits hard-coded so don't mess around with the column or row positions unless you want to amend the code!! I have a few more ideas yet to implement, but will take on board any suggestions I'm really looking to you (the professional WPI user community!) to give me some direction on this - is this a good idea, or is there something better already available. I'm sure there's a better implementation than Excel, but it kinda works okay. I can develop this further, but I'm no Excel expert - if someone else is stimulated by this idea then feel free to take it further. Hoping this gives something back...(and I hope I've managed to upload the file!!!) Thanks, Nick PLEASE test this on a copy of your config.js!!! UPDATE 9/Jan - v0.3a fixed import issue for ORDR column UPDATE 8/Jan - v0.3 release with lots of changes WPI_ConfigMgr.7z

I'd also be interested in the unattended version of the slipstream file - I've tried redirecting input from a text file, but it just fails miserably - a text file with a single carriage return seems to mean that none of the key inputs need responses...I don't really have enough experience with this to even begin debugging it. Bashrat - is this something you'd consider implementing prior to the C## version? It would be useful to know... If not, I'll probably look at writing a script to parse the run_me.cmd batch file and remove the pauses and set my default values. Can you tell me if the format of the run_me.cmd file changes much? Thanks for your hard work on this - it's really useful...just trying to eke that last few percent of efficiency!!! Nick