I can see issues where IT installers are getting confused between the default admin console login of fog and the linux user fog used for back end services.
Recommendation: Either change the default gui login from fog/password to admin/password or change the back end account from fog to something like fogsvc or some other method as long as there is a distinction between the GUI login account and the back end service account.
It would be interesting to know what if anything is posted to the /opt/fog/log/taskscheduler.log when one of these scheduled events are missed. If its not in there, one might think one of the logs would say what just happened. This is very strange that “nothing” happens.
You might want to check to see if the fog task scheduler service is running. I might be able to understand if the scheduler is not running. The web gui looks at the database where the scheduled task is run. It calculates when it should run and displays that to the user. So the time line is correct from the users perspective. Its just the task never kicks off on the back end. This is all speculation, but it sounds logical.
as for updating your host file something as simple as
echo "192.168.1.40 fog_server" >> c:\windows\system32\drivers\etc\hosts in a batch script should add the reference to the host file.
If you have a number of entries saved in a text file you could use something like type hupdate.txt >> c:\windows\system32\drivers\etc\hosts to update the file.
Disclaimer: I have not tested the commands above, they just came to me as I was typing, so YMMV.
@fry_p Just messing with you about the windows storage nodes. But in the end its not a practical solution.
The 990s would work great for you. Depending on the total size of your images I might even throw a small SSD drive in that 990 instead of the 750GB disks, unless you already have the disks then recycle as needed.
For multicasting to work your switches at the sites must support igmp snooping to allow easy access to the multicast stream. Multicasing is typically blocked over wan links (as you found out).
You can do the hyper-v route as Wayne suggests. In a typical FOG image deployment the FOG server just moves files, there are no heavy cpu requirements for the FOG server. I was going to recommend a Intel NUC i3 or i5 for this setup. That coupled with a 250GB SSD would make a very nice deployment server.
Since you have 10 sites, I would configure a FOG storage node just as another client computer as you are creating each FOG server. I would then make a mother image and upload to FOG. Then deploy these 10 990s as just another client. If one fails just spin up a new 990.
@Wayne-Workman OK, lets take a hacker approach here (this is more of a concept than an action). Also I’m not going to give you answers only places to look. If I told you to do this, click that you would only be parroting my instructions and not learning.
Also understand my kernel knowledge is about 10 years old. I’m sure almost everything applies still today.
First of all, you will need to load the kernel development tools for your linux platform. There should be an installation package group for kernel development. Go ahead and install that on your test system.
Once that’s installed we need to do a little reverse engineering. First you need to see how Tom builds his kernels. Not knowing Tom (hacker principals), so you can’t ask questions you’ll have to research a bit. The first thing you will want to do is see if you can (precisely) duplicate his work. For that you need to look at a current bzImage file. Run the file command to find out what linux kernel he used.
Knowing this (assuming he hasn’t messed with the version number because its totally possible) goto kernel.org and download that same linux kernel version. That archive file typically should be expanded to something like /usr/src/kernels.
Now once that kernel has been extracted, you’ll find out you need a config file that sets all of the options to build the kernel. (what you want to do here is to duplicate what Tom does when he builds the kernels). I’m sure if you poke around the fog project github you will find some TomElliott.config files. This should be just a huge text file with a bunch of Y and N settings with a few M scattered about. You will need to copy that to the proper location and probably need to rename it to the proper name. Right now there is no way to know if Tom has patched this official kernel.org kernel, so we have to assume no.
Once you have all of the bits in place, with the kernel dev tools installed all you should have to do is issue a make all command to build the kernel from the source. With any luck the compiler will compile the kernel without error. If the compiler ends without error, the built kernel should be in… that linux source path somewhere in/below boot. What you want to do is see if the compiled kernel is relatively close in size to what Tom makes. If its close then upload that to your dev FOG server and see if it boots.
Once you have a working build environment then you can start experimenting with that config file removing unwanted drivers and adding in the ones you want to deploy. There is a C code header file that contains the kernel version, you might want to update the minor version with something like -WW or what ever so when someone lists out the kernel version you can tell is a WW special.
@mitzayapa First I have to say, if you have a problem with release of a trunk version you should post it here. The debug cycle is very short with the fog project. Your issue could have been resolved since there are typically updates daily. The only way we can get to a stable very faster is to have people help with the debugging phase, then everyone wins.
As Tom noted below the all versions of the 1.x.x support quick image, so your 1.2.0 stable release supports it. What 1.2.0 doesn’t support will is uefi and gpt disk. If you need those and are unable to use the trunk build then you will have to wait until 1.3.0 is officially released.
@adukes40 said in Windows 10- moving from 1511 to 1607 in audit mode?:
mainly backgrounds, colors, Lock Screens, and start menu.
The backgrounds, and colors can be set in the admin account, and then when you sysprep the system reference your unattend.xml file with the copyto setting in the unattend.xml file to copy the settings from the admin account to default user.
As for the start menu that one is a bit tougher and we are still struggling with that one. But basically you need to either create the perfect start menu on a test computer and then export the configuration to an xml file and then have it setup to that when a new user logs into a win10 system the exported menu xml file is imported into the user’s profile. You can also set a registry key to point to this xml file, but it restricts the user from changing/customizing their own menu.
The current security plugin (if it still exists) is very immature and not ready for a production environment. The current way FOG is designed (internally) is not geared towards security at all. You (as a fog user) are either a mobile deployment user or a fog admin. There are no levels of admins or controls of what certain admins can do. This is a bit unfortunate, but it is the current state of the system.
While this is all vaperware right now FOG 2.0 will be built on a tight security model with multiple keys and locks to areas inside fog. But this product is several years off at this point. FOG 1.3.x will be the last in this development line using the LAMP foundation.
With FOG 1.3.0 you can protect images to a certain point where the images can’t accidentally be overwritten. But as an admin you can purposely go in and remove the protection from an image then upload. So if you have an angry admin they can damage the fog system pretty quickly.
@Junkhacker I’ve been meaning to respond to Junkhacker’s post for… about 13 days now.
I agree this would be a very useful function. Along the same lines as Wayne pointed out. If we could twist the groups a bit to make the settings persistent. In the Host detail record, have a template (or group) field. To where you can link the host to a template record. Beyond that something could be setup like how some of the front ends for nagios works. In these there is a template list, and then when a template is selected the data fields update to the template settings. If you want to override a template setting you just uncheck the inheritance check box and enter a device specific setting. (I’d include a picture, but I have no clue how this editor handles picture imports)
That is a nice to have feature, but having a persistent group template would help out. In my case based on different image types I have workstations going into different OUs. This is also the case where I have the same image that is deployed at different sites. These sites have their own computers OU. Right now I have to image the computers to a transfer OU and then manually move them into the right container. I could do this on the windows/unattend.xml file if I could get fog variables into the FOS deployment environment (different feature request).
I’m a bit confused on comment of Tom S, his post implies there is some level of group persistence. If this is the case, why can’t we see the persistent settings when we review the group. Or are only bits of the group properties persistent?
Just to add some info to this thread.
If you don’t have a live linux distribution in mind, the Ubuntu 15 desktop version has a live boot option.
http://releases.ubuntu.com/15.04/
Once booted into the desktop use the search function to find terminal. That will open a console window for you.
@eseelke The what I would recommend is that you create a generic “windows 7” image and then inject the proper drivers during imaging. You don’t want/need the fog client since you won’t be connecting the built computers to AD/renaming them or any of that.
The hardest part will be collecting all of the drivers for each random hardware model. These drivers need to be in INF format and not the drivers that use the automated .exe installers. For Win7 to detect the drivers in C:\Drivers the files need to be in that directory in INF format and for you to update the registry key either through the deployment process or before image capture to have windows look in that folder first for drivers and then in the c:\windows\inf folder.
@mm-Ekimia Just thinking out loud.
If I understand the situation correctly, you want to image 20 disks in some kind of batch using a single computer?
You could do this with FOG and pxe booting if your drives were connected to your target computer using an external sata dock. You would have a single host registered in FOG and have the primary disk setup to point to the SATA dock. You would pxe boot the target computer (or use usb boot) and then still pick quick image to deploy the image to the hard drive connected in the sata dock.
@Jbob I was so excited until you said fog 2.0… 
I can see the “hierarchy of priorities” will work something like how the GPO policies are applied in that higher level groups can overwrite settings of lower level groups. SO that will work just fine.
But again no joy for use who need it today with the 1.3(ish) release. Fog 2.0 sounds really nice. 
@Arrowhead-IT I started putting together a how to last week so @Wayne-Workman can create a wiki page. Let me get a link to that document.
Here is the outline. Both methods work. I wrote the document from a brain dump, so the instructions may have a few kinks but it does work.
https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fog
Yes I’ve seen this before.
You need to add this to the unattend.xml file for Win10
<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:\Drivers</Path>
</PathAndCredentials>
</DriverPaths>
</component>
</settings>
Or where ever your install files are kept. The registry change was last officially supported in XP, and with Win7 they did keep that function in the system for legacy reasons. With Win10 that option was removed. You MUST use the unattend.xml method now.
@mm-Ekimia Its a bit easier than that.
You would take a single host with a sata dock. Inside the FOG Engine (linux OS that deploys images) the sata dock might have a /dev/sdc definition.
Register the host (once) and then manually change the primary disk to /dev/sdc
Insert new hard drive in the sata dock
PXE boot the deployment computer
Select quick image (assuming you are using FOG 1.3.x)
Image is deployed to the target hard drive (on /dev/sdc)
power down the target deployment server
Repeat the process at step 1
I looked in the database and could not find where the groups actually saved the settings (like ou path). If the existing group function actually saved the values that were set it would be a much easier task to patch. From what I can tell, when you go into the group function and change a parameter, it goes through each device and sets that value. But in the end it does not save that value anywhere. Again, if it saved it at the end of the update, I’d be golden.
(ps I was aware of your thread, but I didn’t want to pollute it with my jibber-jabber).
Ok from what I understand your fog server is behind a proxy server, right?
If that is the case you need to set (export) the environment variables to define your proxy server. Also you will need to update the settings in /etc/wgetrc (if you forget this you will not get the kernels and inits).
As I see you are using svn then you probably have the proxy servers set in /etc/subversion/servers
Here is what I have exported in /etc/bashrc
export http_proxy=http://<proxy_server_ip>:<proxy_server_port>
export https_proxy=http://<proxy_server_ip>:<proxy_server_port>
export ftp_proxy=http://<proxy_server_ip>:<proxy_server_port>
export no_proxy=<fog_server_ip>
You didn’t happen to mention what OS you are using here for rhel based (rpm/yum) you need to update /etc/yum.conf with your proxy server setting too.
@Tom-Elliott Do you think we should have the OP setup a debug capture/deploy to get the output of lsblk ? This way we have a solid idea what the partition structure looks like?
It could also be akin to the issue that you coded for in the postinstall script where the disk structure is a bit different between win7 and win10. On win7 p2 was the 
drive and on win10 p3 was the drive.
@mm-Ekimia No would have to power off and pxe boot each time. But the booting process is very quick about 10 seconds. Plus you don’t want to just unplug a disk from linux bad things will happen.
You will also want to use sata over usb since its referenced differently in linux as a different device.