I downloaded the package again and the installation worked.

I don’t know what happened but its now working.

HenryI did an experiment, a simple multicast send and receive on a private network contains only the Access Point and one station. The results are:

With the station sends and the Access Point receives multicast data using 224.0.0.1, the rate is over 20 Mbit/sec. With the Access Point sends and the station receives multicast data using 224.0.0.1, the rate is over very slow even less than 2 Mbit/sec.
I have no clue!!

@george1421

Awesome! It works!

Thanks a lot.

I’ll have a look at dmidecode when things settle down a little thanks.

@Tom-Elliott
@george1421 after updating to the latest version the deployments to the NCR still fail. I am able to image PCs and laptops so I will just use a different solution for the NCRs and leave it at that. Thanks everyone for all of your help and assistance!

Thanks,

Anthony

You can also turn off DHCP config generation by setting bldhcp to 0 in .fogsettings

@Wayne-Workman said in After install FOG my user account's (fog) password seems not to work anymore:

@sdorion said in After install FOG my user account's (fog) password seems not to work anymore:

When I installed kubuntu I choose fog as username…

That was your first mistake. Do not create a user called fog, this is a reserved account.

The password for the fog account will be in storage management. Once in, I would advise you to make a different account called something else, and leave the fog account alone.

OK.
Thank you Wayne.

@Quazz said in Install script errors:

I’m wondering if Ubuntu updated Bash to be a bit different, hmmm.

They didn’t. The installer is tested on Ubuntu every day, you can see the test results here: http://perpetuum.io:20080/fog_distro_check/installer_dashboard.html

@Tom-Elliott we already had FOG_TASK_FORCE_REBOOT set but to no effect. I will try disabling it completely.
Btw. I cannot mark answers of others as correct…

@Tom-Elliott

Yes sir! Things are working well! I’ve multicasted several machines this afternoon without a hitch. Yay! Thanks!!

@Tom-Elliott
i’ts working with the fog server 1.4.4 SVN 6077.

Thanks a lot.

Can you unset the filter after “checking” the boxes to see if they’re all being checked accidentally?

@chief said in Windows 10 Enterprise Fog Client Install:

How do you install the Fog client so that on install it will boot, connect to AD etc?

Install it before going into audit mode.

When I was doing a lot of imaging, I didn’t sysprep. See this older post: https://forums.fogproject.org/topic/8906/to-sysprep-or-not-that-is-the-question

@Tom-Elliott

It was on Raid, so I changed to AHCI. No Joy, still get the same message.

Ok…well not sure why or how I had a couple of machines showing that same error…but I started rebuilding a different machine from the OS up and it captured with no problems. Thanks for your help.

Thanks, it’s clear now.

You can mark it as solved, i will export/import on a fresh install when i will have some times

@Tom-Elliott Dude everyone here gets it and appreciates what you do! Thanks for everything!

@Avaryan That did the trick! I had a feeling it was just a location problem. I can now boot to the ISO. Thanks for the help!

@jlouie.smart that’s too difficult and not supported and I will not help you with it. Just migrate the data and images to a new box, leaving the old box untouched. When done, shutdown the old box. https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

@UWPVIOLATOR the others aren’t concerning. Feel free to fix them though. Google is your friend.

@Tom-Elliott The client is what I suspect is different as I haven’t actually been pushing the client for the last 3 months as I was instructed to remove the client from all but a couple labs. So this is the first attempt for a couple months to have the clients pushed to computers before we image them in order to take full advantage of multicasting from the local nodes. Now it seems that the process used before isn’t working completely together. If I push a client to a computer, it registers with fog, and I see the machine, I suppose (as I haven’t tested) that the snapins and power management will work on these hosts just as they always have. The problem is when I pxe boot the laptops, they show as not registered.

Now I have been running this system here for a couple years since trunk became available so it’s possible I have junk clients registered already, but I didn’t see these machines as I deleted them after removing the clients (at least not in the gui). I can verify this issue does not arise on desktop machines. I just don’t understand why the client would think it wasn’t registered.

I have no idea how any macs could be shared, as we haven’t done anything to initiate that. All clients are currently running Windows 7 so the “randomizing” of any wireless nics isn’t the issue here, but rather in the manner the client registers the hosts.

Quickreg works flawlessly, but it uses different mechanisms to register the nics I’m assuming since it’s still in a pre-boot environment.