Jump to content

Foose

Member
  • Posts

    10
  • Joined

  • Last visited

  • Donations

    $0.00 

Everything posted by Foose

  1. I am running into a mild issue with my base image. It basically deals with the fact I cannot get rid of the ACPI standard hal. My test/build machine is an R40 (P4 2.4ghz with 512megs of ram). The bios is up a revision from June '06. My new deploy machines will be core duo or core 2 duo machines that will be slowly switched out as leases expire. I still need to support my older (Pentium 4 or Pentium M) systems with my image, so I assumed I would try to do the ACPI Uniprocessor HAL during the base image install and have it update if multiprocessor is there via the sysprep.ini. Anyway, I have tried multiple times during the CD install and once either ACPI Uniprocessor or ACPI Multiprocessor is selected as the HAL i want to use, it seems to load the initial drivers and hang before the EULA (this is in the text based section of XP install). If i go back and select the generic ACPI HAL it proceeds fine. I am using an XP SP2 VLK CD. Now on my core duo machines, the ACPI HAL is functioning just fine, but I am sure it is not the most optimal build for it. Any ideas?
  2. So it seems like I either have to re-wrap the app into a form which winbom will like better, or fire it off inside a cmd file in either winbom or sysprep. Not the cleanest way, but do-able. Anyone have any ideas about the Plug and Play? This will be a real showstopper if sysprep is not seeing or using the -pnp trigger.
  3. I am working on my universal image for the company and I was pre-installing the apps then sealing it up with Sysprep to drop down on a new machine with PNP finding hardware and such. Recent changes in hardware (DUO based machines) has given me the opportunity to revisit the process and fix a few issues. I'm now attempting to pre-load software using winbom and the factory section of Sysprep. This is all working as intended except 2 (so far) apps that are giving me fits. Both of which are MSI files, but are not traditional MSIs. They are more of a Installshield with MSI variety. The problem is that winbom doesn't like them. Lets look at one while I show you my problem. So my winbom.ini section kinda looks like this: [OEMRUNONCE] "Install Novell Client", "Novell.Stage", APP "Install Zenworks", "Zenworks.Stage", APP "Install IPrint", "Iprint.Stage", APP "Install McAfee", "McAfee.Stage", APP "Scan New Drivers", "Driver.Stage", APP [Zenworks.Stage] InstallType = Standard SourcePath = C:\Apps\zenagnt SetupFile = zfdagent.msi CmdLine = /quiet /norestart Now the problem is, as you can see, that the msi has it's own triggers. There are only 3 ways I can run this MSI, either as an MSI, APP, or INF. If i run the stage as an MSI, it returns an MSI error of 1639 or something along those lines. After looking up that error, it tells me that the triggers are not correct, which leads me to believe it's attempting to run this with msiexec. If i run it as an APP, it errors out with a error code of 3, which makes no sense. I can however just type zfdagent.msi /quiet /norestart at the command prompt and works fine. If i place this install at the GUIRUNONCE section of Sysprep, it runs and installs fine. This is one of 2 apps like this and with similar triggers. How do i get it to run in the winbom section where it will fire off and wait until moving on to the next section? Place it inside a bat file? A cmd file? Wrap it up as a exe (like using zip to create a self extracting exe) and see if i can trigger it that way? My second issue is I never had problems getting pnp to enumerate when using just sysprep. In the new process, I am attempting to make it more modular where I dump down a driver directory and do a scan on that directory to place the driver sets into the registry entry using spdrvscn from vernalex.com. That way I can alter the drivers needed without having to re-do the base image. I am invoking the scan in the OEMRunOnce section like so: [OEMRUNONCE] "Scan New Drivers", "Driver.Stage", APP [Driver.Stage] InstallType = Standard SourcePath = c:\sysprep\ SetupFile = spdrvscn.exe CmdLine = /p c:\drivers /e inf /d c:\windows\inf /a /s /q Now this works and does place the entries into the registry, but OEMRUNONCE happens after winbom already did the PNP enumeration. I try to set sysprep to re-do the PNP with triggers in the Factory section like so: [Factory] DoDeviceIDScanOnError = Yes FactoryComputerName = * Logfile = C:\Winbom.log LogLevel = 2 Reseal = Reboot ResealMode = Mini ReasealFlags = -pnp WinbomType = Factory Yet, as I was testing the winbom section of the scripting, only a small handfull of the devices were automatically being installed with PNP. If i go into the device manager, I can just have it update the driver and auto search and it installs it. No issue with non-signed drivers or anything along those lines. It's just like the machine tried once but never tried again after the drivers were put into the search path. I also have the DriverSigningPolicy = Ignore in my sysprep.ini. Any ideas?
  4. @Foose: I'm Sorry that I could not help you before but glad that you eventually found the root of the problem. I'll try to make it more clear about the beta version of AutoIt. Also, I've just found that the 'UseWPA' parameter in the .ini file is not documented enough, so I'll update this as well. @The Glimmerman: Can you give us more infos because Ryan replied in another thread that he did not manage to achieve this? It's my own ignorance. I knew i had to be missing something since the rest of you were ok.
  5. Ok, to add to the troubleshooting. On a machine that has never had wireless profile set up on it, it always fails at the wep length. On a machine that has had at least 1 profile created on it it goes passed the WEP section and the next screen (to save to a USB drive) and asks for a USB key to save data to(like it is missing the click to bypass the USB). If you follow through slightly, it finishes itself on the final screen to close out. Again, seems just like a click number issue or something. I am running normal XP SP2, US English. Any ideas? EDIT: Ok, i messed and fussed and messed for days on this. Finally broke down and downloaded the beta version of autoit and it works flawlessly. Sigh. Maybe I missed you saying you build this with beta.
  6. Call me a dufus, but can you translate it to english. I am strugling on the verbage. Thanks Edit: (also posted in the other thread) I am having an odd problem with the Autowep script. It is telling me my wep key is the improper length both when i use it command line or in the ini. Here is a sample of my ini slightly altered. [AutoWEP] version = 0.0.3b0 [Wlan] WlanSSID = myssid Wlankey = 736475940a7b9df73849e72a55 Am i missing quotes or something else? Second Edit: Did my best to translate BoardBabe's script for the screens and it doesn't seem to move passed the first screen. Here is my script as is, any suggestions on what i am missing?
  7. Having a weird error with the script and I am unsure why it is happening. Tried it command line and in the INI but it tells me my wep key is invalid length. Here is my ini (slightly altered) [AutoWEP] version = 0.0.3b0 [Wlan] WlanSSID = myssid Wlankey = 736475940a7b9df73849e72a55 the ssid is made up, but i left my key. As you can see it is 26 characters long. This is unaltered (other than the ssid name) as it appears in the ini. Am i missing quotes or something else?
  8. We are a novell shop. I used an app just now called snapshot. What it does is take a snapshot (imagine that) of all setting files and registry entries prior to changing/installing something then one afterwards to see the changes to the system. This way you can capture those changes/files and deploy them to other machines. From what i saw in the snapshot, when you do wireless zero configuration, it creates a registry entry for the wep and other settings under the adapter ID section. This wont work since adapter id is different for each machine and adapter type. So, the short and skinny is, I am screwed. You wont know the adapter type and ID until the machine is back up and then i wont be able to script anything to pass it down. Please tell me someone developed an app or something I can run to drop these settings. Otherwise this hands off universal image will not be so hands off. I will probably just have to add something to the setup of the image after deployment by our techs. They will have to create the profile.
  9. I am working on a universal image for our desktops/laptops. I have everything worked out but for some reason the wireless settings are not kept after I reseal the image. Is there a way to pass the config with an INI or some other config file either during the mini setup or even afterwards? It can also be outside of sysprep since I will be deploying the image with zen and can drop down files/apps after first login.
  10. Hey, I am working on a Universal Image to be sent out through ZEN and am compiling all the information together. I stumbled upon this thread but honestly it didn't answer what I wanted (to incorporate drivers in after sysprep'ing a machine to be deployed on multiple model types/machines). The process I am employing (at the moment) is to install the image as normal. Install apps/settings. Seal the machine with the -factory switch to force a plug and play scan through at first boot. I would like to have it search secondary location(s) to add in some of the driver items. I did, however, find this Microsoft article on the subject and seems to touch on doing this and more. How to Add OEM Plug and Play Drivers to Windows Will quote the section on sysprep. Hope this helps and I have yet to test this fully. But seems to all be coming together. You may see my write-up on CoolSolutions (if you are novell people) here soon. I will, of course, be providing links and proper praise on who set me on the right path.


×
×
  • Create New...