[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.

Well i found i work around, but it will work on my favor only i guess, not as a general fix to the issue. Technically i just did the same thing but in a different and older bios ( INTEL board, dual core CPU, 4 GB RAM, 80 GB SATA )

My goals :

1 Create a Windows 7 image ( regardless of the hardware)
2 Be able to install this image on different hardware.
3 Different images for different departments within the company.

What i did :

1 Since i was having too many issues with a GIGABYTE board UEFI ready, which i am still not fully familiar with. I decide to get the image from a different board.

2 i installed the image on to a brand new i5 Gigabyte board with 500 GB HD. which it did, only that i found something interesting.

In windows XP (single disk NTFS only) fog will used the entire disk and just use whatever was used by windows for the installation( EX 10 GB ) In windows 7 ( Multiple partitions single disk ) i created the image from a 80 GB SATA HD and fog will use the 80 GB out of the 500 GB HD that i deployed to and leave the rest
unallocated, which for my purpose is really not a bad thing because i can just manually format that partition and use is for local data storage ( not what i wanted but hey )

3 Once i get it working i will create a a different image for our many different departments ( i did this with windows xp and works perfect for me ) this way i am just down to only
some windows updates and join the computer to the domain.

DOMAIN ENVIRONMENT

Now am facing a different issue, i i am just going to mentioned because all of you have been really helpful and i hope my findings help someone else later…

In windows XP i would just deploy the computer and after i was done before joining the computer to the domain i would just run NewSID which will modify any SID entries to avoid any SID
conflicts in my environment. It worked perfect and never had a single issue… Now i ran the NewSID in windows 7 ( as Administrator ) then after the computer restarted windows will not boot again.

I can try to find a work around to this but i don’t want to have to do this all the time. I looked for a NewSid alternative for Win7, but the closes is to run sysprep with the unattended file which i was trying to avoid since i did not have to deal with it in widows xp but i guess i have to.

Again very much appreciated and i will post later my findings !!!

This couldn’t be a firewall thing could it?

sda2 has * boot marked.
sda2 is the 300mb part.

I think there’s a very easy problem/reason, why Win 7 Images (without Sysprep) don’t like Resizable images. It’s likely due to the mbr of the drive. When an image is created using Multi-part, it creates a copy of the mbr and both of the partitions/all of the partitions.

When an image is created using resizable, it creates the 100mb and system image, but the mbr is provided by the FOG script init.gz file.

I believe, and I don’t know how to fix that part of it, the mbr this particular method uses is a copy of a sysprepped (generalized) image so as to allow any size drive. If you copy the mbr of a non-sysprepped image, you are, basically, taking the partitioning table with you (as well as the size of the drive it was created on).

Just my thoughts.

Hi Tom, thanks for your quick reply!
The PCs come actually with the 100 MB partition.
I will have a look at the documentation carefully and I will image not the entire disk but just the Windows 7 partition and see how it goes.
I will post my results after I’m done with the task.

You can also change the sleep time for the snap ins, change this in your image and see if this helps: [url]http://fogproject.org/forum/threads/how-to-modify-your-snapinclient-dll-file-to-check-in-more-quickly-on-a-reboot.613/[/url]