Active Directory settings for Groups do not work as expected
-
Server
- FOG Version: 1.4.0 SVN Revision 6069
- OS: CentOS 7
Client
- Service Version: 0.11.12
- OS: Windows 7
Description
When I use a group to apply AD settings to machines, some of the AD settings are remembered, but the OU is not.
If I’m wrong and this is not expected behavior feel free to tell me what I’m doing wrong, but from what I’ve read in the forums this seems to be by design.
Since the other fields are all filled in, but the OU is not, and since a blank value for the OU causes it to use the default, this makes it very easy to accidentally revert the existing OU assigned to machines back to the default value.
Having a blank value be the default, and also having that blank value cause a destructive change is a bad combination.
If the OU cannot be stored for the group for some reason, then there should be an option when applying group settings to keep the previously assigned value rather than replacing it with the default.
The OU is a particularly bad field to have this behavior, as it’s the most likely to be long and complex and hard to remember.
-
I’ve moved this from bugs to feature request as you are correct that this is the intended option. It will display the OU if ALL hosts in the group have the same OU. The principal premise of Groups in FOG is to update en-mass so all hosts in the group match a given element. If you are dealing with groups that don’t have the same element, it would be recommended to use that particular group to update that “non-matching” element.
-
" It will display the OU if ALL hosts in the group have the same OU."
That’s not the behavior I am seeing. The OU is never displayed, even if all the members have the same value. If I create a group, add two machines to it, then assign an OU to the group, I can then check the individual machines, and they do have the OU populated, but the group still shows a blank value.
Since the value is blank, if I then update the group and forget to re-type the OU data, the group members then get reverted back to the default.The combination of reverting to blank and having the blank value destroy existing data is why I considered it a bug, since it’s surprising and unexpected behavior that causes loss of data.
-
@bmercer There is a partial bug here, in that the “all hosts with same should show” was not happening as intended. I have corrected this action of course and it is currently in the working branch. Thanks for reporting.
As for the “blank data destroying prior data” this is again intended. While I understand the worry, the idea of groups does remain the same. If you blank out a field and update, wouldn’t you expect the items to be blanked out? So I have moved it back to bugs for the reason you’ve indicated. The bug being in the display not working as intended. I didn’t notice a problem because I was using the “selector” OU feature (where the OU’s are presented as a select dropdown list with a default selected for me.)
-
@Tom-Elliott
Understood, it’s not what I’d prefer but I see the reasoning.
I’ll submit a feature request.
