Laundry List of Issues
-
Top o’ the mornin’, to ya. Thanks for the quick responses, folks.
I’m on my way out the door shortly, so I may not have time to answer all of the questions until after I get home from my real job (would you like fries with that?)…but we’ll do what we can.
@ch3i: ah-ha…the log file throws a bone. I’m seeing several hostname-related errors. Looks like retries throughout the process but there are several of them:
[CODE]HostnameChanger Module is active
HostnameChanger Failed: Incomplete server response; got 7 wanted 6
HostnameChanger Host name was not found in database[/CODE][CODE]HostnameChanger Host name was not found in the database.[/CODE]
Rinse and repeat throughout the log…
And the screaming yard ape has finished her breakfast, so it’s time to get up and go. More later…
-
[quote=“Malfunctioning Eddie, post: 39975, member: 27496”]Top o’ the mornin’, to ya. Thanks for the quick responses, folks.
I’m on my way out the door shortly, so I may not have time to answer all of the questions until after I get home from my real job (would you like fries with that?)…but we’ll do what we can.
@ch3i: ah-ha…the log file throws a bone. I’m seeing several hostname-related errors. Looks like retries throughout the process but there are several of them:
[CODE]HostnameChanger Module is active
HostnameChanger Failed: Incomplete server response; got 7 wanted 6
HostnameChanger Host name was not found in database[/CODE][CODE]HostnameChanger Host name was not found in the database.[/CODE]
Rinse and repeat throughout the log…
And the screaming yard ape has finished her breakfast, so it’s time to get up and go. More later…[/quote]
The problem, as I see the log file information:
You have a key entered, but you didn’t recompile the hostname changer file to allow accepting of this new fangled data.
Please follow instructions on this thread:
[url]http://fogproject.org/forum/threads/windows-7-activation-proposal.10745/[/url] -
Just a quick alteration to what Tom said. The link he posted as actually the initial proposal I made for adding such a feature and there are some issues with it. See this post: [url]http://fogproject.org/forum/threads/troubles-with-recompiling-the-hostname-module.11398/#post-36214[/url] for what you should actually do. The source file linked needs to be downloaded and compiled. If you have any issues at all with compiling the patched HostnameChanger, PM me with the details and I can build you a copy of it.
-
So, this is kinda sort where I was going…thinking there was an issue with the HostnameChanger.dll file. I did see a few references to compiling or swapping in a custom version but not a lot of info on exactly what was involved. Now things are starting to make sense. I’m hoping to get all of this in place before Xmas, so I may take Jbob up on his offer to compile for me just to make my deadline. However, I’m not opposed to learning (I’m a sysadmin/network guy, not a programmer) so I would like to try this on my own as well. Be warned: I may need a little hand-holding here to get through this.
So, getting started I have to say I’m running in Linux environment here. Aside from the Windows deployments I’m testing with FOG, I don’t have any working Windows boxes. Can I compile .NET stuff under Linux (say, the FOG server itself)? Time for a little Google spelunking…
-
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.
