Windows 10 EDU 1709 Domain Join Doesn't Work
-
@jay-bosworth Mind trying:
sudo apt-get purge $(for tag in "linux-image" "linux-headers"; do dpkg-query -W -f'${Package}\n' "$tag-[0-9]*.[0-9]*.[0-9]*" | sort -V | awk 'index($0,c){exit} //' c=$(uname -r | cut -d- -f1,2); done) -
Reading package lists… Done
Building dependency tree
Reading state information… Done
Package ‘linux-image-3.13.0-66-generic’ is not installed, so not removed
You might want to run ‘apt-get -f install’ to correct these:
The following packages have unmet dependencies:
linux-image-extra-3.13.0-135-generic : Depends: linux-image-3.13.0-135-generic but it is not going to be installed
linux-image-extra-3.13.0-24-generic : Depends: linux-image-3.13.0-24-generic but it is not going to be installed
linux-image-extra-3.13.0-57-generic : Depends: linux-image-3.13.0-57-generic but it is not going to be installed
linux-image-extra-3.13.0-58-generic : Depends: linux-image-3.13.0-58-generic but it is not going to be installed
linux-image-extra-3.13.0-59-generic : Depends: linux-image-3.13.0-59-generic but it is not going to be installed
linux-image-extra-3.13.0-61-generic : Depends: linux-image-3.13.0-61-generic but it is not going to be installed
linux-image-extra-3.13.0-62-generic : Depends: linux-image-3.13.0-62-generic but it is not going to be installed
linux-image-extra-3.13.0-63-generic : Depends: linux-image-3.13.0-63-generic but it is not going to be installed
linux-image-extra-3.13.0-65-generic : Depends: linux-image-3.13.0-65-generic but it is not going to be installed
linux-image-extra-3.13.0-98-generic : Depends: linux-image-3.13.0-98-generic but it is not going to be installed
linux-image-generic : Depends: linux-image-3.13.0-135-generic but it is not going to be installed
E: Unmet dependencies. Try ‘apt-get -f install’ with no packages (or specify a solution). -
@jay-bosworth Now try the
sudo apt-get install -f -
Same error about the disk being full. I’ll be honest, I am not sure what is safe to delete and what isn’t from the boot volume to free up more space.
-
@jay-bosworth I’m working off a totally different error at the moment, but please try:
dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge -
I apologize, I made the boot partition small to leave more room for my images and now I see that was a mistake. I moved some of the files manually from the boot partition to my images partition and ran the apt-get install -f and it ran okay. I then proceeded to run the fog install again. It worked this time, I am going to update my client now and grab my images, then re-deploy them to see if the update fixed the AD issue.
Thanks!
-
I checked and the client version was the same as the one I was already using. I clicked the button to clear the encryption data and I pushed out my sys-prepped image again. It still did not automatically join to the domain. I have a lab of these that I really don’t feel like typing in the AD info for every one.
-
@jay-bosworth did you provide a clients fog.log?
-
Why don’t you join the domain from the sysprep answer file?
https://technet.microsoft.com/en-us/library/cc730845(v=ws.10).aspx
-
No, I didn’t provide the file. The file actually isn’t changing. I went back in and looked and the last entry in the file had the same 9:00 time stamp that the previous file I sent you had. I also noticed that it doesn’t seem to be updating the host name. Is it possible there is some kind of communication error? I’ve always been able to have them join AD with the tool in FOG, so doing that in the sysprep file was never really something I put a lot of thought into.
-
Hi,
just my 50 cent…
check the specific host for its client service options, i can remember a case where a new client was inventorized but for some reason the options for the host specific client options were disabled.Have you ever tried to disable the option to join the domain for a specific host, delete it’s fog client log and shutdown the machine, enable domain joining again and boot the computer, wait some minutes and supply the fog client log.
@andreiv said in Windows 10 EDU 1709 Domain Join Doesn't Work:
Why don’t you join the domain from the sysprep answer file?
https://technet.microsoft.com/en-us/library/cc730845(v=ws.10).aspx
The op is not asking for other ways. Joining domain is one of the fog clients goal and if we have a problem here everyone like to see it solved, no alternatives!
Hail FOG 
Regards X23
-
I will dig into that tomorrow when I am back at it. Worst case I manually join them this time and just keep plugging away at it. The client service options… Do I look for them in a config file on the client or in my web interface of the server? Again I apologize. I have been using FOG for many years and have built and re built many servers over that time, but some of the recent changes have me re-learning the software all over again.
-
@jay-bosworth
For me, doing it from the sysprep answer file seems the “natural” way. After all, it is built into windows. Why use an external tool, when the built-in one works just fine?
I use third party tools only if Microsoft doesn’t offer a good solution.
For example, I ended up using FOG because Microsoft had no tool that would allow me to deploy dual boot machines. But if you need to deploy only Windows, the RIS from Windows server is an excellent tool. -
@x23piracy I understand. I was just offering a possible solution…
-
@Jay-Bosworth you mentioned you’re using sysprep. Did you follow the client instructions for sysprep? We need more information to help solve this issue https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep
. The fact that the client isn’t logging indicates that the client didn’t start. The sysprep mis-configuration is the most likely cause. Regardless, at this point this is likely just an image configuration issue.
@andreiv A quick comment:
Why use an external tool, when the built-in one works just fine?
There are situations where the client is desired over sysprep when joining the domain, such as when you want computers to have the same hostname they have in FOG, and automatically take care of renaming the machine if you change the name in FOG. The client can also deploys software after imaging to help keep images smaller. Now if you’re in an environment where you don’t use the client (no snapins, printer management, hostname, …) then the sysprep unattended file is absolutely the way to go.
TL;DR: The client should be responsible for managing domain bindings if you want to use FOG as a management solution for software, printers, user tracking, and hostname. If you dont want the client, then sysprep unattended work just fine.
-
Yes, I have followed the client directions. It just seems to be these Lenovo’s I am having issues with. Before the sysprep I disabled and stopped the fog service. The setup complete script is in my scripts folder just like I usually do. In my sysprep I have a local account created. After I image I can login with that account and the fog service is running again.
-
@Jay-Bosworth hmmm that is strange then. So its running and not logging? New client logs are appended to the end of the
fog.logfile. -
@jay-bosworth said in Windows 10 EDU 1709 Domain Join Doesn't Work:
Yes, I have followed the client directions. It just seems to be these Lenovo’s I am having issues with. Before the sysprep I disabled and stopped the fog service. The setup complete script is in my scripts folder just like I usually do. In my sysprep I have a local account created. After I image I can login with that account and the fog service is running again.
Hi,
is the service really running? i cant believe that the log stay completely empty, is the fog.log file created?
What your fog service start option? auto or delayed-auto?If auto please try to set it do delayed.
@Joe-Schmitt wasn’t there a race condition with network and service startup?
Regards X23
-
I’ve had it happen where the service appears to be running, but it’s not actually working. I had to re-install the FOG client.
-
I think there might have been an issue where I wasn’t running sysprep fast enough while in audit mode and it was actually joining to the domain before I had a chance to run that like someone mentioned. I am testing that theory right now though. It also appears there may have been a subtle version difference between client version on my images. I will post again when this finished imaging in a couple of minutes.
