Jump to content

brainstane

Member
  • Posts

    35
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United States

Posts posted by brainstane

  1. All,

    I hope somebody can help me fix a small problem I'm having with certain programs for Windows PE, such as "Salas Password Renew" and "fabs autobackup-pe" which is driving me nuts.

    My problem is this. The programs will launch fine but when I click on the "browse" button to select a destination (or the windows directory) the "browse for folder" window is blank and does not give me a file tree to select the destination. The window pops up as expected but there is nothing to select.

    I know I encountered this problem in Bart-PE aeons ago, but for the life of me cannot remember how I resolved it.

    Can anybody PLEASE help me resolve this, as I would like to migrate to windows PE completely and not being able to run a few of these plugins is making this migration impossible.

    Thank you for your suggestions,

    Dan

  2. Hi and thanks for the input!

    However, I already have a build environment that I am satisfied with so I dont think I will change that part. All I wanna know, if there is something missing in the information stated above, on how to intergrate a new device driver.

    Same here, I understand your point. My suggestion was merely aimed at the idea that you could run thru the manufacturers setup to get the correct mass storage driver entries within the unattend.txt file their process creates and then integrate it into your new build.

  3. I do this to deploy windows occasionally as well..mainly for windows 2000. Only difference being is that I kick off unattended installs from within BartPe and then ghost them from within the same session. I mainly do 2000 as hotfixes aren't really being released as frequently and are quickly picked up with windows update. Also, most drivers are already as new as they're going to get for 2K.

    The only disadvantage of this method (toe me) is the above. The builds become"dated" when new service packs and drivers arrive . No way to update svcpack.inf or slipsteam new fixes\drivers when they arrive without creating a new image. If the builds could somehow be "peeled apart" and new hotfixes\drivers applied it would be THE way of deploying windows...much the way that WIM files work.

  4. The easiest way I've run across to get new model server builds up and running quicky in unattended installs is to do the following:

    1) Boot from the manufacturers supplied deployment kit CD and run through its setup. This typically involves entering some values (such as product key, computer name and such) as well as a cd for your flavor of windows operating system.

    2) Once you are to the point in this setup where you would normally reboot the server and let the build to commence, power the server off.

    3) Boot the server with BartPE and start to look at the goodies the server setup has left you. While the folder structure left on the hard drive is radically different between manufacturers, they all have to play by windows installation rules. This means you'll find a fully configured unattend.txt file of some sort with all the mass storage entries and drivers pre-packed for you. Along with this will come the post configuration software needed to finalize the server deployment. Just roll this part up into your current software installation scheme and you're goood to go.

    4) decipher their build process and implement it into your existing unattended build network. (ris, winnt32.exe /unattend setups...ect.

    I've gotten server builds up and running within a few hours using this method for pretty much all the server hardware I've run across. We switched frome IBM to HP and the transition was pretty seamless.

    It's good to know the fundamentals of mass storage drivers and such but once you have that down, why look a gift horse in the mouth. The majors spend a lot of resources to put together this build process so why try to re-invent their wheel.

  5. That would be great.

    I had to give up. I managed (!) to get the image installed.... that worked flawless. And VERY fast.

    I am now stuck with setting up a 2003 compatibel boot sector. That did not work out. Anyone a tip on that? My boot just went through to CD.

    You could try this plugin for bart (dont know how well it would work in WinPE but it writes a xp/2000/2003 compatible boot sector from a preinstall environment)

    http://www.msfn.org/board/index.php?showtopic=30378 plugin is called fixmbr

  6. you can capture a WIm image of your XP standard image for those machines you need to do and copy the image into the PE 2.0, i just complete the same thing this morning :) it works well

    Is there any way you could write up a small walk through to accomplish this task? I have winpe 2.0 but am unclear on how the imagex process works (if this is indeed what you're using to perform this task)

    I would never ask for step by step but if you could provide a brief overview of the procecure from within PE 2.0 it would be hugely beneficial for us PE 2.0 newbies.

    Thanks so much in advance.

  7. Hi all.

    Hopefully you can help me. I need to convert several ghost images of older PCs into some format that can be run in either Microsoft Virtual Machine 2004 or VMware. I know that you can link virtual machine and VMware to iso CD images. That would be ideal. If there is some way to convert them into actual virtual machines, then even better.

    I've already tried using WinImage. It's great at creating virtual images of existing PCs, but I have images I need to convert. Any ideas? All help would be greatly appreciated.

    Thanks

    Ashley

    There's a plugin specifically created to import ghosted images into a virtual machine. Please see this thread:

    http://www.msfn.org/board/index.php?showtopic=76734

  8. Hi,

    I've done this in the past:

    Kick off an unattended install from within bartPE.

    Once winnt32.exe has completed and all files are copied to the hard drive, dont reboot the machine but rather create a ghost image of the hard drive prior to it restarting from within the same bartPE session.

    This image can then be ghosted onto other machines at a much faster rate than a straight winnt32.exe setup is from bart.

  9. Hi,

    I've stumbled across a really neat tool to take a ghost image of an existing Server\Workstation\Laptop and turn it into a virtual machine. The process is performed using a Bart P2V plugin and is proving extremely handy to me.

    This is a great tool if, for example, you have a bunch of legacy boxes running in your environment that could just as easily be run in a virtual machine, freeing up or tombstoning the old dedicated hardware. You can also take a ghost of your current workstation and import it into a VM, testing changes in a non-invasive way that could otherwise bork your box.

    I am in no way associated with this project nor is any of the work mine, I just thought that I would share this great project as a search did not turn up any evidence of this plugin being previously posted in the forum.

    Here's the link to the main site where the plugins are hosted:

    http://www.rtfm-ed.co.uk/?page_id=174

    Basic overview of the process is this: (there's a complete guide posted on the site with more indepth info)

    Note: The following overview assumes that you have already created a new BartPE .ISO file which contains the plugins that the link above references. Once you have created this .ISO, continue with the following to succesfully deploy it.

    1) Create a new custom virtual machine inside VMware Workstation and select "Windows XP" as the operating system type. This selection works for ghosted images that had been running either Windows 2003 or Windows XP. (I have not ghosted a W2k box yet to test that OS. The plugin does have entries for including Win2K as well as NT4.0 VMware drivers, however)

    2) When you get to the portion of the creation wizard where it asks you for the drive interface, select SCSI rather than IDE

    3) Choose Buslogic as the preferred driver.

    4) Start the newly created virtual machine and boot the BarPE .ISO image that contains the P2V plugin as well as your imaging software (I use ghost as the authors suggest)

    6) From within Bart, launch Ghost (or your imaging software) and import the image of whatever workstation (or server) that you have a "ghost" image of.

    7) Reboot the virtual machine and let it BSOD once. This will assign the drive letter of C:\ to the ghosted partition. (if you check diskpart after you restore a ghost image, you'll notice that it has no drive letter. Trying to do a "sel vol 1" "assign letter=c" typically fails. This is the reason for the reboot)

    8) Boot the VM back into bart from the .ISO file and run the VMware P2V plugin. Follow the instructions in the plugin to inject the correct driver\OS type. Basically you have to select the windows directory and choose to inject the LSIlogic and Buslogic SCSI drivers into the ghosted image. This will let you get past the 07B stop error that occurrs because windows doesn't natively have the VM scsi drivers necessary to boot the ghosted image.

    Using the above process, I've been able to import ghost images of many Dell model workstations, servers and laptops.

    There is also thread covering this plugin over at the VMware site, the thread can be found here:

    http://www.vmware.com/community/thread.jsp...=31448&tstart=0

    Enjoy and drop by that thread to give the author a thumbs up if it proves as helpful to you as it has to me.

    Dan

  10. cacls C:\folder\subfolder /t /e /g "everyone":f

    would give "everyone" full permission to the subfolder.

    Make sure you enclose user groups that contain spaces (i.e domain users) in " " at the end of the command.

    If you want, you can also team this up with the "net share" command and create a share prior to implementing permissions. I use this to share a program installation folder:

    net share Apps=d:\programs\apps /grant:Everyone,full

    followed by the cacls command:

    cacls d:\programs\apps /t /e /g "domain users":f

    Note, the net share command above is 2003 specific. If you do not use the /grant:everyone,full it will default the share to read only. This does not happen in windows XP.

  11. Instead of copying the install files over the network, put your source folders on a USB drive and try to kick off the unattended install from there. You'll need to assign the USB drive a letter (I use Z:) and put the path to the $OEM$ folder in the unattend.txt in the OEMFILESPATH entry.

    This will tell you if it's a networking issue or if there's something wrong with your unattended setup. I've seen broadcom nics "hang" and never really complete the install, but when the same machine is booted and the source files are located on a USB drive, everything works fine and the install proceeds normally.

  12. Do a search on your i386 folder for *.PNF files. Delete them all and then stop/restart the BINL service. Chances are that even tho you updated to the newest pro100 drivers, the .pnf file from the old "bad" pro100 driver still resides in your i386 folder and is causing the problem of the nic not found error. Im assuming your using the latest version of the pro100 driver? Old versions had to have their .inf file edited.

  13. This is more of an unattended windows question rather than a RIS question. You'll get much better responses in that forum for this particular topic. For a thread detailing the use of diskpart and unattended windows installation, you can start by reading the following:

    http://www.msfn.org/board/lofiversion/index.php/t13271.html

    it does a very in depth tutorial on how to implement diskpart into unattended windows installs. Note, you'll have to have a working knowledge of either BartPE or WinPE as the install must be initiated from one of those environments to employ scripted diskpart operations. There is no support in WINNT32.EXE for scripted disk formatting.

  14. I store ghost copies of unattended installs on a network drive and then pxe/cd boot the target machine with bart and load the desired ghost image. If you want to do this, all you need to do is kick off a winnt32.exe network/usb install from bart and grab a ghost image of the hard drive, before you reboot the computer to let the normal windows installation take place.

    When this "pre-install" ghost image is loaded onto another machine and rebooted, a normal unattended windows will install will take place. I have a couple 2k builds that I use this exclusively for as it only takes about 2-3 minutes to copy the setup files to HD using ghost.

  15. Halfwalker,

    I suggest you have a look at the following post to get an idea of how this process works. In the post, the author describes the technique I mentioned to install windows from a network share, but the mechanics for installing from a USB drive are identical. Both are based around the OEMFILESPATH functionality in being able to point to the $OEM$ and I386 source files residing in a location other than on a cd. BartPE (or winPE) is also required.

    http://www.msfn.org/board/lofiversion/index.php/t13271.html

    To actually kick off the windows install from within bart, you only need to call winnt32.exe in the i386 folder with the correct switches. One of my commands to launch the install is as follows:

    z:\flat\XP\I386\WINNT32.EXE /syspart:C: /makelocalsource /unattend:z:\cust\STIBMWKS\unattend.txt

    the $OEM$ folder location is specified in the OEMFILESPATH, as noted in the thread above.

    Hope this helps :)

  16. Do I have to use the OemFilesPath switch in my [unattended] portion of the answer file to point at d:\$OEM$ ?

    You only need to do this when the $OEM$ folder is located someplace else, i.e on a mapped network drive or such. Double check to make sure your folder structure is within the $1 folder and matches the entries in your .sif file. Also, make sure you have the necessary driver files within those folders.

  17. stone_age,

    this can easily be accomplished from within BartPE. The only problem with storing the windows i386 on a second partition is that the path to the $OEM$ folder must be hard coded into the unattend.txt file. This means that you would have to ensure that the partition never lost its drive letter, or the windows installation will fail with an 'unable to find files..ect" error. The needed entry for pointing to the $OEM$ folder in your unattend.txt file is this:

    [unattended]

    OemFilesPath = z:\cust\8148NORD\wininst\$OEM$

    as you can see in the above example, windows setup will search the drive path specified to acquire the $OEM$ folder. I use this technique to install windows from a network share and a USB drive, but it could easily be modified to suit your use in this case.

×
×
  • Create New...