I have been looking for an answer to this, and I can’t seem to figure out what my issue is. I recently updated from FOG 1.2.0 to Trunk to get the imaging working on our new Computers. Now that the imaging is working I’m trying to figure out why I can’t get our new images to add themselves to the domain.

I have put the settings in the FOG Settings, Group Settings, and Host Settings with no change no matter where I put the information. I have both the normal password, as well as the Legacy password with FOGCrypt. The FOG Service is running on the image and I have the Hostname Changer enabled.

I don’t know if I’m missing something, or if there is another log I can check for this. This is a Windows 10 Pro image that I’m trying to deploy. Any help would be appreciated. Thanks.

]]>https://forums.fogproject.org/topic/8101/windows-10-domain-issueRSS for NodeSun, 15 Sep 2019 09:55:54 GMTFri, 15 Jul 2016 13:25:24 GMT60I have been looking for an answer to this, and I can’t seem to figure out what my issue is. I recently updated from FOG 1.2.0 to Trunk to get the imaging working on our new Computers. Now that the imaging is working I’m trying to figure out why I can’t get our new images to add themselves to the domain.

I have put the settings in the FOG Settings, Group Settings, and Host Settings with no change no matter where I put the information. I have both the normal password, as well as the Legacy password with FOGCrypt. The FOG Service is running on the image and I have the Hostname Changer enabled.

I don’t know if I’m missing something, or if there is another log I can check for this. This is a Windows 10 Pro image that I’m trying to deploy. Any help would be appreciated. Thanks.

]]>https://forums.fogproject.org/post/73707https://forums.fogproject.org/post/73707Fri, 15 Jul 2016 13:25:24 GMTAre you using the legacy or new client (and if so what version)? The legacy client has poor support for Windows 10.
]]>https://forums.fogproject.org/post/73710https://forums.fogproject.org/post/73710Fri, 15 Jul 2016 13:52:13 GMTI updated from 1.2.0 this week. I’m not currently using the following.

Running Version 8537
SVN Revision: 5892

]]>https://forums.fogproject.org/post/73711https://forums.fogproject.org/post/73711Fri, 15 Jul 2016 13:53:23 GMTThe legacy client does not support Windows 10 domain joining unfortantly.
]]>https://forums.fogproject.org/post/73712https://forums.fogproject.org/post/73712Fri, 15 Jul 2016 13:54:46 GMT@Joe-Schmitt so the version that I’m using at this time does not support Windows 10 domain joining?
]]>https://forums.fogproject.org/post/73713https://forums.fogproject.org/post/73713Fri, 15 Jul 2016 13:56:39 GMTYou have to use the new client that comes with trunk to get windows 10 support.
]]>https://forums.fogproject.org/post/73714https://forums.fogproject.org/post/73714Fri, 15 Jul 2016 13:58:45 GMT@Joe-Schmitt I did update to trunk. The version that I’m running right now has the option for a Windows 10 image. I’m able to capture and deploy a Windows 10 image using those settings. I just can’t get it to join the domain.
]]>https://forums.fogproject.org/post/73715https://forums.fogproject.org/post/73715Fri, 15 Jul 2016 14:00:14 GMT@Towndrunk I feel a need to clarify.

Windows 10 and Legacy Client will not work automatically, but it can work.

You don’t need anything else installed/enabled in RSAT for Domain joining to work on Windows 10 with the legacy client. However, I would not recommend using this as a means as it does enable the system to have relatively easy enabled access to actually look at and manage your Domain Controller from any system in your environment that has received this image. It will work, but it’s just easier to switch to the new client.

]]>https://forums.fogproject.org/post/73716https://forums.fogproject.org/post/73716Fri, 15 Jul 2016 14:03:37 GMT@Towndrunk The client is not FOG itself. The client is a separate file that you must install on the system images. FOG’s GUI having “Windows 10” in the list is only relevant to the image it’s referencing, it has nothing to do with the FOG Client software.
]]>https://forums.fogproject.org/post/73717https://forums.fogproject.org/post/73717Fri, 15 Jul 2016 14:04:22 GMT@Tom-Elliott@Towndrunk OR install the new client on your image.https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#The_Different_Installers

There are two different clients. Legacy client and new client. You need the new client.

Updating to trunk does not mean all your images have the new client. Your images remain unchanged, in fact. You have to update them. Remove the old client, install the new client, re-capture and everything will work.

]]>https://forums.fogproject.org/post/73720https://forums.fogproject.org/post/73720Fri, 15 Jul 2016 14:21:41 GMT@Tom-Elliott OK, I think I understand. Once I updated to Trunk, I went to “Service Configuration” and under “Client Management” and installed the new client from there before I made a new image. Looking at both the PC I made captured the image from, and the PC I deployed it to, they are both running FOG Service v 0.11.3

Is that the Client that you are talking about?

]]>https://forums.fogproject.org/post/73723https://forums.fogproject.org/post/73723Fri, 15 Jul 2016 14:28:09 GMTPlease upload the fog.log from one of your problem hosts here. (Usually c:\fog.log).
]]>https://forums.fogproject.org/post/73731https://forums.fogproject.org/post/73731Fri, 15 Jul 2016 15:12:22 GMT@Joe-Schmitt This is the log file from a PC that I just tried to deploy to. Windows 10 works fine, but not on the domain like in the past with Windows 7. I’m sure I have something wrong. I see the following in the log, but from that same PC right now I can reach the DC. Not sure what I have wrong.

It sounds like it just can’t find your domain so it cannot connect to the domain.

]]>https://forums.fogproject.org/post/73741https://forums.fogproject.org/post/73741Fri, 15 Jul 2016 15:44:58 GMT@Tom-Elliott I wasn’t sure if that had something to do with the settings or something else. Once the PC boots after the image is deployed, and I log in, I can add it to the domain manually with the same credentials/information I entered into FOG.
]]>https://forums.fogproject.org/post/73754https://forums.fogproject.org/post/73754Fri, 15 Jul 2016 16:58:02 GMT@Towndrunk In the AD settings in FOG, are you using the FQDN or a sloppy name?
]]>https://forums.fogproject.org/post/73756https://forums.fogproject.org/post/73756Fri, 15 Jul 2016 16:59:57 GMT@Wayne-Workman I’m using the FQDN, Ottawacc.local I have tried it both ways, and in all three locations. . . Settings, Group, and Host settings.
]]>https://forums.fogproject.org/post/73758https://forums.fogproject.org/post/73758Fri, 15 Jul 2016 17:09:58 GMT@Towndrunk Try loosing the .local part.
]]>https://forums.fogproject.org/post/73759https://forums.fogproject.org/post/73759Fri, 15 Jul 2016 17:10:34 GMT@Wayne-Workman I will try it again now, with just Ottawacc. Is there one setting that overrides the other? If I am going to use this for every computer, would it be best to put it in the FOG Settings, or the Group Settings?
]]>https://forums.fogproject.org/post/73760https://forums.fogproject.org/post/73760Fri, 15 Jul 2016 17:13:03 GMT@Towndrunk said in Windows 10 Domain Issue:

Is there one setting that overrides the other?

Not sure what you’re referring to.

If I am going to use this for every computer, would it be best to put it in the FOG Settings, or the Group Settings?

First in FOG Settings, then use groups to apply the defaults. When it’s in FOG Settings, inside groups when you check the join domain checkbox - and the fields are already cleared - it’ll populate with the defaults you have in FOG Settings.

Also - just putting these things in FOG Settings ONLY will not automatically change settings on hosts. You have to tell fog to do this. This allows FOG to manage domain joining settings on a per-host basis. At my work, we have one fog server that joins computers to 2 different domains.

]]>https://forums.fogproject.org/post/73761https://forums.fogproject.org/post/73761Fri, 15 Jul 2016 17:16:15 GMTI 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.
]]>https://forums.fogproject.org/post/73762https://forums.fogproject.org/post/73762Fri, 15 Jul 2016 17:33:41 GMT@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.

]]>https://forums.fogproject.org/post/73765https://forums.fogproject.org/post/73765Fri, 15 Jul 2016 18:06:03 GMT@fry_p I wouldn’t call it a work around. This is how it’s done in fog. You set AD settings per-host or with groups.
]]>https://forums.fogproject.org/post/73779https://forums.fogproject.org/post/73779Fri, 15 Jul 2016 18:29:58 GMT@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.
]]>https://forums.fogproject.org/post/73780https://forums.fogproject.org/post/73780Fri, 15 Jul 2016 18:37:33 GMT@fry_p Our big fog system manages computers that are on different domains. If the global defaults automatically cascaded to all hosts - we’d stop using the FOG Client and FOG for domain joining - because it’d cause a complete disaster. It’d probably upset enough people that we might even stop using fog altogether.

]]>https://forums.fogproject.org/post/73782https://forums.fogproject.org/post/73782Fri, 15 Jul 2016 19:11:25 GMTThe way groups work is not a simple feat. The ideology of Groups are indeed overly simplistic, but that simplicity is one of the more powerful aspects, I think, of FOG.

A host is not refined to a single group. The ideology of what groups in fog does is basically a simpler means to associate a common configuration to all hosts within that group. This means you don’t (or shouldn’t) have to make those associations to all hosts in a “one at a time” kind of layout. This is where the “simplicity” of group’s come in.

However, the more complex bits of groups is that you can associate a specific set of things to all hosts and “cascade” through different groups only affecting the hosts within that group.

Why is this useful? As @Wayne-Workman said, the whole ideology of FOG is to be highly configurable to your needs. Is it perfect, not by any means, but this does mean you can associate Host settings (Kernel, KernelArgs, Boot types, etc…) dependent on the group you’re updating.

The way settings get displayed into groups is based on the basis that ALL hosts of that group have the exact same setting. This is on a per group element. For example, the kernel field will only display the kernel assigned (though I suppose I could add it to the group table as well) so long as all hosts in the group have the same kernel defined. Same for image association, kernel args, service settings, and active directory.

This means if you see a “blank field” it could be one of two states, either all hosts don’t have a setting for this field, or all hosts are not defined with the same information for that relevant field. This is intentional though. If we made all groups make changes to a host when they entered, at which group (when a host is assigned to multiple groups) should the host use it’s information?

Multigroup hosts is nice in that you can define a common setting for all hosts in one group, and apply another group layout of settings to all hosts in the other, while the “same hosts in both groups” group applies only the new information to the host.

For example, in a school you have Students and Teachers. In the labs, you may likely have a teacher system and the student systems.

If you have all clients of the lab in the same “lab” group and make changes, and you have the teacher in another group and just need to add a printer, you can do so without much trouble.

Yes you could still perform this same effect with a prewritten setting, but in the case of Active directory, (let’s just say your two labs are to two different domains) which group should be the one your client decides to use?

I’m sure I could go on for days, but I think this/these answers should suffice.

Yes, you can get the group to show the common settings so you’re aware, but you can also achieve what you’re looking for thanks to @george1421.

I don’t plan on adding this, but the beauty of the trigger that george created is that it is not needed for EVERY group you create, rather it’s a once and done kind of thing. Sure it could use some refinement, but this should achieve what you’re looking for. Again, though, it all depends on how you want to use the group system.