Best posts made by george1421

@Wayne-Workman you will need to link the location to a subnet (like 192.168.100.0/24 == NYC, 192.168,112.0/24== ATL, and so on). Then the client would have to query the server to find the storage nodes associated with the subnet.

This would solve an issue I have today where I have a user at another site that needs a program. But the only way to install it is over a very slow DSL link even though there is a FOG storage node at that site. (Quick fix was to move the target computer to a different location temporarly).

I guess the first question is why are you using version 0.30? That is a really old version of FOG. Is this a new install? If so I would recommend that you start with at least 1.2.0. The developers are working on 1.3.0 which has a lot of new enhancements. I would actually recommend the trunk build (pre1.3.0) but right now the installer has a few bugs that was discovered just before christmas that haven’t been addressed yet. So for the trunk build I would hold off a bit longer.

To your question. You would build the reference image and then sysprep it then shutdown.

From there you schedule a upload task in FOG. When you boot the reference image you need to ensure that it pxe boots into the fog menu, that is where the image will then be uploaded into fog. Since I personally haven’t worked with .30 in about 6 years I can’t give you step by step instructions if this part fails.

@Andy-Nicolson You just said something that has me thinking.

Does WOL and PXE boot work if you unplug the power from the computer wait 10 seconds and then replug the power? What I’m trying to identify is that if everything works from a power up state vs a windows shutdown/restart. I remember reading somewhere that win10 can disable change the function of wol. This is because a normal windows 10 shutdown isn’t really a shutdown, but an enhanced sleep state to facilitate a faster startup. I’m not saying this is the case with this hardware (you should see this in others too), but it could be A issue if windows 10 specifically turns it off.
ref: http://www.sysadminshowto.com/how-to-configure-wake-on-lan-in-windows-10-and-windows-8-1/

@RobTitian16 yes if you are using an unattend.xml file.

@Wayne-Workman The other option is for the OP to extract the inits make the change to fog registration script and then recompress the inits and then exchange the “fixed” inits on his fog server with the official ones.

If I understand your question, this one got me confused for a bit too.

(warning typing with one eye open) For debug mode go to the host and then for the host select tasks then advanced (its below the deploy and capture options). When you select advanced you will see a series of additional tasks you can assign to the target computer. Debug is one of them.

@aharrison said in Windows 10 Deployment from existing machine as reference using sysprep:

though the PC is joined to the AD domain.

This is your first problem. Domain joined PCs will be difficult to clone, even if you disconnect them from the domain. Adding a new system to a domain tattoos them with domain “junk”.

The second thing that jumps out at me is your sysprep setup.
sysprep /generalize /oobe /shutdown /unattend:unattend.xml

If it was me I would put the unattend.xml file in the Panther directory AND define the full path to the unattend.xml file. The rest of your sysprep command looks good.

Are/Is this OS you are deploying OEM or do you have a VLK?

@RobTitian16 said in Rolling FOG out to US Site:

I can’t see where the post install script is actually telling the SetupComplete.cmd to run, though. I can see it copies, but nothing tells it to run.

See I think there is where you may be a bit confused (and rightly so). The FOG post install scripts run in linux so they can’t touch any windows programs or windows behavior. All we are doing with the post install script is placing things where windows expects to find them. As Tom posted Windows OOBE will run what ever is in the setupcomplete.cmd file after OOBE is done and before the first login window is displayed. This is a windows thing and has nothing to do with fog other than fog placed that file there. That file could and should have been there when you captured your master image. But since it was not you are using the fog post install script to kind of patch what should have been there prior to image capture.

@juice381 Its still perplexing why the installfog.sh file is not creating the .fogsettings file. I think if you uncover that reason the rest will fall into place.

Did you disable selinux and the firewall?

Are you launching the fog install script with sudo? Does it run through and ask you all of the questions it should? Then it just doesn’t do anything? It almost sounds like selinux is blocking the installer script from writing to the places it needs to.

In regards to your error screen below, do you have another dnsmasq server running that is sending out the legacy ip address? It is saying that you are getting a duplicate option 66 {next-server} from dhcp.

Please start a new thread since your issue will get lost in this thread’s title.

But it sounds like you have two dhcp servers running in your environment.

Your unattend.xml file looks a little “lite” on the required settings. You might want to compare your unattend.xml file against one created by one of the online generators: http://windowsafg.no-ip.org/win10x86_x64.html

Since you have mcafee fde installed you will have to backup the user’s profiles in the windows environment. Linux FOS can’t help you here, or your drive encryption wouldn’t be very good.

We use USMT to transfer the user’s profile to their home drive before imaging and then back after imaging. This is all done in the windows realm outside of FOG.

@juice381 It would be interesting to know of the stats you get with the mobile fog server.

i.e.

1. unicast to a single computer (with d-link)
2. unicast to 2 computers (simultaneously with d-link)
3. unicast to 2 computers (simultaneously with enterprise class switch).

I’m interested in what the Odroid can do, but also the impact of that d-link over an enterprise switch. We see in the forums that the low (discount) switches are under powered for imaging where you will get 1/3 the speed for a multi deployment from a low end switch over an enterprise switch if the switch is the only thing that changes in the mix.

@templink said:

OK self-resolved.
I modified /tftpboot/default.ipxe and restarted tftpd-hpa service
it’s working now

While its working I wonder how many pains it will give you the next time you upgrade your FOG server. There is a setting inside the FOG management console you need to update. Its in the FOG settings section that has the wrong IP address.

@RobTitian16 said in Driver Issues With Dell Latitude 7280 - No Bootable Devices:

I just need to edit the unattend.xml to point to C:\Windows\DRV for the drivers, instead of relying on the registry change?

Correct. I’m a bit surprised that your other win10 images actually worked??

Either way that’s not your issue with the 7280. For the 7280 you need to inject the driver into the reference (golden) image before capture.

@Tom-Elliott Tom I feel you are right here. While this is a pretty lengthy thread, there is a bunch of information that can be gleaned from it. What Rob is doing is pushing the envelope of the FOG infrastructure (which is great since it forces FOG to mature and grow). This is the type of activity I would like to see in the FOG Project. I would (personally) like to see enhancements around the “fog servers” cross communication to eliminate the human involvement. Maybe for FOG 1.3.1 or a brilliant plugin (hint, hint)

My intent was not to cut this thread short of completion, just as a moderator it thing its gone a bit past the original post which hides the rich content of the post. I do think Rob’s current issue should be forked into a new thread since his complete issue is not resolved just yet. Its close but not solved.

@juice381 Sure on the getting multicast working too. I’m sure its just a package name or pre-req this is needed. Once we can find the exact cause the developers can have a look at the installer code and made exceptions for your specific issue.

I think your project would be good one to document for a low cost mobile deployment server that could be used in small sales offices where you need a local fog server (storage node) because of the bandwidth issues, but still manage it from a central location.

@Wayne-Workman If I understand the OP’s post there were two actions that were needed.

1. Since there is a firewall between the two subnets, 2 rules needed to be crafted to allow communication between the devices on the subnet where the fog server was not.
2. On the subnet where the fog server was not he had to update the dhcp to include the next server and boot file settings. On this one I gather (guess) that each subnet has its own dhcp server.

@george1421 ref: https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection/4

For WIN10 you must update the unattend.xml file to include this section. This is an example for the amd64 arch.

    <settings pass="offlineServicing">
        <component name="Microsoft-Windows-PnpCustomizationsNonWinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <DriverPaths>
                <PathAndCredentials wcm:action="add" wcm:keyValue="1">
                    <Path>C:\Windows\DRV</Path>
                </PathAndCredentials>
            </DriverPaths>
        </component>
    </settings>

It depends on how big of a jump between linux versions and what version of FOG you are currently using. But I can say you will probably be happier if you just install a new version of linux and then install a fresh copy of FOG. Depending on the version of FOG you can export the FOG database and import it into your new FOG server then just copy the images between the two. This way if something goes wrong with the new FOG server, you still have an untouched existing one working.