Posts made by dvlsg

Haha shoot. At least you got it sorted out now? Were you able to test booting to the SCSI VMware hard drive?

No, I take back what I said earlier. Did some research into how it actually works, and what I said made no sense.

Can you make a temporary file for PXE to attempt to download that isn’t labeled pxelinux.0, point the DHCP servers to it, and then see if PXE will recognize and pull it across?

Hmm… you could theoretically get the machines to wake-on-lan from magic packets, get them to boot to a stage where you could run an arp-scan to retreive the mac addresses of all the machines on the switch, then upload the returned information into the relevant MySQL tables, then use that information to trigger the imaging process on all of the computers.

Sounds like one hell of an involved project though, and I can already see [I]tons[/I] of possible snags.

Strange… I wonder if the same error would occur if you opened up the kernel and remade it, but didn’t change any settings when doing the make xconfig step. Which I realize is nothing like a solution… More just a curiosity, haha.

On another note, I had a similar problem to yours, so I updated the kernel to include those VMWare drivers. And then I ended up not needing it. The only VMs I need to connect to FOG are my reference images, so when I created the new VMs I created them as blank templates, deleted the default SCSI hard drive, and added VM IDE hard drives which FOG 0.32 picked up just fine.

Not sure if that helps you in your situation at all (especially if you’re trying to connect exisitng vms with SCSI based vmdks), but if you’re sick of banging your head against the bzImage errors and you have the option to switch, it works.

Good stuff. I do a similar thing, but I implemented the logic outside of FOG. Basically, I have scripts run post image that determine which software/drivers need to be run.

I think I like the way you have FOG doing it better, though. Probably requires way fewer lines of code, haha. Sadly, I have to deal with specific installations based off of AD queries, so it made sense to wrap all that up in vbs instead.

Oh, I suppose I should also note that I use the Dell Driver cabs, but I also run them through Microsoft’s deployment workbench from the MDT by importing them as out-of-box drivers to my non-functional deployment share, and then I copy them from the folder structure (\DeploymentShare$\Out-Of-Box Drivers*.*) to the FOG server.

I wonder if that would resolve the unsigned driver issue. It seems to format the structure of the files in the cab to a structure that looks similar to \Windows\System32\DriverStore\FileRepository

As a side note, if you have to use a computer that doesn’t have a nice manufacturer that wraps all the drivers up in a cab like Dell does, you can use the MDT to pull drivers directly from the FileRepository from a computer that has already been set up.

Yeah, a lot of people I talk to are starting to move away from the unattend.xml approach, since it’s [I]technically[/I] not necessary. I prefer to have as clean of an image as I can though, so I still use it. That <DriverPaths> code is embedded in the <settings pass=“windowsPE”> by the way.

Ah, yeah that would make sense. We get all laptops, and our oldest model floating around is in the Latitude E6400 series, which really isn’t that old. We also only deploy Windows 7 - not sure how Windows XP would handle using the unattend.xml.

Ahh okay. I haven’t run into any issues with unsigned drivers. I found that adding this to my unattend.xml was enough (I have the script copying the relevant drivers to c:\drivers and then some vbs down along the line cleaning it up) –

<DriverPaths>
<PathAndCredentials wcm:action=“add” wcm:keyValue=“1”>
<Path>C:\Drivers</Path>
</PathAndCredentials>
</DriverPaths>

But the only machines I have to deploy to are Dells. I suspect all of the relevant drivers are signed.

Hmmm… So I’ve been trying to deploy/execute vbscript using 7zip SFX – and it runs perfectly (.vbs wrapped in a .7 wrapped in a .exe, set to extract to the temp folder and execute the .vbs either directly or through a .bat file that calls cscript.exe), but after it completes, Windows always complains, saying “This program may not have installed correctly.”

Does anyone have any experience with this? So far all I’ve found is a shotgun approach of disabling the program compatibility message for [I]everything[/I] via group policy, and I’d rather not do that.

My FOG server is running on virtualized Ubuntu 12.04, ESXi on a Dell PowerEdge M610. Works great – the only bottlenecks I ever run into is related to our limited network bandwidth, not FOG resource usage.

Yeah, I could see 12.04 being the cause of our problems.

To be honest, if the virus messes up the computer badly enough to need a pxe boot scan to actually remove it, I’ve found it saves time to just reimage the machine (we make use of a lot of network storage, so losing files is almost never an issue).

I’m actually not sure about how well ClamAV works in regards to detecting and removing viruses, but maybe that’s for a different thread.

I actually still have the same problem. The computer running the clamscan errors out on switching directory to /var/lib/clamav
[I]“ERROR: Can’t change dir to /var/lib/clamav”[/I]
Then it tries switching to /usr/share/clamav which, as merc.man87 points out, obviously doesn’t work.

I’m also running 12.04, by the way. I sort of gave up troubleshooting it for a while, since it was turning into a time sink for something I wouldn’t use very often.

Awesome! Thanks for posting. I’ll take a look at it as soon as I get a chance.

Got it working. I ended up working with a simplified version. We’re currently only using Windows 7, so I didn’t need any of the XP sections, and I actually have a different solution set up for joining the domain so I didn’t include that either – where I work, each domain user account is setup as a local admin on their own laptop (but not anywhere else), so I wrote some vbscript that handles that, joins the domain, restarts, and automatically logs in as the user.

But! Your post was very, very helpful in showing me how to get the information from mysql using php (haven’t ever worked with php before), and using sed to replace variables in files. So thanks for taking the time to post this! I really appreciate it.

Haha hey, if it works, it works. I have a bunch of script nonsense that bounces between vbscript and cmdline for silent installations of programs. Sounds like it would fit right in with what I do, haha.

Well, I was unaware that vbscript was even able to do that. It’ll look fancy to me no matter what, haha.

I’m currently using single partitions with Windows 7. Here’s my setup:

1. Deployment/Reference images set up as VMs (using VMWare)
2. Installed Windows 7 (NOT the easy install - leaving the 100mb partition in place)
3. Once image is set up, use sysprep
4. Upload as single-partition, resizable.

That being said, I only have to deploy to Dell machines, so I’m probably just getting really lucky.

Astrouga, would you mind sharing the partition extending vbscript? That sounds interesting.

Ahh okay – yeah I had been eyeing the wiki article about buildroot: ([url]http://www.fogproject.org/wiki/index.php/Build_FOG_file_system_with_BuildRoot_-_init.gz[/url])

I was holding off on diving in to that, since I was hoping there would be a way to mount the init.gz, import the installation (somehow or another), and gzip init back up without having to rebuild the whole thing. But if there’s no other way, then that’s what I’ll do.

Oh that’s interesting. Thanks for the link! That’ll be a good read.

Honestly, the reason I’m interested in it is - just because. Haha. The extra reboot certainly isn’t the end of the world. I would technically save a bit of time, but it’s more an excuse for me to learn more about how FOG works, and how PHP works, so I’m just playing with it when I have extra time (which isn’t very often). I don’t actually use snapins to deploy software - I have a lot of VBS that pulls info from active directory and deploys software from a networked drive based on that information.

Lee, I actually have been working on your post – I don’t have it in production yet, but I still have to fiddle around with buildroot. Although, I’m not sure I’ll need to - I think sed is actually included in whatever build of init.gz I have.