Best posts made by george1421

Can you check 2 places.

1. In the fog configuration settings, there is a timezone settings.
2. You may have to add the timezone value date.timezone in the php.ini file. ref: http://php.net/manual/en/timezones.php

Based on my limited experience with UEFI, IF the bios is in UEFI mode and the legacy ROMS are disabled in the bios AND secure boot is turned off. If these conditions are met then you enter the bios with the USB NIC installed and can see the USB NIC in the selectable devices for booting then that USB NIC should be supported for UEFI booting.

You should be able to press F12 during the bios post test to bring up the boot menu, from there you should be able to select the USB network adapter for booting, it should be in the UEFI section of the boot menu not under BIOS. Again if these conditions are met you must use the ipxe (boot kernel) that ends in efi. Now there may need to be a specific one for that usb driven NIC, you would see this after the file has been downloaded to the target computer as the kernel boots, you may get network communication issues.

@MattPayerle OK so it sysprepped, launched and deployed OK upon reboot. The next step is to introduce FOG into the picture. Repeat the sysprep part, power off the vm and then pxe boot into FOG and capture the image. Then redeploy the image back to the same vm, reboot the system. Since the fog client isn’t installed then none of the fog post install actions will be carried out (make sure the early name change is not enabled too). The expectation of this test is to produce the same exact results as your previous test. If you receive the same oobe results (success) as your first test then go on to the next test.

For the next test you will deploy to a second VM. The expected results is the same as your very first test. In this case you must use your previously captured image (from above) and just deploy to a like Virtual Machine.

Understand this is the same methodical process I would use to find a flaw in my deployments. You need to back up to where you have success and then start moving slowly out to your final design. Once you have a failure then you can identify what changed between working and failure. If the deployment to a second VM works, then you need to introduce the unatten.xml so you can avoid the questions during OOBE.

@jflanagin Ok just a few more questions (I forgot to ask)

6. Since these are different physical locations, what is the bandwidth you have between these locations and HQ.
7. How many workstations do you have total at allocations? And at your largest remote location?
8. How do you deploy your images, do you have a single image that is deployed across all locations or do you have unique images for each location?

While these questions might seem mundane it does add value to get you the best solution.

@doubleailes [Moderator note] Please start your own thread because this thread is over 8 months old and I’m sure your computing environment is not the same as the OP of this thread. In your thread, please include what version of FOG you are using on both the master node and storage node as well as what OS is used on the master node and storage node(s)

I’m wondering 2 things here.

First, if you use another computer can you use tftp client to download that file. We want to make sure the permissions on that boot file is not blocking access. You can use another linux computer or a windows computer if you install the tftp client (built in to windows 7+).

Second, it worked with undionly.kpxe and now with the ipxe.efi it doesn’t. Make sure there is not a blank space on either side of the text in the dhcp server configuration. I’m not seeing anything strange in the pcap files you supplied.

@Joe-Gill You can push out the client (or any msi or exe with an unattended installer) with PDQ Deploy. The free version will work for you. All that is required is the MSI and having/knowing the an account on the target computer that has admin rights. It will take you about 30 minutes to setup pdq deploy and create and deploy your first package. Its not a real big time sync. You can deploy to each machine you define, by machine OU or a custom list you can create. Its pretty flexible.

I do have to say the paid for version is well worth the cost. With the paid for version you can download already created packages for common software as well as create multi step intelligent install scripts (ie switch installers based on target system bits x86 vs x64).

Please search the FOG Project forums. There are several threads on this pxe booting surface pro 4. You can pxe boot these guys but you need to send the uefi kernel to them not the bios (legacy) pxe boot kernel. I think there was also a thread about the keyboard not working with the current FOG kernel, but if you use an external usb keyboard you can move past this issue.

As part of our internal audit program we are required to scan all internal hosts using a SIEM tool to look for vulnerabilities.

Here are several that our FOG server triggered. Understand I’m not implying or forcing anything here only raising awareness to the developers.

1. SSL/TLS: Certificate Expired

Risk: High
Application: https
Port: 443
The certificate of the remote service expired on 2017-02-04 23:55:05.
Certificate details:
subject ...:
1.2.840.113549.1.9.1=#726F6F744073687675786173303439,CN=localhost,OU=SomeOrganizationalUnit,O=SomeO
rganization,L=SomeCity,ST=SomeState,C=--
subject alternative names (SAN):
None
issued by .:
1.2.840.113549.1.9.1=#726F6F744073687675786173303439,CN=localhost,OU=SomeOrganizationalUnit,O=SomeO
rganization,L=SomeCity,ST=SomeState,C=--
serial ....: 00A6
valid from : 2016-02-05 23:55:05 UTC
valid until: 2017-02-04 23:55:05 UTC

I assume this is the SSL certificate used to communicate between the FOG server and the clients. I guess from the clients perspective they don’t care or aren’t checking the validity dates of the certificate in use. Should fog have a process to update this self signed certificate? Maybe something to consider for FOG 2.0?

2. http TRACE XSS attack

http TRACE XSS attack
Risk: High
Application: http
Port: 80
Protocol: tcp
Vulnerability Detection Result:
Solution: 
Add the following lines for each virtual host in your configuration file :
   RewriteEngine on
   RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
   RewriteRule .* - [F]
See also http://httpd.apache.org/docs/current/de/mod/core.html#traceenable
Solution:
Disable these methods.

I’ve added these rules to the /etc/httpd/conf.d/fog.conf file to change the file to this:

    <Directory /var/www/html/fog/>
        DirectoryIndex index.php index.html index.htm
    </Directory>
    RewriteEngine On

    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]

    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d
    RewriteRule ^/(.*)$ /fog/api/index.php [QSA,L]

I’ll know after the next scan if this fix resolved the issue.

The rest of the discovered issues were not related to FOG but system management on the FOG server, such as supporting weak SSL and ssh Ciphers and TCP timestamps. Surprisingly using NFS v3 did not set off a violation alert.

Unless I’m missing something. Your storage node in Melbourne is in th storage group Melbourne. This is understood. But in the Melbourne what is the master node? IMO the Sydney server with ip 192.168.23.10 should be the master node in the Melbourne storage group. The Sydney server can also be a member of the Sydney storage group as a master node. What I see right now (reading the tea leaves a bit) is that in each storage group you only have one device. One group has a master node and storage node with the other group has just a storage node. There is nothing to copy in this setup because each server is in its own group. You need that linking connection.

@Wayne-Workman said in FOG Client Service Updater:

If you go the PDQ route, be sure to include some way to first remove the legacy client. If it’s still there, the new client will not install.

Following Wayne’s instructions then you should create a batch script and deploy that with PDQ Deploy.

In that batch script you will issue the FOG client uninstall command

@echo off
msiexe /X <guid of fog client>

REM then install the new FOG client with 
msiexec /i fogclient.msi <what ever option switches>

@Wayne-Workman Do you think we have enough discrete bits of information to make a wiki page on the surface pro 4? As these devices become more popular I can see the volume of quesitons increase. Having one location (you look here->) would add real value from a support perspective.

@Joe-Gill I don’t know if I have an answer for you on this one. I can tell you that only a full normal mode fog server in a storage group can be a multicaster. If you are running a mix mode where an other device other than a real fog server (with the dabase) is marked as a master node in a storage group, multicasting will not work. Also that ethernet adapter logical name must be defined for that master storage node.

I’m not sure about what password you are changing or IP addresses. But as a test on one of these storage nodes rename the .fogsettings file to something else then rerun the installer. The installer will forget everything about the last install and ask you the questions over again, just reset that storage node as a new storage node pointing to your newly migrated master FOG server. That should be easier then messing with user ids and password on each storage node.

@Wayne-Workman Just looking at drawing a connection here. All three files (kernel, inits, client) are downloaded via wget. If wget is in place then DNS resolution may be another issue. But starting with manually downloading the client agent will give us a better idea of the error.

@MattPayerle Thats great you have it working (sort of).
I’m sure you know this already, but I will state it again. Make sure the FOG service is disabled in your reference image before you sysprep it. Then use the setupcomplete.cmd file and sc to reenable the service. That keeps the fog client from starting its job too soon in the OOBE process.

@jflanagin In your case since you have a 100MB pipe between the remote sites and your HQ and you only have a few hundred computers the best way to set this up is to use a full FOG server at HQ and then FOG Storage nodes at each location. Then within the FOG Master node (at HQ) you will install the location plugin. Then with the location plugin create 4 locations and assign a storage node to that location. Configure the dhcp server at each location to send dhcp 66 and 67 to the local storage node. Your images (that can only be captured on the FOG master node at HQ) will automatically replicate to each storage node. If you update an image at HQ it will automatically replicate to all storage nodes in the same storage group. You will probably want to change the fog client check in interval to be something like 15 minutes or more from the default 5 minute check in to reduce wan traffic. This way there is only one fog server and no need to mess with the FOG config file on the target computers.

@Eric-Johnson While you are way over my head with this coding, I can make a suggestion that may make debugging faster.

1. If you create a /images/dev/postinit script, you can patch (copy over from the FOG server to FOS) /usr/share/fog/lib/partition-funcs.sh on every boot of FOS. You don’t need to unpack and repack the inits. There is an example in the forum on how to patch (replace) fog.man.reg for a custom registration. ref: https://forums.fogproject.org/topic/9754/custom-full-host-registration-for-1-3-4/45

2. At the FOS Linux command prompt, if you give root a password with passwd (just some simple password like hello) and then get the IP address of FOS with ip addr show you can connect to FOS via putty/ssh from a second computer. Of course you need to be in debug mode to do this, but with putty you can copy/paste/debug from your normal workstation.

@bacelo said:

yes, I think so

That is not a reassuring answer. Where do your clients get their dhcp addresses from?
Are the clients on the same subnet as the FOG server?

I can say I use MDT to install fog on my reference images. In MDT I use the following command.

msiexec.exe /i FOGService.msi /quiet USETRAY=“0” WEBADDRESS=“192.168.1.53”

Where 192.168.1.53 is the ip address of the FOG server.

You must disable the fog service on your reference image before you sysprep it and capture with FOG or you will have OOBE boot problems. You will want to enable the FOG Client in the setupcomplete.cmd file to allow FOG to manage the client once OOBE is done.

@sourcaffeine At the bottom of this document: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client search for sysprep.