[quote=“need2, post: 27785, member: 21891”]I’ll look about some more.[/quote]
Thanks a heap for the assistance mate.

[quote=“Tom Elliott, post: 27440, member: 7271”]svn 1709 should address that error as well as remove mysql_ functions and use the $this->DB calls for database purely where needed.[/quote]

Nice, upgraded to revision 1710 and everything works now. So far.
Thx.

Hi Tom,

Thank you very much for your answer. I will try to answer your questions. I did not have to much time to debug this situation.

“Does the table recognize GPT information?”
Yes.
“Does the d1.mbr file size equal 32256 bytes or 512 bytes?”
The size of d1.mbr is 17920.
I restored it with sgdisk but something strange happened. Just to be sure that everything is ok, I did a sgdisk -Z /dev/sda first to delete the GPT and MBR tables. Then I did a restore using sgdisk -l /images/d1.mbr /dev/sda. When I did a gdisk -l /dev/sda it showed no partitions. A read on a forum that before you restore you have to issue sgdisk -G /dev/sda. Apparently this command “Randomizes the disk’s GUID and all partitions’ unique GUIDs (but not their partition type code GUIDs). This function may be used after cloning a disk in order to render all GUIDs once again unique”. After I issued this command and did a restore again, all partitions were created on /dev/sda.

When I have a little more time I will continue debugging and post the results.

Thank you for your time.

Bogdan

We had issues on the 740s as well with fog .32. Before we had to leave the computers on bios version 1.1.3 and use a specific kernel. I don’t remember exactly which one but now that we are on fog 1.0 it doesn’t seem to matter for the kernel. I haven’t tried with an updated bios yet.

I didn’t set that up, it’s just the way the network administrators set it up at the university many years ago before I was even here.

But, it looks like none of that matters now. After updating FOG to the most recent update it magically works the way it is. Because someone, most likely Tom Elliott, is a super hero magician server fixing machine and did something in the most recent commit that fixed my problem.

Now onto my subnet and snapin adventures.

Thanks for all the help 🙂

-JJ

[quote=“Tom Elliott, post: 26107, member: 7271”]Don’t setup as JUST ME, install for everyone.[/quote]
That seems to have done it. Thank you very much. I swear that the last district I was in had this installed for Just Me, but I am content with this solution for the time being. Thank you.

David,

Also be cognisant of the kernel. I know my kernel’s don’t always work on All lenovo’s but there is a kernel floating around the forums here that seems to work well for troublesome kernels. As BPSTravis states, also verify the Drives are in MBR if you’re using 0.32. This does require a little extra work on your part, but ultimately will help you in the long run.

Finally, my problem to deploying came from network Access control list.
Thanxs for your help. 😉

Hi Danvaida,

Any good news on this.

I am facing the same issue with Lenovo L440o_O

[quote=“Nate Baker, post: 24539, member: 23116”]I know this thread is old, but wondering if anyone else has had success with this?

Doug, your method sounds like it would work great, but I’m wondering if that would work with critical drivers such as storage and network? Or do you need to have the storage and network drivers in the image already, and install the rest of the drivers using that method? It seems like since that oobeSystem pass is the last pass, it would need the storage and network drivers by that point.

Thanks,
Nate[/quote]

Sorry for the late reply. You are correct, Nate. I inject mass storage and LAN drivers into my base image for all the models of computers we deal with here before sysprep.

This may be due to how Microsoft looks for the computer name. If you find the registry values you need to edit, you can make a script the queries the other instances of the computer name and synchronizes them.

I think the problem is the fog client, it may not support the naming conventions of Windows 8.

I know this is old as the hills, but check out a awesome tool called sardu. Sardu.it - I recently came across it on spiceworks, awesome little utility. I have Hiren’s Boot CD and a Win7x64 Pro iso on a 16gb flash drive, I can boot into either one.

Samba mailing list post fell on deaf ears (or blind eyes I guess 🙂

But!

THIS. IS. SOLVED!

(or at least worked-around)

So, as it was appearing to be, it was a timing issue.

Fileserver share was opened by Nitrobit client pre-logon screen, and was held opened for a bit (by WIn7, or Samba, not sure but suspect a change in upgraded Samba version to be the cause), then FOG Service tries to immediately join domain, join fails due to the “multiple connections…” issue.

Solution?

Set the FOG Service on Win7 to “Start delayed” \0/

This will cause it to start “approximately 2 minutes after system boots.”

I have tested this several times (10+) on the Win7 VM that I set up and, while it may take a little longer (up to 4 about additional mins), the Windows 7 workstation with the Nitrobit client installed on it goes throught the rename, reboot, domain join, reboot-to-domain-logon process flawlessly now - every time!

So my question is, I wonder what the Samba > v3.6.16 smb.conf option might be to alleviate this without having to modify the FOG Service settings?

Also, I wonder if the FOG Service install could be modified to either automatically set the service to “Delayed Start” or ask during the install:

“Do you have any services that connect to the Domain Controller pre-logon screen?” If yes, then set for delayed start, if no, no delayed start.

Possible other option is what I mentioned previously: FOG Service forcefully disconnects any server connections just prior to join attempt.

It is 11:30pm on a Friday night, and I am so done with this. Happy it is solved. Now to notify our client so everyone can rejoice!

🙂

Thanks Tom, thanks BPSTravis!

Whoops… Now it is 11:30AM… Forgot to click “Post Reply” before walking out of office triumphantly. heh 🙂

Exactly as Tom says. Good luck.

VincentJ you can name them as you want, but I set the fog service to rename them, and if they don’t meet my naming scheme I track them through a management software, a couple of them really, so I can see the Host name assigned to the machine.

I check all of this and even fix it if necessary, which has only been the case on like 4 machines, and then I activate my windows. Everything I do is tied to a user log in, it registers everything to my novel tree and context, names the computer, enables novel auto log in (which heavily depends on the host name of the machine) then it activates windows.

I just experienced this problem with a non-sysprepped Win7 image I was dealing with, and the steps listed here, [url]http://fogproject.org/forum/threads/windows-7-without-sysprep.862/[/url] , from lkrms, did the trick for me. Quoted below:

[LEFT][SIZE=13px][FONT=Tahoma][COLOR=#141414]"I wasn’t able to find bcdedit commands to replicate what sysprep does to the system BCD store, but here’s what I did to achieve the same result (using VirtualBox snapshots):[/COLOR][/FONT][/SIZE][/LEFT]

[LEFT][SIZE=13px][FONT=Tahoma][COLOR=#141414]1. Capture a snapshot of a working audit-mode Windows 7 machine. 32-bit or 64-bit doesn’t matter - the BCD data seems to be interchangeable.[/COLOR][/FONT][/SIZE][/LEFT]
[LEFT][SIZE=13px][FONT=Tahoma][COLOR=#141414]2. Boot your machine, open a command prompt and run: “C:\Windows\System32\sysprep\sysprep /generalize /quit”. The /quit is important; you want the machine to stay up after sysprep so you can collect the BCD store as sysprep leaves it.[/COLOR][/FONT][/SIZE][/LEFT]
[LEFT][SIZE=13px][FONT=Tahoma][COLOR=#141414]3. If curious, run: “bcdedit /enum”. You’ll see what sysprep has done to your BCD store.[/COLOR][/FONT][/SIZE][/LEFT]
[LEFT][SIZE=13px][FONT=Tahoma][COLOR=#141414]4. Capture your BCD store: “bcdedit /export C:\generalized.bcd”. Save the resulting file with your other deployment files; mine ends up living in C:\Windows\System32\sysprep alongside my unattend.xml etc.[/COLOR][/FONT][/SIZE][/LEFT]
[LEFT][SIZE=13px][FONT=Tahoma][COLOR=#141414]5. Feel free to discard the sysprep’d virtual machine. Restore to your step 1 snapshot or similar.[/COLOR][/FONT][/SIZE][/LEFT]
[LEFT][SIZE=13px][FONT=Tahoma][COLOR=#141414]6. As part of your FOG pre-capture workflow, when not using sysprep, run “bcdedit /import generalized.bcd”."[/COLOR][/FONT][/SIZE][/LEFT]

Is it possible the SQL database is corrupt or has too many connections on it? Ultimately what happens with the “process” is the FOG Client sends the data to it’s respective service script. FOG Printer Management sends to {$fogwebdir}/service/PrinterManager.php. The php obtains the information and pulls it from the Database, then reports it’s “findings” to the Client that initiated the call.

It sounds to me like the mysql server has limited the connections, and may be in a Locked or timed out status.

So you’ve already created an image assigned it to the host and are currently trying to upload the image?

To use a resizable image, perform all the steps you do with the multi-partition image. Then sysprep the system before you upload. During the sysprep, set the system to shutdown rather than reboot. Then setup the upload job and turn the system back on. It should work better for the resizable. I haven’t verified all of this with Windows 8, but I have to do the same thing for Windows 7. The only major difference (unless going to EFI/Secureboot) between Windows 8 and Windows 7 is the Metro interface. So theoretically the same steps should be able to be followed.