@Tom-Elliott it appears to be exactly the same with the logging enabled.
Just to make sure here are the logging settings i changed:
@Tom-Elliott it appears to be exactly the same with the logging enabled.
Just to make sure here are the logging settings i changed:
@Tom-Elliott I’m forced to cold reboot once it gets stuck every time. I can get to the ipxe menu when there is no active task. If I go to quick image, it gets past init.xz,…OK but goes dark and stays like that.
@Tom-Elliott Unfortunately, no. I tried every file with the .efi extension. It either falls short of init.xz or freezes at the same point
Hey all,
So far 1.3 RC1 is great. I did run into a hiccup just now however. Using the Usb ethernet dongle that I used many times before is unable to get past the init.xz …OK phase of deployment. After it reaches this point, it freezes. I am using ipxe.efi as the bootfile and secure boot is off. I have the HAS_USB_NIC=1 argument. Really, nothing has changed besides the update to RC1 since the last Surface was imaged. I currently don’t have an EFI exit type set because frankly, I’m ignorant to what that means. That could be a factor(?)
Thanks!
Paul
Installing as we speak. Well done! Though I recently joined the active community for this project, I’ve been using FOG since the 0.29 days and am amazed to see where the project is now. It’s come a long way to say the least. You take tools like this for granted when you are forced to do it the old fashioned way. I (briefly) worked IT at a factory that refused to implement any imaging solution. Each PC was built from OEM Windows from scratch. It sucked.
I’m glad to be back using my favorite open source project out there. Though most things we use at my job are proprietary, the support for FOG far surpasses any paid software. I can literally post on the forums and hear from a moderator, developer, or the legendary Tom Elliott himself within the hour. Even early in the morning!
I’m already thinking in the future, but I must ask, will the trunk style of updating disappear once the final revision of 1.3 is out? It would be bittersweet to lose that. On one hand you have the obligatory bugs that come with any testing, but being on the cutting edge of a growing project is actually pretty cool.
But I digress, keep up the good work guys and kudos for the dedication to the project. I look forward to the 1.3 release party
@Wayne-Workman Then what is the point of having the defaults set? I have entered the AD defaults into fog configuration and have hostname changer enabled globally, should it not propagate to all hosts? When I then went to a host, the box is checked for domain join, but as @Towndrunk said, the AD info is blank until you uncheck then recheck. It’s not an issue any more for me though, just confused is all.
@Towndrunk said in Windows 10 Domain Issue:
I think I found the issue. I had the settings in the Default FOG Settings, and had the “Join Domain after image task” checked in the Group, but there was no information in the settings. I unchecked it, and checked it again, and it populated with the data from the FOG Settings. It is now working like it should. Using Ottawacc.local. Thanks for the help.
@Tom-Elliott , just a heads up, remember I had that same issue in the past with the same workaround? Since I did my batch adding all hosts to one group to check and uncheck the join box, I haven’t had any issues.
Thanks everybody for your thoughts. We rely heavily on the Google Admin Console, so I think we are going to do it the old fashioned way for now. We will also pay for the White Glove on them for the time being. I did hear about an interesting method for automation of the registration to google console and wifi. There are USB devices called “rubber ducky” sticks. They are keystroke injectors that if used for the powers of good, can help you. Theoretically, once you capture the desired clicks and keys, you can plug it into chromebooks and the process will be replicated. They run for about 50 bucks a piece, so we may get 5 or so to save white glove money in the future.
Hi @GFm
I had the same issue in the past. The reason this is happening is that the newer revisions of the FOG client are much more efficient than the legacy client. It is basically kicking in too early. The way to fix this is to disable the service before you sysprep it pre-capture (best practice for the FOG Client). You then use the setupcomplete.cmd method shown in this Wiki Article:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep
You are basically telling it to re-enable and start the FOG service after sysprep is finished.
Not really a feature request, more of a probing question. Can someone describe any and all capabilities FOG has with Chromebooks if any? This could be construed as a stupid question, but like I said, just probing. The reason I ask is our district is moving to more Chromebooks for students (eventually a 1 to 1 program). I know and trust FOG and it would be great if there was a way to automatically register them with our network and Google Console. I know FOG has been embraced by school districts as the largest demographic, and the climate at both districts I have worked at has been that Google is the future. GAFE, chromebooks, chrome bases, etc. Feel free to be blunt with me, if this isn’t the direction FOG is going, no love lost. We will still have plenty of PC’s in our district for the foreseeable future.
Thanks!
Paul
@Tom-Elliott I don’t know what happened, but due to another issue, I updated to 8440 and the new host joined with no issue. So adding all of the existing hosts to a group and applying AD changes to them took care of those, and the patch to 8440 seems to have changed something that was keeping my defaults from populating on new hosts. Thanks!
@Tom-Elliott They seem to. I spot checked some random hosts and it seems to all be populated. So that should take care of that part of the problem. I am registering and imaging a new host right now to see what it does.
@Tom-Elliott I just added everything to a group (1700 or so hosts) and checked the box for AD. I hope this will fix existing hosts, but FYI this is what I see after I hit “Update”
It populates when I hit the tick box, but as soon as it reloads, everything is gone.
@Tom-Elliott said in Issues with Automatic Domain Join and name change:
This happens every time you register?
Yes sir. New hosts and old hosts that re-image both have this issue.
Hello all,
I am having some strange issues that have appeared recently. I am running 8413 with client 11.2. This issue is also hard to describe so bear with me. From what I gather, this is happening to newly registered and re-imaged existing hosts. When I register new hosts, I go through full registration and choose “y” for domain join. They image and come out of sysprep and sit. It looks like it checks in fine and does not receive all of the info and credentials from the server
------------------------------------------------------------------------------
--------------------------------HostnameChanger-------------------------------
------------------------------------------------------------------------------
7/6/2016 6:44 AM Client-Info Client Version: 0.11.2
7/6/2016 6:44 AM Client-Info Client OS: Windows
7/6/2016 6:44 AM Client-Info Server Version: 8413
7/6/2016 6:44 AM Middleware::Response Success
7/6/2016 6:44 AM HostnameChanger Checking Hostname
7/6/2016 6:44 AM HostnameChanger Hostname is correct
7/6/2016 6:44 AM HostnameChanger ERROR: Required ADDom Joining information is missing
So I look at the AD settings on the host in the GUI and see this:
I figured it could be a defaults setting but it appears everything is set properly.
The only workaround I found for this is to either add all of the needed hosts to a group, go to the AD option, uncheck the Join box, recheck the join box (it then populates the missing fields), and hit save (or do the same thing for specific hosts).
Also, under service settings, hostname changer is enabled and set to default.
Thanks!
Paul
@Wayne-Workman I realize it is important, but I got burned by updating quickly before. I had to recreate most of my images due to the constant failing of sysprep due to the service. I know the setupcomplete.cmd method was already best practice (I was unaware of this at the time), but 10.6 made it mandatory. I’d like to have some control over it.
@Wayne-Workman I had it as well. Luckily it only affected one image for me. I was able to boot into a live CD of Puppy linux and delete it from there. Exact same situation though, 10.6 to 11.2. This could have been bad if it was all of my images. That would be over 500 PC’s to correct… I also am wondering why it is updating automatically still. I have my global client updater setting disabled, but on all of my hosts under service configuration, it is checked and grayed out.
@Tom-Elliott said in 8062 and 8064 Fail to mount /dev/nvme0n1p1:
Just guessing but this one can be solved?
Sorry, yes it can be solved. Nothing to do with FOG i think. I borked partitions somehow is all.
@Quazz Not inconvenient at all, I’m already deploying that image to other Surface Pro 4’s! They seem to be working. I’ll let you know if any fail. It’s weird that I had to do what I did because I started from scratch the exact same way I did for any other win 10 image.
@george1421 I think I got it. It wasn’t a problem with FOG at all. You are correct, I wanted to upload a non-sysprepped image as a fail safe just in case I screwed anything up during sysprep. I got pretty deep in the matrix trying to look at partitions and such. Now I don’t know much about that kind of stuff, but gdisk found overlapping partitions and I deleted the second. I booted into windows and it did a quick checkdisk and successfully booted. I rebooted a few times to check the stability and it seems good. I was able to upload after that. I did debug again just in case and it barked at me for a few partition things, but went through. BTW secure boot is disabled.