Laundry List of Issues
-
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.
-
I’m going to go out on a limb here and say the current SVN version fixes more bugs than it creates. However, I understand being reluctant. The fix you need itself is actually pretty simple to perform. Basically you’re going to want to extract & mount init.gz, and perform the change I proposed here: [url]http://fogproject.org/forum/threads/host-registration-broken.11270/[/url] . I forgot the exact commands you use to extract it, sorry.
As for the dll’s I’ll double check the ones I compiled, who knows maybe I screwed up and compiled the unpatched version.
-
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.
-
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.
-
That would mean I gave you the unpatched version. I’ll pm you new ones when I get a chance.
-
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.
-
not to throw a spanner in the works (now that you’ve got it working and all) but as you’re using sysprep, you could do host renaming during postscripts (getting it to modify the unattend.xml on the new downloaded image). and/or domain join if needs be. that way no need for reboots as the name is set (and domain details) correctly in unattend pre-sysprep.
Just an alternative
-
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.
-
postscripts are native to FOG it’s the capability to run any custom script after the image has finished deploying right before it reboots. it’s easy to use as you just use the variable passed by FOG i.e. $addomain, $adou so maintainence free and technically could be clientless really.
sounds like you’ve got it covered now though
-
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…
-
well… may be causing you more work/testing here but you could get postscripts to handle your drivers too for you so they get installed during sysprep rather than after?
i’ll write a quick thread about setting up AD and Drivers and even snapins in postscripts, it’s long overdue anyway and might be helpful to others, it don’t fit all scenarios but ppl could take chunks from it :-)…
-
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.
-
put it this way, we have 2500 Devices, 23 different models (yes 23!! don’t ask, serious just don’t ask!) 18 sites “large” sites across the stretch of the country (UK) and we can rebuild a machine (with all the software, bells, whistles you name it + more) in under 15 minutes, regardless of what site and it only takes a minute of an engineers time to do (less if device is registered)
just kick it off and check webgui in 15 mins or so.we only have 3 images to maintain (i use the methodology of, if it doesn’t update often or complex to configure (and is needed across the entire estate) or it takes a long time to install - add to image, otherwise do it in the snapin, so all we have on our base image is office and latest win updates of course.)
anyway so:
1 image for Win7 x86
1 image for Win7 x64
1 image for Win8.1 x64we have 1 snapin script to maintain that covers 15 variations of builds (script is 1.5MB)
and a driver directory on server to maintainNew model comes in:
process is, create new folder in driver directory on server, add drivers to new folder (.inf) job done new model supportedNew software version released (been tested, ready/happy to use)
process is, overwrite old software installer on server with new (amend script slightly if needed) - job doneso yes, used right and setup right, FOG can be pretty damn powerful and low maintainance one thing you’ll always have with FOG which you won’t with most retail products. full control and full potential… there’s nothing FOG can’t do, only restriction is your/the community/us developers technical abilities and knowledge
hope that helps your case study to sell FOG to your manager, i know all about having to convince management of FOG.
now they love it that it’s saving them 1000’s upon 1000’s of £’s a year and same goes for engineer time/resources, travelling cost (no more need to travel to sites!) -
[quote=“Lee Rowlett, post: 40352, member: 28”]put it this way, we have 2500 Devices, 23 different models (yes 23!! don’t ask, serious just don’t ask!) 18 sites “large” sites across the stretch of the country (UK) and we can rebuild a machine (with all the software, bells, whistles you name it + more) in under 15 minutes, regardless of what site and it only takes a minute of an engineers time to do (less if device is registered)
just kick it off and check webgui in 15 mins or so.
[/quote]23 doesn’t sound bad at all to me. we have 33 models in the 800 or so machines currently in fog
