Active directory Join issue
-
@anthonyglamis to add on, what you see by default in that field is how big a disk (approximately) you need to be able to image. The way it’s populated is as Wayne stated, through imaging tasks. There is also a field that, by default now, is hidden and will show how much space on disk it will use. If you enable viewing of the image, it should show a size which would then show you how much server disk space it’s using.
-
Come to think of it those images have the previous client service from 1.2.0, I’m guessing I will want to update the client service and capture again?
-
@anthonyglamis yes.
-
@Tom-Elliott
Do you need any information from me concerning the images I have that did not create the d1.mbr file? Just asking as I have to update the Fog server and start recapturing new images with the latest client. I essentially have no use for the previous images I created. -
OK so I’m having a brain fart today. I wanted to update to the latest version. I ran the install.sh and it rolled me back to 6032. Where is the latest version located?
Never mind, I was in the wrong folder. I am back on 6038, but would still like to upgrade to the latest version. I thought the installer would update.I used this link and SVN
-
@anthonyglamis if you are using svn to manage the trunk package, you change into the trunk folder and run
svn upthat will download the latest code from the subversion repository. Thencd binand then./installfog.shIf you are using git they have a comparable update command.
-
@george1421 Thanks! I completely missed that step.
-
@anthonyglamis I like scripting things. And I like sharing. Here’s how I do my fog updates with one command.
If you stick with svn, you can just change the git function in the script to do svn up instead of git pull and change the path variables too in the variable setting function. Or just use git, because sourceforge likes to crash.
https://forums.fogproject.org/topic/6331/automating-git-updates-for-fog -
@anthonyglamis you can but the new client is actually msi and has support for cli arguments to define configuration of the client. This means you can create a GPO to install the new client. Of course you still have to remove the old client first but I believe there’s a forum posting that discuss how to do this.
-
OK update time. I updated Fog to 6048. Captured 2 images with updated client service. Operating systems are Windows 7 pro. Models are Lenovo E431, and Dell Latitude 3450. The d1.mbr file was captured for both images.
The Dell 3450 just finished, however it did not join to AD. Attached is the log. I am getting an authentication error again. Not too sure what I might be doing wrong. I reset the encryption data for each host before the capture. I noticed that is an option in the group setting as well. Should I have done that?
0_1453407792520_3450fog.logThe Lenovo E431 partclone process didn’t even start. The error is “problem opening# Error is 2” Partition file missing /images/E431I3/d1p.img* the specified file does not exist.
In my /images directory that file is there, but it is named as follows:
itadmin@fogserver:/images/E431I3$ ls
d1.fixed_size_partitions d1.original.fstypes d1p2.img
d1.mbr d1.original.swapuuids d1p3.img
d1.minimum.partitions d1p1.img d1.partitions
Is this just a matter of renaming those files to what fog is looking for? Lol it will not boot not since the initial partclone process wipes the mbr. I’m bricking things left and right! Woop Woop! -
Updated to Fog 6050, installed the latest client service and installed the certificate from my server in my certificate store just to be sure. The dell 3450 instantly rebooted and joined to AD. I am starting over from scratch with new cert and client installed. Am taking two more captures now, and will deploy as soon as I’m done. Operating system Win 7 Pro, models are Dell3450-I5/Lenovo E431-I3.
I will update if these images work and join to AD. -
Apparently I have no idea what I am doing. I captured both images, tried to deploy them and I get this error
“an error has been detected no partition type passed (perform non resize restore)”
I don’t get what I might be doing wrong. Any ideas?The Dell 1d.mbr is 32Kb
Upon inspection of the d1.mbr file for my Lenovo E431 captured image it is 1 MB according to the Fog Wiki it should be 32 KBThe option Single disk, multiple partition will manage to upload/deploy all the partition of the disk. The OStype setted to Linux will copy a 32256 bytes MBR.
NOTE: setting a Windows 7 OStype, will clone a 512 bytes MBR: at the boot the system will show the string GRUB and then will hang!
With this configuration, after the image upload, in the directory /images of the fog server there should be a directory with the name selected for the image containing:
d1.mbr (the MBR: should be 32256 bytes) d1p1.img d1p2.img d1p4.imgthere are 1 file for partition, with the exception of the swap partition.
-
I realize you had a long and troubled day. So my questions may put you over the top.
Can you create a truth table from your testing thus far? (dell, full disk cap = No, dell, resizeable cap = Yes, Lenovo =No) there has to be some rational here.
Do you have one system that you can capture and deploy successfully?
Your issues are seeming to be multiple. The first is of course capture and deploy and then once deployed connecting to AD.
Its not clear quite yet in my mind is your issue with the new way fog is trying to capture images or the hardware them selves. Both of these systems are pretty new with new next gen components. If they are not reliable, do you have older systems you to setup a baseline with? I have seen recently with some of the newer lenovo, they have a built in small hard drive (16GB in size M.2 SSD) that seems to be causing some capture issues with other people. I’m not saying that is the issue with your lenovo its just one possibility.
-
@george1421
George it is odd to say the least. The images are indeed capturing but I’m really not sure how fog captures them, and if the problem lies there. In the images folder the 1d.mbr mbr file as well as all respective partitions are there. When creating new image I am choosing #2 single disk multiple partition. Next option #1 everything. Deploying fails every time.
The reason I am doing 2 different models is obviously for testing. I want to replicate errors or success across more than one platform.
In all reality I should be focused on the Lenovo E431 platform because the company I work for has these deployed the most. So it will be beneficial for me to get this image working. I am new to Linux so I am learning but I am certain I can pick this up.
After a capture why would fog fail if I am trying to deploy to another CPU that is the same model platform? Is it not capturing a complete image in general? That is my guess.
To answer your other question I have been able to successfully deploy images but those were all in older versions of fog. I have since updated to trunk. The AD/client service is working now, just not the imaging process.
I apologize if I didn’t answer all of your questions in full detail. -
@anthonyglamis are you running the latest trunk?
-
@Tom-Elliott I am running 6050, but will update today to the latest.
-
@Tom-Elliott I just updated to 6064. Do I also need to download the client every time there is a new revision?
-
@anthonyglamis Nope. The installer will auto download the latest client to your server and you don’t need to maually update your hosts with the new client. I think it’s supposed to update itself even, if I remember right
-
Update. I reran the deployment of the 2 images I captured and they imaged on both models.
They did not auto join to AD though 
I am receiving the same authentication error in the log. This is odd as before capturing both images I installed the client service 0.9.10 as well as the certificate from http://192.168.1.243/fog/management/other/ssl/svrpublic.crt
Post deployment I uninstalled the client service, and removed the log file. Restarted. Installed the client service again. Restarted, and they auto joined to AD. Obviously I only did that for testing purposes. Am I missing something in the pre-deployment phase?
Should I have reset the encryption data in Group Management? -
@anthonyglamis This sounds like a client issue, any thoughts @Jbob