Active directory Join issue
-
@anthonyglamis Yes, pull new revision, run installer.
The certs and CA carry over.
-
@Wayne-Workman I just updated my revision, reinstalled fog. Tried to deploy the same image that was successful 3 times today and I received an error "no disk passed (runPartprobe)
Thoughts? I checked out this thread however I am not capturing and image, I am attempting to deploy a known good image (at least before a revision upgrade and reinstall of fog).https://forums.fogproject.org/topic/6535/windows-10-capture-deploy-woes/2
-
@anthonyglamis I think this is a bug. Tom’s doing a whole lot of work/improvements on the upload/download scripts at the moment.
-
Update. Earlier I was successful deploying an image to 3 different laptops. These were for my Austin site. I just tried to deploy the same image to another laptop for my Austin site, and the authentication errors have returned. This is kind of blowing my mind. I am on revision 6124. I’m not really sure why I was successful 3 times and now the CA chain is broken. This is interesting.
More updates. I have 2 images, both are for my Austin sites. 1 is a baseline, the other has printers already set up as TCP/IP ports. The image with the printers is failing. The log is returning Authentication errors as stated above, and the hostname changer did not work either.
I decided to try the baseline image. The hostname changer worked. I have a “switch user” option and my domain is showing up as an option to log into. I try to login and it says “The security database on the server does not have a computer account for this workstation trust relationship”. I did stage the computer in my default directory OU before deploying the image. The log is still stating that the CA cert validation failed. Could not authenticate. -
@Wayne-Workman Is there any way to get this post categorized as “unsolved”? I am still having issues.
-
@anthonyglamis said:
“The security database on the server does not have a computer account for this workstation trust relationship”.
Check to see if your image is already bound to the domain.
Also, inside of your /opt/fog/.fogsettings file, make sure there is not two fields for
CaCreated= -
@Wayne-Workman Wayne, thank you for the reply. I apologize but what do you mean by “bound to the domain”? This is what my .fogsettings file looks like.
Created by the FOG Installer
Version: 6124
Install time: Thu 14 Jan 2016 04:05:49 PM CST
ipaddress=“192.168.1.243”;
interface=“eth0”;
routeraddress=" option routers 192.168.1.1;“;
plainrouter=“192.168.1.1”;
dnsaddress=” option domain-name-servers 192.168.20.5; “;
dnsbootimage=“192.168.20.5”;
password=“0ea409”;
osid=“2”;
osname=“Debian”;
dodhcp=“n”;
bldhcp=“0”;
installtype=“N”;
snmysqluser=”"
snmysqlpass=“”;
snmysqlhost=“”;
installlang=“0”;
donate=“0”;
fogupdateloaded=“1”
submask=‘’
blexports=‘1’
storageLocation=‘/images’
storageftpuser=‘’
storageftppass=‘’
docroot=‘/var/www/html/’
webroot=‘fog/’
caCreated=‘’
startrange=‘’
endrange=‘’
bootfilename=‘’
packages=‘apache2 php5 php5-json php5-gd php5-cli php5-curl mysql-server mysql-client tftpd-hpa tftp-hpa nfs-kernel-server vsftpd net-tools wget xinetd sysv-rc-conf tar gzip build-essential cpp gcc g++ m4$
noTftpBuild=’’
notpxedefaultfile=‘’ -
@anthonyglamis said:
caCreated=“”
@Tom-Elliott will need to confirm/deny if that is right… normally when the CA has been created, this is set to
yesand if it’s blank, this might be why you get authentication errors every time you update… because it’s remaking the CA every time. I’d say it’s probably safe to type yes inbetween those quotes.In my /opt/fog/.fogsettings file, the yes is between double quotes. like this:
caCreated="yes";About the image bound question, that’s just a generic term I use, “Bound”. Meaning already joined to a domain. In the Apple world, it’s called “Binding”… but anyways…
Download your image to a computer, but before you do, disable domain joining for just that particualr computer. You can do this from the host computer’s menu on the left, there’s a link labeled “Active Directory”, in there you can just uncheck the “Join” checkbox and then save that, then deploy your image to this machine.
After it’s deployed, just look to see if the computer is already joined to the domain or not. If it is, that’s what’s causing your trust relationship error.
FYI, never capture from a computer that is joined to a domain. Good advice: Never capture an OS build from a computer that has ever been joined to the domain. Joining mucks with settings on the image and all you’ll be doing is begging for complications down the road, even if you later unjoin it and then capture.
-
@Wayne-Workman Thanks for the quick response. Yes the image baseline I used was at a certain point on the domain. I removed it from the domain in order to create a baseline as I do not have a volume license with Microsoft so I have nothing else to go off of. I can try a new windows 7 license though. I have one copy. That might be my best bet. Start from scratch.
I am deploying the image now as you suggested. With the new client 0.9.10 do the new clients intended to be deployed and auto joined to the domain need to be created in AD before deployment? -
@anthonyglamis said:
With the new client 0.9.10 do the new clients intended to be deployed and auto joined to the domain need to be created in AD before deployment?
No. When they join, they will appear in the default OU, whatever that’s configured as. On an unchanged AD setup, this is the “computers” OU. I always change mine though.
-
@Wayne-Workman So what if I restore one of my laptops to factory default? The reason I say is we don’t use WAIK, or sysprep. Let’s say I create a master golden image, but it is time to update it for instance adding an additional program. Once the image is created can I manipulate it if I ever had to?
-
@anthonyglamis said:
Once the image is created can I manipulate it if I ever had to?
In a way, yes.
You’d un-check the domain joining checkbox for a host, download your image, make your changes, and then re-upload.
When you re-upload, if you do not change the image assigned, it will write over your old image. You can create a new image and assign the new image to the host, and upload to that if you want. That way lets you keep both the old image and the new image - but it takes up space. This is what I do, if you were wondering. Space is cheap.
-
@Wayne-Workman Just deployed my image. I unchecked add to domain and it imaged and did not join to AD. The log output states: “Authentication error. CA is not from the fog server”. Any suggestions on next testing steps?
I can attempt to perform a factory reset for my most heavily used model, build an image, install the client service , register the host and capture. -
@anthonyglamis No need, just uninstall the fog client and then reinstall. Reboot a few times and see if the errors go away.
Make sure you set your /opt/fog/.fogsettings caCreated to yes so this doesn’t happen again.
Also, I forgot to ask earlier, but is there a reason why your fog ftp credentials are blank in that file?
-
@Wayne-Workman I updated the .fogsettings file to reflect “yes”;
The ftp credentials were left blank upon install. If I change this does it also have to be changed on the fog server? -
@anthonyglamis yes. There’s a article all about ftp. “Troubleshoot FTP” in the wiki.
-
@Wayne-Workman Currently I am not receiving an error file not found, but I assume I want a password in that field for added security. Thanks again for the input.
Now I am curious. Would FTP mismatch in credentials cause the error “image store corrupt”? I know what happened. The d1.mbr file was not created on that image. Duh…at least I’m starting to recognize some of these issues. Capturing again. This time I am trying Single disk (re sizable)
-
@Wayne-Workman I just finished reading your post and the FTP WIKI. I apologize I don’t think I was understanding what you were referring to. So in my storage node settings the FTP path must match, as well as the user name and password. Thanks for the heads up. I have updated all the info. Straight from the WIKI.
Web Interface -> Storage Management -> Your storage node -> Management Username & Management Password Web Interface -> FOG Configuration -> FOG Settings -> TFTP Server -> FOG_TFTP_FTP_USERNAME & FOG_TFTP_FTP_PASSWORD The local 'fog' user's password on the Linux FOG server /opt/fog/.fogsettings -> storageftpuser & storageftppass (For recent FOG Trunk versions only. 1.2.0 does not have this setting. 1.3.0 will though.) -
@Wayne-Workman @Arrowhead-IT @Tom-Elliott
Just wanted to update. I noticed the capture on my “golden” image yesterday did not capture or create the 1d.mbr file. I updated Fog today to the latest revision, 6136 (I just noticed there is another) recaptured, and checked for the 1d.mbr file and to my surprise the d1.partions file was there as well. Fog deployed this image to another laptop with success as well as auto joining to AD. I think I am getting the hang of Fog. I want to test a few more platforms. I will update, and if successful we can set this thread as solved!
Once I determine that capturing and deploying is stable I will perform my own write up. I understand that most of the info is in the WIKI, but some of it is outdated. The instructions still list fog 0.32, which if you remember the beginning of this thread, that’s what I started with
-
@anthonyglamis said:
Once I determine that capturing and deploying is stable I will perform my own write up.
Good documentation is a vital part of any software solution - open source or not.
So is a helpful and acive forums
