Laundry List of Issues
-
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.
-
You’re going to want to PM me. Trust me. I’ve dealt with compiling the old client and it is not pretty. It will take a bit of work to compile it on linux because of some dependency issues. The dll is a one-size-fits-all. It doesn’t matter if the host has a product key or not. I already have the infastructure and scripts required to build you a copy in a matter of seconds. What I need from you (in PM form) is an email address and what pass phrase you want (or if the default one will work).
-
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,
-
That full host registration issues sounds familiar. I believe it this issue I reported a while back: [url]http://fogproject.org/forum/threads/host-registration-broken.11270/[/url]
Updating to the latest svn version would fix the issues if you don’t feel like manually implementing it yourself. The error
“[FONT=Consolas]Failed: Incomplete server response; got: 7; wanted: 6.” [/FONT]Suggests that the dll was never replaced with one that I compiled. -
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
