You could add a second network interface to your VM, configure it for bridge mode (NAT would probably work too, I suppose) and let it get a dynamic address from the core network. That should let the server hit the 'Net for updates (assuming the core DHCP serves out a gateway as part of the lease). Your original interface can be restricted to it’s own VLAN for imaging/deployment tasks. You could configure the server to handle DHCP/DNS for the VLAN. Deployment clients would have to be on the VLAN somehow…not sure exactly how you’d want to handle that.

As for the images, you could burn the individual images to DVD or USB or something. I’m not sure how you’d deploy them with FOG. They’re Partclone images, so perhaps Clonezilla Live? One of the developers would be able to provide a better answer.

As for the identical hardware, I would definitely sysprep the image. Even given that they’re all identical units with the same hardware, sysprep is generally a good idea. You can preinstall the drivers in Audit Mode, if you want, and they’ll be installed automagically by sysprep during deployment.

If you don’t sysprep, you’ll almost certainly run into problems with OEM licensing…although FOG can update the licenses on a per-machine basis if the data exists in the database. I’m doing something similar myself, since I’m also using OEM licensing…I use a generic non-activating key with sysprep to skip the “enter license” prompt and let FOG enter it for me post-install.

The aircard…sorry, can’t help you here. Never used one…anyone else…?

The SID…well, Microsoft will lead you to believe there will be all kinds of end-of-the-world-as-we-know-it consequences if machines do not have a unique SID. Since I use sysprep, I’ve never worried about. I do know of others (including colleagues) who never worry about it and have deployed without regenerating the SID (or using sysprep). They’ve never had issues.

Hope that helps.

heh…no worries about more work/testing. I’m probably a few tomatoes short of a salad, but I enjoy the challenge. Unfortunately, the scenario where all of this will eventually be deployed will not be part of AD. But that doesn’t make it something I can’t use.

My real job, at a local university, uses AD, KMS licensing and relies on a variety of imaging and deployment tools depending on the circumstance. So…my goal is to ultimately implement a one-size-fits-all solution: FOG. My pointy-haired boss doesn’t care much for FOSS stuff; he prefers a commercial product so he can phone for support if things don’t work or something breaks. I need to build a case study to prove FOG is a viable option. I figure this retail project is going to be a lot more work in most respects than an AD/KMS environment…but I’ve been wrong before (only once or twice, though). Any input you can offer would be great.

Is there a list of those FOG variables somewhere? A quick search of the forum didn’t turn up anything…

I ask now because I have a problem with license key updates. The key is entered during Full Registration and is correct according to Host Management, but updating it on the client seems to be hit’n’miss. I suspect it’s a network driver thing. If the client deploys and Windows has a native driver installed during sysprep, the key seems to update correctly from FOG. If the driver is added as part of the post-deploy routine (SAD2), the key does not get updated.

I’m looking for a method to force the key to update from FOG, since the client doesn’t seem to do it even after multiple restarts or waiting for the client check-in period to pass. If FOG provides a variable for the key, I may be able to force the update that way. Of course, I’m open to suggestions for alternatives…

I’m not sure I follow. Do you mean assigning the hostname as part of the unattend.xml or changing the hostname post-install with another script? Given the retail environment this project will be used in, I’m not sure assigning hostname via unattend.xml would work well. A post-install script would work and I’ve done it this way in the past on other projects. Given that FOG has this feature baked in, it made more sense to me to leverage FOG’s native abilities for this task. In the end, the process has to be simple-to-use, streamlined and, relatively speaking, easy-to-maintain for my client. I am, after all, just a hired gun; I’m not an employee. They want a dependable solution for their needs and I believe FOG will be a great fit for their environment.

Success! So far, one test deployment has worked correctly with the patched and recompiled HostnameChange.dll provided by Jbob. I’m running another test as I type this to confirm, but I suspect things are now good-to-go. Much thanks to Jbob for all of his help and his patience with my incessant demands and long-winded forum posts.

Another update.

I’ve redeployed my test image using the recompiled default key DLL instead of the custom one. Same $#&%, different pile. The log file still displays the [I]got 7, wanted 6[/I] error (see the log file in my earlier post) and the host is never renamed.

I decided to hop out on that limb too, so I’ve upgraded FOG to SVN. So far, so good…and the endless product key prompt is gone. It takes the key on the first shot and Host Management now has complete fields after Full Host Registration. Awesome.

Not so awesome, unfortunately, is the hostname issue. It’s still hanging in there. I made sure I renamed and copied the custom DLL into the FOG client folder (replaced the existing one) and redeployed. I’m still seeing the same errors in [I]fog.log[/I] as in my earlier post: [I]Incomplete server response; got: 7; wanted 6[/I].

Just for giggles, I removed a bunch of stuff from deployment during this last testing phase. In an attempt to minimize the issue in case it there was a conflict with somthing else, I removed the all of the device drivers (except for ethernet) from the SAD2 post-deployment. The script I use (purloined from the Tutorial forum) stops the FOG service while it runs, but I figured it wouldn’t hurt to slim things down during testing. In this case, it didn’t help either.

Real life beckons for a few hours, but I hope to get back at it tonight.

Yep, that’s sounds like what I’m seeing alright. Fixed in SVN…hmmm.

Ok, here’s a silly question. I’m currently using the release version of FOG 1.2.0 for all of this fun. How much hurt am I gonna be in for if I bump up to the SVN release? I understand bugs (err…undocumented features) happen but this project will eventually be a production deployment solution for a client. Is it worth the risk…?

Will moving to SVN resolve the hostname/product key issues (I assume they’re related) or will I still need the recompiled DLL files provided by Jbob?

@Jbob: I’m sure I replaced the DLL with the custom one you provided, but I’m gonna go back to my image and double-check.

Howdy, folks! Grab a beverage, this could be a long one…

With some help from Jbob, I now have recompiled HostnameChange.dll. Two versions, actually. One is a default key version and the second is a custom key version compiled with details I provided. Thanks for stepping up to the plate, Jbob. My first test uses the custom version.

So…I replaced the default HostnameChange.dll in the FOG directory on my image with the custom one and started the process. If I choose Full Host Registration, it walks me through the process but still refuses to accept any of the Windows 7 product keys I’ve entered (I have several to test with). These are OEM keys, not volume license. Registration just keeps prompting me to enter the product key. I’ve tried a few different formats just in case it was being picky:

• XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
• xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
• XXXXXXXXXXXXXXXXXXXXXXXXX
• xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

No change in behavior. It just returns to the prompt and asks me to enter the product key. Ok, annoying but not a deal-breaker. I’ll enter it in the FOG GUI under Host Management for the machine. This is the same behavior I described originally.

After rolling out the image, right before it restarts to begin sysprep, I see something about changing the hostname but it flies by too quick for me to actually see if it’s doing anything or not. Oddly, sysprep now prompts me to enter a hostname…something it never did before. I took the default offering of “PC” and carried on. Once at the desktop, after sysprep is complete and drivers are installed, the computer still has a hostname of “PC”. The correct hostname was not applied (even after several restarts) and I no longer have the “FOG-xxx” hostname I described above.

Here’s an excerpt from [I]fog.log[/I] on the client:

[CODE] 19/12/2014 3:53 PM FOG Service Engine Version: 3
19/12/2014 3:53 PM Starting all sub processes
19/12/2014 3:53 PM 6 modules loaded
19/12/2014 3:53 PM * Starting FOG.SnapinClient
19/12/2014 3:53 PM * Starting FOG.GUIWatcher
19/12/2014 3:53 PM * Starting FOG.HostNameChanger
19/12/2014 3:53 PM FOG::GUIWatcher Starting GUI Watcher…
19/12/2014 3:53 PM * Starting FOG.HostRegister
19/12/2014 3:53 PM * Starting FOG.SnapinClient
19/12/2014 3:53 PM * Starting FOG.TaskReboot
19/12/2014 3:53 PM FOG::TaskReboot Taskreboot in lazy mode.
19/12/2014 3:53 PM FOG::TaskReboot Starting Task Reboot…
19/12/2014 3:53 PM FOG::ClientUpdater Starting client update process…
19/12/2014 3:53 PM FOG::HostRegister Starting host registration process…
19/12/2014 3:53 PM FOG::ClientUpdater Sleeping for 358 seconds.
19/12/2014 3:53 PM FOG::SnapinClient Starting snapin client process…
19/12/2014 3:53 PM FOG::HostnameChanger Starting hostname change process…
19/12/2014 3:53 PM FOG::HostnameChanger Yielding to other subservices for 8 seconds.
19/12/2014 3:53 PM FOG::HostRegister Exiting because only 1 mac address was found.
19/12/2014 3:53 PM FOG::HostnameChanger Attempting to connect to fog server…
19/12/2014 3:53 PM FOG::HostnameChanger Module is active…
19/12/2014 3:53 PM FOG::HostnameChanger Failed: Incomplete server response; got: 7; wanted: 6.
19/12/2014 3:53 PM FOG::HostnameChanger Host name was not found in the database.[/CODE]

I’m going to retry this process using the default key version of the HostnameChange.dll and see what happens. I’ll post back later today. In the meantime, if anyone can shed some light on this I’d be most appreciative.

Thanks in advance,

A quick poke around looks like I might be able to compile .NET in Ubuntu using Mono. Before I get too gung-ho, I have a few more points I should mention about what I’m trying to accomplish in case it affects the results I’m looking for.

All of these questions arise from the contract I’ve been asked to fulfill. My client is looking for something simple to use and relatively easy to maintain; I recommended FOG based on my own past experiences with it. My client runs a retail shop; this means systems will have varying hardware and a product key (for varying Windows operating systems) that is unique to that system. No volume license/KMS stuff here. Computers will also be standalone workgroup machines; no active directory/LDAP stuff to worry about. As I mentioned previously, the deployments and driver installs are working great. The hostname/product key part not so much.

I’m not sure how (or if) this affects the HostnameChanger.dll issue. Is compiling the dll from source a one-size-fits-all solution that needs to be done once or will I need multiple versions depending on the specific Windows version to be installed? Will the lack of active directory cause issues at all? Research shows the dll affects both hostname and active directory joins…can you configure one option (hostname) and not use the other (AD) part?

To perhaps save someone some typing, I’ve also looked at the Capone plugin but I don’t think that’s the solution I’m looking for…unless I misunderstood it’s purpose/application (hey, stranger things have happened).

Thanks again to those folks who’ve thrown me a bone or two.