@astrugatch Thanks for pointing us to JAMF as example for CA/cert management with clients. It’s been a while but I had this on my list of things to do/check and now I got to it.

JAMF can be setup to use different CAs/certs: https://docs.jamf.com/10.0.0/jamf-pro/administrator-guide/PKI_Certificates.html

That page led me to the so called Simple Certificate Enrollment Protocol (SCEP) which does handle some of the things that come with certificates. But the initial problem of establishing a CA trust is still the same - described in section 5.5:

Before any transaction begins, end entities have to get the CA (and possibly RA) certificate(s) first. Since the requester may have no CA certificates or CA public keys at all, this message can not be encrypted and the response must be authenticated by out-of-band means.
[…]
If the requester does not have a certificate path to a trusted CA certificate, this fingerprint may be used to verify the certificate, by some positive out-of-band means, such as a phone call.

Let’s assume the situation where the clients already trust the built-in self-signed FOG server certificate. We could use that to establish a trusted communication channel and send the new CA certificate to the clients and tell them to install and trust it. Definitely a possible route. But what about clients that are switched off at that moment? We would need allow clients to use both CA trusts over a period of time till all of them have moved to the new one. This is definitely possible but complex to implement and I wouldn’t find the time although I find it interesting and challenging.

Trying to digg a little deeper if and how JAMF has solved the above mentioned trust problem when moving from one CA to another I found those notes in the manual:

Note: By default, Jamf Pro uses the signing and CA certificates for the Jamf Pro built-in CA. You must replace these certificates with the ones for the external CA when you initially set up the integration.

and

Note: If you need to make changes to your organizational or third-party CA in Jamf Pro, it is recommended that you contact your Jamf account representative. Changes to the PKI could lead to re-enrolling the mobile devices in your environment.

Now let’s look at the other situation where no clients have been pinned to the FOG server yet. If you re-compile the client to check on a different name in the CA cert you can happily use external CA certs without an issue.

Thank you. I’ll look in to it.

@george1421 Fog is a waaaaaaayyyyyyyyyyy better fit than Zenworks at the moment, it images 4x faster and its more stable. Fog is actually working very well without these refinements that I want to do 🙂

@Tom-Elliott Ouch. I feel silly now. That was totally the issue. Thanks!

Your Fantastic! My system admin and I have been going through as many settings as we could find this week. The Dnsmasq solved it!

Please mark as read

@emryz @ragnurenson From my point of view it’s all working fine. See the screenshot below. You are right that the power management task is not in the scheduledTasks table. I was on the wrong track with that when I had a brief look at this last time. As mentioned by @emryz the power management tasks show up in the same view where you schedule those for the host. See my screenshot below.

@emryz I can imagine that some kind of AdBlock add-on in the browser could make this view disappear. We had a very strange case where one single text field was missing just because of an AdBlock add-on. Please disable these and see if it works for you.

Note: I corrected my other post so when people come along and find this, they don’t get confused.

laa.jpg

I need to deploy the image I created from the virtual machine (legacy) onto uefi is that possible or do I need to create another image?

@george1421 Okay so 19.1 seems to work great, on my desktop. The only thing I had to do different was change the permissions on the 19.1 folder since it locked it down to root but that was most likely from me running the terminal in “su” I’m guessing.

For some odd reason the laptop I’ve been using to test these does not want to boot it still and I am not sure why, it boots the Windows and Debian installers fine which is odd. It is plugged in with an ethernet cable the same as the desktop. I’m guessing this may have been giving me some of the issues in the past but I did double check on my desktop before posting and it was not going in my case.

I must be missing something in Mint 19 v2 but I’m not going to worry about it at this point since 19.1 is working great. I am doing the install right now and it so far is having no issues.

Thank you for all your help and if I figure out what the issue is with the laptop I’ll be sure to share in case anyone else happen to come across a similar issue.

Cheers
Ben

SOLVED
Thanks guys, once the certificates were copied to the fog2 server, AD join started working

Yay 🙂

@Sebastian-Roth yes, the esxi host has a NIC on each network. I am attempting to get the network to allow access to an single IP in the management for each lab so I can just use the 066 DHCP option to point to the interface that works for TFTP which I believe is the way the guys that are doing similar setups are making it work.

@jameto333 I have a little experience in installing similar programs with snapins and am familiar with Sketchup Pro. May I ask which file format you have the installer (exe or MSI)? Also, may I ask which type of licensing you have?

Hi @linuxba ,

I have the same esnario in my university. I can tell you a workaround to solve this or how we solve this problem in our university.

Create a complete image of your dual system:
Imagen name: Dual_Image
Image type: One disk not resizable
OS: windows 10
Partitioning: Everything Upload it to the server. FOG will create you a new folder in /images, in this case:
/images/Dual_Image
This folder has the different partition files, for example: d1.has_grub d1.mbr d1p1.img -> UEFI or boot partition d1p2.img -> windows system d1p4.ebr d1p5.ebr d1p5.img -> Ubuntu parition d1.partitions Now we will create a new image definition:
Imagen name: Ubuntu_Partition5
Image type: One disk not resizable
OS: windows 10
Partitioning: Partition 5 This step in not necessary but I recommended you. Assign this image to your PC and upload this image. In this way FOG will create you the folder in the server, /images/Ubuntu_Partition5. Connect to the server via ssh cd /images/Ubuntu_Partition5. If you don’t do the 4 step, you need create the folder and give permission 777. erase the file d1p5.img and do a soft link:
ln -s …/Dual_Image/d1p5.img .
You can do, if you want, more soft links to the other files: d1.has_grub, d1.partitions, …
With this method, is a little rustic but practice, you only manage one image, Dual_Image, because with the links the Ubuntu_Partition5 is updated automatically.

In our university we have windows images and dual images, with different disk sizes but, at last, the d1p2.img and d1p5.img files are always the same. Updating the windows images and ubuntu images, I update all images versions (for small disks (160GB), big disks (500GB)).

If you want to recovery only the linux partition in one PC, assign the Ubuntu_Partition5 image to the PC and deploy it.

@elementalwindx said in First time FOG user needs help:

I’m used to just uploading a couple .wim files

Well we were spot on until I hit this line. WIM files are windows only (there are wim file readers for linux but they are not as efficient as Partclone that FOG uses). To use FOG you need to capture your reference image with FOG if you want to deploy with FOG.

The core differences between MDT/WDS and FOG is that FOG is a (disk) block level cloning tool where MDT/WDS is a file level cloning tool. Both have their advantages and disadvantages. Generally block level cloning is faster than file level cloning. For reference I can push out a 25GB fat image to a target computer is under 4 minutes. Or to say it another way I can go from a bare metal system to a computer running windows setup/oobe is about 6 minutes. Then depending on the system OOBE runs for about 11-16 minutes. So roughly more or less 20 minutes from bare metal to a workstation ready to move to the user’s desk. Try doing that with MDT/WDS or SCCM. Understand there is a lot going on here outside of FOG (which is involved with imaging for only 4 minutes of the 20)

I have a tutorial that shows how to boot most other OS kickstart images (ISO). There ARE posts in the FOG forum that show how to boot Hirens iso images too. For your windows deployment its best to build a golden image and deploy that instead of trying to load windows setup via fog (which can be done). The rest of your requirements are already built into FOG’s base code.

ref: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

I would admit you are absolutely correct. I should not have put the local admin into the group…

I was finally able to get back in. I appreciate all of your help!

@NT_Tech Access control is a plugin now which has much more use than the “mobile” vs “non-mobile” account.

FOG was indeed a single user system, from it’s original startup. The only thing that kind of made things different was the mobile interface.

I want you to understand, mobile interface was it’s OWN element from the main interface. This meant having to update two GUI platforms to ensure all functionality was maintained. When moved to a single interface that could do both mobile and full screen usages, I removed the “mobile only” user type.

I want to stress, while it wasn’t necessarily intuitive, even in 0.32 a “mobile only” user had exactly the same level of usage as the full admin users. The GUI access was limited and didn’t allow a mobile only user to see anything, but a mobile user could delete items, change things, etc… if they knew the url pathing and calls. They couldn’t see it, but it was not “limited” in the way you thought it was. As the access control plugin was created and managing a single interface made updating and keeping things in a more testable and common way, I decided to remove the “mobile only” option. This was not intended to hurt people who were using the element, but rather there were better things in place that did far better at controlling the scope of things and in a more granular and appropriate fashion.

@george1421 Thanks, with this commands above i was not presented to enter password, thanks.

@Sebastian-Roth Sorry, I completely forgot about this. Just updated to latest kernel on my server and tested on 1803, worked perfect. Thanks for the update.

Your dnsmasq configuration is not complete. It only addresses bios based systems. My recommendation would be to follow and use the dnsmasq configuration from this tutorial exactly. Don’t just patch your’s to match: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

I just tested using my api token for slack running the working-1.6 version of fog and am not seeing an issue.